Hi,

I am using RTOS and EthernetInterface in order to send data from the MBED to a computer listening on the internet (static IP's).

The problem I'm having is that the mbed does not re-send a lost packet, but instead re-sends the subsequent packet.

I am sending data in chunks less than 1K - I've seen packets with payloads as small as 9 bytes and as large as 794 bytes. However, I send these chunks as fast as possible.

Using wireshark on the listener side, I have seen the following (edited for readability):

(columns are: frame, protocol, packet size, packet summary)

80 TCP  94   49153 > pcs-sf-ui-man [PSH, ACK] Seq=16654 Ack=16 Win=2905 Len=40
81 TCP  54   pcs-sf-ui-man > 49153 [ACK] Seq=16 Ack=16694 Win=48556 Len=0
82 TCP  850  [TCP Previous segment lost] 49153 > pcs-sf-ui-man [PSH, ACK] Seq=16927 Ack=16 Win=2905 Len=796
83 TCP  54   [TCP Dup ACK 81#1] pcs-sf-ui-man > 49153 [ACK] Seq=16 Ack=16694 Win=48556 Len=0
84 TCP  850  [TCP Retransmission] 49153 > pcs-sf-ui-man [PSH, ACK] Seq=16927 Ack=16 Win=2905 Len=796
85 TCP  54   [TCP Dup ACK 81#2] pcs-sf-ui-man > 49153 [ACK] Seq=16 Ack=16694 Win=48556 Len=0

"49153" is the mbed, and "pcs-sf-ui-man" is my listening computer.

Following the Seq and Len values, this can be summarized as follows:

1. mbed sends 40 bytes to computer (frame 80)
2. computer sends ACK of the 40 bytes back to mbed (frame 81)
3. mbed sends 16927-16694 = 233 bytes that is never received by the computer
4. mbed sends 796 bytes to computer (frame 82)
5. computer sends ACK that it's only gotten 16694 so far; i.e. it never received the 233 bytes (frame 83)
6. mbed continues to send duplicate packets containing the 796 bytes, but never the 233
7. computer continues to re-send the ACKs of 16694 (duplicates of frame 81)

The missing 233 bytes come from 3 calls to send_all on the mbed that returned 20, 26 and 187 respectively. After that, a call to send_all on the mbed returned 796 (and became the packet in frame 82).

I'm confused why the mbed never re-sends the packet of lost data.

Any help on this matter is greatly appreciated!

I have published a library that is simplified and reproduces the problem (with my setup, in any case).

The library can be found here:

http://mbed.org/users/uci1/code/testEthIntfTCPSocket/

I use the following python script in order to print the bytes arriving on the other end:

/media/uploads/uci1/testtcptwisted.py.zip

The program sends some fake data from an array of bytes in the mbed's memory. It tries to send the bytes in chunks: first 9 bytes, then 26 bytes, then 711, 40, 432.

When I run the program, I see the problem described in the first post of the thread.

(Note that if the DEBUG switch is enabled, the slow print outs (at 9600 baud) reduce the throughput rate enough that no packets are lost and the problem doesn't occur.)

Any suggestions of where to look for potential problems are more than welcome!!

Thanks.

TCP windowing issue

Thanks, Steve.

I'm reading about TCP windowing and tuning issues.

I don't have experience with this, though. If you have any advice, I'm all ears!

For my application, robustness is more important than transfer speed.

Well, I made a version of the example program that uses NetServicesMin (no rtos) and that works.

I tried copying the TCP options from NetServicesMin over to EthernetInterface (like MEMORY_SIZE being 3000, TCP_MSS being 536, etc) but that didn't seem to help. That probably makes sense, though, since EthernetInterface does re-send packets, it just resends the wrong packet and causes the handshaking to completely stall.

As I can't seem to fix this issue, our project will have to use NetServicesMin...