LWIP not ACKing data in retransmissions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

LWIP not ACKing data in retransmissions

Fabian Koch-2

Hey all,

 

we have a weird behavior of one of our devices and I wonder if anyone could provide any pointers as to what is going on.

(pcap attached)

 

Scenario:

  • Our device is 172.22.66.200 in this capture
  • Other device is 172.22.67.200
  • Pcap contains only one TCP stream between the two
  • We are using the socket API on top of LWIP 1.4.1

 

Good behavior:

  • In #9, the peer sends a retransmission because our device didn’t answer for 240ms
  • In #10, we ACK that retransmission with no payload and everything looks fine

 

Weird behavior:

  • In #92 there is another retransmission by the peer after 527ms and we even take another 478ms to answer
  • #93 ACKs the retransmission but does not increase the ACK number to include the payload of the retransmission
  • So that retransmission is sent again and again (exponential back-off) but the payload is never ACKed
  • Meanwhile our device happily sends payloads and the gateway ACKs them

 

What is happening here?

 

Kind regards

Fabian


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

LWIP_retrans_ACK.pcapng (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: LWIP not ACKing data in retransmissions

goldsimon@gmx.de
Hi Fabian,

sorry for taking so long to answer...

Am 12.04.2019 um 14:59 schrieb Fabian Koch:

> Hey all,
>
> we have a weird behavior of one of our devices and I wonder if anyone
> could provide any pointers as to what is going on.
>
> (pcap attached)
>
> Scenario:
>
>   * Our device is 172.22.66.200 in this capture
>   * Other device is 172.22.67.200
>   * Pcap contains only one TCP stream between the two
>   * We are using the socket API on top of LWIP 1.4.1

Yes, 1.4.1 is bad ;-)
But this shouldn't be the issue here...

>
> Good behavior:
>
>   * In #9, the peer sends a retransmission because our device didn’t
>     answer for 240ms
>   * In #10, we ACK that retransmission with no payload and everything
>     looks fine
>
> Weird behavior:
>
>   * In #92 there is another retransmission by the peer after 527ms and
>     we even take another 478ms to answer
>   * #93 ACKs the retransmission but does not increase the ACK number to
>     include the payload of the retransmission
>   * So that retransmission is sent again and again (exponential
>     back-off) but the payload is never ACKed
>   * Meanwhile our device happily sends payloads and the gateway ACKs them
>
> What is happening here?

Hmm, that's hard to tell. What's funny is that after #92, your device
does not send empty ACKs any more as it would when receiving new data.
So it seems like the device just does not receive all the
retransmissions from the other device. A pcap does not really help here,
you need to debug your target (e.g. dump lwIP error counters, or even
make a LED blink on RX).

Without knowing the driver, it's even more wild guessing: maybe
interrupts stop working (no RX) and TX doesn't need interrupts...

What kind of hardware/driver is this?

Regards,
Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users