Hello, Sorry, smth is wrong with my email client. We had troubles with udh...@bb 1.17.3 and an ISP's original interpretation of rfc2131 on last week. Dumps showed that server sends ACK inside large DHCP packets (with stateful, stateless and ms stateless routes), if no maximum message size options was specified. Meanwhile OFFER packets weren't oversized, 'coz udhcpc explicitly sets MSZ inside DISCOVER to minimum 576. UDHCPC_SLACK_FOR_BUGGY_SERVERS config options could help in this case, but it's kind of dog-nail, I'll explain why. Origin of UDHCPC_SLACK_FOR_BUGGY_SERVERS was oversized OFFER packets only, but not only as the answer to DISCOVER, and the same story could happen with ACK. Windows(tm) DHCP clients doesn't include MSZ option, and eats all packets up to if's MTU. We could achieve similar buggy-free behavior by setting UDHCPC_SLACK_FOR_BUGGY_SERVERS to the maximum (924), overall dhcp packet size will be 1500. But, ihmo, it's redundant in terms of bss consumption. Am I right? So, just malloc ip_udp_dhcp_packet struct with max. option size, get rid of static buffer and cleat up redundant slack record member.
Second way is to include actual MSZ to DISCOVER, REQUEST and INFORM packets, rfc says that client may do it. Actual MSZ means it should be set to sizeof(struct ip_udp_dhcp_packet), if it less than current interface MTU. If struct size is equal or greater then MTU, we really doesn't need to set MSZ, no oversized broadcast packets could arrive which could be sent with pmtu assumption. In the simple case, we have to get MTU on start, but there's need of interface mtu polling on every outgoing packet. Proposed patch is attached, needs review, and several questions are still open: What if mtu gets lower than buffer in the middle of discover/request stages. What if DHCP server sends MTU options and pretty sure it will be used instead of local current MTU. What if jumbo frames are enabled and MTU is greater than 1500. p.s also patch fixes typo UPD->UDP and interface index polling while running on a bridge. Best Regards, theMIROn ICQ: 303357 Skype: the.miron
302-udhcp-packet-size.patch
Description: Binary data
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
