wireless, Broadcom & jaunty

[Derek Broughton]

Joep L. Blom wrote:

> Derek Broughton wrote:
>> Joep L. Blom wrote:

>> Do you _have_ response packets?  No need to get into packet sniffing -
>> what
>> actually shows in syslog?  If you don't actually see DHCPOFFER, then it
>> seems your router never hears from you.
>>
> Derek thanks.
> The problem is that it's not always the same. I now have rebooted and
> the system now behaves differently.
> When I look in the syslog it doews the following:

> 1. The kernel module associates the card (eth0) with the wireless router
> but it associates the IPv6 address with it: as seen here:

That's fine and normal.  I think I said the IPv6 address is automatic - you 
don't need DHCP for that - but since many/most networks still don't actually 
handle ipv6, you need an ipv4 address.
> ....

> May  3 14:25:32 velsatis kernel: [ 1085.876616] eth0: associate with AP
> 00:c0:49:54:77:9e
> THIS IS THE MAC ADDRESS OF THE WIRELESS ROUTER

Of course - you associate "with" the router.
> 
> May  3 14:25:32 velsatis kernel: [ 1085.878475] eth0: RX AssocResp from
> 00:c0:49:54:77:9e (capab=0x431 status=0 aid=6)
> May  3 14:25:32 velsatis kernel: [ 1085.878480] eth0: associated

So now, at the ethernet level you have communication to the router...

> May  3 14:25:32 velsatis kernel: [ 1085.878610] ADDRCONF(NETDEV_CHANGE):
> eth0: link becomes ready

Here the kernel says "OK, I have a working interface - let's IFUP"

> May  3 14:25:33 velsatis avahi-daemon[3399]: Registering new address
> record for fe80::20c:76ff:fe71:bd44 on eth0.*.
> !!! THIS IS THE IPv6 MAC ADDRESS OF THE WIRELESS CARD !!!

That's also "avahi" (beats me what that actually means, but they can't call 
it "zeroconf" - which it is - because somebody has a trademark on that!).  
Its primary purpose is to allow you to connect with the local network 
_without_ an Internet connection.  For our current purposes, it's 
irrelevant.

> 
> with ifconfig the inet6 address is that address but the MAC address is
> 00:0c:76:71:bd:44.

Well, you missed a hex digit in the ipv6 address, but if you look at the 
pairs of digits, and take the 2nd, 4th, 5th and 8th thru 10th pairs, you get 
your MAC address (with the high-order bit set).  I don't know why it's 
mapped that way, but I suspect it's to do with the way the ipv6 maps to 
vendor, model, and serial number.

> Therafter the dhcpclient starts and gives then:

Right this is the important stuff.

> May  3 14:25:36 velsatis dhclient:
> May  3 14:25:36 velsatis dhclient: wmaster0: unknown hardware address
> type 801

Mine always does this, so I don't think it's important.

> May  3 14:25:36 velsatis avahi-daemon[3399]: Withdrawing address record
> for fe80::290:f5ff:fe32:20cb on eth1.
> May  3 14:25:36 velsatis dhclient: wmaster0: unknown hardware address
> type 801
> May  3 14:25:36 velsatis dhclient: Bind socket to interface: No such
> device etc.

OK, THAT's serious.  (Though not as simple as it appears - please don't just 
tack words like "etc" onto your log - I thought you must have mistyped etc 
for eth somewhere, but I see it doesn't actually display the device name in 
the log).

For instance, mine will usually go:
May  4 19:42:59 morgen NetworkManager: <info>  dhclient started with pid 
17605
...
May  4 19:42:59 morgen dhclient: wmaster0: unknown hardware address type 801
May  4 19:43:00 morgen dhclient: wmaster0: unknown hardware address type 801
May  4 19:43:00 morgen dhclient: Listening on LPF/wlan0/00:23:4e:61:4f:fc
May  4 19:43:00 morgen dhclient: Sending on   LPF/wlan0/00:23:4e:61:4f:fc
May  4 19:43:00 morgen dhclient: Sending on   Socket/fallback
May  4 19:43:00 morgen dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 
port 67 interval 7
May  4 19:43:03 morgen dhclient: DHCPOFFER of 192.168.1.113 from 192.168.1.1
May  4 19:43:03 morgen dhclient: DHCPREQUEST of 192.168.1.113 on wlan0 to 
255.255.255.255 port 67
May  4 19:43:03 morgen dhclient: DHCPACK of 192.168.1.113 from 192.168.1.1
May  4 19:43:03 morgen dhclient: bound to 192.168.1.113 -- renewal in 38589 
seconds.

> So I assume there are several mixups in the network configuration but I
> haven't found out which scripts I have to adapt to correct this.
> Hoep you have some ideas?

I would _suspect_ it's not network configuration - I don't like that "No 
such device" message, but there are a few things that could be network 
related.

First, I suggested deleting the udev rule, and you said it had no effect, 
but it _can't_ have no effect.  If you don't have any udev rule mentioning 
eth0, it wouldn't say "udev: renamed network interface wlan0 to eth0".  So 
I'd recommend removing that rule, and restarting udev.  If it still shows as 
eth0, reboot.

Second, what happens when you do "sudo dhclient eth0" (or "wlan0" if you get 
the device back to wlan0)?  wicd isn't even managing that much.

Third, do you have a good reason for using wicd?  I have no problem 
recommending wicd for people who can't use NetworkManager, for whatever 
reason, but frankly I don't believe it's any better than NM, it just has its 
own set of problems.
-- 
derek