Bug 459401 - nm state flip-flop when associated in ad-hoc mode
nm state flip-flop when associated in ad-hoc mode
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-18 10:31 EDT by Fabrice Bellet
Modified: 2008-10-30 17:26 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-30 17:26:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fabrice Bellet 2008-08-18 10:31:50 EDT
This behaviour doesn't prevent NetworkManager to work as expected, it justs fills my logs a bit faster as expected :)

When setting up a wifi connection in ad-hoc mode, with wep enabled, after the other peer associates, nm flip-flops between the following states, several times per second :

Aug 18 15:14:16 localhost NetworkManager: <info>  (wlan0): supplicant connection state change: 7 -> 4
Aug 18 15:14:16 localhost NetworkManager: <info>  (wlan0): supplicant connection state change: 4 -> 7

the log for the supplicant provides the corresponding entries :

CTRL-EVENT-CONNECTED - Connection to 0a:40:b9:a5:ec:e7 completed (reauth) [id=0 id_str=]
Associated with 0a:40:b9:a5:ec:e7
CTRL-EVENT-CONNECTED - Connection to 0a:40:b9:a5:ec:e7 completed (reauth) [id=0 id_str=]
Associated with 0a:40:b9:a5:ec:e7
...and so on.
Comment 1 Fabrice Bellet 2008-08-18 10:33:17 EDT
I forgot to add : kernel-2.6.25.11-97.fc9.i686, iwl3945, wpa_supplicant-0.6.3-6.fc9.i386
Comment 2 Fabrice Bellet 2008-08-19 08:30:12 EDT
Another weird problem, that may be related, that occurs *sometimes* exactly when the peer associates to the ad-hoc network :

  . the kernel thread events/0 takes 100% cpu time
  . packets are correctly received from the peer
  . but packets sent to the peer are apparently not received, as the peers keeps asking for a dhcp lease.

When the peer disassociates :
  . the desktop freezes for a few seconds, 10-20 (and keyboard is unresponsive, probably X is overwhelmed by events coming from the wifi card ?)
  . then events/0 stops taking 100% cpu time
  . and the desktop becomes responsive again.
  . no specific error message in the logs.

The peer in my case, is a nokia N800.
Comment 3 Fabrice Bellet 2008-08-19 09:56:50 EDT
more debug from the mac80211 layer :

phy0: Removed STA 00:19:4f:9e:97:e8
phy0: Destroyed STA 00:19:4f:9e:97:e8
phy0: HW CONFIG: freq=2412
phy0: Adding new IBSS station 00:19:4f:9e:97:e8 (dev=wlan0)
phy0: Allocated STA 00:19:4f:9e:97:e8
phy0: Inserted STA 00:19:4f:9e:97:e8
wlan0: beacon TSF higher than local TSF - IBSS merge with BSSID 5a:a4:20:4e:e5:f1
phy0: Removed STA 00:19:4f:9e:97:e8
phy0: Destroyed STA 00:19:4f:9e:97:e8
phy0: HW CONFIG: freq=2412
phy0: Adding new IBSS station 00:19:4f:9e:97:e8 (dev=wlan0)
phy0: Allocated STA 00:19:4f:9e:97:e8
phy0: Inserted STA 00:19:4f:9e:97:e8
wlan0: beacon TSF higher than local TSF - IBSS merge with BSSID 5a:a4:20:4e:e5:f1

and after enabling CONFIG_MAC80211_IBSS_DEBUG :

RX beacon SA=00:19:4f:9e:97:e8 BSSID=3a:e9:c3:c6:5a:46 TSF=0x0 BCN=0xb3b2fa diff=-11776762 @13405353
phy0: Removed STA 00:19:4f:9e:97:e8
phy0: Destroyed STA 00:19:4f:9e:97:e8
phy0: HW CONFIG: freq=2412
phy0: Adding new IBSS station 00:19:4f:9e:97:e8 (dev=wlan0)
phy0: Allocated STA 00:19:4f:9e:97:e8
phy0: Inserted STA 00:19:4f:9e:97:e8
RX beacon SA=00:19:4f:9e:97:e8 BSSID=3a:e9:c3:c6:5a:46 TSF=0x0 BCN=0xb6d2d2 diff=-11981522 @13405558
phy0: Removed STA 00:19:4f:9e:97:e8
phy0: Destroyed STA 00:19:4f:9e:97:e8
phy0: HW CONFIG: freq=2412
phy0: Adding new IBSS station 00:19:4f:9e:97:e8 (dev=wlan0)
phy0: Allocated STA 00:19:4f:9e:97:e8
phy0: Inserted STA 00:19:4f:9e:97:e8
RX beacon SA=00:19:4f:9e:97:e8 BSSID=3a:e9:c3:c6:5a:46 TSF=0x0 BCN=0xb861f6 diff=-12083702 @13405660
phy0: Removed STA 00:19:4f:9e:97:e8
phy0: Destroyed STA 00:19:4f:9e:97:e8
phy0: HW CONFIG: freq=2412
phy0: Adding new IBSS station 00:19:4f:9e:97:e8 (dev=wlan0)
phy0: Allocated STA 00:19:4f:9e:97:e8

TSF, aka rx_timestamp should not be null ?
Comment 4 Fabrice Bellet 2008-08-19 11:57:39 EDT
yes, I think the get_tsf handler in iwl3945-base should remain undefined, instead of returning zero, which is considered by mac80211 as a valid answer. The problem of thread events/0 high cpu usage remains.
Comment 5 Fabrice Bellet 2008-08-21 17:32:39 EDT
bug report for comment #2 is here : https://bugzilla.redhat.com/show_bug.cgi?id=459571
Comment 6 Rui Matos 2008-09-29 07:14:26 EDT
I also see this. Maybe the bug should be reasigned to the kernel package?
Comment 7 Rui Matos 2008-09-29 07:16:36 EDT
(In reply to comment #6)
> Maybe the bug should be reasigned to the kernel package?

Sorry, forget that comment. A new bug was filled for that.
Comment 8 Fabrice Bellet 2008-10-24 03:58:06 EDT
a fix should hopefully be upstream soon :

http://marc.info/?l=linux-wireless&m=122483096421981&w=2
Comment 9 John W. Linville 2008-10-27 18:08:42 EDT
Patch from comment 8 just merged to wireless-testing, and I put it into rawhide kernels for tomorrow.
Comment 10 Fabrice Bellet 2008-10-30 17:26:58 EDT
it works for me, with kernel-2.6.27.4-68.fc10.i686.rpm. thanks! closing the bug.

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