Re: Ethereal comparison 1.265 vs 1.270 DHCP Discover

2005-02-11 Thread Dan Williams
On Fri, 11 Feb 2005, Bill Moss wrote:
 Your patch did not work. From experience with dhcpcd.c, I knew it would 
 not work but I also knew how to fix it. The 1.265 and 1.270-mypatch 
 discovery messages that work are 346 bytes and the UDP part is 312. The 
 1.270 discovery message that does not work is 331 bytes and the UDP part 
 is 297. I believe this may be a size issue. The SMC AP/DHCP server seems 
 to be rejecting the discovery message because its size is too small. 
 Your patch will not work with
 
 DHCP_CLASS_ID_MAX_LEN, %s, sname.sysname);
 
 OR
 
 DHCP_CLASS_ID_MAX_LEN, %s %s, sname.sysname, sname.release);
 
 It only works with
 
 DHCP_CLASS_ID_MAX_LEN, %s %s %s, sname.sysname, sname.release, 
 sname.machine);
 
 If I am right about size and this is an issue for older hardware, then 
 saving a few bytes in the dhcp discovery message is not worth it.

Well, the problem was that exposing the kernel version in the DHCP message is 
basically saying come get me.  I guess there are two options here:

1) The message that _doesn't_ work has an odd # of bytes.  Maybe the SMC has a 
bug that requires an even # of bytes.
2) The message isn't long enough, as you say

One or the other, I guess.  I'll have to see what I can do to add padding to 
the 
message.

Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Ethereal comparison 1.265 vs 1.270 DHCP Discover

2005-02-11 Thread Dan Williams
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
 Index: dhcpcd/buildmsg.c
===
RCS file: /cvs/gnome/NetworkManager/dhcpcd/buildmsg.c,v
retrieving revision 1.5
diff -u -r1.5 buildmsg.c
--- dhcpcd/buildmsg.c   10 Feb 2005 20:54:04 -  1.5
+++ dhcpcd/buildmsg.c   12 Feb 2005 03:36:02 -
@@ -138,7 +138,8 @@
 /*/
 unsigned char *fill_message_type (unsigned char request, unsigned char *p)
 {
-   const unsigned short dhcpMsgSize = htons (sizeof (dhcpMessage));
+#define MAX_DHCP_MSG_SIZE  576
+   const unsigned short dhcpMsgSize = htons (MAX_DHCP_MSG_SIZE);
 
*p++ = dhcpMessageType;
*p++ = 1;
@@ -150,6 +151,15 @@
return p;
 }
 /*/
+unsigned char *fill_padding (dhcpMessage *start, unsigned char *p)
+{
+#define PAD_STOP   324 /* Completely arbitrary even number */
+
+   while ((char *)p - (char *)start  PAD_STOP)
+   *p++ = 0;
+   return p;
+}
+/*/
 udpipMessage *build_dhcp_discover (dhcp_interface *iface, int *msg_len)
 {
udpipMessage*udp_msg = calloc (1, sizeof 
(udpipMessage));
@@ -171,9 +181,9 @@
p = fill_param_request (p);
p = fill_host_and_class_id (iface, p);
*p++ = endOption;
+   p = fill_padding (dhcp_msg, p);
 
/* build UDP/IP header */
-   p++;
dhcp_msg_len = (char *)p - (char *)dhcp_msg;
udpipgen ((udpiphdr *)(udp_msg-udpipmsg), 0, INADDR_BROADCAST, 
iface-ip_id, dhcp_msg_len);
*msg_len = (char *)p - (char *)udp_msg;
@@ -198,10 +208,10 @@
p = fill_lease_time 
(iface-dhcp_options.val[dhcpIPaddrLeaseTime], p);
p = fill_param_request (p);
p = fill_host_and_class_id (iface, p);
-   *p = endOption;
+   *p++ = endOption;
+   p = fill_padding (dhcp_msg, p);
 
/* build UDP/IP header */
-   p++;
dhcp_msg_len = (char *)p - (char *)dhcp_msg;
udpipgen ((udpiphdr *)(udp_msg-udpipmsg), 0, INADDR_BROADCAST, 
iface-ip_id, dhcp_msg_len);
*msg_len = (char *)(p++) - (char *)udp_msg;
@@ -224,9 +234,10 @@
 #endif
p = fill_param_request (p);
p = fill_host_and_class_id (iface, p);
-   *p = endOption;
+   *p++ = endOption;
+   p = fill_padding (dhcp_msg, p);
 
-   p++;
+   /* build UDP/IP header */
dhcp_msg_len = (char *)p - (char *)dhcp_msg;
udpipgen ((udpiphdr *)(udp_msg-udpipmsg), iface-ciaddr, 
iface-siaddr, iface-ip_id, dhcp_msg_len);
*msg_len = (char *)(p++) - (char *)udp_msg;
@@ -247,10 +258,10 @@
p = fill_lease_time 
(iface-dhcp_options.val[dhcpIPaddrLeaseTime], p);
p = fill_param_request (p);
p = fill_host_and_class_id (iface, p);
-   *p = endOption;
+   *p++ = endOption;
+   p = fill_padding (dhcp_msg, p);
 
/* build UDP/IP header */
-   p++;
dhcp_msg_len = (char *)p - (char *)dhcp_msg;
udpipgen ((udpiphdr *)(udp_msg-udpipmsg), iface-ciaddr, 
INADDR_BROADCAST, iface-ip_id, dhcp_msg_len);
*msg_len = (char *)(p++) - (char *)udp_msg;
@@ -274,10 +285,10 @@
p = fill_lease_time (lease_time, p);
p = fill_param_request (p);
p = fill_host_and_class_id (iface, p);
-   *p = endOption;
+   *p++ = endOption;
+   p = fill_padding (dhcp_msg, p);
 
/* build UDP/IP header */
-   p++;
dhcp_msg_len = (char *)p - (char *)dhcp_msg;
udpipgen ((udpiphdr *)(udp_msg-udpipmsg), 0, INADDR_BROADCAST, 
iface-ip_id, dhcp_msg_len);
*msg_len = (char *)(p++) - (char *)udp_msg;
@@ -299,10 +310,10 @@
p = fill_server_id (iface-dhcp_options.val[dhcpServerIdentifier], p);
memcpy(p, iface-cli_id, iface-cli_id_len);
p += iface-cli_id_len;
-   *p = endOption;
+   *p++ = endOption;
+   p 

Re: Ethereal comparison 1.265 vs 1.270 DHCP Discover

2005-02-11 Thread Bill Moss
I removed the first patch from dhcpcd.c and applied the patch to 
buildmsg.c. It works. Here is what ethereal shows

324 UDP data  PAD_STOP
 +8  UDP header
= 332 UDP total
 +20 IP header
= 352 UDPIP
 +14 Ethernet header
= 366 total
I tried
#define PAD_STOP304
and it also works
304 UDP data  PAD_STOP
 +8  UDP header
= 312 UDP total
 +20 IP header
= 332 UDPIP
 +14 Ethernet header
= 346 total
This 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 total
This 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