[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Re-Transmission from PC is ignored due to sequence numb
Re: [lwip-users] Re-Transmission from PC is ignored due to sequence number
Mon, 23 Apr 2018 13:19:27 -0400
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
On 4/23/2018 11:49 AM, address@hidden wrote:
On 23.04.2018 17:18, Patrick Klos wrote:
Thinking about the retransmission from PC side:
Shouldn't lwip also do a retransmission of the lost frame?
You know, these bytes never get acknowledged by PC.
Yes, the LwIP side should have retransmitted the packet. Packet 21 of
the trace file shows an ACK of 00009b45, so even though the LwIP device
thought it sent a response to the PC (bumping the ACK to 00009b56), LwIP
should have noticed that and resent the data from the previous packet.
On what basis do you say that? Retransmissions are triggered mainly in
a) timeout (this did not happen here)
b) dup-acks: a fast retansmission is done if 2 duplicate acks are
receiver (i.e. three times the same ACK). This is not the case here,
we just received the 2nd ACK.
I'm still saying lwIP is correct.
I'm not saying LwIP is incorrect, per se. But the overall behavior
being exhibited is not correct. Sooner or later, a retransmission
should occur by the embedded system with the missing data. More context
needs to be provided to know for sure.
Maybe the embedded system in question broke something in the stack? Or
had a problem transmitting the packet?
Clearly, LwIP thinks it sent the response to the MODBUS request (even
though it didn't seem to show up at the PC). Until we know what
happened to that packet, we're just guessing.
It's been a while since I read RFC793, so I don't know if the bare ACK
in packet 22 should include the unacknowledged sequence number or the
acknowledged sequence number? Still, I'd look at the hardware (and
possibly critical sections) before I'd look at LwIP.