| Summary: | udhcpc oversized packets bug | ||
|---|---|---|---|
| Product: | Busybox | Reporter: | Evgeniy Manachkin <sfstudio> |
| Component: | Networking | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | busybox-cvs |
| Priority: | P5 | ||
| Version: | 1.16.x | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: |
Patch fix udhcpc oversized packets bug, from OpenWRT for 1.16.1 busybox
dump`s from user patched/non patched versions |
||
There is a guard in networking/udhcp/common.h against that error:
/* Let's see whether compiler understood us right */
struct BUG_bad_sizeof_struct_ip_udp_dhcp_packet {
char BUG_bad_sizeof_struct_ip_udp_dhcp_packet
[(sizeof(struct ip_udp_dhcp_packet) != 576 + CONFIG_UDHCPC_SLACK_FOR_BUGGY_SERVERS) ? -1 : 1];
};
Can you attach a hex dump of such bad packet? Including ethernet, ip and udp headers.
(In reply to comment #1) > There is a guard in networking/udhcp/common.h against that error: But it does not work. > Can you attach a hex dump of such bad packet? Including ethernet, ip and udp > headers. The problem appears not for me. Trouble with ISP for one of users wive-ng. I will ask to make a dump. The truth it will be difficult as on its device not enough RAM. P.S. The problem dares the enclosed patch. The patch in OpenWRT migrates from the version in the version. It means that the problem is not individual and actual for considerable number of users. Probably it makes sense to contact developers OpenWRT and they can explain in more details why the code described to you in networking/udhcp/common.h does not solve this problem? RFC 791 says that all IP networks must support packets at least 576 octets big. the question is, *what is included* in those 576 octets? Here is the text from the RFC:
Total Length is the length of the datagram, measured in octets,
including internet header and data. This field allows the length of
a datagram to be up to 65,535 octets. Such long datagrams are
impractical for most hosts and networks. All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments). It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.
"Including internet header and data" means that in this case, "length" includes IP headers and IP data (in case of DHCP packets, IP data will contain UDP headers and then DHCP packet), bot does NOT include ethernet header, nor ethernet CRC.
With ethernet header of 14 bytes, 576 + 14 = 590.
Here, for example, we also see *590* bytes mentioned:
http://technet.microsoft.com/en-us/library/cc749902.aspx
(In reply to comment #3) > RFC 791 says It`s true... However with some ISP we have a problem. The given problem already was discussed here http://lists.busybox.net/pipermail/busybox/2006-November/059404.html Some buggy dhcp server on some ISP drop 590bytes packets. $( Probably issue not in size of packet, but in zero padding that is used on udhpcd. Created attachment 1795 [details]
dump`s from user patched/non patched versions
User send me dumps:
tcpdump.dhclient-ubuntu-dhcpclient-work-ok
tcpdump.udhcpc-nopatched-no-work
tcpdump.udhcpc_patched-work-ok
Fixed in git, will be in 1.17.x Thanks. |
Created attachment 1783 [details] Patch fix udhcpc oversized packets bug, from OpenWRT for 1.16.1 busybox Some ISP do not accept DHCP packages in the size more than 576 byte whereas udhcpc dispatches packages in the size of 590 byte. This patch from OpenWRT is fix`it trouble. Please include this patch in mainline.