wireless assistant does not connect in edgy

Ditto. However, when I first upgraded from Dapper to Edgy a few weeks ago, this problem did not occur.

Attached is the console output that shows that while wlassistant fails to run dhclient properly, running dhclient manually works fine.

...oops...forgot to check that little box, even though the file got uploaded...

The dupe was confirmed, so this should be too. I can confirm it personally, anyway. :)

In my case, I just need to do sudo dhclient eth3,

See https://launchpad.net/bugs/65153

*sigh* Now Edgy has been released with this bug. It wasn't a bug a month ago around Knot3 or so. Could we at least get an importance assigned to this? (In Debian we can do that ourselves...)

Strange as my bug (65153 - bundle with knot3) was set as "Medium" for importance...

I'm a little upset/disappointed with edgy flavour as it looks it's not as reliable as dapper... :-/

I think I may have found the cause of the wlassistant not working in Edgy. I have noticed the same problem as well, but I didn't use wlassistant to configure my connection. I just edited the /etc/network/interfaces file so the wifi part reads:

auto wlan0
iface wlan0 inet dhcp
wireless-essid XXXX-XXXX-XXXX
wireless-key XXXX-XXXX-XXXX

This worked just fine in Dapper, however when I booted in Edgy, although my wifi device was detected, it did not connect to the network. However, when I reboot and use the Dapper kernel, wifi works just fine. This would suggest the problems with the kernel and not with wlassistant. Hope this helps in resolving this bug!

Confirmed here. sudo ifup eth1 works perfectly, with the appropriate iwconfig setup for my network. Disappointing, since this worked perfectly last week with Dapper...

Kubuntu 6.10 has wireless work flawlessly after initial installation.
It gets lost after several boot sequences.
The workarounds suggested above did not work in my case.

I have Kubuntu 6.06 installed on the same computer. I therefore copied the contents of /etc/networks/interfaces from Kubuntu 6.06 into file /etc/networks/interfaces of my 6.10 installation.

As of now it works. Wireless is running again in Kubuntu 6.10. For how long I do not know yet.

I can now confirm that my workaround posted on 11/01/06 does indeed work for my installation of Kubuntu 6.10. I have been using the modified 'interfaces' file since then and performed a great number of cold boots as well as regular boot sequences.

The computer boots with the wireless connection already working. I do not need to go to the Wireless Lan Assistant. In fact, I avoid touching it at all cost because I noticed that my system slows down to a crawl whenever I get the Wlan Assistant involved.

My modified 'interfaces' file looks like this:

auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet dhcp

auto eth2
iface eth2 inet dhcp

auto ath0
iface ath0 inet dhcp

auto wlan0
iface wlan0 inet dhcp

#auto lo
#iface lo inet loopback

#auto eth0
#iface eth0 inet dhcp

#auto eth1
#iface eth1 inet dhcp

#auto eth2
#iface eth2 inet dhcp

#auto ath0
#iface ath0 inet dhcp
#wireless-essid xxxxxxxxxxxx

#auto wlan0
#iface wlan0 inet dhcp
#wireless-essid xxxxxxxxxxxx

The section with the entries commented out is the 'original' Kubuntu 6.10 text while the active part of the file is a direct copy of my Kubuntu 6.06 'interfaces' file.

This may not work for everyone but it certainly solved my problem.

Confirmed here. I must add that it eventually works :

Just fire up WLAssistant and connect. It will say connection error. Just let it be. After a while you'll be connected. Weird.

I'm also concerned that this bug doesn't have a priority assigned yet. It is a MAJOR bug for laptop people!

Further to the comment of M. Torres and pursuant to my remarks: I should have kept my mouth shut.
Everything worked fine until I posted my last confirmation of the workaround. Trouble started thereafter.

I still get connected over 95% of the time on booting up. However, if I work too many connections to web sites in quick succession, the wireless connection brakes down. It is difficult, if not impossible, to reconnect using the wireless assistant.

I succeeded by eliminating/erasing the file(s) dhclient.pid followed by a command line sudo dhclient ath0. Works sometimes.
I also found that rebootingfrequently restarts the wireless connection.

In any case, it takes some time for the wireless connection to be (re)established - just as Miguel Torres remarked.

This bug should receive a priority set high. It is a niusance and makes Kubuntu 6.10 hard to use.

Jozo in #ubuntu-devel pointed out this in Debian, which could be related:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375551 wlassistant: Wrong call to dhclient

From #ubuntu-devel:

<StevenK> I know what is going on.
[06:16] <StevenK> wlassistant fires off dhclient, which complains about a zero length PID file on stderr. wlassistant takes any output on stderr as being a problem, and so kills dhclient.
[06:17] <StevenK> The bug can be worked around in wlassistant, however.
[06:17] <StevenK> Which requires learning QT file handling functions.
[06:18] <StevenK> And coding C++.
[06:18] <StevenK> Neither really appeals.
[06:18] <Hobbsee> StevenK: or fix dhclient? nah...
[06:19] <StevenK> Maybe.
[06:19] <StevenK> dhclient sucks a lot, though.
[06:19] <Hobbsee> am i being slow tonight, or do you just have to check if the output on the stderr is about the zero length PID, or nothing else fail?
[06:20] <StevenK> Hobbsee: The point is dhclient should remove it's PID file on exit.
* StevenK will look at a fix in about 5

None of the 'fixes' and workarounds work reliably, including mine.

On booting the connection is established and works for a while but then decides to quit.
Once that happens, I can restore it sometimes using one or the other of the suggested solution.
Simply re-booting appears to be the best of them all.

By the way, I had similar problems with another OS and kppp. In that case, a .pid file was left behind upon closing or losing the connection. No new connection could be made without first erasing this .pid file.

Seems to apply to this situation also. I managed to connect after erasing all .pid files related to wireless.

Hope this gets fixed soon. It is mighty inconvenient. It also makes me think about going to another OS without this problem..

After upgrading to Edgy I've started experiencing unusually long boot times. I suspect that is is caused by the failure of the network initialization. Is it possible to just ignore that init step and still be able to connect throught iwconfig && dhclient? If so, how can I do that?

This bothers me too, so I sat down this morning and made an ugly hack that causes wlassistant to ignore the message about pid files. Anyway, afterwards I was able to connect to networks. I'm not really sure how to make patches, so if I did it wrong, oops.

I have also worked on this, and have a patch that somewhat encompasses Ryan's changes, but also makes wlassistant work for me. There is in fact more than one problem, and I'm sure that the second and third problems would have come up during testing.

The problems:
1. wlassistant fires off dhclient, which complains about a zero length PID file on stderr. wlassistant takes any output on stderr as being a problem, and so kills dhclient.
2. wlassistant then parses dhclient's leases file, which could contain any number of leases, picks the first default gateway and tries to ping it. And gets upset if it fails.
3. Even commenting out that block, it then runs route, and looks for 'default' followed by an IP address, which is only the case if your default gateway doesn't reverse resolve.

Due to these three problems, I think this bug should be solved in Edgy, given it has the potential to affect every Kubuntu Edgy user that runs wlassistant.

Attached is a debdiff which solves all three of these problems. I have tested this (over and over, sigh) and it works for me.

Let me ask a naive question that sounds pushy but is not intended as such. This bug is listed as 'High' in importance and was first reported 10/9/06, over a month ago. However, I see that no one has been assigned to fix the bug. Is that typical or normal under these circumstances? Is there work going on behind the scenes I know nothing about?

I, for one, would really like to get this fixed so I can use my wired connection for its intended machine. Also, I'm going to need wireless to use the machine in the office - right now it's stuck at home.

EB

Changes from Medium to High has been made a few days/weeks ago... ;-)

My ugly workaround was to use wpa_supplicant for network I know (home, professional, etc) so that I do not need wlanassistant except when I'm out of home/office ;-)

Patch looks excellent, testing among Kubuntu developers is successful, subscribing ubuntu-sru to review. (Patch and description in comment from Steve Kowalik at 2006-11-13 12:16:40GMT.)

Finally some very good news indeed.
Now a question from a non-programmer and Linux -Wannabe:

How does one apply this patch to an existing 6.10 installation?

I know the very basics of Unix/Linux but my 'Unix for Dummies' says nothing about applying a patch and debdiffs!

Thanks for sorting out the patch, but I think this says that there are problems with the Kubuntu QA process.

Personally I would consider this bug a release blocker.

In the modern world, internet connectivity is probably the most important function of a laptop.

OK for -proposed, please continue SRU process

Accepted into edgy-proposed. Steve, please notify the QA team via Simon Law to verify that this bug has been fixed and that there are no regressions.

Please also upload a similar fix with a newer version number to Feisty. At some point, I would prefer that the messy textual check for dhclient's pid file confusion be replaced with something better; grepping stderr for particular error messages is just nasty. I'd suggest filing a bug about this.

I was planning on fixing this issue by changing the patch to dhclient to not complain about stale PID files. However, after I did that, it became apparent that wlassistant had further problems, and I made the decision that it would be easier to make wlassistant just cope with dhclient complaining, at least in the short term.

wlassistant 0.5.5-0ubuntu4 has been uploaded to Feisty, and has built on all arches.

So for us newbie users, what does this mean? Is there a patch uploaded? How do I fix the wireless problem?

Thanks.

EB

In the Adept Package Manager, navigate to 'Manage Repositories' and add 'deb http://archive.ubuntu.com/ubuntu edgy-proposed main restricted' and then update your sources. That should show updates to among other things, wlassistant. If you could please comment here on whether or not it solves the problem, that would be great.

Added the repository and updated wlassistant.

* Booting the system with dhcp and a network defined lasts long and does not connect (static works)
* Deactivating the module and reinserting does not connect
* Using wlassistant not works perfectly

In my opinion the patch is ok but there is another dhcp problem.

Added repository and updated wlassistant as suggested.
Rebooted.

Wireless working; wlassistant shows active connection.

However, I cannot tell whether this is a result of the update. Most recently, my wireless access has worked again reliably at each and every reboot.

I will disconnect now and then reconnect via wlassistant. Report back results.

Disconnected active connection.
Reconnected repeatedly and successfully to access point with MANUAL SETTINGS.

Attempts to reconnect to a different access point (set to automatic) repeatedly failed.

Manual works, automatic (DHCP) most likely not.
Furthermore: Upon manual reconnection the wireless connection was establlished but attempts to open several websites failed.
"Server could not be found."

I noticed this before: Whenever I disconnect a connection that was established at boot up and then reconnect successfully 'server not found' is an error with the browser and Thunderbird e-mail.

It appears that the DNS is not found or activated.

Steve,

I'm a little concerned about that usleep() in the patch, as there could be a race in there. A slow machine could fail.

Is there some better way you could ensure that dhclient has done the Right Thing? Like wait for it to exit properly?

Simon,

Unfortunately, you can't check if dhclient has done the Right Thing, since it daemonizes, and stays put in the background. The value of 150ms was picked since there was a call to usleep in the code that specified it, and I shifted it to be called just after dhclient. I see your point, perhaps a loop that checks if an IP has been assigned, sleeping for 100ms, and dropping out and screaming after 5 seconds?

Steve,

As we discussed on IRC, it looks like that usleep() is actually superfluous. dhclient goes into the background only after it's done the right thing.

Please update the status of this bug report to Fix Committed when the appropriate package lands in -proposed. You may opt to keep that usleep() in there, for the purposes of efficiency.

Simon

Simon,

I'm opting to keep the usleep() for the moment, just to save the hassle of preparing another upload. I have set the bug report to Fix Commited, as 0.5.5-0ubuntu3.1 has landed in edgy-proposed.

Tested to work with dhclient in edgy-proposed. Does not cause regressions in wlassistant functionality from Edgy.

Ready to go into -updates after the seven day waiting period.

I would suggest that you just uninstall wlanassistant and use knetwork manager instead. With a few simple file edits, you can have it up and running in minutes. It supports WPA1 and WPA2. It also puts an icon in the system tray for easy use. Follow this link for instructions. All you have to do is change the "gedit" command to "kwrite". It works like a charm. note: you must have wpa_supplicant installed for wpa support!
http://www.debianadmin.com/enable-wpa-wireless-access-point-in-ubuntu-linux.html

I have a related problem.
I installed my Edgy from CD letting all peripherals on in order to be detected. I have an eth0 interface and a wlan0 interface recognized well by Dapper. In Edgy the wlan0 interface is recognized as eth1. I'm still not able to connet via wireless. When I start knemo it shows the connected icon of eth0 (for the normal router) and the disconnected icon eth1 (should be my usb adapter, which is wlan0 under Dapper for the wireless router) in the tray. When I follow the guide about installation of wireless I have to comment the line in /etc/network/interfaces file

auto wlan0
iface wlan0 inet dhcp
wireless-essid XXXX-XXXX-XXXX
wireless-key XXXX-XXXX-XXXX

this makes however no sense since the wlan0 is not recognized and since it has been replaced by the wrong interface eth1. I should maybe comment the other line where auto eth1 is located...

Upload verified and accepted for edgy-updates.

I have been having the same problems in the Dapper (stable) release.
I've been using various bash scripts to fix the routing problems. I installed
the 'wffi-radar' wifi manager and it worked right off. No more scripts.
I would suggest that you look at how 'wifi-radarr' solved these problems.

I my last post, I made several spelling errors.
The wifi manager that works is 'wifi-radar'.
YumaJim

I just wanted to report that I installed the current nvidia driver manually
after I got it on there website. It solved the problem. Till I have another
kernel upgrade at least :-)

2007/3/2, Michael Vogt <email address hidden>:
>
> ** Tags removed: verification-needed
>
> --
> wireless assistant does not connect in edgy
> https://launchpad.net/bugs/64841
>

--
Martin Hamel
(418)261-2222
<email address hidden>

wifi-radar doesn't work any better than the others for me.

I'm finally trying out linux, and this supposedly user-friendly distro doesn't come with wireless? Or did I get the wrong distro, or something?

I've noticed typing 'sudo dhclient' will sometimes connect to a network but I don't get to pick which one. The network in my house has a WEP key though, so I need some way to select it and provide the key...

Umm, I see it says fix released. How do I get the fix? Thanks a bunch, guys!

Try the info at : https://help.ubuntu.com/community/KeepingUbuntuUpdated

I did that. It worked for a while and then quit.
Impossible to do it again because I cannot connect to the Net.
Only 6.06 still has wireless going.

Andrew Ash wrote:
> Try the info at : https://help.ubuntu.com/community/KeepingUbuntuUpdated
>
>

I'm using kubuntu, not ubuntu, so I don't seem to have that program. Is there some way to do it with adept? Adept currently says I have the most current version of wlassistant (0.5.5.0ubuntu3.2)

I'm also using kubuntu and still having the above mentioned issue. I have recently upgraded from Dapper 6.06 to Edgy 6.10. Can someone please tell me (a fairly worn newbie) what steps to take to fix this issue. I am using my PC wirelessly and a friend (who is new to Linux) is using his laptop. We are both frustrated at the way this problem is ruining our Ubuntu experience.

Jwednesday wrote:
> I'm also using kubuntu and still having the above mentioned issue. I
> have recently upgraded from Dapper 6.06 to Edgy 6.10. Can someone
> please tell me (a fairly worn newbie) what steps to take to fix this
> issue. I am using my PC wirelessly and a friend (who is new to Linux)
> is using his laptop. We are both frustrated at the way this problem is
> ruining our Ubuntu experience.
>
>
I stopped worrying about wlassistant and changed to knetwork-manager,
which supports not only WEP, but also WPA encryption.

Thank you for your response. Will it work if you only have Ubuntu installed or do you have to have Kubuntu?

Jwednesday wrote:
> Thank you for your response. Will it work if you only have Ubuntu
> installed or do you have to have Kubuntu?
>
>
There are some similar, non-kde packages like network-manager and
network-manager-gnome. It should be the same.

-Pablo