[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: wifi failed after hibernate

Freddy Freeloader wrote:

Joe Emenaker wrote:

Stuart Prescott wrote:
[1] <rant>Long story... when I was setting this system up that was the recommended way to do it. It worked really well for me. Then the wpa_supplicant maintainers changed their minds... 
I was similarly pissed about the change....
I have never had this specific problem, but I ran into the confusing change in wpa_supplicant on a laptop rebuild a while back. I figured that change out and actually thought it was quite an improvement.
Okay, I did some reading and have cleared up my understanding of the current state of wpasupplicant.
First, to recap... if you look in /usr/share/doc/wpasupplicant/NEWS.Debian, you'll come across the message that most people discovered too late: 
 -- Kel Modderman <kelrin@tpg.com.au>  Tue, 13 Jun 2006 22:33:16 +1000

  IF YOU HAVE USED WPASUPPLICANT BEFORE, THIS UPGRADE PROBABLY BROKE YOUR
  CONNECTION!
This package does not ship any configuration to wpasupplicant in /etc/{wpa_supplicant/,}wpa{,_}supplicant.conf anymore. 
  ...
... Therefore, in order to actually use wpasupplicant in this package, you are required to edit your /etc/network/interfaces in order to start wpasupplicant. Please read the file README.modes...
The "old way" was to have your wifi interfaces *not* set to auto in /etc/network/interfaces, and then to start wpasupplicant which would automatically ifup/ifdown the interface when it associated with an AP.
The maintainers decided that they didn't like this. They wanted more of the network info to be kept in /etc/network/interfaces whenever possible.... so ifupdown was changed so that it recognized a bunch of new options, like: 
iface ath0 inet static
        wpa-driver madwifi
        wpa-ssid HotSpot1
        wpa-bssid 00:1a:2b:3c:4d:5e
        wpa-psk madhotspot
        wpa-key-mgmt WPA-PSK
        wpa-pairwise TKIP CCMP
        wpa-group TKIP CCMP
        wpa-proto WPA RSN
This allowed you to keep all of your wifi settings in /etc/network/interfaces with all of your other stuff. The *problem*, however, was that you could only specify a single wpa-ssid, a single WPA key, etc. <sarcasm>This made it great for people with wifi desktop machines and for laptop users who never take their laptop anywhere. In other words, about 5% of wpasupplicant's user base</sarcasm>
There's also a bit of a "Chicken or Egg" problem, where you might have some network settings that need to be set in /etc/network/interfaces, but you don't know which values to use until wpasupplicant knows which AP it has associated with, but, under the new system, wpasupplicant doesn't get run until the interface is ifup'd from /etc/network/interfaces. 

The way they eventually dealt with this seems to be like this:
1 - In your /etc/network/interfaces, you define your wifi interface as "manual", and you give a path to a conf file for wpasupplicant. 
iface eth1 inet manual
        wpa-driver wext
        wpa-roam /path/to/wpa_supplicant.conf
2 - Also in /etc/network/interfaces, you define some pseudo interface names which will, later, be referenced by wpasupplicant depending upon which AP you're connected to: 
iface plain_dhcp inet dhcp

iface at_home inet static
        address 192.168.0.20
        gateway 192.168.0.1

iface at_work inet static
        address 12.34.56.78
        gateway 12.34.56.1
3 - Then, in your wpasupplicant conf file (the one mentioned in the "wpa-roam" line), you define the AP's and you use the id_str option to reference which of these pseudo interfaces to map to: 
network={
        ssid="HomeSweetHome"
        id_str="at_home"
        key_mgmt=NONE
}

network={
        ssid="BigCorp"
        id_str="at_work"
        psk=123456789...
}

network={
        ssid=""
        key_mgmt=NONE
        id_str="plain_dhcp"
}
IMHO, it's a little demented to have the settings go from /etc/network/interfaces, out to a wpasupplicant.conf, and then *back* into /etc/network/interfaces under a different name... but I can't think of a better way to do it if they're committed to having everything go through /etc/network/interfaces, first. 

Hope this helps some people....

- Joe

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply to: