wireless, Broadcom & jaunty

[Joep L. Blom]

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

> 


> 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.
> 

> 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.
Yes, sorry for the typo. I read somewhere (long time ago) the somewhat 
convoluted way IPv6 and IPv4 is related but is apparently related to 
easy hex calculation (using bit shifting in machine language). Long time 
ago I used it myself in low-level programming to have certain routines 
running really fast (I worked with real-time AD-conversion in the '80's).
> 
> 
> 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).
Sorry for the etc. It's automatic. I'll try to replace it with "..." to 
indicate continuance.
> 
> 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.
Interesting suggestion.
I  renamed the rule 70-persistent-net.rules to ~.old and restarted udev 
(sudo service udev restart). It didn't make a new rule but ifconfig gave me:
eth0:avahi Link encap:Ethernet HWaddr 00:0c:76:71:bd:44
	inet addr:169.354.6.148 Bcast 169.254.255.255 Mask: 255.255.0.0
	UP BROADCAST MULTICAST MTU:1500 Metric:1

Apparently because the ~-net.rules doesn't exist it gives some standard 
apparently hard-coded IP address to the card, which than can be reached 
(pinged).
> 
> 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.
sudo dhclient is trying to an address by sending out DHCPDISCOVER 
packets on port 67 with varying time-intervals and the last line is:
No DHCPOFFERS received. (which is correct)
> 
> 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.
Yes, I have a very good reason for wicd as NM simply didn't work 
reliably (at least in Hardy) and now am accustomed to wicd (which I 
think is now the preferred network manager in Ubuntu) and I haven't 
tried NM again. It was a suggestion of Noop who gives very sound and 
well documented advices.
As you see my problem is as yet unresolved. However, it is interesting 
and gives me the opportunity to get better acquainted with wireless 
world in IT. I'm a HAM radio amateur (call sign PE1IIW) and although I 
did work a little on 70 cm the techniques used in the current wireless 
transceivers is a little over my head.

Thanks for the elaborate and thoughtful replies on my request. I have 
not all the time I would to solve my computer problems as I have, 
although retired, other work (i.e. activities requested by others as 
well for money as voluntarily) which consume a lot of time.
Joep