Getting networking up and running on the T60p has been a mixed bag. On one hand, the wired connection was easy (expected). The wireless was at first REALLY flaky, then after some fiddling the connection at home (WEP) was functional, and as of now (when I’m finally posting this thing) it still doesn’t work at work (LEAP).
I set the wired connection (using e1000 module) up with netplug so that it will figure out when the cable is and isn’t there – it has the added bonus of scheduling net-dependent services at startup.
For whatever reason, this laptop does not have an Intel wireless chipset. The Atheros AR52121 that it does have requires the
I also need WEP and LEAP, so I use wpa_supplicant as well.
At first, wpa_supplicant would drop the connection after a few minutes. I couldn’t find anything conclusive about why this was happening, but the one thing I did find suggested using the generic interface (wext) with wpa_supplicant rather than madwifi2. No change.
When at home using WPA, the connection cycled frequently (sometimes as frequently as once every 4 or 5 minutes). When at work trying to use LEAP, it wouldn’t correctly establish a connection at all. :sigh:
I think I was suffering from a known bug3, so I created some new ebuilds for the 1605 version of madwifi-ng. That seems to have improved the resilience of the connection considerably.
I still am having trouble with rotating through connections and associating via LEAP at work. I have been using ap_scan=2 because of hidden SSIDs in the office, the problem is that this forces profiles to be tried in order, and when wpa_cli fails on the first one, it seems not to automagically roll over to the next (which previous versions of wpa_supplicant did just fine.. )
I’ve found some evidence4 suggesting that ap_scan=2 won’t work because madwifi-ng doesn’t support it. Lovely. But! There is hope5 a patch was added to the madwifi driver at a later level than the one I had to revert to.
I haven’t retried wireless at work recently. I’ll post more when I do.
— update 2007 Jan 5: madwifi-ng-0.9.2.1 should also include the association fix… I am now using madwifi-ng-0.9.2.1 (r1842), and that seems to work as well.