Ticket #6750 (new defect)

Opened 5 years ago

Last modified 5 years ago

Incorrect wireless setting after resume

Reported by: kimquirk Owned by: cjb
Priority: blocker Milestone:
Component: power manager (OHM) Version:
Keywords: release? Cc: bemasc, mtd
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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?

Attachments

olpc_trac-6750-nm_crash_assert_20080328-1.txt (33.3 kB) - added by mtd 5 years ago.
trimmed logs around: nm_device_activate_stage4_ip_config_timeout): assertion failed: (self)
olpc_trac-6750-nm_crash_assert_20080328-2.txt (88.9 kB) - added by mtd 5 years ago.
full /var/log/messages with two examples (for comparison/context)

Change History

Changed 5 years ago by 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?

Changed 5 years ago by cjb

  • keywords review? added
  • priority changed from high to blocker

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.

Changed 5 years ago by mstone

  • keywords release? added; review? removed

Changed 5 years ago by bemasc

  • cc bemasc added

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.

Changed 5 years ago by mtd

  • cc mtd added

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.

Changed 5 years ago by 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...

Changed 5 years ago by mtd

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

Changed 5 years ago by mtd

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

Changed 5 years ago by gregorio

  • milestone deleted

Milestone Never Assigned deleted

Note: See TracTickets for help on using tickets.