Network Manager connection to "(none)" (Broadcom STA Driver)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux-restricted-modules (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
I'm not entirely sure where to report this bug. I wrote a request for forum help a few days back (see http://
I'm testing out a new Netgear WNDR3300 Dual Band router (firmware V1.0.29_1.0.29NA) with my Dell Inspiron E1505. My laptop has Broadcom Draft N wireless card:
*-network
description: Wireless interface
product: BCM4328 802.11a/b/g/n
vendor: Broadcom Corporation
physical id: 0
bus info: pci@0000:0b:00.0
logical name: eth1
version: 01
serial: xx:xx:xx:xx:xx:xx
width: 64 bits
clock: 33MHz
I'm using the Broadcom STA wl driver and things are working ok when connected to the G network SSID (using wpa/tkip). When I switch over to the N network, I get a message that "You are now connected... " showing the correct SSID. Once connected, Network Manager shows no connection in the icon (all grey signal bars) and the hover text says: "Wireless network connection to '(none)'". The network is still alive (I'm posting this via the N network) and yet it doesn't appear to be quite right. The speed is double that of the G network, so it seems to be working at least to some extent. The driver doesn't seem to be reporting valid information when connected to the N network:
> iwconfig
lo no wireless extensions.
eth1 IEEE 802.11 Nickname:""
Access Point: Not-Associated
eth0 no wireless extensions.
pan0 no wireless extensions.
> iwlist eth1 rate
eth1 no bit-rate information.
I've just installed the latest restricted drivers for Intrepid. While they didn't seem to break anything, they also don't seem to have solved this problem. I will go ahead and attach the rest of the requested information.
Changed in linux-restricted-modules (Ubuntu): | |
status: | Confirmed → Won't Fix |
Looking at the Network Manager code (version 0.7), it appears that the "(none)" string originates in the file nm-device-wifi.c . Digging around, it *seems* like this may be an issue with a failure of some of the expected IOCTL's in "n" mode.
In the function "nm_device_ wifi_get_ ssid" there is an IOCTL call to retrieve the SSID. I wonder if that is somehow failing? While I'm a programmer, this is getting beyond my skills with Linux development.
memset (ssid, 0, sizeof (ssid)); essid.pointer = (caddr_t) &ssid;
wrq.u.
wrq.u.essid.length = sizeof (ssid);
wrq.u.essid.flags = 0;
strncpy (wrq.ifr_name, nm_device_get_iface (NM_DEVICE (self)), IFNAMSIZ);
if (ioctl (sk, SIOCGIWESSID, &wrq) < 0) {
nm_warning ("Couldn't get SSID: %d", errno);
goto out;
}
It appears that at some point the SSID was correct, but then switches according to daemon.log:
Jan 6 18:46:34 ubuntu-laptop avahi-daemon[4877]: Registering new address record for 192.168.0.2 on eth1.IPv4.
Jan 6 18:46:34 ubuntu-laptop dhclient: bound to 192.168.0.2 -- renewal in 60998 seconds.
Jan 6 18:46:35 ubuntu-laptop NetworkManager: <info> (eth1): device state change: 7 -> 8
Jan 6 18:46:35 ubuntu-laptop NetworkManager: <debug> [1231289195.494675] periodic_update(): Roamed from BSSID 00:22:3F:36:6A:C8 (seteran) to (none) ((none))
Jan 6 18:46:35 ubuntu-laptop NetworkManager: <info> Policy set 'Auto seteran' (eth1) as default for routing and DNS.
Jan 6 18:46:35 ubuntu-laptop NetworkManager: <info> Activation (eth1) successful, device activated.
Jan 6 18:46:35 ubuntu-laptop NetworkManager: <info> Activation (eth1) Stage 5 of 5 (IP Configure Commit) complete.