This is our old Q&A Site. Please post any new questions and answers at

First let me state I an extremely new to networking. My situation is I am using an embedded ARM device with some custom hardware and Ethernet driver chip and a third party TCP-IP stack as well as a third party SMTP client application for that stack. My ultimate goal is just to be able to send emails.

I was experiencing previously odd behavior where connecting to a '' email server and sending emails to myself would work sometime and not others.

I started my search by forgetting SMTP and just issuing a TCP connect sequence with the mail server. I saw similar behavior where it would work fine once but after resetting my embedded device I started getting lots of TCP retransmissions and out of orders warnings and other oddities.

I setup hMailServer on my laptop to take '' out of the equation but proceeded to get the same TCP re-transmissions and out of orders warnings and even some duplicate ACKs.

The device always connects to the server but it just seems to me that for a hardwired connection all on my desk I should be experiencing 0 re-transmissions or other oddities. But is it possible that having a slow (<50MHz) ARM processor could be the cause of those re-transmissions etc when connected to a much faster server and much faster internet in general?

Here is the condensed log from wireshark:

asked 30 Apr '14, 14:45

wes000000's gravatar image

accept rate: 0%

I don't think that these are real re-transmissions but just traced twice. Looking at the delta times of the suspected packets - they 'retransmissions' occur in the same ms.

  • 166,167 is the SYN_ACK occuring 15.777 seconds into the trace (note the slightly different size)
  • 170,171 is the SMTP Welcome message occuring 15.933
  • 615,616 is an ACK to the client's FIN occuring 55.239 into the trace

I suggest yo look at the of those packets to verify whether it's the same packet traced twice or a real re-transmission

permanent link

answered 01 May '14, 00:50

mrEEde's gravatar image

accept rate: 20%

200ms delay between two packets is way too slow for duplicates, they usually have a delta of only a couple of microseconds. But without a capture and a description of the capture setup it can't be completely ignored as an option.

(01 May '14, 06:35) Jasper ♦♦

I guess your ARM processor might be too slow when talking to your mailserver. If you look at packet 170 you see that the mail server sends "S: 220 WESLEY-LAPTOP ESMTP" to the client", but there is no acknowledge or answer coming back. I guess this triggers a retransmission after 200ms in packet 171, because the server assumes the packet 170 got lost since it didn't get acknowledged. The only reason I can think of in a network as small and simple as the one you're describing is that the client is having trouble answering in time.

The same happens again in packets 1086 and 1087, again with over 200ms delta.

So again, my money is on the ARM processor being too slow (or the code not fast enough, however you want to look at it :-))

permanent link

answered 30 Apr '14, 16:54

Jasper's gravatar image

Jasper ♦♦
accept rate: 18%

As @mrEEde indicated, there are duplicate frames in the capture file coming from (the SMTP server). I don't think they are re-transmissions. I believe they are just duplicates due to the way the capture file was taken (probably on the SMTP server itself or on a mirror port of the switch duplicating the server traffic).

I believe the capture file was taken on the server, because of the duplicate frames 125,126. Frame 125 was captured before padding (on the server), frame 126 was captured after padding.

125 12.636354000 Pegatron_ad:34:d3 1e:30:6c:a2:45:5c ARP 42 is at 4c:72:b9:ad:34:d3 126 12.636598000 Pegatron_ad:34:d3 1e:30:6c:a2:45:5c ARP 60 is at 4c:72:b9:ad:34:d3

So, those duplicate frames are not going to cause a problem on the embedded device, because there are no duplicates (re-transmission) on the wire.

After you remove the duplicate frames, you'll get this:

162 15.690765000 TCP 60 1024 > smtp [SYN] Seq=0 Win=4380 Len=0 MSS=1460 166 15.777702000 TCP 58 smtp > 1024 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 169 15.931764000 TCP 60 1024 > smtp [ACK] Seq=1 Ack=1 Win=4380 Len=0 170 15.933402000 SMTP 79 S: 220 WESLEY-LAPTOP ESMTP 173 16.076656000 TCP 60 1024 > smtp [ACK] Seq=1 Ack=26 Win=4380 Len=0 614 55.239381000 TCP 60 1024 > smtp [FIN, ACK] Seq=1 Ack=26 Win=4380 Len=0

Everything is well until frame 173, where the client ACKs frame 170. But then, the server does not answer, which makes the client close the connection in frame 614.

The same thing happens in the second attempt.

So, currently everything points into the direction of the SMTP server. Maybe there is something in frame 173, that the server does not like, but we cannot see in the text output - like checksum errors, or the client ACKs the wrong number of bytes, etc., which in effect would make the embedded device the guilty party. Otherwise, it's the SMTP server (software, OS, security software on the systems, etc.).

According to the hint of @mrEEde, the client should send the HELO/EHLO after it received frame 170. However, it does not. It simply ACKs the data in frame 173 and then closes the connection in frame 614. So, the problem is (probably) within the SMTP library of the embedded devices or the software that uses the SMTP library.

We would need the real capture file to analyze that. If possible, please post the pcap file instead of a text file.

There isn't much we can analyze in the capture file. The best thing is to enable debugging on the embedded device or check the software logic if possible.


permanent link

answered 01 May '14, 16:56

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
accept rate: 15%

edited 02 May '14, 00:47

the capture file was generated using the same computer the server is running on. Is that bad practice generally? And I will post the pcap file next week (sorry for the delay) but the computer with the server on it as well as my ARM device is unavailable until then.

(01 May '14, 20:14) wes000000

"Everything is well until frame 173, where the client ACKs frame 170. But then, the server does not answer, which makes the client close the connection in frame 614." Wouldn't the next expected packet be the client's HELO packet?

(01 May '14, 23:04) mrEEde

Wouldn't the next expected packet be the client's HELO packet?

Ah, sure. It was very late when I answered the question. Thanks for the hint.

So, yes the client should send the HELO. As a result, it's a problem with the embedded smtp client, instead of the server as I said in my answer. Sorry for the confusion.

(02 May '14, 00:36) Kurt Knochner ♦

Is that bad practice generally?

Not in general. Sometimes there is no other option than to capture on one of the involved systems. But sometimes you'll get false results, as in your case. We have had similar problems in other questions. Duplicate frames when captured on the server, but there was no common reason observable (yet). Could be a driver issue or some software on the capturing system (VPN, Firewall, IDS/IPS, Endpoint Security, etc.).

Anyway, please see the very good comment of @mrEEde and my comment above. The problem is most likely not the server, but the client, because it does not send the HELO/EHLO.

(02 May '14, 00:41) Kurt Knochner ♦

Thank you guys for all the help! We are currently in the process of debugging and working with the client software and are in communication with the support team responsible for the third party smtp client and stack. Thanks again!

(03 May '14, 17:19) wes000000
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 30 Apr '14, 14:45

question was seen: 3,481 times

last updated: 03 May '14, 17:19

p​o​w​e​r​e​d by O​S​Q​A