|
| From: | Paul Butler |
| Subject: | [lwip-users] Dropped Packets on PC receiver with lwip 1.1.0 Transmitter |
| Date: | Wed, 28 Mar 2007 19:36:27 -0500 |
|
All,
It appears many of my earlier problems were due to
ADI using version 1.1.0 for the basis of their port (not 0.6.3 as I previously
indicated), which had a problem with the Nagle algorithm. They appear to
have corrected that in their port, and my problems regarding throughput have
diminished greatly. I can now get the network utilization reported by
windows XP up to around 80% and can sustain that data rate pretty
reliably.
However, I am still having a problem where the
receiver appears to drop perfectly valid data (as seen by ethereal), failing to
generate an ACK. Honestly, it appears as if the receiving socket has
closed itself but does not issue a FIN or RST to indicate this. Is it
possible for a receiving socket (utilizing winsock2 on windows XP) to simply
stop responding to data reported by ethereal? Can anyone offer any insight
into what could be happening here? Keep in mind my high bandwidth
utilization, can that be causing any problems? This problem appears to be
aggravated when DHCP is used, although again ethereal does not show anything
problematic.
I have also run an experiment using a PC instead of
lwip to generate the data, and there the utilization is 99% sustained, and does
not appear to have these issues with ignored packets. Looking at the log,
I noticed that very few packets from the PC have the PSH bit set, where every
packet from lwip has PSH set. Is this intentional? Could it be
related to my problems?
If someone can tell me the trick to posting a file
to the list I can send some logs of this problem. I have pasted the
summary lines from one log file below. 37 is the lwip device transmitting
data, 36 is the PC receiving data. The listening socket is on the lwip
device. You can see after a series of successful transmits and
acknowledgements, the retransmission in segment 151 appears to be ignored, as
was the initial transmission of the sequence in segment 150. I'm open to
any suggestions at this point that would allow data received by ethereal to not
cause an acknowledgement back to the sender.
Thanks,
Paul
------------------------------
No.
Time
Source
Destination Protocol
Info
121 3.399910
192.168.16.37
192.168.16.36
TCP 7010 > 7010 [PSH, ACK] Seq=100741 Ack=1
Win=8192 Len=1460
122 3.400067 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=102201 Ack=1 Win=8192 Len=1460 123 3.400095 192.168.16.36 192.168.16.37 TCP 7010 > 7010 [ACK] Seq=1 Ack=103661 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 124 3.400266 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=103661 Ack=1 Win=8192 Len=1460 125 3.400409 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=105121 Ack=1 Win=8192 Len=1460 126 3.400435 192.168.16.36 192.168.16.37 TCP 7010 > 7010 [ACK] Seq=1 Ack=106581 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 127 3.400573 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=106581 Ack=1 Win=8192 Len=1460 128 3.400702 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=108041 Ack=1 Win=8192 Len=1460 129 3.400725 192.168.16.36 192.168.16.37 TCP 7010 > 7010 [ACK] Seq=1 Ack=109501 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 130 3.400874 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=109501 Ack=1 Win=8192 Len=1460 131 3.401012 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=110961 Ack=1 Win=8192 Len=1460 132 3.401036 192.168.16.36 192.168.16.37 TCP 7010 > 7010 [ACK] Seq=1 Ack=112421 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 133 3.401185 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=112421 Ack=1 Win=8192 Len=1460 134 3.401309 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=113881 Ack=1 Win=8192 Len=1460 135 3.401487 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=115341 Ack=1 Win=8192 Len=1460 136 3.401525 192.168.16.36 192.168.16.37 TCP [TCP Dup ACK 132#1] 7010 > 7010 [ACK] Seq=1 Ack=112421 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 137 3.401608 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=116801 Ack=1 Win=8192 Len=1460 138 3.401622 192.168.16.36 192.168.16.37 TCP [TCP Dup ACK 132#2] 7010 > 7010 [ACK] Seq=1 Ack=112421 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 139 3.401934 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=118261 Ack=1 Win=8192 Len=1460 140 3.401945 192.168.16.36 192.168.16.37 TCP [TCP Dup ACK 132#3] 7010 > 7010 [ACK] Seq=1 Ack=112421 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 141 3.402061 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=119721 Ack=1 Win=8192 Len=1460 142 3.402075 192.168.16.36 192.168.16.37 TCP [TCP Dup ACK 132#4] 7010 > 7010 [ACK] Seq=1 Ack=112421 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 143 3.402188 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=121181 Ack=1 Win=8192 Len=1460 144 3.402200 192.168.16.36 192.168.16.37 TCP [TCP Dup ACK 132#5] 7010 > 7010 [ACK] Seq=1 Ack=112421 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 145 3.402354 192.168.16.37 192.168.16.36 TCP [TCP Fast Retransmission] 7010 > 7010 [PSH, ACK] Seq=112421 Ack=1 Win=8192 Len=1460 146 3.402612 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=122641 Ack=1 Win=8192 Len=1460 147 3.402640 192.168.16.36 192.168.16.37 TCP 7010 > 7010 [ACK] Seq=1 Ack=113881 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 148 4.756081 192.168.16.37 192.168.16.36 TCP [TCP Retransmission] 7010 > 7010 [PSH, ACK] Seq=113881 Ack=1 Win=8192 Len=1460 149 4.756213 192.168.16.36 192.168.16.37 TCP 7010 > 7010 [ACK] Seq=1 Ack=124101 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 150 4.756758 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [PSH, ACK] Seq=124101 Ack=1 Win=8192 Len=1460 151 6.256042 192.168.16.37 192.168.16.36 TCP [TCP Retransmission] 7010 > 7010 [PSH, ACK] Seq=124101 Ack=1 Win=8192 Len=1460 152 8.063536 Dell_ea:aa:9e Broadcast ARP Who has 192.168.16.200? Tell 192.168.16.2 153 9.255802 192.168.16.37 192.168.16.36 TCP [TCP Retransmission] 7010 > 7010 [PSH, ACK] Seq=124101 Ack=1 Win=8192 Len=1460 154 12.976243 Dell_ea:aa:9e Broadcast ARP Who has 192.168.16.23? Tell 192.168.16.2 155 15.256433 192.168.16.37 192.168.16.36 TCP [TCP Retransmission] 7010 > 7010 [PSH, ACK] Seq=124101 Ack=1 Win=8192 Len=1460 156 25.543310 Ibm_11:83:a2 Broadcast ARP Who has 192.168.16.22? Tell 192.168.16.32 157 27.255518 192.168.16.37 192.168.16.36 TCP [TCP Retransmission] 7010 > 7010 [PSH, ACK] Seq=124101 Ack=1 Win=8192 Len=1460 158 27.259166 HewlettP_a3:5f:35 CDP/VTP/DTP/PAgP/UDLD CDP Device ID: HP ProCurve Switch 2626(001185-a35f00) Port ID: 11 159 30.020045 Ibm_11:83:a2 Broadcast ARP Who has 192.168.16.40? Tell 192.168.16.32 160 34.756319 192.168.16.36 192.168.16.37 TCP 7010 > 7010 [FIN, ACK] Seq=1 Ack=124101 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 161 34.756501 192.168.16.37 192.168.16.36 TCP 7010 > 7010 [ACK] Seq=125561 Ack=2 Win=8191 Len=0 162 34.786842 Wistron_34:70:ec Broadcast ARP Who has 192.168.16.40? Tell 192.168.16.22 163 38.569883 Dell_ea:aa:9e Broadcast ARP Who has 192.168.16.22? Tell 192.168.16.2 164 51.254659 192.168.16.37 192.168.16.36 TCP [TCP Retransmission] 7010 > 7010 [PSH, ACK] Seq=124101 Ack=2 Win=8191 Len=1460 165 51.254751 192.168.16.36 192.168.16.37 TCP 7010 > 7010 [RST, ACK] Seq=2 Ack=125561 Win=0 Len=0 166 60.526906 HewlettP_a3:5f:00 09:00:09:00:00:67 HP HP Switch Protocol |
| [Prev in Thread] | Current Thread | [Next in Thread] |