RE: udhcpc in 1.10.3 doesnt like my WLAN card
Hello, Hope you remember that the probleme I have is not on a Wireless Card. The kernel and all the tools that I am using are not fancy tools. The probleme must come from 'BPF filter' hecause when I comment this line the DHCPC works correctly: -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Denys Vlasenko Envoyé : jeudi 19 juin 2008 20:58 À : busybox@busybox.net; Cristian Ionescu-Idbohrn; Alexander Griesser (LKH Villach) Objet : Re: udhcpc in 1.10.3 doesnt like my WLAN card On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: The problem seems to be that your wlan-card does not see/catch the dhcp-offer. Cristian, this is not true. In tcpdump I see This is the packet from us: 14:20:27.629001 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:00, length 548, xid 0x51d537f3, Flags [ none ] (0x) Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 50:00:00:00:26:00 Vendor-Class Option 60, length 12: udhcp 1.10.3 MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP and this is the reply: 14:20:28.633227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 192.168.8.38.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x51d537f3, Flags [ none ] (0x) Your-IP 192.168.8.38 Server-IP 192.168.8.254 Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.8.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.8.254 Domain-Name-Server Option 6, length 8: 192.168.8.50,80.10.246.2 The fact that it is seen by tcpdump means that WLAN card (or whatever other link is used) _did_ receive the packet. On Wed, 18 Jun 2008, SAMUEL Dinesh wrote: My DHCPD server is: * Running under Linux Debian * version : Dhcp 2.0pl5-19.1 Is this a Debian sarge (oldstable) or woody (even older) distribution? I do no longer have access to anything like that. Did you check the non-working version with another dhcp-server? What arch are you using? I see no such problems when using Debian etch dhcp3-server 3.0.4-13, some misterious m$ dhcp server, dnsmasq various versions, udhcpd 0.9.8cvs20050303-2. Is the mac address 50:00:00:00:26:00 the real thing or just an obfuscation? Maybe that BPF filter should be made into an option. My wild guess is that BPF filter assumes some specific Ethernet frame format, and unfortunately there are several of those. And especially in wireless LAN world it's still incredibly messy. (I've been there. I was developing a wireless driver). That explains how BPF filter works for Alexander with one WLAN device but doesn't work with another: the second device translates WLAN frames into different Ethernet frame format! Read here: http://en.wikipedia.org/wiki/Ethernet Ethernet frame types and the EtherType field section. -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: udhcpc in 1.10.3 doesnt like my WLAN card
On Thursday 19 June 2008 22:22, Cristian Ionescu-Idbohrn wrote: On Thu, 19 Jun 2008, Denys Vlasenko wrote: On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: The problem seems to be that your wlan-card does not see/catch the dhcp-offer. Cristian, this is not true. Yes it is :) ... The application won't see it if the kernel (as instructed) will filter it out. You said your wlan-card does not see/catch the dhcp-offer. wlan-card, not application. Here the card did see the offer. -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: udhcpc in 1.10.3 doesnt like my WLAN card
On Friday 20 June 2008 09:18, SAMUEL Dinesh wrote:
Hello,
Hope you remember that the problem I have is not on a Wireless Card.
The kernel and all the tools that I am using are not fancy tools.
The problem must come from 'BPF filter' because when I comment this line the
DHCPC works correctly:
Clientsocket.c
if (SERVER_PORT == 67 CLIENT_PORT == 68)
{
/* Use only if standard ports are in use */
/* Ignoring error (kernel may lack support for this) */
if (setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER,
filter_prog,
sizeof(filter_prog)) = 0)
DEBUG(attached filter to raw socket fd %d, fd);
}
Does this help?
http://busybox.net/downloads/fixes-1.10.3/busybox-1.10.3-udhcpc.patch
--
vda
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
RE: udhcpc in 1.10.3 doesnt like my WLAN card
Hello,
Yep this patch is working.
Thanks.
Bye
-Message d'origine-
De : Denys Vlasenko [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 20 juin 2008 16:50
À : SAMUEL Dinesh
Cc : busybox@busybox.net; 'Cristian Ionescu-Idbohrn'; 'Alexander Griesser
(LKH Villach)'
Objet : Re: udhcpc in 1.10.3 doesnt like my WLAN card
On Friday 20 June 2008 09:18, SAMUEL Dinesh wrote:
Hello,
Hope you remember that the problem I have is not on a Wireless Card.
The kernel and all the tools that I am using are not fancy tools.
The problem must come from 'BPF filter' because when I comment this line
the
DHCPC works correctly:
Clientsocket.c
if (SERVER_PORT == 67 CLIENT_PORT == 68)
{
/* Use only if standard ports are in use */
/* Ignoring error (kernel may lack support for this) */
if (setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER,
filter_prog,
sizeof(filter_prog)) = 0)
DEBUG(attached filter to raw socket fd %d, fd);
}
Does this help?
http://busybox.net/downloads/fixes-1.10.3/busybox-1.10.3-udhcpc.patch
--
vda
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: udhcpc in 1.10.3 doesnt like my WLAN card
The problem seems to be that your wlan-card does not see/catch the dhcp-offer. On Wed, 18 Jun 2008, SAMUEL Dinesh wrote: My DHCPD server is: * Running under Linux Debian * version : Dhcp 2.0pl5-19.1 Is this a Debian sarge (oldstable) or woody (even older) distribution? I do no longer have access to anything like that. Did you check the non-working version with another dhcp-server? What arch are you using? I see no such problems when using Debian etch dhcp3-server 3.0.4-13, some misterious m$ dhcp server, dnsmasq various versions, udhcpd 0.9.8cvs20050303-2. Is the mac address 50:00:00:00:26:00 the real thing or just an obfuscation? Maybe that BPF filter should be made into an option. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: udhcpc in 1.10.3 doesnt like my WLAN card
On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: The problem seems to be that your wlan-card does not see/catch the dhcp-offer. Cristian, this is not true. In tcpdump I see This is the packet from us: 14:20:27.629001 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:00, length 548, xid 0x51d537f3, Flags [ none ] (0x) Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 50:00:00:00:26:00 Vendor-Class Option 60, length 12: udhcp 1.10.3 MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP and this is the reply: 14:20:28.633227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 192.168.8.38.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x51d537f3, Flags [ none ] (0x) Your-IP 192.168.8.38 Server-IP 192.168.8.254 Client-Ethernet-Address 50:00:00:00:26:00 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.8.254 Lease-Time Option 51, length 4: 86400 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.8.254 Domain-Name-Server Option 6, length 8: 192.168.8.50,80.10.246.2 The fact that it is seen by tcpdump means that WLAN card (or whatever other link is used) _did_ receive the packet. On Wed, 18 Jun 2008, SAMUEL Dinesh wrote: My DHCPD server is: * Running under Linux Debian * version : Dhcp 2.0pl5-19.1 Is this a Debian sarge (oldstable) or woody (even older) distribution? I do no longer have access to anything like that. Did you check the non-working version with another dhcp-server? What arch are you using? I see no such problems when using Debian etch dhcp3-server 3.0.4-13, some misterious m$ dhcp server, dnsmasq various versions, udhcpd 0.9.8cvs20050303-2. Is the mac address 50:00:00:00:26:00 the real thing or just an obfuscation? Maybe that BPF filter should be made into an option. My wild guess is that BPF filter assumes some specific Ethernet frame format, and unfortunately there are several of those. And especially in wireless LAN world it's still incredibly messy. (I've been there. I was developing a wireless driver). That explains how BPF filter works for Alexander with one WLAN device but doesn't work with another: the second device translates WLAN frames into different Ethernet frame format! Read here: http://en.wikipedia.org/wiki/Ethernet Ethernet frame types and the EtherType field section. -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: udhcpc in 1.10.3 doesnt like my WLAN card
On Thu, 19 Jun 2008, Denys Vlasenko wrote: On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: The problem seems to be that your wlan-card does not see/catch the dhcp-offer. Cristian, this is not true. Yes it is :) In tcpdump I see This is the packet from us: 14:20:27.629001 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 50:00:00:00:26:00, length 548, xid 0x51d537f3, Flags [ none ] (0x) Right. and this is the reply: 14:20:28.633227 IP (tos 0x10, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 328) 192.168.8.254.67 192.168.8.38.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x51d537f3, Flags [ none ] (0x) Sure. The fact that it is seen by tcpdump means that WLAN card (or whatever other link is used) _did_ receive the packet. The application won't see it if the kernel (as instructed) will filter it out. My wild guess is that BPF filter assumes some specific Ethernet frame format, and unfortunately there are several of those. And especially in wireless LAN world it's still incredibly messy. (I've been there. I was developing a wireless driver). We can't do better than assume the kernel is doing TRT. That explains how BPF filter works for Alexander with one WLAN device but doesn't work with another: the second device translates WLAN frames into different Ethernet frame format! That's still weird, wouldn't you say? Read here: http://en.wikipedia.org/wiki/Ethernet Ethernet frame types and the EtherType field section. I'll do that in a moment. But, until we get clever WRT that, to solve the current hickup, we should better do the BPF filter optional. We'd need a full trace to be able to find out if the frame types may be the cause. There's another thing I thought about: byte order. There could be something fishy there. I somehow got the impression the problem occured on a mips-arch, but let's wait for a confirmation. The BPF filter may have a bug, there may be a bug in the kernel too. I'll Bcc: the start of this thread to a couple of my collegues (much more knowledgeable than I am in this area) and see if they can make more sense out of it: http://busybox.net/lists/busybox/2008-June/031820.html and the file we're talking about: http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/networking/udhcp/clientsocket.c?rev=21487sortby=fileview=markup It's the 'raw_socket' function and the BPF filter there. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: udhcpc in 1.10.3 doesnt like my WLAN card
On Thursday 19 June 2008 19:58:19 Denys Vlasenko wrote: On Thursday 19 June 2008 14:43, Cristian Ionescu-Idbohrn wrote: The problem seems to be that your wlan-card does not see/catch the dhcp-offer. Cristian, this is not true. In tcpdump I see This is the packet from us: and this is the reply: The fact that it is seen by tcpdump means that WLAN card (or whatever other link is used) _did_ receive the packet. Maybe that BPF filter should be made into an option. Or should be made to work with buggy Linux versions. Some kernels don't allow a packet length of -1 to pass the full packet. Instead use a large enough number for the packet, but small enough for BPF to work. I used 65535. http://bugs.gentoo.org/show_bug.cgi?id=215174 Thanks Roy ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: udhcpc in 1.10.3 doesnt like my WLAN card
Samuel, Could you please provide some info about your dhcp-server? Brand, version, OS, version , age, etc. On Wed, 18 Jun 2008, SAMUEL Dinesh wrote: 09:36:12.339382 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:00:26:01 (oui Unknown), length 548 09:36:12.351751 IP 192.168.8.254.bootps 192.168.8.39.bootpc: BOOTP/DHCP, Reply, length 300 09:36:12.362863 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP, Request from 50:00:00:00:26:01 (oui Unknown), length 548 09:36:12.367958 IP 192.168.8.254.bootps 192.168.8.39.bootpc: BOOTP/DHCP, Reply, length 300 Hope this will help you. No, not really. To give you an idea of what Denys meant with: On Thu, 12 Jun 2008, Denys Vlasenko wrote: Can you collect tcpdump -nlieth0 -s0 -vvv -xX port 67 or port 68 output for both? and what I meant with: On Mon, 16 Jun 2008, Cristian Ionescu-Idbohrn wrote: Acctualy: $ tcpdump -nlieth0 -s0 -w filepath 'udp and port (67 or 68)' would be more interesting. Here is an example: # tcpdump -nnnlieth0 -s0 -vvv -xX 'udp and port (67 or 68)' tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 10:25:03.157828 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:40:8c:73:05:23, length 548, xid 0xc71ebb6c, Flags [ none ] (0x) Client-Ethernet-Address 00:40:8c:73:05:23 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether 00:40:8c:73:05:23 Hostname Option 12, length 17: axis-00408c730523 Vendor-Class Option 60, length 34: AXIS,Video Server,241S,HEAD 080506 MSZ Option 57, length 2: 576 Parameter-Request Option 55, length 7: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, BR, NTP 0x: 4500 0240 4011 78ae [EMAIL PROTECTED]@.x. 0x0010: 0044 0043 022c 5ef0 0101 0600 .D.C.,^. 0x0020: c71e bb6c ...l 0x0030: 0040 8c73 0523 [EMAIL PROTECTED] 0x0040: 0x0050: 0x0060: 0x0070: 0x0080: 0x0090: 0x00a0: 0x00b0: 0x00c0: 0x00d0: 0x00e0: 0x00f0: 0x0100: 6382 5363 3501 013d c.Sc5..= 0x0110: 0701 0040 8c73 0523 0c11 6178 6973 2d30 [EMAIL PROTECTED] 0x0120: 3034 3038 6337 3330 3532 333c 2241 5849 0408c730523AXI 0x0130: 532c 5669 6465 6f20 5365 7276 6572 2c32 S,Video.Server,2 0x0140: 3431 532c 4845 4144 2030 3830 3530 3639 41S,HEAD.0805069 0x0150: 0202 4037 0701 0306 0c0f 1c2a ff00 [EMAIL PROTECTED] 0x0160: 0x0170: 0x0180: 0x0190: 0x01a0: 0x01b0: 0x01c0: 0x01d0: 0x01e0: 0x01f0: 0x0200: 0x0210: 0x0220: 0x0230: 10:25:03.167046 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 192.168.222.42.67 192.168.222.200.68: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0xc71ebb6c, Flags [ none ] (0x) Your-IP 192.168.222.200
Re: udhcpc in 1.10.3 doesnt like my WLAN card
On Mon, 16 Jun 2008, SAMUEL Dinesh wrote: We have the same problem as described in this link. http://busybox.net/lists/busybox/2008-June/031835.html We don't use WLAN card. Just the two Ethernet cards included in the taihu evaluation board (ppc 405ep). We tried the solution supplied in the topic linked below and it worked for us. Tcpdump output on the dhcp server looks pretty normal. Here's the debug output we had before modifying clientsocket.c with(out) your code block : [snip] Could you please provide us an explanation for this. If removing the code block you specified is enough, please let us know too :-) Could you please provide that trace, as Denys asked for? On Thu, 12 Jun 2008, Denys Vlasenko wrote: Can you collect tcpdump -nlieth0 -s0 -vvv -xX port 67 or port 68 output for both? Write it to a file and post it. If you don't want to make it public, please post to our private addresses. Acctualy: $ tcpdump -nlieth0 -s0 -w filepath 'udp and port (67 or 68)' would be more interesting. I'm interested too, as it was on my initiative that filtering code was added. Cheers, -- Cristian ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
