Arch Linux

firecat53

Member

From: Lake Stevens, WA, USA

Registered: 2007-05-14

Posts: 1,542

Website

[Solved]netcfg2 behavior on resume from suspend

I'm using the core/netcfg package to manage wireless with my HP DV6000 laptop (b43 driver for Broadcom 4311 card). I have two profiles setup - one for home with a WPA network and one for work with an unencrypted network. At home, I can suspend (using s2ram from the uswsusp pkg) and resume, and the wireless will automatically reconnect on resume.
  At work, on the unencrypted network, I don't get the wireless back on resume. Ifconfig and iwconfig show the ip address and that the connection is still up, but I can't even ping the router. In order to get it back, I have to do netcfg2 -a && netcfg2 station1.

Any ideas why this might be different?

Here are the two profiles:

CONNECTION="wireless"
DESCRIPTION="Home"
INTERFACE=wlan0
HOSTNAME=scotty
IP="dhcp"
ESSID=homeessid
SECURITY=wpa # One of wep, wpa, wpa-config, none
KEY="secretkey"
SCAN="YES"
TIMEOUT=10

CONNECTION="wireless"
DESCRIPTION="Station 1"
INTERFACE=wlan0
HOSTNAME=scotty
IP="dhcp"
ESSID=dd-wrt
SECURITY=none # One of wep, wpa, wpa-config, none
SCAN="YES"
TIMEOUT=10

[Thanks, Scott

Last edited by firecat53 (2008-09-27 02:57:39)

---

Github

Profjim

Member

From: NYC

Registered: 2008-03-24

Posts: 658

Re: [Solved]netcfg2 behavior on resume from suspend

I don't really know _why_ you'd be experiencing the difference. But I can offer some ideas about how to make it easier to live with. You can add the "take down netcfg" and "bring netcfg back" scripts to the commands that run when you suspend or resume. (If you use pm-utils, these are in /etc/pm/sleep.d/.)

And perhaps you can get by with less pushy commands. When you're at work, suspend and resume. Now instead of "netcfg2 -a && netcfg2 station1", see if "dhcpcd -n wlan0" or "dhcpcd -r '' wlan0" or "dhcpcd -k wlan0; dhcpcd wlan0" will be enough to get you going. If so, you can fold those commands into your resume-from-sleep scripts instead.

firecat53

Member

From: Lake Stevens, WA, USA

Registered: 2007-05-14

Posts: 1,542

Website

Re: [Solved]netcfg2 behavior on resume from suspend

Anyone able to have a look at this?

Scott

---

Github

iphitus

Forum Fellow

From: Melbourne, Australia

Registered: 2004-10-09

Posts: 4,927

Re: [Solved]netcfg2 behavior on resume from suspend

Make sure the networks are taken down before suspending, and then reconnected from scratch upon resume. Wireless connectivity was not designed to handle suspend. (I think theres a suspend config for this or something...)

If that's still not working, unload/reload the module before trying to connect. Some wireless drivers have pretty weak resume support.

Last edited by iphitus (2008-09-25 08:12:28)

firecat53

Member

From: Lake Stevens, WA, USA

Registered: 2007-05-14

Posts: 1,542

Website

Re: [Solved]netcfg2 behavior on resume from suspend

Oops . . .  sorry Profjim .... didn't see your post before I bumped!  The dhcpcd commands don't seem to work after a resume.

However -- I figured out how to make it work -- not sure WHY, but it works!

I had added the 's2ram -f' command to /etc/acpi/handler.sh under the lid/button event to trigger the suspend (since pm-suspend would freeze on resume). BUT -- after adding /etc/pm/config.d/config with:

SLEEP_MODULE=uswsusp
ADD_PARAMETERS="--force"

in order to force pm-suspend to use the uswsusp suspend (which works properly for my hp dv6000), AND change the 's2ram -f' to 'pm-suspend' in /etc/acpi/handler.sh -- it WORKS! Ok -- well, the resume at work on the unencrypted network works now to restore the connection. Still have to check it at home on Sun.

Thanks all!
Scott

---

Github

The Void

Member

Registered: 2008-09-06

Posts: 3

Re: [Solved]netcfg2 behavior on resume from suspend

Since the last netcfg2 upgrade, I have the same problem resuming.  I see you found a solution that works, but I found a different solution that worked for me.  I'll post my solution just in case others have the same problem.

I'm willing to bet that you could fix your problem with the Driver Quirks of netcfg2 described here.  http://wiki.archlinux.org/index.php/Net … d_later.29  Apparently these driver quirks workarounds were built into the previous versions of netcfg.

My wireless card is an Intel PRO/Wireless 4965AGN.  Adding the line QUIRKS=(preessid) to /etc/rc.conf fixed my resume problem.  Yours may need prescan defined in quirks.