On Wednesday 20 October 2010 19:09, Vladislav Grishenko wrote: > > From: Denys Vlasenko > > Sent: Wednesday, October 20, 2010 10:06 PM > > To: Vladislav Grishenko > > Cc: [email protected] > > Subject: Re: FW: udhcpc: DHCP packet size and friends > > > > 2010/10/20 Vladislav Grishenko <[email protected]>: > > > 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? > > > > I guess for many cases this would be quick and acceptable solution. > > In this case, what UDHCPC_SLACK_FOR_BUGGY_SERVERS is stand for?
For the padding added after the packet, in case servers send packets larger than we say we can accept. > It doesn't need to be configurable, or we could face with no huge packets > are accepted. ? > > > Second way is to include actual MSZ to DISCOVER, REQUEST and INFORM > > > packets, rfc says that client may do it. > > > > Yes, I think we can do this, if it convinces some servers to not send > oversize > > packets. > It forces servers to not to continue to fill the options buffer, and to > start using file/sname override. It expands options, but not sufficient for > a possible large routes lists. > > > > 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. > > > > How about just using DHCP_MAX_SIZE = 576 always, without regard to MTU? > > I bet not many people run on networks with MTU smaller than that (is it > even > > allowed by IP protocol to have MTU < 576?). > It could be the solution, but any large packets which don't fit in 576 bytes > will be lost. > I've seen 572 packets (without override), and it's almost the limit. So, > forcing MSZ to 576 is really could be wrong, not now, but tomorrow. Show me example packets where 0.5k is not enough. > Refreshing interface index is also important, if udhcpc is running on a > bridge. Applied to git. BTW, unrelated fixes should be in separate patches. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
