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 ] (0x0000) 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 ] (0x0000) 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=21487&sortby=file&view=markup It's the 'raw_socket' function and the BPF filter there. Cheers, -- Cristian _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
