[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #54117] ICMP echo reply breaks ip_frag under a specifi
From: |
Scott |
Subject: |
[lwip-devel] [bug #54117] ICMP echo reply breaks ip_frag under a specific circumstance |
Date: |
Thu, 14 Jun 2018 13:51:14 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko |
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/
- [lwip-devel] [bug #54117] ICMP echo reply breaks ip_frag under a specific circumstance,
Scott <=