2010/10/20 Vladislav Grishenko <[email protected]>: > 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?
I guess for many cases this would be quick and acceptable solution. > So, just malloc ip_udp_dhcp_packet struct with max. option size, get rid of > static buffer and cleat up redundant slack record member. What static buffer? We have static packet buffer? Where? > 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. > 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?). > 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. Let's commit typo fix first... done in git, please pull. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
