Bug 3992 - WiFi connections having static IP addresses do not disconnect properly leaving wlan0 up
: WiFi connections having static IP addresses do not disconnect properly leavin...
Status: RESOLVED DUPLICATE of bug 6615
Product: Connectivity
WiFi
: 4.1.3 (5.2008.43-7)
: N800 Maemo
: Low major (vote)
: ---
Assigned To: unassigned
: wifi-bugs
:
: moreinfo, use-time
:
: 2602
  Show dependency tree
 
Reported: 2009-01-08 21:45 UTC by urb
Modified: 2010-03-11 16:02 UTC (History)
9 users (show)

See Also:


Attachments
syslog information showing wlan0 problem (9.39 KB, text/plain)
2010-01-17 01:04 UTC, Vincent Lefevre
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description urb (reporter) 2009-01-08 21:45:25 UTC
SOFTWARE VERSION:
see above

STEPS TO REPRODUCE THE PROBLEM:
PREPARATIONS:
A. Set up a bogus wlan ad-hoc connection.
  1. Control Panel > Connectivity > Connectivity > Connections > New
  2. Choose Connection Type WLAN
  3. Scan for available Networks = Yes
  4. SSID = anything
   Network hidden = yes
   Network mode = adhoc
   Security mode = none
  5. Click "Advanced"
  6. Click IP Addresses
  7. Uncheck Auto-retrieve IP address
  8. Set IP to 127.0.0.99.
  9. Finish.

B1. Install wireless-tools package
B2. Install htop
(sorry I'm unable to provide details, I can't remember how to do this.
Anyway, some obscure operations with repositories are needed here)

C. Open two terminal windows. Launch htop in one. Spawn root shell in the
other.

D. Open a browser window. Using your usual internet connection, load the site
http://www.7uplimafree.com
(probably any other extremely heavy flash site will do as well)

E. When the site loads completely, disconnect the internet connection.

BUG HUNTING CYCLE:
1. "Connect" to the bogus ad-hoc network from the connection icon drop-down
menu.
2. Wait some random time. 
3. Disconnect using the drop-down menu so that the connection icon greys out
4. Check the wlan0 interface status from the root console window with
"iwconfig"

EXPECTED OUTCOME:
wlan0 interface goes down after disconnection, iwconfig outputs :

wlan0     NOT READY  ESSID:"anything"
          Mode:Auto Channel:0  Access Point: Not-Associated
          Link Quality:0  Signal level:0  Noise level:0

ACTUAL OUTCOME:
wlan0 remains up with the wireless chip drawing 200 mA from the battery,
iwconfig outputs:

wlan0     IEEE 802.11b/g  ESSID:"anything"  
          Mode:Ad-hoc Frequency:2.417 GHz  Cell: AA:BB:CD:11:22:33
          Bit Rate=0 kb/s   Tx-Power=19 dBm   Sensitivity=0/200  
          RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality:49/0  Signal level:-46 dBm  Noise level:-95 dBm 

REPRODUCIBILITY:
Frequently. 4 out of 5 cycles.

EXTRA SOFTWARE INSTALLED:
see bug 3738
Comment 1 Neil MacLeod maemo.org 2009-01-08 22:46:10 UTC
*** Bug 3988 has been marked as a duplicate of this bug. ***
Comment 2 Eero Tamminen nokia 2009-01-12 16:46:46 UTC
> B1. Install wireless-tools package
> B2. Install htop
> (sorry I'm unable to provide details, I can't remember how to do this.

They're in the SDK tools repository: http://maemo.org/development/tools/
Comment 3 urb (reporter) 2009-01-13 12:01:35 UTC
FURTHER INDICATIONS:
1. Keep the browser window in the foreground when "disconnecting"
2. Try with the following replacement sites for item (D):  
http://www.tracychapman.com
http://www.speakvisual.com
Comment 4 urb (reporter) 2009-01-17 22:19:02 UTC
*** Bug 3738 has been marked as a duplicate of this bug. ***
Comment 5 Vincent Lefevre 2009-01-18 00:52:04 UTC
*** Bug 3806 has been marked as a duplicate of this bug. ***
Comment 6 Vincent Lefevre 2009-01-18 01:11:55 UTC
I could reproduce this bug. But a few seconds later, a "Select connection" box
appeared (and reappeared, though I clicked on "Cancel"). I wonder why. Usually
such a box never appears unless I ask for a connection explicitly.
Comment 7 Andre Klapper maemo.org 2009-01-19 14:29:54 UTC
Unfortunately votes are not copied when marking a bug report as dup. Hence
please vote again here if you had voted for bug 3738 or bug 3806.

Confirming as per last comment.
Comment 8 Andre Klapper maemo.org 2009-01-20 13:13:00 UTC
(In reply to comment #6)
> I could reproduce this bug. But a few seconds later, a "Select connection" box
> appeared (and reappeared, though I clicked on "Cancel"). I wonder why. Usually
> such a box never appears unless I ask for a connection explicitly.

That might be related to bug 3979.
Comment 9 Vincent Lefevre 2009-01-20 13:57:32 UTC
(In reply to comment #8)
> That might be related to bug 3979.

I don't know, but I wasn't in offline mode: I had just disconnected.
Comment 10 urb (reporter) 2009-01-25 12:17:21 UTC
I suggest that this bug carry a different title: "WiFi connections having fixed
IP addresses do not disconnect properly leaving wlan0 up".
Reason: I am able to reproduce this bug with steps as described but with the
following hardware access points connected instead of the bogus ad-hoc, under
these listed conditions:

Access point        OS (driver)         Mode
---------------------------------------------
Fritz!Box 7141      proprietary         Infrastructure
Fritz!Box 3050      proprietary         Infrastructure
TCom Sinus 154SE    proprietary         Infrastructure
Linksys WUSB54GC    WinXP (proprietary) Ad-hoc
Linksys WUSB54GC    Linux (rt73usb)     Ad-hoc
TP-Link TL-WN510G   Linux (MadWiFi)     Ad-hoc
TP-Link TL-WN510G   Linux (MadWiFi)     Infrastructure
Comment 11 Quim Gil nokia 2009-01-25 16:33:18 UTC
(In reply to comment #10)
> I suggest that this bug carry a different title: "WiFi connections having fixed
> IP addresses do not disconnect properly leaving wlan0 up".

Please, if this is the case.
Comment 12 Quim Gil nokia 2009-01-25 16:36:26 UTC
CCing Kalle since they have a better infrastructure than my homke to test this
bug and whether it is being inherited in Fremantle as well.

Kalle, look at comment #10 since urb seems to go further noting that the bug
might rely on WiFi connections having fixed IP addresses. Thanks!
Comment 13 Kalle Valo nokia 2009-02-05 11:04:10 UTC
(In reply to comment #12)
> CCing Kalle since they have a better infrastructure than my homke to test this
> bug and whether it is being inherited in Fremantle as well.
> 
> Kalle, look at comment #10 since urb seems to go further noting that the bug
> might rely on WiFi connections having fixed IP addresses. Thanks!

Thanks, I'll forward this to the icd maintainer.
Comment 14 Andre Klapper maemo.org 2009-03-25 14:43:53 UTC
(In reply to comment #13 by Kalle Valo)
> > Kalle, look at comment #10 since urb seems to go further noting that the bug
> > might rely on WiFi connections having fixed IP addresses. Thanks!
> 
> Thanks, I'll forward this to the icd maintainer.

Kalle, any news here?
Can this be reproduced in Fremantle builds?
Is there an internal NB# number to track?
Comment 15 Kalle Valo nokia 2009-03-30 12:53:50 UTC
(In reply to comment #14)
> (In reply to comment #13 by Kalle Valo)
> > > Kalle, look at comment #10 since urb seems to go further noting that the bug
> > > might rely on WiFi connections having fixed IP addresses. Thanks!
> > 
> > Thanks, I'll forward this to the icd maintainer.
> 
> Kalle, any news here?

I informed this via email but didn't get reply IIRC.

> Can this be reproduced in Fremantle builds?
> Is there an internal NB# number to track?

I haven't worked on this bug.
Comment 16 Vincent Lefevre 2009-04-14 14:45:27 UTC
I've just noticed that wlan0 was still up and running (and the tablet was hot,
as usual in such a case), even though I was in offline mode! AFAIK, this is the
first time I have this problem in offline mode (I usually switch to offline
mode in order to avoid battery drain, but now I can see that this isn't even
guaranteed).
Comment 17 urb (reporter) 2009-04-15 00:27:30 UTC
(In reply to comment #16)

Confirmed here, can be reproduced with step 3 from section "Bug hunting cycle"
replaced with "press hardware power button, select "Offline mode", tap OK"
Comment 18 Andre Klapper maemo.org 2009-10-01 17:35:48 UTC
I tried to reproduce this in Fremantle, but whoever set the IM mode for that
dialog should be at least seriously injured.
Fail.
Comment 19 Andre Klapper maemo.org 2009-12-30 15:55:10 UTC
This report was filed against Maemo4 ("Diablo").
The N900 and Maemo5 ("Fremantle") have been available for some time now.

If you own an N900, we kindly ask you to retest this with Maemo5 if possible,
and update this report by 1) describing whether this still happens, 2) which
exact Maemo5 version you use (Settings > General > About product), and 3)
removing the "moreinfo" keyword.

This is unfortunately a WONTFIX for Maemo4 as Maemo4 is in maintenance mode and
Nokia will only provide bugfixes for critical issues if at all, as Nokia
currently seems to concentrate on Maemo5 and future Maemo releases. Hence
without any status updates, this report will be closed within the next months.

Sorry that your issue could not be fixed for Maemo4. For your interest the Mer
project aims to provide a community backport of Maemo5 for 770/N8x0 devices.
See http://wiki.maemo.org/Mer for more information.
Comment 20 Vincent Lefevre 2010-01-15 01:15:31 UTC
I have exactly the same problem on my N900 with 2.2009.51-1.002.
Comment 21 Vincent Lefevre 2010-01-15 01:17:37 UTC
Actually, this wasn't an ad-hoc connection (didn't try), but wifi connections
with hotspots.
Comment 22 Vincent Lefevre 2010-01-17 01:04:19 UTC
Created an attachment (id=2010) [details]
syslog information showing wlan0 problem

I've attached a syslog excerpt from my N900. At 20:35, I left home, while I was
still being connected, i.e. without disconnecting first. Thus the signal became
low (first syslog line) and was eventually lost (no probe response from AP). It
seems that the N900 tried to reconnect (vinc17 was the SSID), but as expected,
didn't succeed. Then a kernel message said "wl1251: down". I think that until
now, everything is OK, but 1 second later:
  wl1251: 151 tx blocks at 0x3b788, 35 rx blocks at 0x3a780
  wl1251: firmware booted (Rev 4.0.4.3.6)
Does this mean that something is trying to reconnect? Is there a race condition
here? It seems that the following occurred:
1. Connection was lost.
2. Perhaps because some software attempts to do network access, the N900 tries
to reconnect.
3. wlan0 down due to (1).
4. wlan0 up again due to (2).
Then the system is in an unexpected state, causing battery drain. (2) would
explain why the problem doesn't always occur.

When I looked at my N900 four minutes later (20:40:14), wlan0 was up with no
association. To avoid the battery drain, I set my N900 to offline mode
(20:40:37), and the kernel said "wl1251: down".
Comment 23 ext-jason.rudd@nokia.com nokia 2010-01-21 13:38:21 UTC
This is a replica of:

https://bugs.maemo.org/show_bug.cgi?id=6615

Ad-hoc network uses Static-IP. Please install the script published by Marcus
Silvan in the above link.
Comment 24 Vincent Lefevre 2010-01-21 18:36:40 UTC
Thanks for the information. This wasn't an ad-hoc network in my case, but the
IP was static. So, this is the same bug.
Comment 25 Josh Triplett 2010-01-24 21:44:29 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > I suggest that this bug carry a different title: "WiFi connections having fixed
> > IP addresses do not disconnect properly leaving wlan0 up".
> 
> Please, if this is the case.

Retitling, since the most recent comments confirm that non-ad-hoc connections
with fixed IPs also trigger the problem.
Comment 26 Andre Klapper maemo.org 2010-03-11 16:02:50 UTC
(In reply to comment #24)
> So, this is the same bug.

Marking as duplicate.

*** This bug has been marked as a duplicate of bug 6615 ***