Wireless network keeps reconnecting (ubuntu edgy)

Attached log file here as well.

I'm having the same problem (frequent disconnects).
- I have an ipw2100 card.
- The WLAN uses WPA encryption.
- I'm using the gnome nm-applet.
- Using wpasupplicant or Windows I get no disconnects.

I have the same disconnect/reconnect issues running Edgy on a Dell E1505 laptop with ipw3945 wireless card connected to a WPA network. It seems to be something concerning wpa_supplicant trying to re-authenticate. The network works, but it hiccups every 5-15 seconds, making it very choppy. For some reason this seems to happen whether I try connecting to a WPA encrypted network, or even an unencrypted network.

I can get a steady wireless connection easily though.... by simply closing NetworkManager and editing /etc/network/interfaces to include my WPA key information. Then just starting eth1 normally, not using NetworkManager. But I like the ease of use NM provides, so I'd like to get it working.

Looking at log files I get the same reoccurring messages in a perpetual loop. Something about eth1 timing out, then WPA trying to reauthenticate. I attached daemon.log kern.log messages and syslog, these are the ones I see reoccurring entries in for this issue.

Same problem here. The reconnects do not occur on WEP encrypted networks. I usually do a "kill -STOP" on pidof Network-Manager now, to prevent it from dropping my link every other minute! Sucks, sucks, sucks.

I have the same problem on a Thinkpad X60 tablet running edgy. My wireless adapter is AR5212 802.11abg, network manager disconnects and reconnects to the same wireless network every ~20 sec, but wireless works fine using just wpa_supplicant. Here is a snip of daemon.log around the time of reconnect:

NetworkManager: <information>^IActivation (ath0) Finish handler scheduled.
NetworkManager: <information>^IActivation (ath0) Stage 5 of 5 (IP Configure Commit) complete.
NetworkManager: <information>^IActivation (ath0) successful, device activated.

[ now connected, correct IP has been set by DHCP ]

NetworkManager: <information>^Iath0: link timed out.
NetworkManager: <information>^ISWITCH: found better connection 'ath0/lart' than current connection 'at
h0/lart'. same_ssid=1, have_link=0
NetworkManager: <information>^IWill activate connection 'ath0/lart'.

Seems like the problem is network-manager decicing that the link has timed out when it is probably just fine (?).

Hi again,

Unfortunately this bug is still alive and kickin' in the current 7.04 beta (Feisty).

These disconnections do not usually interfere with network use, but it's an annoying issue anyway. Is anybody working on fixing this?

After some more testing I am more ready than ever to blame network-manager for this; I have used kwlan (which uses wpa-supplicant directly) for the wlan configuration for some time and I got 100% reliable wlan connectivity with that setup.

System info. etc - see the first comment in this bug. Tested version of network-manager: 0.6.4-6ubuntu2.

Best regards,
Lars

I think I sort of found the root cause for this reconnection thing:

I keep getting this in syslog:

---8<-----8<-----8<-----
SWITCH: found better connection 'eth1/AF2' than current connection 'eth1/AF2'. same_ssid=1, have_link=0
---8<-----8<-----8<-----

Apparently this is a network switch reconsideration failure. Somehow the manager thinks one and the same AP is better than itself and it needs to switch. This is kind of schizophrenic behaviour. PLEASE get it fixed. It IS a pain!

Just for the records: This bug has been filed as Bug #78181 for the kdenetwork and knetwork-manager, too!

I had a look at the source, now.

The reconnection is apparently caused by a temporary loss of the wireless link while the network detection code finds out that the AP is still online. It appears like some combinations of cards/APs are especially prone to temporary link outages, if you google for reports. Intel drivers in particular.

To me it looks like there are two possible solutions for this:

1) Never let the code decide to reconnect to an AP to which it already IS connected! (link or not). Because the idea is just silly. If the link is gone then the situation will probably not improve by resetting everything. Or, at least, introduce a very, very generous timeout of about 20 to 30 seconds and wait for the link to get up again by itself (which usually happens in this situation):

2) Just increase the timeout for link losses generally (this is the easier way). Ideally this should be adjustable at least via gconf but like with most things that should be adjustable in network-manager a stone-age-style hard coded constant is being used.

For the time being, I changed src/nm-device-802-11-wireless.c, line 2318

from
        self->priv->link_timeout = g_timeout_source_new (8000);
to
        self->priv->link_timeout = g_timeout_source_new (20000);

which basically is a shot at method 2).
To try method 1) I would need to dig and understand more code so I left that one alone for now.

The timeout extension seems to fix the problems for me, it seems. I am going to let this settle for some days and if I get no more nagging reconnects, I'll make up a patch (probably including a gconf key because the current solution just sucks).

Hi!
Thanks for your feedback! =)
I don't see the exact error message you refer to on my laptop, but I think it may be related. See the attached log excerpt - I still get more or less that very same sequence of messages when this occur. For some silly reason NM seems to want to blacklist my AP immediately after every scan request.

I would definitely be interested in trying your patch if it comes to that. Are you doing it against the current NM version in Ubuntu?

Thanks & Best Regards,
//Lars

Hi,

I just saw a patch re-submitted on ipw2100-devel ML for ipw2200 cards, which seems still necessary with latest linux 2.6.20 kernels.
The comment says:
    /* Do not force reassociating if the new essid is the same as the
     * current one and we are already associated.
     */

Can't test - but it sounds like this bug.

At least I dont have ipw2200 but ipw2100. The other thing is: the reconnects dont happen when I dont use network-manager, e.g. with wifi-radar oder direct use of wpa-supplicant, no problems. So the driver may be involved in triggering the problem but probably isnt the only cause of it.

I have had the above patch running flawlessly for about two days now and I will likely submit the fix tonight right here.

As promised I am releasing a patch that seems to help at least on my system, as far as I could test yet. the patch is for the current feisty source. The patch also includes a little fix for Bug #91698 which makes backporting easier.
If you remove the top 47 lines from the patch, the patch will also apply to the edgy source tree.

Just apt-get source, apt-get build-dep, patch and dpkg-buildpackage. Dont blame me if things get stuck.

As you can read in my earlier posts I originally intended to make the timeout configurable via gconf. I dropped this idea for now since network-manager itself is not capable of using gconf at all. It receives all its configuration via dbus command sequences. So I hacked "nm-tool" to include an option for setting the timeout. Feel free to add the functionality to the gnome applet - it can store the settings via gconf then.

Once you have applied the patch you can set the reconnection timeout to e.g. 20 seconds when NM is running by issuing the following command:

#> nm-tool --set-timeout 20000

You can do this automatically in a script and even adjust the timeouts for different connection situations.
Just drop the script in /etc/NetworkManager/dispatcher.d/
See also "man NetworkManagerDispatcher" for info

Happy patching. And report back if it does not do you any good!

Fionn,

Thanks for the patch. I have it running on Edgy for now. I've run out of time to test it throughly tonight, but for the first fifteen minutes, I can definitely say it is working. :)

I want to post the more precise sets I used for the patch and upgrade process on Edgy, in case someone less technical also wants to try it out. Once I'm able to test it for longer, I'll provide morem feedback about how well the patch works on Edgy. Thanks again!

gunzip reconnect-timeout.diff.gz

# manually trim out the first 47 lines
gedit reconnect-timeout.diff

sudo apt-get install dpkg-dev
sudo apt-get source network-manager
sudo apt-get build-dep network-manager
cd network-manager-0.6.3/
sudo chown -R $USER .
patch -p1 <../reconnect-timeout.diff

# vim manually create a new changelog entry and bump the version number
# be careful to follow the format carefully!
gedit debian/changelog
sudo dpkg-buildpackage
cd ../

# this assumes all the ".deb" files generated are related to your project
sudo dpkg -i *.deb
cd network-manager-0.6.3/
./test/nm-tool --set-timeout 20000

I'm having this same problem on up-to-date Feisty with Intel PRO/Wireless 2200BG.

I have now had more time to test the patch on Ubuntu Edgy and can confirm it works wonderfully. Without it, I experienced a disconnect/reconnect within a minute.

With it, no disconnects have happened.

  Mark

Hi Fionn,

Thanks for creating the patch. Have you sent it to the NetworkManager team?

Margaret

On Mon, 2007-03-26 at 19:38 +0000, Margaret McGaley wrote:
> Hi Fionn,
>
> Thanks for creating the patch. Have you sent it to the NetworkManager
> team?

Margaret,

There is a corresponding bug in the NetworkManager bug queue upstream,
and I've made them aware of this patch.

In the short term, I could publish the ".deb" packages I made from
Fionn's patch, which have been working great on Edgy.

Unfortunately, the NetworkManager developers haven't responded so far
about whether they will include a variation of this patch or not. If you
look at this ticket through the web on Launchpad, you'll find the links
to the upstream bug entries.

  Mark

Hi Mark,

Thanks for getting back to me. I should probably just follow the
instructions on the thread and maybe learn a little something about
patches :)

Margaret

On 3/26/07, Mark Stosberg <email address hidden> wrote:
> On Mon, 2007-03-26 at 19:38 +0000, Margaret McGaley wrote:
> > Hi Fionn,
> >
> > Thanks for creating the patch. Have you sent it to the NetworkManager
> > team?
>
> Margaret,
>
> There is a corresponding bug in the NetworkManager bug queue upstream,
> and I've made them aware of this patch.
>
> In the short term, I could publish the ".deb" packages I made from
> Fionn's patch, which have been working great on Edgy.
>
> Unfortunately, the NetworkManager developers haven't responded so far
> about whether they will include a variation of this patch or not. If you
> look at this ticket through the web on Launchpad, you'll find the links
> to the upstream bug entries.
>
> Mark
>
> --
> Wireless network keeps reconnecting (ubuntu edgy)
> https://launchpad.net/bugs/64173
>

Edgy 6.10 worked fine on my box.

Feisty 7.04 beta does not connect to my WEP-encrypted network.

Here's some useful data: I was able to connect to my neighbor's unencrypted (and very weak) wifi signal intermittently as a test. My guess is that Fawn isn't storing properly the WEP password.

On Do, 2007-03-29 at 02:10 +0000, pterandon wrote:

> Edgy 6.10 worked fine on my box.
>
> Feisty 7.04 beta does not connect to my WEP-encrypted network.
>
> Here's some useful data: I was able to connect to my neighbor's
> unencrypted (and very weak) wifi signal intermittently as a test. My
> guess is that Fawn isn't storing properly the WEP password.

This report does not sound like it is related to this particular bug.
More like some problem with wpa-supplicant or gnome-keyring. Keep in
mind that network-manager itself does no key management by itself at
all. It uses the mentioned external programs for that.

Fionn

Hello folks. I wanted to report my experience with the patch by Fionn. In the three days of testing it on Ubuntu Fiesty with NetworkManager 0.6.4, I can report that it does help significantly but has not completely eradicated the problem in my case. Over the last 16hrs (roughly) of computer usage, I can remember two drop-out/reconnects. Compare this to one every 5-15 minutes (or less) and progress has definitely been made. I'll watch /var/log/messages for changes during a reconnect even in the future.

This message will be reposted under Bugzilla GNome #418065 as well.

Matt

As promised, here is a reconnect event /val/log/messages output:

Apr 8 09:52:14 squid-linux kernel: [ 2871.588823] ADDRCONF(NETDEV_UP): ath0: link is not ready
Apr 8 09:52:16 squid-linux kernel: [ 2873.894889] ADDRCONF(NETDEV_CHANGE): ath0: link becomes ready
Apr 8 09:52:22 squid-linux dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.host_name
Apr 8 09:52:22 squid-linux dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.domain_name
Apr 8 09:52:22 squid-linux dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.nis_domain
Apr 8 09:52:22 squid-linux dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.nis_servers

I seem to have issue installing the suggested temporary timeout patch.

The network-manager version on my system is network-manager-0.6.4 instead of .3 I suspect that could cause the patch to fail when trying to apply it.

If you could confirm and / or update your fix it would be greatly appreciated.

Issue on my side is happening on a

Toshiba Tecra S1 1.5
2100B card
7.04 ubuntu fresh install + updates

Best Regards,

Simon

It appears like the upstream developers didnt feel like incorporating the patch into their code - despite the positive feedback.
I do not have the time to adapt my patch to new upstream code every other day. So, if their code does not work for you because they dont include redily submitted fixes, please COMPLAIN TO THEM. I'll happily compile a new patch as soon as I know they will actually use it.

I really do hope you didn't take my reply as a complain. It was far from being the objective. My goal was mainly to figure if my patching problem was related to the new version they released.

Thanks a lot for your quick reply,

Simon

I did not take it as such. I was just voicing my slight disappointment about the fact my efforts to bring forth a fix that could easily be adopted by the developers were apparently futile. I will put up my fixed debs at http://fionn.de/software/debian/ tonight (which is about 6 hrs from the moment I posted this). You may want to subscribe there tomorrow and download the latest fixed package until the original works for you again. Dont expect me to keep up with unbuntu packaging cycles on a regular basis though. I tend to keep using a fix for as long as it works for me.

Heh, same thing happens to me too. I'm on ipw3945. for the strange part:

I can use it for days without problems, but if my brother in the room next to mine, powers up his Windows computer (with ipw2200), both me and him get disconnected. It looks like this is major problem in ipw2200 (both windows and linux).

I would suspect that the last post is probably closer related to mutual RF interference than to a software problem.

Hi Fionn,

I still am unfamiliar with key signing repository but it seems like I need a .asc file to be able to sign your repository. The command posted on fionn.de/software/debian does not work for me.

Let me know please

Thanks a lot

You dont need to sign anything to use any repository on the net. The signing key importing procedure is just optional, to avoid warning messages about unknown signing keys. Please do not post inquiries on this bug thread about topics which are not related to the original network manager bug.

This is just to confirm that I can reproduce this problem on a Thinkpad T42 with an ipw2200 card connecting to an SMC SMCWEBT-G in access point mode, using WPA1. I can also verify that I do not see this problem when rebooting the Thinkpad into Windows XP.

To follow up on myself, this is with Ubuntu 7.04, upgraded from 6.10 yesterday with update-manager, and up-to-date packages as of this morning.

Well, seeing as this issue remains unresolved, I thought I'd mention that the temporary workaround found in a similar bug #37821 has helped relieve pain for me.

$ sudo wpa_cli
> ap_scan 0

It's also worth noting that this has been an issue for over a year now according to just launchpad.net bug reports, and perhaps even 2-3 years by google's search results.

I'm running the Netgear WG311T PCI card with Atheros chipset myself. Both of the workarounds posted here and in the above mentioned bug report have helped me temporarily. Perhaps either could be incorporated into a future network-manager/mad-wifi version?

Mowerm,
by temporary do you mean it has to be done every boot-up?
Thanks
Stu

Also, is there anyway to use another system in Feisty than network manager?

mowerm wrote:

> $ sudo wpa_cli
> > ap_scan 0

Well, on my system, this yields:

Could not connect to wpa_supplicant - re-trying

Then, nothing happens until I press Ctrl-C.
So this doesnt seem to be a fix for people who use network-manager to drive wpa_supplicant.

I'd also like to point out that THIS bug has initially been reported by an Intel Wifi user. It is NOT a specific atheros/madwifi issue!

I also received the "Could not connect to wpa_supplicant - re-trying" message. At this point when I entered ap_scan 0, hit enter, then ctrl+c, my network stopped dropping. (Still, I may have performed a disservice by not testing a solution for several days before posting)

I took it for granted that the Intel card was using an Atheros chipset, I should have thought about this harder. Sorry to suggest this was only atheros/madwifi specific.

I've since removed network-manager through synaptic since I only associate with one wireless network on this computer. All of the configuration settings were retained so I still connect to the network on boot-up. There have not been any drops/re-associates since doing this. (I realize I wouldn't see any balloon messages, but I don't notice any connection issues on the network or internet, as well as /var/log/messages being devoid of reconnect messages)

I encourage those interested in this ticket to consider commenting on
the upstream ticket, in the Gnome bug tracking system:

http://bugzilla.gnome.org/show_bug.cgi?id=418065

At least one developer for NetworkManager receives the bug mail from
that, but I'm not sure that any NetworkManager developers are following
this bug report.

In that bug report, I offered to loan a developer an affected card so
they can work on the issue, but so far none have responded to take me up
on the offer.

( And Fionn: thanks for your alternate packages for Feisty. However, it
seems they no longer appear as option to install because the revision is
older than the latest official one. )

   Mark

Regarding the package versions problem: You can always decide which version of a package you want to install. To do this in Synaptic you click on the package you want to install, then you choose "force version" from the menu "Package" (or press Ctrl+E) and choose what you want to have. On the command line you list your available options by typing:

#> apt-cache policy network-manager

Then you choose which version you want to install and do so by typing

#> apt-get -f install network-manager=x.y.z-ubuntuN <--- preferred version as reported by above cmd
for example
#> apt-get -f install network-manager=0.6.4-6ubuntu3f

As I already mentioned I dont have time to keep up with ubuntu release cycles. I'll release an update whenever the package will break for me (e.g. must be updated because it keeps other software from installing or running properly).

I've recently reverted back to the network manager package offered by Fionn after he explained the process of forcing a version in synaptic. Setting the timeout to 30000 (30sec) has prevented disconnects (completely so far). Is there a public forum where we can ask stupid questions about the patch and other possible solutions so people like myself aren't cluttering official bug reports? linuxquestions.org maybe?

It strikes me that the patch is perhaps not being applied for
political reasons. What's important is that the highest proportion of
users are able to utilise Ubuntu. It's unfortunate but true that users
don't really care about the how and why of the politics, only that the
system works....

Can we not please get this patch applied? This is silly.

Chris

Hello Scott,

From the ChangeLog for the NetworkManager Ubuntu package, it appears you put
together the most recent release.

However, I don't see your name as "watcher" of this critical bug filed against
the package:

 https://bugs.launchpad.net/bugs/64173

Upon reviewing it, you'll find that it affects many people, and that a patch
has already been prepared and tested.

Would you review the issue and incorporate the patch or provide further
comment?

Thanks!

    Mark

Hi all,

Although I am the guy who created this bug report, I'm beginning to feel like I have to come to the defence of NetworkManager here.... :)

The issue that I had with the WLAN in Edgy was that the network link would seem to be interrupted for some very short time now and then - ie like if you pull the cable from a network card for some fractions of a second. This did not seem to happen when some other similar network manager program was used (kwlan, for example) so I put the blame on NetworkManager - wrongly, I now think. I would now guess that it was due to some ipw2200 driver bug, which by the way seems to me to have been fixed by now - if it still happens I have not been able to detect it.

I have never seen networkmanager completely break an existing connection with an access point and go through the whole interface setup procedure, renew IP-addresses, etcetera. Granted, KNetworkManager can be somewhat tricky to use at times, but when it has established a connection it is rock solid from there on.

My apologies if the initial report was not clear enough about the exact problem I had. I guess it may be the case that some of you who have added to this bug report have seen a different problem.

I have seen some behavior similar to my initial problem on another laptop I have (the WLAN "hangs" for a second or two now and then) but this laptop (an LG M1, Intel 3945, ipw3945 driver) has proven generally Linux-unfriendly so I am not yet ready to put the blame on Ubuntu for this. Except for those annoying short lockups, the wireless network software and notably networkmanager itself seems to work perfectly fine.

I guess my point is that Networkmanager at this time actually works very well, at least for me, so it can't be completely broken. Unfortunately I have no tips, tricks or good explanations for those of you who have more trouble with it than I have had...

Best regards,
Lars

My problem is gone too. Problem was in two or more networks on the same
channel. AP was restarting randomly - problem wasn't caused by NM or
ipw3945.

Ante, I allmost thing the 3945 isn't one of the affected cards. I just replaced my 3945 yesterday and only got disconnected from the wireless once since then. I moved the access point from channel 9 to 6 and it's been 12 hours without a single disconnect. Meanwhile, my ThinkPad (Atheros) is still useless unless plugged in to the network, it can't maintain a connection.

Lars M Bengtsson wrote:
>
> Although I am the guy who created this bug report, I'm beginning to feel
> like I have to come to the defence of NetworkManager here.... :)
> [...]
> I have never seen networkmanager completely break an existing connection
> with an access point and go through the whole interface setup procedure

Well, I have experienced exactly this and it still happens regularly
when I dont change timeouts. Interesting enough the problem seems to be
gone sometimes (rarely) after a reboot for some time but then I suspend
and change networks and when I come back the disconnects are there
again. In the worst case NM actually interrupts and reconnects about
once a minute which renders the connection basically unusable.

>From what I read here, I am not quite the only one who had this problem.
So, although I am glad for you that your problems have gone away, there
are apparently still some for a significant number of users.

> [...] NetworkManager can be somewhat
> tricky to use at times, but when it has established a connection it is
> rock solid from there on.

Not true for everyone.

> My apologies if the initial report was not clear enough

I think there is no fault whatsoever on your side. Although the original
intent of your report might have shifted somewhat due to the numerous
additional comments, there still IS a problem here that isnt fixed.

kind regards,
  Fionn

Just want to add a "I have this problem too".
I have a Netgear WG511T wireless card on an IBM Thinkpad A31, running Gutsy.

I found that quitting Network manager, then disabling roaming and manually setting up the wireless connection through the Network screen works fine. Once I did this I haven't had any downtime.

Charl

Hello Alexander,

From the ChangeLog for the NetworkManager Ubuntu package, it appears you put
together a recent release.

However, I don't see your name as "watcher" of this critical bug filed against
the package:

 https://bugs.launchpad.net/bugs/64173

Upon reviewing it, you'll find that it affects many people, and that a patch
has already been prepared and tested.

Would you review the issue and incorporate the patch or provide further
comment?

Thanks!

    Mark

if the patch proposed in https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/64173/comments/55 helps, then the next gutsy upload will bring a cure for you. I will bump connection timeout to 20 seconds (up from 8) hardcoded. For the patch ... its much appreciated, but making a user-defined variable out of this isn't the right way to go imo. In the end it would only help expert users, which is not what we want.

Alexander Sack wrote:

> For the patch ... its much appreciated, but making a user-defined
> variable out of this isn't the right way to go imo. In the end it
> would only help expert users, which is not what we want.

Well, changing a hardcoded value to some other hardcoded value isnt
exactly elegant, too. The patch creates the possibility to e.g. have an
"/etc/default/network-manager" file, store the timeout there and have it
set in the dbus startup script for network-manager.

That sure is a little more complicated but next time the timeout doesnt
fit the setup of someone, it will be as easy as starting a text editor
for them to have it fixed.

More so if you would place a hint in the not yet existing man-page for
network-manager (possibly along with some instructions on how to restart
network-manager properly because it tends to get stuck on some dbus
queue congestion issue after some quite large number of reconnects. I
really should file a bug on that and the missing manpage).

kind regards,
  Fionn

On Mon, Jul 30, 2007 at 12:20:11AM -0000, Kansei wrote:
> Also confirming that this still exists in Gutsy Tribe 3..
>
> confirmed on:
> ThinkPad T42 (IBM A/B/G Atheros / madwifi)
> Dell Latitude D620 (Intel 3945 ipw3945)
> Vaio S-series (Intel 2200 ipw2200)
>

Can you please try if manually setting essid of your network device to
"" (nothing) helps if you do that right before attempting to connect
through network-manager?

Would be great if you could try on all chipsets you have listed above.

Thanks,

 - Alexander

On Sun, Aug 05, 2007 at 05:49:53PM -0000, Fionn wrote:
> More so if you would place a hint in the not yet existing man-page for
> network-manager (possibly along with some instructions on how to restart
> network-manager properly because it tends to get stuck on some dbus
> queue congestion issue after some quite large number of reconnects. I
> really should file a bug on that and the missing manpage).

That bug might be fixed in next gutsy upload as well.

 - Alexander

The patch at https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/64173/comments/12 actually didn't work for me. I still get all the disconnects.

Everything works like a charm if/when I run wpa_supplicant and dhclient3 manually.

Turbo Fredriksson wrote:

> The patch at https://bugs.launchpad.net/ubuntu/+source/network-
> manager/+bug/64173/comments/12 actually didn't work for me. I still get
> all the disconnects.

I hope you have understood that the patch itself will not change
anything in network-manager, unless you use nm-tool to increase the
timeout values at runtime. So if you just patched your source and
nothing else, everything will be like before.

kind regards,
  Fionn

I will try manually setting the ssid to blank on the chipsets mentioned, and can try it on three additional cardbus cards I have as well --a dlink (atheros), a linksys (broadcom.. seems to work a-ok with networkmanager in ubuntu), and a Belkin (unsure on model/chipset).

When you say set it manually.. do you want me to do this through networkmanager (i.e. 'connect to a different network' or however it is wordered, then specify a blank ssid and attempt a connection), or via ifconfig/iwconfig?

I know Fionn. I've even tried 60 seconds, but still the same...

My negative report might have beenpremature... It seems like it's working as it's supposed to now.
I only get a few disconnects now. I'll try without the --set-timeout value again and see if the disconnects come back.

This seems to have been fixed in network-manager 0.6.5-0ubuntu9.

No, it is still present in network-manager 0.6.5-0ubuntu9

Boris, Can you please open a new bug report and discribe your bug again and please attach the output of lspci -v and attach the file /var/log/syslog to the new bug report. Thank you.

Done so: https://bugs.launchpad.net/ubuntu/+bug/144520

I've had the same problem for a long time now (since edgy, maybe before) but I believe I managed to find a temporary solution. Before I go on, I must say that NetworkManager 0.6.5 **did not** fix the issue for me.

But then I noticed that my logs always mentioned something about IPv6 near the place where the re-connects were occurring. So I decided to try turning off IPv6 by editing /etc/modprobe.d/aliases, changing the line...

alias net-pf-10 ipv6

...to...

alias net-pf-10 off ipv6

...then I restarted the computer.

It's been running fine for 2 days now. Given that the re-connects used to happen every 15 minutes or so, it appears that it's all fixed now.

I just did a clean install of Gutsy. The problem persists, and disabling IPv6 (as shown above) still circumvents it.

What's the status on this bug report anyways? I don't see much action...

This seems to be fixed in Hardy.

no, i have a similar problem since some days running 8.04 native on my macbook pro (santa rosa). i am using the wireless workaround from the wiki: https://help.ubuntu.com/community/MacBookPro#Wireless and it was working stable for some month but now the connection is going down many times per hour. a reconnect is not possible. the connection to the router is still there but i have no connection to the internet. i have to deactivate the wlan interface (e.g., using nm-applet 0.6.6) and activate it again. then i have a connection for some minutes and so on. this does not happen if i boot mac os. i am using wpa and madwifi.

from the user.log:

Jul 31 22:10:39 simbox dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.host_name

Jul 31 22:10:39 simbox dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.domain_name

Jul 31 22:10:39 simbox dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.nis_domain

Jul 31 22:10:39 simbox dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.nis_servers

Jul 31 22:10:39 simbox dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/ath0 for sub-path ath0.dbus.get.interface_mtu

setting alias net-pf-10 off ipv6 does not work for me.

setting the router from '802.11g and 802.11n' to '11g only' solved the problem. imo it is a madwifi issue.

Can confirm this on 8.04 i386. The nm configuration does not work, the wlan (rt61) cannot be disabled, awakes seconds after deactivation. Under this circumstances the lan connection looks activated but does not work. I have to unplug the pccard, then windoze alike switch2 times lan on or off to catch my network.
wlan is running in 11g only mode from my vigor. The profile option in nm does not really work.

whatever reactivate wlan automaticly, should be disabled when nm is installed on the system.

Eric

which driver/chipset does your wifi use?

Hi,

after an dist-upgrade from hardy to intrepid ibex i had the same problems. After studying some googlehits and bugreports I found a solution that seems to work for me:

1: removed all network manager * (core, gnome, kde)
2: removed wpa_supplicant
3: installed ubuntu_desktop

-NM and wpa_supplicant are interfering each other.
-To have it clean either install gnome or kde NM.

Thanks for your good work@ubuntu

@Krzysztof Janowicz : setting the router from '802.11g and 802.11n' to '11g only' solved the problem.

It seems to work for me by change to g only at the router setting, at least improves a lot. Will do more testing.

On Fri, Dec 26, 2008 at 12:18:18PM -0000, yang_yi_cn wrote:
> @Krzysztof Janowicz : setting the router from '802.11g and 802.11n' to
> '11g only' solved the problem.
>
> It seems to work for me by change to g only at the router setting, at
> least improves a lot. Will do more testing.
>

yes, the iwl* drivers are known to have issues with "n" networks. So
using g-only should workaround most nasty issues.

Alternatively, you could try to install the linux-backport-modules
package that might have a fixed driver in it.

 - Alexander

Updates:

1. Remove n improves, but not eliminates the problem. I was testing using ping, which can reach 0% packet loss if you are not doing anything else. However, if you have too much Internet activity, such as download large files, or opening dozens of web pages in a few seconds, it's much easier to drop the connection in one or two minutes, and the period without Internet is about 10 secs. Seems like NM or the driver is trying to adjust the link speed, and during that 10 secs Internet is not accessible at all.

2. lspci -v
0c:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)
 Subsystem: Dell Device 000b
 Flags: bus master, fast devsel, latency 0, IRQ 17
 Memory at f6cfc000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: [40] Power Management version 3
 Capabilities: [58] Vendor Specific Information <?>
 Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
 Capabilities: [d0] Express Endpoint, MSI 00
 Capabilities: [100] Advanced Error Reporting <?>
 Capabilities: [13c] Virtual Channel <?>
 Capabilities: [160] Device Serial Number 23-00-36-ff-ff-4e-e8-24
 Capabilities: [16c] Power Budgeting <?>
 Kernel driver in use: wl
 Kernel modules: wl

I don't know why, but any other driver will not be recognized by NM. Only when I use the 'wl' driver it will show the device in iwconfig. I tried backports kernel and modules b43, ssb, or even ndiswrapper, the device is showing at lspci but not iwconfig.

On Fri, Dec 26, 2008 at 07:37:34PM -0000, yang_yi_cn wrote:
> Updates:
>
> 1. Remove n improves, but not eliminates the problem. I was testing
> using ping, which can reach 0% packet loss if you are not doing anything
> else. However, if you have too much Internet activity, such as download
> large files, or opening dozens of web pages in a few seconds, it's much
> easier to drop the connection in one or two minutes, and the period
> without Internet is about 10 secs. Seems like NM or the driver is trying
> to adjust the link speed, and during that 10 secs Internet is not
> accessible at all.
>
> 2. lspci -v
> 0c:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)

I talked about iwl* driveres ... you have broadcome, so you are seeing
a different issue than i referred to.

 - Alexander

Same problem, except the wireless connection is never re-established automatically. In other words, in intervals between 5 and 20 minutes, I must reboot my AP (a Siemens Gigaset SX762 WLAN at 54Mbps) and manually go into NM to re-scan networks so that it finds the wifi connection again.

System: IBM Lenovo Thinkpad R61
Ubuntu 9.10 Jaunty.

By the way, in Windows 7 the connection never falls. I leave PC on day and night, and connection is always up.

Problem disappeared for unknown reason. Monitoring system...

Same issue for my Dell Mini 9, using the proprietary broadcom-wl driver and NetworkManager 0.7.1 (PPA) in Jaunty UNR.

On Sun, Aug 02, 2009 at 09:59:04PM -0000, Student Driver wrote:
> Same issue for my Dell Mini 9, using the proprietary broadcom-wl driver
> and NetworkManager 0.7.1 (PPA) in Jaunty UNR.
>

this is not your bug. Its almost certainly a driver bug - which
unfortunately can only be fixed by broadcom.

 - Alexander

bananaslama109, please do not change the status of a bug without offering a reason for doing so.

This bug was originally reported in 2006, and marked "Fix Released" on 2007-08-09.

I've also seen no other comments from you in the entire bug history.

If you're experiencing a similar problem, please refer to the following page on how to use "ubuntu-bug" to open a new bug which will include debug information which will help us understand your problem better.

https://help.ubuntu.com/community/ReportingBugs

I have exactly the same problem on ubuntu 12.04, AMD 64 with the following setting of wireless:

SSID:
ConcordiaUniversity

Authentication:
WPA2 or WPA (WPA2 is preferred)

Encryption:
AES or TKIP (AES is preferred) with WPA2 Authentication, TKIP with WPA Authentication.

802.1x/EAP Type:
PEAP

Authentication Method:
MS-CHAP V2

Regards,

Leo