> From: Denys Vlasenko > Sent: Thursday, October 21, 2010 1:43 AM > To: Vladislav Grishenko > Cc: [email protected] > Subject: Re: FW: udhcpc: DHCP packet size and friends > > > It doesn't need to be configurable, or we could face with no huge > > packets are accepted. > > ? It should be at maximum for the long run to accept any huge packets. Same dangerous configurable thing as FEATURE_SYSLOGD_READ_BUFFER_SIZE, which should be de-facto 1024 miminum.
> > > > 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. Here tcpdump's log. And I'm afraid that the number of routes will grow over the time. > BTW, unrelated fixes should be in separate patches. Ok, original mtu reading was related. Best Regards, theMIROn _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
