On Fri, Aug 29, 2008 at 11:17 PM, Sean Crago cragos@gmail.com wrote:
You know, I should probably just ask the list about this:
I've got a well defined interfaces file (follows in the PS), but neither my Ubuntu laptop nor my Ubuntu desktop manages to create a wireless link on boot. It brings up the interface, but it doesn't actually establish comms with my Tomato-powered AP. However, when I just run a simple "ifdown wlan0;ifup wlan0" on either PC, it establishes a good, reliable link and hits the DHCP server with nary a hiccup.
Anyone got an easy fix? I'll gripe and moan until the universe dies its heat death about the age and maturity of Linux not being reflected at all in luser-friendly GUI wifi configuration out of the box (or until it's fixed), but this should be what those apps are doing under the hood, and even it's not working right.
Thanks, Sean Crago Kathmandu
PS: Here's my interfaces file. Pretty much the same on both boxes: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5).
# The loopback network interface auto wlan0 eth0 lo iface lo inet loopback
# The primary network interface iface wlan0 inet dhcp wpa-driver wext wpa-key-mgmt WPA-PSK wpa-proto WPA wpa-ssid 001601842AEE wpa-psk MD5_hash_of_my_WPA2-AES_key
iface eth0 inet dhcp
On Sat, Aug 30, 2008 at 1:23 AM, Sean Crago cragos@gmail.com wrote:
Is there a reason to avoid Network Manager and applets? I've found it works well, but as per the README requires that that specific file be mostly blank!
Justin Dugger
Unfortunately it works so poorly in my specific configuration, works so poorly with secured access points, that the primary tutorials for Ubuntu push users in the direction that I took. It's a damned shame that it doesn't work as seemlessly and easily as it does in the OSS embedded GTK Maemo, but NetworkManager really didn't work for me.
-Sean
On Sat, Aug 30, 2008 at 10:43 PM, Justin Dugger jldugger@ubuntu.com wrote:
On Sat, Aug 30, 2008 at 12:38 PM, Sean Crago cragos@gmail.com wrote:
If you've tested with the latest Intrepid LiveCD, maybe report a bug in Launchpad. As you probably know, some hardware has less vendor support for Linux, but we do what we can ;)
Can you cite the "primary tutorials" you read that moved away from NM? I'd like to read it as well, since I've been spoiled by NM working on my hardwares.
Justin Dugger Ubuntu Member
Sure - Here's one on the subject - May not be the official way to do it, but it worked for me: http://ubuntuforums.org/showthread.php?t=202834
And here's an old bug report on the subject: https://bugs.launchpad.net/linux/+bug/33089
There are multiple forum entries on the subject as well, but they mostly end with lazy half-fixes like the one I put in place (ifdown wlan0;ifup wlan0 in the /etc/rc.local file). One way or another though, it still doesn't make a lick of sense that the ifup script can succesfully work with iwconfig when the system's fully loaded, but can't halfway through. It should have no significant dependencies.
By the way, I've had the same problem on two completely different sets of hardware, too. Full lspci output's in the bug report. Me thinks NetworkManager is just too immature to properly handle WPA2. it's a shame - incredibly simple and clean interfaces are out there and just waiting to be ripped off from myriad embedded Linux projects.
Sean Crago Kathmandu
On Sun, Aug 31, 2008 at 2:04 AM, Justin Dugger jldugger@ubuntu.com wrote:
On Sat, Aug 30, 2008 at 11:01 PM, Sean Crago cragos@gmail.com wrote:
I don't know why you consider that a "half-fix". The computer always boots to full functionality. If you want to call it a "hack" or "kluge", I can agree with that.
Here's my theory on why it's happening: It's not a "dependency" per se, but a timing issue. As the layers of drivers initialize, they return a "successful" status, even though the hardware really isn't quite ready for prime time, because there is nothing left for the CPU to communicate to the card to complete the hardware initialization. The situation is not unlike an application making a system call to write data to disk, which returns with a good status even though the data have not physically been committed to the drive's platters, as it may be buffered in RAM by the kernel, or shipped down the wire to the drive and sitting in another buffer there. The ifup being executed earlier in the init scripts is catching the card in this state, but when rc.local runs a few seconds later, the hardware really is ready to come out and play, so the ifup works.
-
Justin Dugger -
Monty J. Harder -
Sean Crago