Incorrect wireless setting after resume

[kimquirk]

Build 702, q2d14a

I clicked on a WEP AP on two laptops; shared some activities. Then pressed the suspend (pwr) button to sleep.

Later (the next morning) when I presse the power button again, the laptops woke up, restarted the wireless scanning, but did not find WEP AP; instead connected to a local link mesh 1.

Isn't it supposed to go through the same scanning algorithm as when first booted?

[cjb]

Yes, it should go through the same scanning algorithm (and does, as far as I know). Were the WEP APs on the mesh view after the resume?

[cjb]

Wad has reported that, after failing to connect to a school server on boot, he's seeing laptops revert to simple mesh rather than the AP they were last using.

NetworkManager hasn't changed since last year, so this is quite strange.

[bemasc]

I cannot reproduce this under update.1-702.

I olpc-update'd from joyride-1796. After reboot, my settings were preserved in .sugar/default/nm/networks.cfg, and I was connected to my WPA AP automatically.

I removed .sugar and rebooted. After specifying my new name, and then typing in the password for my AP, I was connected correctly. After another reboot, I was connected to the AP without any user intervention.

NetworkManager does seem to scan all the mesh channels first, in search of a school server. When it doesn't find one, it connects to the AP. I do not know what would happen in the presence of a school server, or even other laptops listening on the mesh.

[mtd]

I've seen this problem frequently, and it's not new (since resume started working in joyride / update-1). Between work and home (10 minute walk through the central London RF jungle), when I resume my XO I have to associate manually 1/2 the time. Work wireless has no encryption, home wireless is WPA2 (no I haven't got that backwards).

Before suspend/resume was enabled, I had the related symptom that when one favorite (e.g., work) network was lost, and 5-10 minutes later a new favorite (e.g., home) was available (clearly visible in the Neighborhood frame), NM wouldn't switch and I'd have to manually request association to the newly-visible favorite. The Neighborhood frame would also show the old favorite until I requested association with the newly available favorite, at which point the old favorite would disappear (along with a few other networks that were only visible around the old favorite's physical location). I'm assuming that this is a separate issue but just in case I mention it.

[mtd]

I've had four NM asserts and two NM crashes coming out of / going into olpc_do_sleep this morning playing around trying to tickle this bug. Attaching /var/log/messages snippets in a sec...

[mtd]

trimmed logs around: nm_device_activate_stage4_ip_config_timeout): assertion failed: (self)

[mtd]

full /var/log/messages with two examples (for comparison/context)

[gregorio]

Milestone Never Assigned deleted