lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #46467] ip_frag() shouldn't modify pbuf in case of a r


From: Zach Smith
Subject: [lwip-devel] [bug #46467] ip_frag() shouldn't modify pbuf in case of a retransmission
Date: Fri, 18 Mar 2016 22:38:54 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36

Follow-up Comment #7, bug #46467 (project lwip):

Oh, I see that you are right that the seg->p->len/tot_len modifications do
still work if p->payload > tcphdr. They wrap around and work ok for me too. I
don't think I was quite right in identifying the problem before.

When execution reaches ip_frag() I notice that p->payload is pointing at the
IP header. It is then incremented further into the data payload as chunks are
sent out. The len member is modified appropriately (decremented) as chunks are
sent. tot_len is not modified, it is left at the original value. So, at the
end of ip_frag, tot_len does not equal len as they did in the beginning.

So, that right there seems to me to be the problem. tot_len > len and
pbuf->next is null. I can't see that there is anything in tcp_output_segment()
or anywhere else that fixes that. So, when a re-transmission happens we have a
corrupt pbuf. tcp_output_segment() attempts to adjust p->payload to point back
to the tcp header and to adjust p->len and p->tot_len. p->len gets adjusted
correctly because it was modified in ip_frag() relating to the current
position of p->payload. But since p->tot_len is the orignal total length
(including the ip header) the adjustment doesn't work and it ends up still
greater than p->len.

perhaps the fix could be as simple as setting tot_len = len before exiting
ip_frag although that doesn't feel right and may affect other areas. I'm not
sure. And I am not sure how all this would work with chained pbufs ???



Here is how I force this problem to occur (if it helps)

My application that I am running to test this sends packets that are ~1000
bytes. So, I set my mtu to be 700 so it will force ip fragmentation. I also
have to #define TCP_CALCULATE_EFF_SEND_MSS 0 so the MSS is not changed. I then
start my application which starts sending 1000 byte packets. I can see with
Wireshark they are all getting fragmented. Then I put a breakpoint in
tcp_rexmit_rto() and just wait to hit it. It doesn't take very long since I am
on a Wi-Fi link. If on a local Ethernet link re-transmissions are very rare so
one way to force it to happen is in ip_frag() where the netif->output()
function is called do something like this:
if(dbg++ != 35){
        netif->output(netif, rambuf, dest);
}
So when dbg reaches 35 the fragment will simply not be sent and a re-transmit
will occur.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?46467>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]