[lwip-devel] [bug #54117] ICMP echo reply breaks ip_frag under a specific circumstance

[Scott]

URL:
  <http://savannah.nongnu.org/bugs/?54117>

                 Summary: ICMP echo reply breaks ip_frag under a specific
circumstance
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: ciws
            Submitted on: Thu 14 Jun 2018 05:51:12 PM UTC
                Category: IPv4
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: 1.4.1

    _______________________________________________________

Details:

Pinging my stack with a payload greater than 1 packet in length causes the
following ASSERTION:
>> this needs a pbuf in one piece!
>> failed at line  764 in file ipfrag.c

My configuration options:
MTU                             1500
IP_FRAG_USES_STATIC_BUF         0
TCP_MSS                         1460
ETH_PAD_SIZE                    0
MEM_ALIGNMENT                   4

An incoming ping of length 4000 causes ip_frag to generate the following pbuf
chain lengths:
1486, 14, 1466, 14, 1048 => tot_len(4028).

This chain gets passed into icmp_input which, after some tweaking, sends the
chain to ip_output.
ip_output then calls ip_frag which walks the chain and works its magic.

The assertion error happens when ip_frag is presented with the 14 byte pbuf.
Line 764 makes sure p->len >= (IP_HLEN)
IP_HLEN == 20, so the assertion fails.

So the root cause is the fact that the incoming 1500 byte packet got fragged
into a 1486 and 14 byte pbuf chain.

This happens in pbuf.c line 255:
p->len = LWIP_MIN(length, PBUF_POOL_BUFSIZE_ALIGNED -
LWIP_MEM_ALIGN_SIZE(offset));

length = 1514
offset = 16
PBUF_POOL_BUFSIZE_ALIGNED = LWIP_MEM_ALIGN_SIZE(PBUF_POOL_BUFSIZE) = 1516 
(1514 MEM_ALIGNED)
PBUF_POOL_BUFSIZE = LWIP_MEM_ALIGN_SIZE(TCP_MSS+40+PBUF_LINK_HLEN) = 1514
PBUF_LINK_HLEN = (14 + ETH_PAD_SIZE)
LWIP_MIN(1514, 1516 - 16)
p->len = 1500

That leaves 14 bytes for the next pbuf in the chain.

My solution (work around?) was to reduce TCP_MSS from 1460 to 1452, which
resulted in a 22 byte packet fragment which avoids the assertion error.

Is modifying TCP_MSS the "best" answer or...
Could/Should a compiler #error macro be devised to catch this?
Could/Should icmp make sure it is passing "good" pbufs to ip_frag?
Could/Should ip_frag handle pbufs whose length is less than IP_HLEN?
Other?





    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/