Re: [lwip-users] Re-Transmission from PC is ignored due to sequence number

[Patrick Klos]

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 
> two ways:
> 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.

Patrick