[SOLVED] To get wifi up on this laptop, I need to run wpa_supplicant by hand. Why?

This is a Dell laptop running a very bare-bones cli-only version of Slackware-current. Yes, I know that's not the way you're supposed to do it, but I have a well-behaved working Slackware-15 on another machine and this is an educational project. I also have a fully loaded antiX-26 on this machine and I'm currently using that for all my updates (antiX directly and Slackware in chroot).

I have rc.inet1.conf set up for wlan1, since that's what the kernel calls it. Why "1" and not "0" as in antiX, I don't know (ethernet also comes up in Slackware on this machine as eth1). I've specified for the rc.inet1 script to use wpa_supplicant with wext. The authentication data are in /etc/wpa_supplicant.conf. When I boot, it tries to activate wlan1, then fails with "Nexthop has invalid gateway". I haven't found anything useful by googling this.

Stopping and restarting rc.inet1 has no effect, but running wpa_supplicant by hand brings the interface up smoothly and I can then ping both the router and the Google DNS server at 8.8.8.8. So why does it work when launched that way, and what do I have to add to make it work automatically at boot?

You almost certainly have a mistake in your rc.inet1.conf file. There's some pretty heavy shell and networking things in there so if you don't want to bother with it, you can push it off onto NetworkManager. rc.inet1 is the lower-level networking stuff. rc.inet2 is the network server stuff that doesn't apply to your current issue (one-indexed, 1..N). The interfaces are zero-indexed (0..N). Following this, you should have eth0, wlan0, etc. You should not need run wpa_supplicant by hand.

wext is old; use nl80211 instead for modern systems at WLAN_WPADRIVER. Make sure you understand shell arrays - they are zero-indexed. rc.inet1.conf has some examples, so edit the array number that corresponds to that interface as an array. Make as few changes as possible to the script, test, repeat. Keep a backup in case you get too lost so you can start over. You can also call rc.inet1 as a switch by itself with DEBUG_ETH_UP="yes" set in rc.inet1.conf to see what it's doing in various situations. See the case statement at the bottom of rc.inet1 to see what parameters it will take. Someone who is using Slackware wirelessly can probably give you a good example. It's been 6+ years since I had this machine setup with wifi (as a client) so any examples I give might just add to the confusion.

It doesn't sound like your interfaces are playing musical chairs, but if they are, you can tell them to stop with /etc/udev/rules.d/70-persistent-net.rules . You get the ATTR{address} value using, for example, ip -c link show eth0 and taking the link/ether address.

# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="6c:4b:90:17:7c:1d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x10ec:0x8821 (rtl8821ae)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="60:14:b3:6f:a3:bf", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

# USB device 0x0b95:0x1790 (usb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:05:1b:8f:f0:dd", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

I don't think this is what's happening with you; I only include it for sake of completeness.

Originally Posted by jayjwa You almost certainly have a mistake in your rc.inet1.conf file. There's some pretty heavy shell and networking things in there so if you don't want to bother with it, you can push it off onto NetworkManager.

If I did that, I'd have to create some nm connections. I gather that when nm is running, it doesn't allow wpa_supplicant to access its own config file but makes it use config data provided by itself over dbus.

rc.inet1 is the lower-level networking stuff. rc.inet2 is the network server stuff that doesn't apply to your current issue (one-indexed, 1..N). The interfaces are zero-indexed (0..N). Following this, you should have eth0, wlan0, etc. You should not need run wpa_supplicant by hand.

That's what I thought. So why is the numbering different in my case? I've never seen device numbers like that before for network interfaces.

wext is old; use nl80211 instead for modern systems at WLAN_WPADRIVER.

Thanks. I'll definitely do that.

Make sure you understand shell arrays - they are zero-indexed. rc.inet1.conf has some examples, so edit the array number that corresponds to that interface as an array.

Sorry, you've lost me there.

Make as few changes as possible to the script, test, repeat. Keep a backup in case you get too lost so you can start over. You can also call rc.inet1 as a switch by itself with DEBUG_ETH_UP="yes" set in rc.inet1.conf to see what it's doing in various situations. See the case statement at the bottom of rc.inet1 to see what parameters it will take.

I'll definitely try that.

It doesn't sound like your interfaces are playing musical chairs, but if they are, you can tell them to stop with /etc/udev/rules.d/70-persistent-net.rules . You get the ATTR{address} value using, for example, ip -c link show eth0 and taking the link/ether address. I don't think this is what's happening with you; I only include it for sake of completeness.

I don't actually mind whether it's wlan0 or wlan1; I'm just curious to know why it's different on this system from what I've seen on all my others. For example, antiX on the same machine (and also on my Vaio All-in-1) uses wlan0 as expected.

I have found out why I have eth1 and wlan1 rather than eth0 and wlan0. Here is the relevant bit of dmesg:

[    6.290205] r8169 0000:02:00.0 eth0: RTL8168g/8111g, 98:40:bb:10:80:c3, XID 4c0, IRQ 129
[    6.290213] r8169 0000:02:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[    6.295523] r8169 0000:02:00.0 eth126: renamed from eth0
[    6.296011] r8169 0000:02:00.0 eth1: renamed from eth126
[    6.320104] dell_laptop: Using i8042 filter function for receiving events
......................................
[    6.343633] ath: phy0: ASPM enabled: 0xc43
[    6.343677] ath: EEPROM regdomain: 0x6c
[    6.343679] ath: EEPROM indicates we should expect a direct regpair map
[    6.343681] ath: Country alpha2 being used: 00
[    6.343683] ath: Regpair used: 0x6c
...........................................................................
[    7.000077] ath9k 0000:01:00.0 wlan125: renamed from wlan0
[    7.000227] ath9k 0000:01:00.0 wlan1: renamed from wlan125

It seems that they do get the expected name eth0/wlan0 initially but then get renamed to some ridiculous 3-figure value. Presumably that wouldn't work as a device designation, so it gets truncated to the first digit. At least that's my reading of it.

The obvious culprit to check is udev, but I grepped through /lib/udev/rules.d and couldn't find anything that looked suspicious.

btw I'm not the only one to get a weird eth name. Here's a post from someone else who got the same:
https://www.linuxquestions.org/quest...b0-4175743498/
https://www.linuxquestions.org/quest...n0-4175650016/
The point is that the assigned names do seem to work even though they are not the expected ones. Eth1 comes up without any problem when I have the ethernet cable plugged in and wlan1 can be brought up manually.

I have also discovered that the index numbers in the rc.inet1.conf file refer to indexes in an array of possible network devices defined in the rc.inet1 script. They have nothing to do with the device name! So the network device number is 4 even when the device name is wlan0 or wlan1.

That no doubt is what @jayjwa meant in paragraph 2 of his post, which I didn't understand at the time. You see, that's why I enjoy doing things this way. You get to learn something new.

Just for interest, here is the current state of the wlan1 block in rc.inet1.conf:

IFNAME[4]="wlan1"
#IPADDRS[4]=""
USE_DHCP[4]="yes"
#DHCP_HOSTNAME[4]="icculus-wireless"
#DHCP_KEEPRESOLV[4]="yes"
#DHCP_KEEPNTP[4]="yes"
#DHCP_KEEPGW[4]="yes"
#DHCP_IPADDR[4]=""
WLAN_ESSID[4]="(my essid)"
#WLAN_MODE[4]=Managed
#WLAN_RATE[4]="54M auto"
#WLAN_CHANNEL[4]="auto"
#WLAN_KEY[4]="D5A31F54ACF0487C2D0B1C10D2"
#WLAN_IWPRIV[4]="set AuthMode=WPAPSK | set EncrypType=AER | set WPAPSK=(my hex key)"
#WLAN_IWPRIV[4]="set WPAPSK=(my hex key)"
WLAN_WPA[4]=wpa_supplicant 
WLAN_WPADRIVER[4]=nl80211
#WLAN_WPAWAIT[4]=30

This doesn't yet work so I suspect some of the other fields need to be activated but I don't yet know which ones.

There's man pages for rc.inet1.conf and rc.inet1 . I tend to forget that they are there. I think you're on the right track though.

For me I use

ip link ... to indicate the wifi, mines wlan0

wpa_passphrase myssid myssidpassword >/etc/wpa_wlan0.conf
wpa_supplicant -B -i wlan0 -c /etc/wpa_wlan0.conf
dhcpcd wlan0

check with ... ip a

Yesterday I found something better than a man page -- a pdf written by AlienBob called Configuring Your Network in Slackware. It explains what each of those wifi variables in the config file actually does, which is not obvious if (like me) you don't know the terminology. For example, what does "Managed" mean? I thought it meant using a higher-level program like NetworkManager or connman to manage your wifi, but apparently it means that your computer is being set up to talk to a box that provides services like routing, dns and dhcp, and not directly to another computer or a wifi printer (which would be "Ad Hoc"). Who knew!

I am going to follow this book to uncomment the elements that I think I now need, and we'll see if the script can then invoke wpa_supplicant by itself, which is obviously how it's supposed to work. An alternative would be to put the wpa_supplicant invocation into rc.local but I sort-of feel that would be cheating.

a pdf written by AlienBob called Configuring Your Network in Slackware

Yummy! Could you post the link to it?

Also, what exact model Dell are you using?

P. S. Love reading about your projects & learning, as always!

https://wiki.alienbase.nl/doku.php?id=slackware:network.

The computer is a Dell Latitude-3570. I bought it off @beachboy2. It's rather a big laptop (what we used to call a "luggable") but that suits me just fine as I intend to use it mainly as a home machine, replacing my old Lenovo tower. I am much more interested in the quality of the keyboard than in the weight; I hate fiddly little keyboards where each key has 3-4 different values depending on what combination of control keys you use.

Finally! I just had to uncomment a few more lines in rc.inet1.conf, notably the suggested mode, rate and channel. Now it calls up wpa_supplicant by itself. Thanks to everyone who helped.

Originally Posted by hazel Finally! I just had to uncomment a few more lines in rc.inet1.conf, notably the suggested mode, rate and channel. Now it calls up wpa_supplicant by itself.

Except that it only did that once! Since then it has always failed. I don't have the energy to argue with this machine any more; it clearly wants to use an explicit wpa_supplicant invocation, so I have put one into rc.local and now it connects by itself every time. Maybe I'll come back to this later

I assume that people prefer to use something like NetworkManager or Connman because they want their laptop to be fully mobile, use-anywhere. Mine, as I think I've mentioned, is a big, heavy "luggable" which I am going to use mainly at home. I only need it to connect to my own router and the one at my church, and my two-stanza /etc/wpa_supplicant.conf file handles that just fine.