324 UDP data & PAD_STOP
+8 UDP header
= 332 UDP total
+20 IP header
= 352 UDPIP
+14 Ethernet header
= 366 totalI tried
#define PAD_STOP 304
and it also works
304 UDP data & PAD_STOP
+8 UDP header
= 312 UDP total
+20 IP header
= 332 UDPIP
+14 Ethernet header
= 346 totalThis is where you were before you deep-sixed the client id stuff. I think 304 suffices. This has padded with 15 bytes over what you had before the patch.
I tried PAD_STOP 290 which is just a pad of 1 byte.
290 UDP data & PAD_STOP
+8 UDP header
= 298 UDP total
+20 IP header
= 318 UDPIP
+14 Ethernet header
= 332 totalThis did not work so it is more than just having even values for these various sizes.
Dan Williams wrote:
Bill,
Can you apply this patch to current CVS copy of NM? It changes dhcpcd/buildmsg.c only. It now pads the message to over 300 bytes and ensures that the message is always an even number of bytes long.
Thanks, Dan
On Fri, 11 Feb 2005, Bill Moss wrote:
I think older hardware may reject messages that are too short. The UDP part of the message contains a BOOTP section of options and there was a time when BOOTP messages had a minimize size of 300 bytes. If this is what the SMC is doing, the a message with a UDP part of 297 bytes will not pass muster. This is just a guess. I suppose you can pad the message one byte at a time and see where the boundary is. I am betting on 300 or 312.
-- Bill Moss Professor, Mathematical Sciences Clemson University
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
-- Bill Moss Professor, Mathematical Sciences Clemson University
-- Bill Moss Professor, Mathematical Sciences Clemson University
_______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
