Problem (and the patch) when having multiple search domains on a network.
Hi,
When the domainName DHCP option contains spaces, nm-named-manager
proclaims it as invalid, although multiple domain names are often used
in the DHCP server configuration. The attached patch fixes this
behavior.
2005-02-11 Tomislav Vujec [EMAIL PROTECTED]
* named/nm-named-manager.c
- (validate_domain_list) new function for validating
domain names lists
- (nm_named_manager_add_domain_search) domain search
validation done with validate_domain_list
Best regards,
--
Tomislav Vujec
Manager, Client Development
Red Hat Otto-Hahn-Strae 20 85609 Mnchen-Dornach
Tel +49 89 205071 212 Fax +49 89 205071 111 Cell. +49 172 623 1214
Index: named/nm-named-manager.c
===
RCS file: /cvs/gnome/NetworkManager/named/nm-named-manager.c,v
retrieving revision 1.10
diff -u -r1.10 nm-named-manager.c
--- named/nm-named-manager.c 2 Feb 2005 22:34:16 - 1.10
+++ named/nm-named-manager.c 11 Feb 2005 12:38:46 -
@@ -566,6 +566,24 @@
return TRUE;
}
+static gboolean
+validate_domain_list (const char *domain_list, GError **error)
+{
+ char **domain_array = g_strsplit(domain_list, , 0);
+ gboolean valid = TRUE;
+ char **p = domain_array;
+
+ for (; *p; p++)
+ {
+ if (!validate_host(*p, error)) {
+ valid = FALSE;
+ break;
+ }
+ }
+ g_strfreev(domain_array);
+ return valid;
+}
+
static void
compute_search (gpointer key, gpointer value, gpointer data)
{
@@ -658,7 +676,7 @@
{
guint id;
- if (!validate_host (domain, error))
+ if (!validate_domain_list (domain, error))
return 0;
id = ++mgr-priv-id_serial;
signature.asc
Description: This is a digitally signed message part
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: CVS 8/2 compile error
On Tue, 2005-02-08 at 13:34 +0100, Tom Parker wrote: Getting errors on NetworkManagerDevice.c, because I don't appear to have a pci/types.h. No idea where the heck this would be (on a Debian system), but then worked out that we only needed a few types from it and so wrote a patch. Index: src/NetworkManagerDevice.c === RCS file: /cvs/gnome/NetworkManager/src/NetworkManagerDevice.c,v retrieving revision 1.91 diff -u -r1.91 NetworkManagerDevice.c --- src/NetworkManagerDevice.c 7 Feb 2005 23:04:05 - 1.91 +++ src/NetworkManagerDevice.c 8 Feb 2005 12:32:11 - @@ -3600,7 +3600,10 @@ /**/ /*Ethtool capability detection*/ /**/ -#include pci/types.h +typedef unsigned long long u64; +typedef unsigned int u32; +typedef unsigned short u16; +typedef unsigned char u8; #include linux/sockios.h #include linux/ethtool.h Hmm. Why not port the code to the glib typedefs (e.g. guint32) instead? While those typedefs are correct (AFAIK) on all the important platforms that Linux runs on today, there's no guarantee that in the future e.g. int will be 32 bits. On such a platform the code will probably start failing mysteriously. signature.asc Description: This is a digitally signed message part ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Ethereal comparison 1.265 vs 1.270 DHCP Discover
Bootstrap Protocol identical down to 1.270: Option 53 DHCP Message TYPE = DHCP Discover Option 57: Maximum DHCP Message Size = 548 Option 51: IP Address Lease Time = infinity Option 55: Parameter Request List Option 12: Host Name = localhost.localdomain == SMC DHCP does not send an ARP. It is stuck here. It doesn't like something about the way this message is constructed. All checksums are correct in all parts of the message. 1.265 Option 53 DHCP Message TYPE = DHCP Discover Option 57: Maximum DHCP Message Size = 548 Option 51: IP Address Lease Time = infinity Option 55: Parameter Request List Option 60: Vendor class identifier = Linux 2.6.10-1.760_FC3 i686 Option 61: Client identifier == SMC DHCP immcdiately sends an ARP and the process continues to completion -- Bill Moss Professor, Mathematical Sciences Clemson University ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: define u64 too
On Fri, 2005-02-11 at 16:32 +0100, [EMAIL PROTECTED] wrote: /usr/include/linux/ethtool.h:243: error: syntax error before u64 hm, i have to define u64 too... Fixed, thanks. 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
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
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
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
