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

asked 2018-07-14 03:37:50 +0000

gily
1 ●2

updated 2018-07-14 03:38:25 +0000

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

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2018-07-14 07:56:28 +0000

mrEEde
4033 ●16 ●48 ●77

updated 2018-07-16 13:47:28 +0000

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.

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

edit flag offensive delete link

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 ( 2018-07-16 04:46:22 +0000 )edit

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 ( 2018-07-17 08:39:51 +0000 )edit

add a comment

answered 2018-07-15 08:46:41 +0000

Eddi

2379 ●8 ●48 ●59

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.

edit flag offensive delete link

Comments

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

gily ( 2018-07-16 04:48:04 +0000 )edit

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 ( 2018-07-16 09:57:31 +0000 )edit

add a comment