On Fri, Aug 29, 2008 at 11:17 PM, Sean Crago [email protected] wrote:
There is one major drawback that isn't specific to any one adapter, though. iwconfig et al are a huge PITA, complicated further by Debian/Ubuntu's underperforming networking initialization scripts. Though I finally do have /etc/network/interfaces defined well enough that it is finally reliably connecting to my WAP upon request, I find myself having to run ifdown/ifup on every boot - Might be able to fix this problem by moving the network initialization script further into the boot process, but I really haven't the slightest idea why.
Unlike competently designed systems such as Maemo (where seemless 802.11 functionality matters a wee bit more than Ubuntu powered laptops with wireless), Ubuntu causes far more problems running over a wireless connection (regardless of the card) than it does over a physical connection. The myriad poorly designed frontends to iwspy are similarly inadequate and, if you'll forgive the repetition, incredibly poorly designed. Don't even get me started on Xandros, and the Eee's half-assed attempt to find a better solution to the aforementioned problem.
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 [email protected] wrote:
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.
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.
# 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
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 [email protected] wrote:
On Sat, Aug 30, 2008 at 1:23 AM, Sean Crago [email protected] wrote:
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.
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.
# 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
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
On Sat, Aug 30, 2008 at 12:38 PM, Sean Crago [email protected] wrote:
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
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 [email protected] wrote:
On Sat, Aug 30, 2008 at 12:38 PM, Sean Crago [email protected] wrote:
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
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
On Sat, Aug 30, 2008 at 11:01 PM, Sean Crago [email protected] wrote:
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.
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.