First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

Outlook sending attachment fail with error 0x800CCC0F, server send rst,ack to client.

  • retag add tags

My outlook sending plain txt mail is ok, while sending with attached even very small size 80KB, it's getting error 0x800CCC0F, and sending failed, If use web mail instead of outlook cleint it's success. Trying to fix it in many ways googled but no help. Other laptop connecting to same AP is working fine, till now only 3 laptops getting the issue. It's win10 and i reinstalled outlook/OS, no use. Captured the pcap at mail server side, found the server send rst,ack to client (166.78.79.129 to 172.16.2.87), before that there are many "Reassembly error" Any one can help to analyse it how it happened? Thanks in advance.

image description

image description

gily's avatar
1
gily
asked 2018-07-14 03:37:50 +0000, updated 2018-07-14 03:38:25 +0000
edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

2 Answers

0

Please read this posting at the Micorosft Community

Matthias has already determined that the RESET is injected into the TCP stream. An antivirus program could definitely do this.

It is possible, that some type of malware is adding or manipulating attachments. This could also be a false positive in your AV program.

If indeed your anti virus is responsible you should see a message in the AV log.

Eddi's avatar
2.4k
Eddi
answered 2018-07-15 08:46:41 +0000
edit flag offensive 0 remove flag delete link
more

Comments

thanks, Eddi, actually we had disabled the laptop Antivirus and Firewall but problem still.

gily's avatar gily (2018-07-16 04:48:04 +0000) edit
more
  • delete

Hi Throb

I just looked at the trace file.

This event involves 2 IP addresses and presumably 3 devices:

  • The Workstation 172.16.2.87
  • The Exchange server 166.78.79.129
  • Another device (firewall? IPS? Load balancer?) sending packets with source ip 166.78.79.129

The interesting part is the TTL field in the IP header. Locate any IP header in the trace, then right-click on the TTL field and select "Apply as column". You should now see a new column with the TTL for each IP header.

Next apply the display filter 

ip.src==166.78.79.129

You will notice, that the majority of packets has a TTL of 242. Only SYN-ACK and the packets with a RESET flag use a TTL of 241.

Since the TTL is one lower than the host I suspect an active network device that is inspecting the TCP session. Please ... (more)

Eddi's avatar Eddi (2018-07-16 09:57:31 +0000) edit
more
  • delete
add a comment see more comments
0

First off I don't think this capture was taken at the server side as there are other conversations to/from the client at 172.16.2.87
image description
Secondly I don't think that the reset packets are really coming from the "server" but from some device in the middle.
image description
The server ACKs segments after the ACK numbers in the RST packets!
The ip.ttl and ip.id of those packets will give you more clues whether this is true.
Uploading your capture would certainly help giving a better answer .
Regards Matthias

Update
The capture filtered on tcp.port==49470 actually show that the RST packets arrive with a TTL of 241 whereas the other packets arrive with a TTL of 235/236. An indication that another device (LB ? ) is sending the RST packets.

I believe this is/may be caused by an invalid Selective Acknowledgement where the 'server' asks for 3760 and the SACK left edge indicates 801 was successfully received.

(tcp.options.sack_le == 801 or tcp.flags&4)

As the LB/Server are probably not in your scope to fix I would recommend you disable the SACK option and see if this gets you through.

image description

mrEEde's avatar
4k
mrEEde
answered 2018-07-14 07:56:28 +0000, updated 2018-07-16 13:47:28 +0000
edit flag offensive 0 remove flag delete link
more

Comments

Thanks Matthias, you're right, the file captured on client (win10) side. You can watch or download the file on cloudshark.pcap file

gily's avatar gily (2018-07-16 04:46:22 +0000) edit
more
  • delete

Really appreciate your analysis, i will try to find a way to disable SACK on windows 10. btw, how the invalid SACK generated? As in this case, the SLE=801 and ACK=3760.

gily's avatar gily (2018-07-17 08:39:51 +0000) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer