[solved] wpa_supplicant following system update

Looking at friend's monitor (running Arch), I saw his clock was behind, so I wanted to # ntpdate pool.ntp.org his system. It turned-out ntp hadn't been installed. I started with #pacman -S ntp, but dependency errors appeared -- the typical sign that a system needs updating. So, # pacman -Syu, and sure enough, it was at leas 4GB out of whack. Afterwards, all was good for adding ntp and running ntpdate. His clock updated.

The problem was, the first time he cycled power, his wifi didn't connect. I found I could easily connect his system manually (CLI) with

# wpa_supplicant -Dwext -iwlp1s0 -c/etc/wpa_supplicant/wpa_supplicant.conf &

or better...

# wpa_supplicant -Dnl80211 -iwlp1s0 -c/etc/wpa_supplicant/wpa_supplicant.conf &

So, WTF? One possibility was that, beginning in 2016, dhcpcd stopped connecting its built-in wpa_supplicant hook during dhcpcd install. It has to be done manually. There's also a second option, giving at least two solutions.

two solutions

1. # systemctl disable wpa_supplicant.service
   # cp /usr/share/dhcpcd/hooks/10-wpa_supplicant /lib/dhcpcd/dhcpcd-hooks

   This puts dhcpcd in charge, calling and restarting wpa_supplicant, as needed. Make sure the right PID directory (if needed) and password are in /etc/wpa_supplicant/wpa_supplicant.conf, so it can negotiate security. Also, if dhcpcd is hanging looking for an IPV6 connection, a person can add the "-4" flag to the "ExecStart" command in /usr/lib/systemd/system/dhcpcd.service. Problem solved; back to rock solid wifi connection.
2. Instead of putting dhcpcd in charge, put wpa_supplicant in charge, calling dhcpcd. This is not recommended since it requires a bunch of complicated custom shit described below

unit file

I checked systemd (systemctl list-unit-files) and, as expected, I saw that wpa_supplicant was no longer enabled. When I enabled wpa_supplicant, it created symlinks which were not straightforward ("epitest.fi"?), which I did not trust as helpful. So I wrote him a straightforward service unit file specific for initializing his wifi:

# nano /etc/systemd/system/johndoewifi.service

# custom wifi connect
# Arch location: /etc/systemd/system/johndoewifi.service
[Unit]
Description=wpa_supplicant wext wifi
Wants=network.target
After=network.target
# Before=network.target

# execute and run in background
[Service]
Type=forking
PIDFile=/var/run/wpa_supplicant.pid
ExecStart=/usr/bin/wpa_supplicant -Dwext -iwlp1s0 -c/etc/wpa_supplicant/wpa_supplicant.conf
# ExecStop=/usr/bin/wpa_supplicant -x

[Install]
WantedBy=multi-user.target

restart from user

You can get wpa_supplicant to run from user, with eg

# nano /etc/wpa_supplicant/wpa_supplicant.conf
# Allow users in the 'wheel' group to control wpa_supplicant
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel

If John Doe is in the wheel group he can start wpa_supplicant no problema. However, it will fail, since he doesn't have authority to bring the interface UP or DOWN from userspace. That requires another kludge.
(source: Gentoo wiki)

slackware 12.0 - wpa, wicd

I'm using the Atheros AR242x 64 (5007 chipset) in a Toshiba Satellite running Zenwalk 5.2. So, this is not technically a Slackware 12.0 post - the Slackware foundation of Zenwalk means they are similar. I'll edit the specifically Slackware aspects of this post over Christmas break. For Zenwalk WPA, I mostly followed these excellent instructions .

Atheros AR242x 64 (5007 chipset)
The information here was helpful for understanding this newer chip. For a module, Zenwalk provides ath5k, but ath5k wasn't responding well to configuration attempts, so I turned to a Madwifi module. Incidentally, the Madwifi site also contains information on ath5k here, and it appears the ath5k module will eventually be effective. Currently however, the steps which worked with the Madwifi module were:

1. in /etc/modprobe.d/blacklist, blacklist the "ath5k" module
2. reboot and lsmod - make sure ath5k is gone
3. download madwifi-hal-0.10.5.6-r3861-20080903.tar.gz , or the newest one there, make, and install.
4. reboot again and lsmod
5. iwconfig ath0

WEP
WEP is trivial, merely requiring the two iwconfig commands "essid" and "key restricted", matched to whatever network I was using. Because I'm multihomed, the order of bringing-up the interfaces was the only other pay-attention issue. If the interfaces are activated backwards in /etc/rc.d/rc.local, then dhcpcd apparently attempt to assign DNS to the interface on the LAN, rather than the one on the WLAN. blah blah blah.

WPA
The basis here was again gained at this Zenwalk wiki , but there are a couple of tweaks or clarifications. It appears that wpa_supplicant relies upon inserting the wext module into the kernel.
1. using wpa_passphrase with the [essid] and [password] varies with the WLAN with which one wants to connect. The command is used similarly to the WEP iwconfig ath0 key restricted "xxxxx", which varies with each WLAN. Wpa_password then, is not a key for the laptop I'm working from, it's a password key hashed for the WLAN I'm attempting to connect with. This means I have a different entry for each WPA WLAN I'm working on.
2. wpa_password [essid] [password] > /etc/wpa_supplicant.conf is a brilliant way to start the initial conf file. And, as noted in the wiki, the file can be this simple to work:

network={
ssid="BART Transit"
#psk="oct2008@rezt9bit"
psk=3ad964f16045787dec86a4730e9dec4bedaa9e24f2998eacfa363e80510e3393
key_mgmt=WPA-PSK
proto=WPA
}

3. The following command line from the wiki configured ath0 properly on the first shot:

wpa_supplicant -i wlan0 -D wext -c /etc/wpa_supplicant.conf -B

the "-B" switch is added to make the program run as a daemon, and might not be necessary.
4. After the above, I had only to dhcpcd ath0 to get a valid connection.
5. One issue appears to be quickly enabling or disabling configurations for different WLANs via /etc/wpa_supplicant.conf. (see wicd below).
6. Permanence/boot - inserting the line in Step 3 above into an /etc/rc.local should work if I have an /etc/wpa_supplicant.conf file with a single network configuration in it.

more wpa_supplicant.conf
Wpa_supplicant is not necessary for WEP security, since we can program the card directly with CLI commands to prepare WEP. However, if one chooses to run wpa_supplicant for everything, /etc/wpa_supplicant.conf files appear able to configure WEP and unencrypted connections, in addition to WPA connections. The conf files are useful for storing various wi-fi location configurations. Each connection requires a different conf file, eg etc.wpa_supplicant1.conf, etc.wpa_supplicant2.conf, etc. Apparently wicd can do this with a gui interface which manages switching. But this also means the wicd daemon must run - additional memory usage.

A site with the wpa_supplicant.conf commands is this one, and a site that shows the different WLAN setups in the "conf" file is here (scroll down).

wicd
Wicd configuration files live in /etc/wicd/encryption/templates. A primer for converting wpa_supplicant.conf files to wicd configurations is at this site. Once the various templates are in place, it appears we can switch between them using the wicd gui, though it's unclear if dhcpcd would need to be killed and restarted in the command line?

zenwalk 5.2 in Toshiba Satellite (L305D-S5869)

2022 update

The original post from 2008 is at the bottom, but I just couldn't help wanting this dinosaur alive. NB: You must get the replacement battery for the model S5869 which is 11.1 VDC, not the 10.8 VDC of most replacements. I could not get the laptop to boot with a 10.8VDC battery.

battery and sdd

• $0 CMOS battery: run down, but I don't have an adjustable soldering iron right now, so I installed ntp and ran

  # ntpdate pool.ntp.org

  right after connecting to my local router
• $19 battery: an inexpensive Chinese "TA3533LH" Li-Ion, 5200mAh, 6 cell. However, when I received it, it was for the
• $15 hdd -> ssd: I'd read somewhere that SATAIII was backwards compatible with SATAI and II, so I simply bought a new drive and moved stuff over.
• $0 OS: The latest version of Arch worked fine with the old hardware.

From 2008

These were on-sale recently (9/25) at Fry's and seemed like a good deal although it's understood the Linux factor might be difficult with ATI video and so on. Still for $400:

15.4 WXGA
AMD Athlon 64 X2 Dual Core
1024 MB PC6400 SDRAM
Radeon 3100HD (RS780) w/VGA out
Atheros AR5007EG (wifi)
Realtek RTL8102E (ethernet)
Realtek ALC268 (sound)
120GB 5400 RPM SATA 2.5"
DVD RW, PCMCIA, SD port
3xUSB 2.0
No bluetooth or videocamera

Booted into pre-installed Windows Vista first. The return policy is 15 days for laptops and specifies software and hardware must remain unmodified. After verification of hardware features, I blew out the unbelievably bloaty factory load, dropped in a boot disk, formatted, and mke2fs /dev/sda1. Nice.

Slackware 12.0

I had a Slack 12.0 DVD gathering dust available and Slackware is my favorite. However, errors appeared on installation and it seemed an extensive parameter set was required to tame them:

#boot nosmp noapic irqpoll

To me, these problems meant that, if I continued with the Slack install on the newer hardware, I might be compiling and patching over the weekend, or that I should download and burn Slack 12.1 and begin there. I also had a copy of Slackware-based Zenwalk (formerly Minislack) 5.2 which possessed a newer kernel and a supposedly candy-coated installation process. Choices.

Zenwalk 5.2

Installed smoothly with only irqpoll needed as a parameter.

Atheros AR242x 64 (5007 chipset)
The instructions here were helpful for understanding this newer card. Zenwalk provides ath5k, but it wasn't going well. The Madwifi site has information on ath5k here, and it appears the ath5k module will eventually be effective. Currently however, the steps which worked were:

1. in /etc/modprobe.d/blacklist, blacklist the "ath5k" module
2. reboot and lsmod - make sure the ath5k is gone
3. download madwifi-hal-0.10.5.6-r3861-20080903.tar.gz , or the newest one there, make, and install.
4. reboot again and lsmod
5. iwconfig ath0

WEP and WPA
WEP is trivial, merely need the two iwconfig commands "essid" and "key restricted" to make it work. WPA, on the other hand, is a separate post. It only took 10 minutes to configure, but the description is too long for this overview. If one has a distro which requires kernel modification for WPA, the process becomes longer. This site seems to explain it t I'm also currently building a chart for easier understanding based on this site.

screen brightness and gamma
The default settings for screen brightness and backlighting install maxed at 100%, and the Fn buttons don't seem to work except in Windows - battery life, screen life, eyestrain. Without going into X, one has command-line control over the brightness. Look in /proc/acpi/video/VGA/LCD/brightness to see the possible brightness settings for the card, such as 25, 50, 75%, and so on. I like 25%, so:

#echo -n 25 > /proc/acpi/video/VGA/LCD/brightness

It appears we cannot change the backlighting outside of X, though I haven't researched. Once in X however, open a terminal and select any number between 0.00 and 1.0 for gamma, eg:

xgamma -gamma 0.75

Realtek ALC268 Sound
Some duplicate alsamixer settings were seen. For example, alsamixer showed two microphone capture bars when only one channel was connected. I went to the Realtek downloads site, clicked a link there to the "HD Audio Codec Driver", and agreed to licensing language. After download and unpacking, it turned out this was the latest release of ALSA, so it basically installs the latest ALSA, but apparently with a newer HD driver. The alsamixer showed proper inputs following this ALSA update. and so, after setting levels, it was time for # alsactl store.

Radeon 3100HD RS780MC
Initially, Zenwalk loaded the vesa driver in /etc/xorg.conf, providing resolutions of 800x600. Common sense and #gtf seemed to indicate higher resolutions were available. In /etc/xorg.conf, I replaced "vesa" with, alternately, "ati", "radeon", and "radeonhd"; these did nothing but break X. I then relented for the proprietary driver "fglrx" described on most blogs as bloaty and slow, but operational. The driver was avialable here by selecting the Linux x86_64 -> Radeon -> ATI Radeon HD 3xxx Series and pressing "go". One note about installing this - I received checksum errors when I attemped to install it with #. ati*; I had to explicitly invoke bash #bash ati*. However, following this installation, I simply replaced "vesa" with "fglrx" in the Device section of /etc/X11/xorg.conf, rebooted, and everything worked. With the vesa-fglrx swap, the /etc/X11/xorg.conf file looks like this:

Section "Device"
Identifier "Videocard1"
VendorName "ATI Technologies Inc"
BoardName "Video device"
Driver "fglrx"
BusID "PCI:1:5:0"
Option "RenderAccel" "true"
EndSection

Adjustments to the fglrx module "Options" can come some other weekend; resolution and display appear sharp currently.

additional fglrx considerations for the Radeon 3100HD R5780MC
The fglrx driver, although supplied by Radeon, does appear to have significant Googleland complaints for slowness. For me, it renders well, but very slowly: I'm experience update lines even scrolling through a simple text page on Mousepad, etc. So, it appears something either a)very inefficient, or b)very underpowered, is taking place in terms of memory usage with the fglrx driver. From Google, it appears there are a few things to investigate: 1) does flglrx load as a module? (lsmod |grep fglrx). Mine does not appear in lsmod, and this apparently means xorg.conf loads a substandard fglrx_drv.ko module. Lsmod failed to locate this module either. Odd. 2) Settings in /etc/X11/xorg.conf for the fglrx driver, under "Options" may be important. 3)Settings (don't know syntax or location) for whether the ATI card uses SIDEPORT mode (card uses its own memory),UMA mode (card shares system memory), or another unnamed mode where it uses a mix of SIDEPORT and UMA. One thing for sure, a lifesaver in these forum boards is fglrxinfo or fglrxinfo -v:

# fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.4 (2.1 Mesa 7.0.3)

glxinfo is also important. On my system, glx is not enabled, though this may be a different problem than the overall slowness of screen panning and scrolling that I'm experiencing. A good forum thread for these issues is here, not for solutions but for the many aspects of the problem.

netpkg repos
Each time zenwalk is released, the repositories update to the most current release so that, if one needs a certain package, they generally have to update the rest of their system to be in sync with it. Suppose I like my release and just want to keep it into perpetuity. As long as 1) I have the installation disk 2) have netpkg'ed all the programs from that release I want (they download to /var/packages), and 3) have downloaded a copy of PACKAGES.TXT.gz, I can point netpkg to /var/packages and use the older release. A couple of simple modifications are required with two configuration files since netpkg doesn't inherently recognize URLs of the type "file:///". This link describes the changes to the two files, /usr/libexec/netpkg-functions and /etc/netpkg.config files, which I repeat here.

/usr/libexec/netpkg-functions, at or about line 144:

if [ $( echo "$url" | egrep -e "ftp:.*|http:.*|file:.*" ) ]; then

...at or about line 205:

if [ ! "$(echo $mirror | egrep 'http://|ftp://|file://')" ] ; then

/etc/netpkg.conf add another line such as

Internet_mirror = file:///var/packages

Put a copy of PACKAGES.TXT.gz into /var/packages, and you've got a self-contained distribution.

unsolved: multiple instantiation of mplayer, thunar, etc
Perhaps because of multiple processors, there's currently a problem when using DVD's. Multiple instances of related applications appear, eg 2 x MPlayer or 2 x Thunar. Working around this by disabling automatic HAL events for the time being. Manually opening one instance of the application for now.