Wi-fi roaming from the command line

[allanlewis]

After reading this howto, I decided that there must be a way of doing what Gnome (via NetworkManager), Windows XP/Vista and other systems do: automatically connecting to the network with the strongest signal from a "hardwired" list. Windows does this graphically (and not terribly reliably in my experience) but in Linux it inevitably falls to the command line. So, here goes...

1. Open a terminal window.
2. Type

   Code: Select all

   geany /etc/wpa_supplicant.conf &

   and press enter to open the wpa_supplicant configuration file in a text editor.
3. Put a hash, #, at the beginning of every line in the file without one already---this will disable any configurations already there but still allow you to go back to your old configuration if this doesn't work. (Alternatively, if you know what you're doing, you could make a backup of the file and restore it later if necessary.)
4. Put the following code at the beginning of the file:

   Code: Select all

   ctrl_interface=/var/run/wpa_supplicant
   ap_scan=2
   update_config=1

5. Go to the end of the file and add one of the following "sections" for each network you want to be able to connect to, depending on the type of security, if any, employed. In all cases, networkname is the name of the network, myname is an arbitrary name for this network (e.g. "home" or "work") and x is the priority---a higher value here will make a connection to this network more "desirable". (Wpa_supplicant automatically prefers secured networks to unsecured networks, and prefers WPA to WEP, but the priority value overrides this.)
   • Unsecured networks:

     Code: Select all

     network={
     	id_str="myname"
     	ssid="networkname"
     	key_mgmt=NONE
     	priority=x
     }

   • WEP-encrypted networks:

     Code: Select all

     network={
     	id_str="myname"
     	ssid="networkname"
     	key_mgmt=NONE
     	wep_key0=0123456789abcdef012345678
     	wep_tx_keyidx=0
     	priority=x
     }

     Notes:
     • If you have multiple WEP keys, then add parameters wep_key1, wep_key2, etc. and change the value of wep_tx_keyidx as appropriate. I'm not familiar with systems that "rotate" WEP keys---that's outside the scope of this howto.
     • I'm not sure if the WEP key needs to be in double quotes or not - can someone please try both and let me know? (The wpa_supplicant documentation says it doesn't, but I have reason to disbelieve that.)
   • WPA-secured networks:

     Code: Select all

     network={
     	id_str="myname"
     	ssid="networkname"
     	psk="0123456789abcdef012345678"
     	proto=WPA
     	key_mgmt=WPA-PSK
     	pairwise=TKIP
     	group=TKIP
     	priority=x
     }

     Notes:
     • As above, I'm not sure in what circumstances the security key needs to be in double quotes - for my network it does.
     • I'm assuming TKIP encryption here. To the best of my knowledge, the majority of home wireless systems use this, but some use AES, in which case both instances of TKIP should be replaced by CCMP. Also, the value of proto should be changed to RSN or WPA2 (it doesn't matter which). Having said that, I'm not sure if other changes need to be made in that case - see the end of this post for further info.
6. Save the file and return to the terminal window. (You can close Geany, the text editor, if you want.)
7. Type

   Code: Select all

   geany /etc/rc.d/rc.local &

   and press enter to open the user startup script---all the commands in this file are run every time you boot into Puppy.
8. Add the following lines to the end of the file:

   Code: Select all

   ifconfig ethX up
   wpa_supplicant -Dwext -iethX -c/etc/wpa_supplicant.conf
   rm /etc/dhcpc/*.pid
   dhcpcd -t 30 -h puppypc -d ethX

9. Replace ethX with the name of your wireless interface. If you don't know this, type

   Code: Select all

   iwconfig

   into a terminal and find the interface that doesn't say "no wireless extensions"---it's likely to be eth0, eth1 or wlan0.
10. Replace wext in the second line if you have an unusual network adapter, according to the following list, taken from the wpa_supplicant README (and edited for brevity):
    • hostap = Host AP driver (Intersil Prism2/2.5/3)
    • atmel = ATMEL AT76C5XXx (USB, PCMCIA)
    • wext = Linux wireless extensions (generic)
    • ralink = Ralink Client driver
    • wired = wpa_supplicant wired Ethernet driver
11. Save the file, close everything, and reboot Puppy. If all goes well, Puppy should take a little longer to start than usual but should be connected to your wireless network as soon as the system has finished booting!

Good luck!

Note: The homepage of wpa_supplicant is pretty useful if you get stuck, as are the README and example configuration file.

[Pizzasgood]

For starters, your question about quotes: As far as I've been able to tell, when using WPA if you put quotes around the passkey it assumes that it's the ASCII key, before being transformed into the 64 character hexidecimal key (consisting of only 0-9 and A-F). If you don't use quotes, it assumes it's the 64 character hex key that was generated from the ASCII passkey.

I don't have experience with the WEP version, but I assume it's the same situation (though possibly with different lengths of keys).


On the part with the dhcpcd -t 30 -h puppypc -d ethx, the -h puppypc probably isn't necissary. Also, some people might need to use a longer timeout than 30 seconds. For most people it will probably be fine though. Just something to keep in mind if you find you aren't able to connect for some reason.


A final note: in my (very limited) experience, you should use wext when using ndiswrapper. Maybe that's a Puppy specific quirk, or maybe something to do with the particular card I was testing with. But IIRC whenever I tried using ndiswrapper rather than wext it wouldn't work right.

[allanlewis]

Thanks for that - I'll bear those points in mind.

[tempestuous]

allanlewis,
you have done some good investigation into the workings of wpa_supplicant, especially the part about "priority=..".
There are many users on this forum struggling to understand the basic wifi commands, so for the sake of clarity let me re-emphasize that your system of connecting to a WEP-encrypted network is somewhat unconventional in that it uses wpa_supplicant rather than the more commonly used iwconfig.
Fundamentally, this means that all WEP encryption/de-encryption is done purely in software with wpa_supplicant, rather than being handled by the inbuilt WEP encryption/de-encryption functions of the wifi hardware and its driver/firmware.

There is one line missing from your wpa_supplicant.conf which can be important: "ap_scan=.."
This deals with routers which do not broadcast their ESSID. I can't remember the correct settings, but it was discussed on the forum when rarsa was initially rewriting the Network Wizard to accommodate WPA -
http://www.murga-linux.com/puppy/viewtopic.php?t=15180

but some use AES, in which case both instances of TKIP should be replaced by CCMP.

Yes, but it's also necessary to change the "proto=.." line. This has already been discussed and tested on the forum, and in recent versions of Puppy there is a WPA2 (AES) configuration file - /etc/wpa_supplicant2.conf

Not all of the -D (driver) parameters that you listed are valid ... I compiled the version of wpa_supplicant in Puppy and I can say that only certain parameters were enabled in the compilation ...

hermes - No. This failed to compile. But the hermes driver is rare, and the devices which need it can usually work with the orinoco driver or ndiswrapper.

broadcom - No. This is for the proprietary driver for Broadcom-based wireless routers that use Linux.
Broadcom wifi devices require the wext parameter.

madwifi - this parameter successfully compiled, but SHOULD NOT be used. Atheros-based devices now require the wext parameter.

ipw - this is no longer valid for ipw (Intel) devices, but it is needed for Realtek devices.

bsd and ndis - these are incompatible with Linux.

whenever I tried using ndiswrapper rather than wext it wouldn't work right

Yes, "ndiswrapper" is not a valid -D parameter. "wext" is correct.

the -h puppypc probably isn't necessary

The -h (hostname) parameter is useful when connecting via Samba to Windows machines. Some versions of Windows (I'm not sure which ones) need to identify other network clients by their hostname.

[allanlewis]

allanlewis,
you have done some good investigation into the workings of wpa_supplicant, especially the part about "priority=..".

Thanks

There are many users on this forum struggling to understand the basic wifi commands, so for the sake of clarity let me re-emphasize that your system of connecting to a WEP-encrypted network is somewhat unconventional in that it uses wpa_supplicant rather than the more commonly used iwconfig.
Fundamentally, this means that all WEP encryption/de-encryption is done purely in software with wpa_supplicant, rather than being handled by the inbuilt WEP encryption/de-encryption functions of the wifi hardware and its driver/firmware.

I didn't realise that - so would this affect very old computers? Is the encryption/de-encryption process complex enough to affect the performance of a very slow machine?

There is one line missing from your wpa_supplicant.conf which can be important: "ap_scan=.."
This deals with routers which do not broadcast their ESSID. I can't remember the correct settings, but it was discussed on the forum when rarsa was initially rewriting the Network Wizard to accommodate WPA -
http://www.murga-linux.com/puppy/viewtopic.php?t=15180

Yes, you're right. In fact, there's another line too:

Code: Select all

ctrl_interface=/var/run/wpa_supplicant

Also,

Code: Select all

update_config=1

is useful for debugging with the wpa_cli app.

but some use AES, in which case both instances of TKIP should be replaced by CCMP.

Yes, but it's also necessary to change the "proto=.." line. This has already been discussed and tested on the forum, and in recent versions of Puppy there is a WPA2 (AES) configuration file - /etc/wpa_supplicant2.conf

Thanks again - I really shouldn't write HOWTOs in the early hours of the morning!

Not all of the -D (driver) parameters that you listed are valid ... I compiled the version of wpa_supplicant in Puppy and I can say that only certain parameters were enabled in the compilation ...

Thanks again! It seems to me that the vast majority of wireless adapters will work with wext anyway - am I correct?

the -h puppypc probably isn't necessary

The -h (hostname) parameter is useful when connecting via Samba to Windows machines. Some versions of Windows (I'm not sure which ones) need to identify other network clients by their hostname.

The -h certainly doesn't do any harm, and I think that parameter is what shows up on the wireless router's "associated devices" (or equivalent) page.

Thanks for all those tips - I'll do a little editing now to take account of all your advice.

Update: I've now edited the HOWTO. Tempestuous, can you please check it to ensure that I've understood what you said in your previous post. (Anyone else, feel free to post corrections/addenda here.)

[JohnRoberts]

Allan, could you please post a complete copy of the config file (with sensitive data marked out)?

Thanks
JR

P.S. Guys, maybe this thread could be sticky-fied, what do you think?

[allanlewis]

Allan, could you please post a complete copy of the config file (with sensitive data marked out)?

Which file? The wpa_supplicant config file or the rc.local startup script?

P.S. Guys, maybe this thread could be sticky-fied, what do you think?

I second that.

[JohnRoberts]

Which file? The wpa_supplicant config file or the rc.local startup script?

...both of them, please

[allanlewis]

Which file? The wpa_supplicant config file or the rc.local startup script?

...both of them, please

OK...

The wpa_supplicant.conf file should contain the following at the top:

Code: Select all

ctrl_interface=/var/run/wpa_supplicant
ap_scan=2
update_config=1

The rest should be several sections beginning "network={", as described above, depending on whether you have WPA, WEP, or unencrypted networks. I can't give you the complete file because it depends entirely on how many and what types of networks you want to be able to connect to.

The rc.local file should contain the following lines. The order matters but the location doesn't - if in doubt, put them at the end of the file.

Code: Select all

ifconfig eth0 up
wpa_supplicant -Dwext -ieth0 -c/etc/wpa_supplicant.conf
rm /etc/dhcpc/*.pid
dhcpcd -t 30 -h puppypc -d eth0

Some terms might need to be changed depending on your configuration:

• eth0 could also be eth1, eth2, etc. or wlan0, or ra0. (If anyone knows of any other possibilities, please tell me.) This needs to be the same in every instance in the code above - there are three, one in the first, second, and fourth lines.
• wext probably doesn't need to be changed for the vast majority of wireless adapters - could someone tell me what wireless adapters actually require a different setting here?
• puppypc can be anything you like, as it's just what your computer tells your wireless router when the router asks for a machine name. (There's probably a limit on how long it can be and you definitely can't have spaces in it - best to keep to alphanumeric characters.)

Does that explain everything OK?

[JohnRoberts]

loud & clear

[allanlewis]

loud & clear

Glad I could help

[tempestuous]

wext probably doesn't need to be changed for the vast majority of wireless adapters - could someone tell me what wireless adapters actually require a different setting here?

I listed all valid -D parameters with corresponding compatible modules in Part2 of my wifi HOWTO -
http://www.murga-linux.com/puppy/viewto ... 336#159336

[allanlewis]

wext probably doesn't need to be changed for the vast majority of wireless adapters - could someone tell me what wireless adapters actually require a different setting here?

I listed all valid -D parameters with corresponding compatible modules in Part2 of my wifi HOWTO -
http://www.murga-linux.com/puppy/viewto ... 336#159336

Thanks for that.

I think I'm right in saying that the majority of current wireless adapters will work with wext or ralink - correct? I checked the Linux Wireless LAN Support Guide and it seems that most of the 818x and hostap adapters are obsolete - again, am I broadly correct? This is all a bit confusing, since surely wpa_supplicant could find out the chipset itself quite easily - maybe using iwconfig - and this would save people some effort when running it from the command line. (I imagine this sort of autodetection is something that either the developers of wpa_supplicant, or of the "wext" wireless extensions, are working on, but the Puppy network wizard has it all sorted anyway )

[tempestuous]

Well you're generally correct, the Prism2/2.5/3 chipsets (supported by HostAP driver) are no longer in production, but I wouldn't want to speculate about what wifi devices are actually in common use out there.
Certainly, there are still people with older devices who want to use WPA encryption under Linux. There are such instances on this forum.

surely wpa_supplicant could find out the chipset itself quite easily - maybe using iwconfig

No, unfortunately. However, Dougal has dealt with this problem in the Network Wizard by determining the driver in use, then setting the necessary -D parameter automatically (see lines 94-105 of /usr/sbin/wag-profiles.sh). So people who use the Network Wizard for WPA configuration never need to know the inner workings of wpa_supplicant.

[allanlewis]

Well you're generally correct, the Prism2/2.5/3 chipsets (supported by HostAP driver) are no longer in production, but I wouldn't want to speculate about what wifi devices are actually in common use out there.
Certainly, there are still people with older devices who want to use WPA encryption under Linux. There are such instances on this forum.

Thanks for that - useful for future reference.

surely wpa_supplicant could find out the chipset itself quite easily - maybe using iwconfig

No, unfortunately. However, Dougal has dealt with this problem in the Network Wizard by determining the driver in use, then setting the necessary -D parameter automatically (see lines 94-105 of /usr/sbin/wag-profiles.sh). So people who use the Network Wizard for WPA configuration never need to know the inner workings of wpa_supplicant.

That's sort of what I meant - that wpa_supplicant could find out the driver in the same way the Puppy network wizard does, while perhaps allowing a user override in case it gets it wrong.

Anyway, I have one other (open) question:
Does the use of wpa_supplicant for WEP/WPA encryption have any impact on system performance? From previous posts (on other threads) I am lead to believe that no Linux drivers apart from the ralink ones support hardware encryption, so wpa_supplicant does the encryption in software. Is this CPU use significant when, say, constantly downloading large amounts of data? So if someone was downloading across a wireless network at a constant 10MB/s, how much system resource would that use and would it produce any noticeable slowdown on an old, slow system? (It doesn't make any difference on my laptop, but that's fairly recent - Centrino 1.7GHz, recently upgraded to 2GB RAM. Just wondering if it would have any impact on, say, a 486...)

[tempestuous]

Does the use of wpa_supplicant for WEP/WPA encryption have any impact on system performance?

In theory, yes. But I haven't tested the theory.

It would make an interesting experiment to check CPU usage (with conky) while downloading a large file using WEP decryption via iwconfig, versus WEP decryption via wpa_supplicant.

Then do the same test again using WPA with the Ralink driver and iwpriv commands, versus wpa_supplicant.

I'm guessing the difference in CPU usage would only be noticeable with an i486 or Pentium1.

[allanlewis]

Does the use of wpa_supplicant for WEP/WPA encryption have any impact on system performance?

In theory, yes. But I haven't tested the theory.

It would make an interesting experiment to check CPU usage (with conky) while downloading a large file using WEP decryption via iwconfig, versus WEP decryption via wpa_supplicant.

Then do the same test again using WPA with the Ralink driver and iwpriv commands, versus wpa_supplicant.

That would be interesting Any volunteers?

I'm guessing the difference in CPU usage would only be noticeable with an i486 or Pentium1.

That's what I would think too.

[Gizzo]

I'm a new puppy user and whilst I was getting my wpc54gs up and running I noticed a significant increase in performance using ndiswrapper as opposed to bcm43xx.
Indeed, the bcm driver was only good for getting the card up to scan for networks. When it came to establishing a wpa connection it got to 8% and then the red bar maxxed-out. End of wpa connection.

I can't say I'd ever thought too much about wifi performance before I read this thread and experienced the above.

Is this expected, or is it just buggy?

Any thoughts are most appreciated.