[Edgy] Unable to connect to some access points

All of the log output was taken while at the location.

This isn't an issue with NetworkManager. It's a hardware specific issue, and so I'm reassigning to linux-meta. However, since the driver you're using is in the restricted set, I don't imagine there is much they can do to help...

Thanks for the response. Seeing I didn't know the nature of the problem I wasn't 100% certain of the package the problem existed in.

If they cannot help because the driver is in the restricted set then perhaps there should be an easy way to use a different kernel seeing I know this WAP was accessable with Dapper.

I heard that Edgy was going to have an easy way to roll your own kernel, but I haven't had chance to dig into any of that documentation. I'll poke around and see what I can come up with.

This is half a "me too" sorta comment. I've an IBM T43p with an Atheros chip built in, here's the lspci output:

04:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
        Subsystem: IBM Unknown device 057e
        Flags: bus master, fast Back2Back, medium devsel, latency 168, IRQ 58
        Memory at a8400000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [44] Power Management version 2

The device worked just fine in dapper, where I used network manager to connect to wireless networks with no problems. However, when upgrading to edgy, I've noticed many more problems specifically, I've noticed the following behaviors:

1. I am unable to connect to many wireless networks. These networks will show up in NetworkManager as having a reasonable signal strength, but not allow me to associate. NetworkManager keeps on trying to associate with the network. In general I've only noticed this on unencrypted networks, but that's probably because I only connect to one encrypted network (my home).

2. Those networks I can connect to frequently see dropped connections. I have my access point on one corner of my desk, about 3 feet from my laptop. With dapper I had maybe one dropped connection in six months. With Edgy I get a dropped connection about every 10 minutes (on bad days). On weaker networks its even worse, making the network basically unusable.

I have noticed a few changes, I now have a wifi0 and ath0 interface. wifi0 shows no wireless extensions when I run iwconfig. It also has a very strange hardware address:

wifi0 Link encap:UNSPEC HWaddr 00-16-CE-20-80-9D-00-00-00-00-00-00-00-00-00-00

According to my system logs, this should be a wireless interface for me, and it even says that I've got 802.11/a/b/g on it. Nothing of the sort shows up for ath0 in my log or dmesg.

I also see some strange lines in my system log related to the interface when running network-manager:

Oct 13 19:46:46 localhost kernel: [17211313.984000] ADDRCONF(NETDEV_CHANGE): ath0: link becomes ready
Oct 13 19:47:16 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.host_name
Oct 13 19:47:16 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.nis_domain
Oct 13 19:47:16 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.nis_servers
Oct 13 19:52:30 localhost kernel: [17211658.552000] ADDRCONF(NETDEV_UP): ath0: link is not ready

Not sure how relevant those are, but I hope this can help someone.

I believe that the wifi0 devices is a new device needed for madwifi-ng. I have recently compiled madwifi-ng from their subversion trunk. I am going to try and connect to that WAP today.

Wouldn't that be a bit of a regression in the regular madwifi drivers? I was using Ubuntu Dapper for a long time and the wifi card worked out of the box (not with Breezy though). I did not have a wifi0 device listed there.

If it is a change in drivers, the dist-upgrade process from dapper->edgy (what I used) needs to be updated to take this into account.

Hi again,
I was successfully able to associate with the access point today after compiling madwifi-ng from the trunk.

Unfortunately I am affected by a second bug "send_packet: Message too long" see also Bug #61989.

I would have to think that this bug can be close if a the latest madwifi-ng package gets included into edgy.

For anyone else who is having this issue you could try following the same directions I followed in order to compile madwifi-ng from the trunk.

https://help.ubuntu.com/community/WifiDocs/Driver/Madwif

Patrick sorry didn't see your comment.
I may be a regression. I did not have the problems either with Dapper at the same WAP.

I have used the MTU work around in bug #61989 and I am now able to access the WAP I could not before.

To whom ever may be looking at this bug. Compiling the latest madwifi-ng from there subversioning trunk will fix this problem.

I can confirm this problems, I have a Thinkpad T60 with an atheros a/b/g wlan-card. Since my school uses quite a complicated (at least for network-manager) wlan setup with wep(!), peap, mschapv2 and so on I have to use wpa_supplicant without network manager.
However, while I have no problems connecting to my home wlan using wpa_supplicant, I need about 10 to 15 minutes connecting to the school wlan until I get an IP. The problem (according to dmesg) is always ath0 "link is not ready". So my current workaround is deactivating and activating ath0 until I get an IP ;)
But I will try the madwifi-ng driver as soon as I'm on a wired network next time.

It seems to be a kernel issue.
I found the same problems - I have wifi0 and ath0 - ath0 is the one that wants to connect and has the wireless extensions -wifi0 dowsnt however the dmesg tells me that is is a wifi card. I have an nc4010 laptop with atheros chipset.

  This only happens if I boot with 2.6.17 kernel. The old 2.6.15 kernel doesnt have the problem... I think the 17 kernel uses a different module... I dont think I will mess with madwifi-ng- or at least not until its stable in the kernel/dist instead I will just use 15 for now.

This problem seems to be resolved with Feisty.

Incorrect, problem persists on my installation of Feisty. Believe it's due to madwifi, however.

Odd. I just brought my Feisty laptop to the location where I originally had the problem and it did not happen.

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!