# "Saving" wireless setup on suspend

## justin_brody

Hello,

Is there a way to get my machine to save the configuration of the wireless card on suspend and just re-use that on resume?  Specifically, it would be nice if the machine didn't have to reconnect to the router and get an IP address [not entirely sure how much of this it does now, but it does take about a minute to get connectivity back after resume].  For what it's worth, I'm using pm-suspend for hibernation.

Thanks!

-Justin

----------

## dmpogo

 *justin_brody wrote:*   

> Hello,
> 
> Is there a way to get my machine to save the configuration of the wireless card on suspend and just re-use that on resume?  Specifically, it would be nice if the machine didn't have to reconnect to the router and get an IP address [not entirely sure how much of this it does now, but it does take about a minute to get connectivity back after resume].  For what it's worth, I'm using pm-suspend for hibernation.
> 
> Thanks!
> ...

 

It has to connect to router anyway - after all router routes the traffic  :Smile: ,  and a sane administrator will not configure dhcp/router  to allow incoming cards to use IP of their choosing.  Your better bet is to investigate why it takes a minute to get IP

----------

## justin_brody

Thanks for the response.  I apologize for my ignorance about networking.

With the dhcp, if I'm leasing an IP address for a certain amount of time, shouldn't I be able to re-use within that time frame?  

In terms of the reconnect process, here's some line's from my messages file:

 *Quote:*   

> 
> 
> Aug  2 16:43:27 citta kernel: [ 9279.514358] bcm5974 3-6:1.2: __pm_runtime_resume()!
> 
> Aug  2 16:43:27 citta kernel: [ 9279.514362] usb 3-6: __pm_runtime_resume()!
> ...

 

So it's about 19 seconds (I guess a minute was an exaggeration   :Wink:  ).  I can certainly live with this if it's what needs to happen; I just thought there might be a way to speed it up a little.  Does the whole "supplicating" process begin again once I resume the machine?  If so, does it have to?

----------

## dmpogo

There are two steps to estabilishing wireless network. First you establish wireless connection with access point.  This envolved frequency negotiation and authentication, after which access point allows you to connect.  The authentication can be none,   mac address filter, WPA key exchanges etc, checks for SSID etc. Usually this is what 'supplication is'.   It is usually reasonably fast, but some mechanisms are faster, some more secure.  You could speed it up a bit if you use WPA, for example, by keeping in your config (say wpa_supplicant.conf) not a plaint text password, but a HEX key generated by wpa_psk.

After the wireless connection is setup, network is configured, in the same way as a wired one.  Here is where dhcp kick in. This often takes the longest.

19 sec is not fast but OK, with 1 min I started to worry that some timeouts are kicking in (typically dhcpcd cleint timeouts in 30 sec)

dhcp may well give you the same IP as before.  But it depends on configuration of both server and client.   Lease has time, and may be either released or not on disconnect.  If you use dhcpcd as a client, by default it leaves all the lease time issues  in the hands of the server.  But there are some options to the client that modify its behaviour., check man pages.

----------

## justin_brody

Thanks for the clarification!  After playing around a bit, it looks like most of the time is taken up by the "supplication".  I tried changing the password to HEX as you suggested, but it unfortunately didn't seem to save any time.

I did notice that it spent a bit of time "scanning" first, presumably to figure out which SSIDs were available (I'm using wpa_supplicant, for what it's worth).  Would it be possible to skip that step?  Somehow have the machine save the Access Point on suspend and automatically reassociate with it on resume?

Specifically, here's some of what's happening on resume:

```

# iwevent 

Waiting for Wireless Events from interfaces...

23:02:35.428867   eth1     Custom driver event:Conn Disassoc 00 08

23:02:35.428911   eth1     New Access Point/Cell address:Not-Associated

23:02:50.539984   eth1     Set Mode:Managed

23:02:50.540030   eth1     Set Frequency:24.22 GHz

23:02:50.540165   eth1     Set ESSID:"JB"

23:02:55.494018   eth1     New Access Point/Cell address:00:14:00:00:83:8F

23:02:55.582992   eth1     Registered node:00:14:D1:C4:83:8F

23:02:55.583014   eth1     Custom driver event:Conn Success 00 00

```

So it's taking about 15 seconds to figure out which ESSID to associate with?  Could I just use iwconfig to set that on resume?

----------

## dmpogo

Could you post wpa_supplicant.conf ?

One thing is, if SSID is not defined there,  you can define it and perhaps avoid extra scanning.

----------

## justin_brody

Sure, here's the first few lines:

```

 # cat /etc/wpa_supplicant/wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant

ctrl_interface_group=0

update_config=1

network={

        ssid="JB"

        psk=*****   

        proto=WPA

        key_mgmt=WPA-PSK

        priority=100

}

network={

        ssid="FandM-WiFi"

        psk="******"

        proto=RSN

        key_mgmt=WPA-PSK

        priority=10

}

```

Just as an experiment I tried using iwconfig to set the AP but that seemed to start the supplication process over.

----------

## dmpogo

And you are trying to connect to the first one ? (I assume since psk does not have quotation there  :Smile:  )

----------

## justin_brody

Both actually; the first one is my home and the second is my work.

You're right about the quotes though, that's my replacing the plain text with the hex code  :Smile: 

----------

## dmpogo

 *justin_brody wrote:*   

> Both actually; the first one is my home and the second is my work.
> 
> You're right about the quotes though, that's my replacing the plain text with the hex code 

 

I just wanted to confirm that the one you have delay with does have a higher priority (although I found that it does not immediately mean it will be checked first).

I am somewhat out of ideas at this stage, especially if delay is on connection setting phase, over which we do not have much control.

Overall it seems that something - access point/card combination is just a tad slow.  BTW, how fast is the connection at that other network ? (i.e do you just have 

a slow to connect access point in the first case)

There is couple of  parameters to wpa_supplicant that has to do with scanning

ap_scan = 0/1/2

in the global section and 

scan_ssid=0/1 

in the network block. I never noticed whether the first one makes a difference, and the seconds default (0) is claimed to be the fasted. It is, however, the broadcast one.

If you have one access point in the network that you know well,   you can set bssid variable in network block. It is Mac of access point. 

Maybe it will give some speed up.

----------

