168c:002c [Eee PC 1005P] Frequent disconnects only at Honk Kong airport

[Rolf Leggewie]

I'm currently at the Hong Kong Airport. Free wifi is offered and I believe there are multiple AP transparently networked together. I am using a 1001P netbook and the wifi is unstable, reconnecting about every 30 seconds. Judging from the syslog it looks like this is due to failed roaming ("Roamed to ... none"). Obviously, I will not be able to repeat this problem after today.

lspci:
02:00.0 Network controller: Atheros Communications Inc. Device 002c (rev 01)
 Subsystem: Device 1a3b:1112
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0, Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 17
 Region 0: Memory at fbff0000 (64-bit, non-prefetchable) [size=64K]
 Capabilities: <access denied>
 Kernel driver in use: ath9k
 Kernel modules: ath9k

$ grep Roam.*HKAir /var/log/syslog -3
Jul 17 18:58:40 localhost avahi-daemon[1045]: New relevant interface wlan0.IPv4 for mDNS.
Jul 17 18:58:40 localhost avahi-daemon[1045]: Registering new address record for 192.168.61.145 on wlan0.IPv4.
Jul 17 18:58:41 localhost NetworkManager: <info> (wlan0): device state change: 7 -> 8 (reason 0)
Jul 17 18:58:41 localhost NetworkManager: <debug> [1342522721.093985] periodic_update(): Roamed from BSSID E8:BA:70:C3:EF:21 (#HKAirport Free WiFi) to 08:17:35:C7:2E:A0 (#HKAirport Free WiFi)
Jul 17 18:58:41 localhost NetworkManager: <info> Policy set 'Auto #HKAirport Free WiFi' (wlan0) as default for routing and DNS.
Jul 17 18:58:41 localhost NetworkManager: <info> Activation (wlan0) successful, device activated.
Jul 17 18:58:41 localhost NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
--
Jul 17 18:59:45 localhost kernel: [ 1172.737870] wlan0: authenticate with 08:17:35:c7:2e:a0 (try 2)
Jul 17 18:59:45 localhost kernel: [ 1172.937865] wlan0: authenticate with 08:17:35:c7:2e:a0 (try 3)
Jul 17 18:59:45 localhost kernel: [ 1173.137881] wlan0: authentication with 08:17:35:c7:2e:a0 timed out
Jul 17 18:59:46 localhost NetworkManager: <debug> [1342522786.430972] periodic_update(): Roamed from BSSID 08:17:35:C7:2E:A0 (#HKAirport Free WiFi) to (none) ((none))
Jul 17 18:59:47 localhost NetworkManager: <info> (wlan0): supplicant connection state: completed -> disconnected
Jul 17 18:59:47 localhost NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
Jul 17 18:59:47 localhost NetworkManager: <info> (wlan0): supplicant connection state: scanning -> associating
--
Jul 17 19:02:53 localhost avahi-daemon[1045]: New relevant interface wlan0.IPv4 for mDNS.
Jul 17 19:02:53 localhost avahi-daemon[1045]: Registering new address record for 192.168.61.145 on wlan0.IPv4.
Jul 17 19:02:54 localhost NetworkManager: <info> (wlan0): device state change: 7 -> 8 (reason 0)
Jul 17 19:02:54 localhost NetworkManager: <debug> [1342522974.469060] periodic_update(): Roamed from BSSID E8:BA:70:C3:EF:21 (#HKAirport Free WiFi) to 08:17:35:C7:2E:A0 (#HKAirport Free WiFi)
Jul 17 19:02:54 localhost NetworkManager: <info> Policy set 'Auto #HKAirport Free WiFi' (wlan0) as default for routing and DNS.
Jul 17 19:02:54 localhost NetworkManager: <info> Activation (wlan0) successful, device activated.
Jul 17 19:02:54 localhost NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
--
Jul 17 19:03:34 localhost kernel: [ 1402.293177] (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 17 19:03:36 localhost NetworkManager: <info> (wlan0): supplicant connection state: associating -> associated
Jul 17 19:03:36 localhost NetworkManager: <info> (wlan0): supplicant connection state: associated -> completed
Jul 17 19:03:38 localhost NetworkManager: <debug> [1342523018.003442] periodic_update(): Roamed from BSSID 08:17:35:C7:2E:A0 (#HKAirport Free WiFi) to 08:17:35:C6:F4:71 (#HKAirport Free WiFi)
Jul 17 19:03:55 localhost wpa_supplicant[1140]: Trying to associate with 08:17:35:c7:2e:a0 (SSID='#HKAirport Free WiFi' freq=2462 MHz)
Jul 17 19:03:55 localhost kernel: [ 1422.739252] wlan0: deauthenticating from 08:17:35:c6:f4:71 by local choice (reason=3)
Jul 17 19:03:55 localhost NetworkManager: <info> (wlan0): supplicant connection state: completed -> associating
--
Jul 17 19:03:55 localhost kernel: [ 1422.775211] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Jul 17 19:03:55 localhost kernel: [ 1422.775226] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 17 19:03:55 localhost kernel: [ 1422.775242] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 17 19:03:56 localhost NetworkManager: <debug> [1342523036.229992] periodic_update(): Roamed from BSSID 08:17:35:C6:F4:71 (#HKAirport Free WiFi) to (none) ((none))
Jul 17 19:04:05 localhost wpa_supplicant[1140]: Authentication with 00:00:00:00:00:00 timed out.
Jul 17 19:04:05 localhost NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
Jul 17 19:04:06 localhost wpa_supplicant[1140]: Trying to associate with 08:17:35:c6:f4:71 (SSID='#HKAirport Free WiFi' freq=2462 MHz)
--
Jul 17 19:04:07 localhost kernel: [ 1434.843048] cfg80211: Current regulatory domain updated by AP to: HK
Jul 17 19:04:07 localhost kernel: [ 1434.843060] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Jul 17 19:04:07 localhost kernel: [ 1434.843075] (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Jul 17 19:04:08 localhost NetworkManager: <debug> [1342523048.134885] periodic_update(): Roamed from BSSID (none) ((none)) to 08:17:35:C6:F4:71 (#HKAirport Free WiFi)
Jul 17 19:04:10 localhost NetworkManager: <info> (wlan0): device state change: 8 -> 3 (reason 11)
Jul 17 19:04:10 localhost NetworkManager: <info> (wlan0): deactivating device (reason: 11).
Jul 17 19:04:10 localhost NetworkManager: <info> (wlan0): canceled DHCP transaction, dhcp client pid 4659
--
Jul 17 19:05:08 localhost avahi-daemon[1045]: New relevant interface wlan0.IPv4 for mDNS.
Jul 17 19:05:08 localhost avahi-daemon[1045]: Registering new address record for 192.168.61.145 on wlan0.IPv4.
Jul 17 19:05:09 localhost NetworkManager: <info> (wlan0): device state change: 7 -> 8 (reason 0)
Jul 17 19:05:09 localhost NetworkManager: <debug> [1342523109.131201] periodic_update(): Roamed from BSSID 08:17:35:C7:E8:41 (#HKAirport Free WiFi) to 08:17:35:C6:F9:91 (#HKAirport Free WiFi)
Jul 17 19:05:09 localhost NetworkManager: <info> Policy set 'Auto #HKAirport Free WiFi' (wlan0) as default for routing and DNS.
Jul 17 19:05:09 localhost NetworkManager: <info> Activation (wlan0) successful, device activated.
Jul 17 19:05:09 localhost NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
--
Jul 17 19:06:15 localhost kernel: [ 1563.544263] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Jul 17 19:06:15 localhost kernel: [ 1563.544276] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 17 19:06:15 localhost kernel: [ 1563.544289] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 17 19:06:20 localhost NetworkManager: <debug> [1342523180.001628] periodic_update(): Roamed from BSSID 08:17:35:C6:F9:91 (#HKAirport Free WiFi) to (none) ((none))
Jul 17 19:06:25 localhost wpa_supplicant[1140]: Authentication with 00:00:00:00:00:00 timed out.
Jul 17 19:06:25 localhost NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
Jul 17 19:06:26 localhost wpa_supplicant[1140]: Trying to associate with 08:17:35:c7:35:91 (SSID='#HKAirport Free WiFi' freq=2437 MHz)
--
Jul 17 19:06:43 localhost avahi-daemon[1045]: New relevant interface wlan0.IPv4 for mDNS.
Jul 17 19:06:43 localhost avahi-daemon[1045]: Registering new address record for 192.168.61.145 on wlan0.IPv4.
Jul 17 19:06:44 localhost NetworkManager: <info> (wlan0): device state change: 7 -> 8 (reason 0)
Jul 17 19:06:44 localhost NetworkManager: <debug> [1342523204.007847] periodic_update(): Roamed from BSSID E8:BA:70:F8:03:91 (#HKAirport Free WiFi) to 08:17:35:C6:F9:91 (#HKAirport Free WiFi)
Jul 17 19:06:44 localhost NetworkManager: <info> Policy set 'Auto #HKAirport Free WiFi' (wlan0) as default for routing and DNS.
Jul 17 19:06:44 localhost NetworkManager: <info> Activation (wlan0) successful, device activated.
Jul 17 19:06:44 localhost NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
--
Jul 17 19:06:55 localhost kernel: [ 1603.520950] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Jul 17 19:06:55 localhost kernel: [ 1603.520965] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 17 19:06:55 localhost kernel: [ 1603.520981] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Jul 17 19:06:56 localhost NetworkManager: <debug> [1342523216.224824] periodic_update(): Roamed from BSSID 08:17:35:C6:F9:91 (#HKAirport Free WiFi) to (none) ((none))
Jul 17 19:06:58 localhost NetworkManager: <info> (wlan0): supplicant connection state: associating -> disconnected
Jul 17 19:07:05 localhost wpa_supplicant[1140]: Authentication with 00:00:00:00:00:00 timed out.
Jul 17 19:07:05 localhost NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
--
Jul 17 19:07:45 localhost kernel: [ 1654.045086] wlan0: associate with 08:17:35:c6:f9:91 (try 2)
Jul 17 19:07:45 localhost kernel: [ 1654.245076] wlan0: associate with 08:17:35:c6:f9:91 (try 3)
Jul 17 19:07:46 localhost kernel: [ 1654.445225] wlan0: association with 08:17:35:c6:f9:91 timed out
Jul 17 19:07:50 localhost NetworkManager: <debug> [1342523270.001365] periodic_update(): Roamed from BSSID 08:17:35:C6:F9:91 (#HKAirport Free WiFi) to (none) ((none))
Jul 17 19:07:55 localhost wpa_supplicant[1140]: Authentication with 08:17:35:c6:f9:91 timed out.
Jul 17 19:07:55 localhost NetworkManager: <info> (wlan0): supplicant connection state: associating -> disconnected
Jul 17 19:07:55 localhost NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
--
Jul 17 19:12:03 localhost avahi-daemon[1045]: New relevant interface wlan0.IPv4 for mDNS.
Jul 17 19:12:03 localhost avahi-daemon[1045]: Registering new address record for 192.168.61.145 on wlan0.IPv4.
Jul 17 19:12:04 localhost NetworkManager: <info> (wlan0): device state change: 7 -> 8 (reason 0)
Jul 17 19:12:04 localhost NetworkManager: <debug> [1342523524.549428] periodic_update(): Roamed from BSSID E8:BA:70:C3:EF:21 (#HKAirport Free WiFi) to E8:BA:70:C3:EE:91 (#HKAirport Free WiFi)
Jul 17 19:12:04 localhost NetworkManager: <info> Policy set 'Auto #HKAirport Free WiFi' (wlan0) as default for routing and DNS.
Jul 17 19:12:04 localhost NetworkManager: <info> Activation (wlan0) successful, device activated.
Jul 17 19:12:04 localhost NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete.
---
AlsaVersion:
 Advanced Linux Sound Architecture Driver Version 1.0.23.
 Compiled on Mar 29 2012 for kernel 2.6.32-41-generic (SMP).
AplayDevices:
 **** List of PLAYBACK Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC269 Analog [ALC269 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: ALC269 Analog [ALC269 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: leggewie 1970 F.... pulseaudio
CRDA:
 country 98:
  (2402 - 2472 @ 40), (N/A, 20)
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf7cf8000 irq 29'
   Mixer name : 'Realtek ALC269'
   Components : 'HDA:10ec0269,104383ce,00100004'
   Controls : 10
   Simple ctrls : 6
DistroRelease: Ubuntu 10.04
EcryptfsInUse: Yes
Frequency: Once a day.
MachineType: ASUSTeK Computer INC. 1001P
Package: linux (not installed)
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.32-41-generic root=/dev/mapper/hostname-root ro quiet splash acpi_osi=Linux backlight=vendor
ProcEnviron:
 PATH=(custom, user)
 LANG=de_DE.utf8
 LC_MESSAGES=C
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-41.91-generic 2.6.32.59+drm33.24
Regression: No
RelatedPackageVersions: linux-firmware 1.34.14
Reproducible: No
Tags: ubuntu-une lucid networking needs-upstream-testing
Uname: Linux 2.6.32-41-generic i686
UserAsoundrc:
 pcm.btheadset {
         type bluetooth
         device 00:1A:45:A3:56:60
         profile “auto”
 }
UserGroups: adm admin audio cdrom dialout dip fuse libvirtd lpadmin netdev plugdev sambashare src video
dmi.bios.date: 06/23/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1202
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 1005P
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: x.xx
dmi.chassis.asset.tag: 0x00000000
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer INC.
dmi.chassis.version: x.x
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1202:bd06/23/2010:svnASUSTeKComputerINC.:pn1001P:pvrx.x:rvnASUSTeKComputerINC.:rn1005P:rvrx.xx:cvnASUSTeKComputerINC.:ct10:cvrx.x:
dmi.product.name: 1001P
dmi.product.version: x.x
dmi.sys.vendor: ASUSTeK Computer INC.

[Rolf Leggewie (r0lf)]

I am running lucid with all the latest updates.

$ uname -a
Linux 1001P 2.6.32-41-generic #91-Ubuntu SMP Wed Jun 13 11:44:43 UTC 2012 i686 GNU/Linux

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1025638

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

apport information

[Rolf Leggewie (r0lf)]

I hate being routinely asked for a bunch (!) of information, 99% of which is irrelevant. Whatever happened to data frugality?

http://de.wikipedia.org/wiki/Datensparsamkeit_und_Datenvermeidung

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.5kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[Rolf Leggewie (r0lf)]

Thank you for the quick response

Flight is over already and I'm no longer at the airport, so at least for the moment I can't test. I'm not sure when the next time will be where there is wifi roaming set up.

[penalvch (penalvch)]

Rolf Leggewie, please reopen this report when the required information can be provided. Thank you for your understanding and feel free to report any future bugs you may find.

[Rolf Leggewie (r0lf)]

come on, this is stupid! If you pay my ticket, I'll happily go back to the airport to test. Or send me a network of AP I can set up here in a similar fashion. Until then, this ticket should be open in case somebody else experiences the same issue.

I appreciate the quick responses, that's a good change. But simply routinely asking for a bunch of information and then dropping the ball half-way and closing as invalid is not the way to go.

[penalvch (penalvch)]

Rolf Leggewie, this bug is publicly searchable independent of the Status.

Despite this, this report may not remain outstanding if the minimum requirements noted in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1025638/comments/20 are not provided. As well, if someone else has the problem, it is best they open a new report. For more on this please see https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported .

If you are back in the Hong Kong airport, and can provide the previously requested information, please re-open the report and we can take it from there. Otherwise, please do not toggle this report.

Thank you for your understanding and feel free to report any future bugs you may find.

[Rolf Leggewie (r0lf)]

Resetting status to what Brad as member of the kernel team set it to.

[Rolf Leggewie (r0lf)]

It never fails to surprise me how many people think the purpose of a bug tracker is to close tickets instead of documenting and fixing *problems*

[penalvch (penalvch)]

Rolf Leggewie, I PM'ed you but received no response.

Regarding your comments https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1025638/comments/25 , that is Brad Figg's bot marking it Confirmed because the apport-collect information was provided.

Regarding your comments https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1025638/comments/26 , nobody appreciates your negative, incorrect presumptions. To maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/community/conduct/ . Bug reports are handled by humans, the majority of whom are volunteers, so please bear this in mind.

Regarding the technical merits of this report, the current outstanding minimum requirements of this report are:
+ Is this a regression?
+ Does this problem occur in mainline?
+ Does this occur with other wireless access points?
+ Does the access point in Hong Kong have some firmware bug or access policy that does not permit Ubuntu/Linux clients?
+ What is the manufacturer and model of the access point?

So, unless you can provide all the information mentioned above, and previously requested, unfortunately, this report is, at best, frivolous.

I empathize that it sucks when you get into situations where you expect things to work, and they do not. But, if one cannot see through a bug to it's conclusion by providing minimum requirement information for a developer to work on it, expecting a miracle and not getting it is no reason to keep a report open, nor be rude.

This report is being closed within policy of both the Ubuntu Kernel Team and Ubuntu Bug Control as per https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Invalid . If you have any further questions about this, please feel free to E-Mail me directly and we can discuss further.

If you can provide the minimum requirements, please reopen the report with this information, and we can work together on getting this fixed asap.

Thank you for your understanding.

[Rolf Leggewie (r0lf)]

Christopher, may I kindly suggest you speak for yourself? Furthermore, where exactly is the CoC-violation in comment 26? You are throwing around a bunch of stuff without merit, I'd say.

The link you gave says "Bugs which are not legitimate bugs are set to Invalid. This can include bugs which failed to provide requested debug information or bugs which are the result of user error." You are requesting an ever increasing amount information that is by now simply IMPOSSIBLE to provide. You are not seriously requesting for me to contact the airport and ask them for what model of AP they deployed or else you will not act on this ticket? What if they have more than one AP, will I need to find out which particular brand I had connected to? Last time I heard, it was that 802.11x was a standard. I think for now it's safe to assume that the AP is following the standard. HKG is a busy and well-maintained airport, I'm sure that if there was a genuine problem with their setup, they would hear about it and fix it. But not only that, you will not do anything unless I can prove this is a regression? How am I supposed to know? It's the first time I ran into this issue and I reported it the first time I came across it. Do you want me to test every kernel that was ever released? I guess that's the next step, hm?

You might not like to hear this but you are being ridiculous with your requests. Is this the new kernel bug triaging team policy, to request an ever increasing amount of information so that you can happily close the ticket as invalid when it's not provided? I already provided a bunch of unnecessary information and pointed out the violation of the principle of "Datensparsamkeit".

I understand and agree that it would be nice to see if the problem does occur in mainline as well, but at the moment it's impossible to verify that. That doesn't make this ticket invalid. In fact, the link you provided, explicitly states 'If a bug is in a Confirmed state but has not yet tested the upstream mainline kernel, tag the bug "needs-upstream-testing". If a bug has been tested with the upstream kernel, move the bug to a "Triaged" state."' So, confirmed is the proper state of this ticket, the tag is already there. I'm quoting officially published rules, you seem to make up your own along the way, handing out links that do not support or in fact often even contradict your arguments.

I might go to HKG again next month or at the end of October or both. If I do, I will be sure to test mainline. If there is any other tests you expect, let me know ahead of time. I suggest you close this ticket as invalid no earlier than in 120 days as seems to be kernel team expiration policy for "information requested" bugs. I won't object to setting this ticket to "incomplete" if that made you happier.

[Rolf Leggewie (r0lf)]

To explicitly answer your new requests to the best of my ability:

+ Is this a regression?
+ Does this occur with other wireless access points?

I don't know. I never into it before AFAIR. But the situation is obviously special and occurs only where a roaming setup of several AP with the same ESSID is deployed. Furthermore, it's safe to assume that an airport such as HKG is wifi-busy. The problem might not occur in other, less congested environments. I have never experienced the problem since and connected fine to a few wifi networks (but in less congested areas and without a roaming setup as far as I am aware of).

+ Does this problem occur in mainline?

untested at the moment, still pending as tagged

+ Does the access point in Hong Kong have some firmware bug or access policy that does not permit Ubuntu/Linux clients?

I think we should assume no. I was able to surf for several minutes at a time.

+ What is the manufacturer and model of the access point?

that's a silly question. I don't know. I'm not going to contact the airport and ask them. There *IS* a limit to what I will do to help bug triage.

[Rolf Leggewie (r0lf)]

of course, it's very well possible this is a bug in other parts of the software and not the kernel. at the moment I reported the issue the kernel seemed to be the most natural choice, especially since I had the impression of lacklustre wifi driver performance a few times in the past.

Google gets a bunch of hits for "Roamed from BSSID" "to (none) ((none))". Bug 291760 looks similar and was fixed in network-manager. But apparently, similar issues still exist for people in very recent releases of Ubuntu.

Just throwing some findings out there without much of a direction for now. Maybe somebody else can connect the dots or maybe I will have a moment of clarity soon.

I have a few routers at my disposal. Can I somehow easily recreate a roaming setup? It might still not be enough to trigger the bug, but then again it might. I shall try creating a WDS setup to see if it reproduces the problem here.

[Rolf Leggewie (r0lf)]

I tried to but so far failed to create a WDS between an OpenWRT WRT54G and a ralink router. This is something new for me.

[Rolf Leggewie (r0lf)]

I will be back at HK airport at the begining of March. I'll try to collect more information then.

[penalvch (penalvch)]

Rolf Leggewie, thank you for reporting this and helping make Ubuntu better. Lucid reached EOL on May 9, 2013.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the kernel in the mainline kernels archive directory daily folder. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Helpful bug reporting tips:
https://help.ubuntu.com/community/ReportingBugs

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]