Raspbian Stretch: Wifi not starting on boot

[sparkie777]

Most of this thread is about various ill-informed attempts to modify interface naming. I was always simple to select either the old (unpredictable) behaviour or Predictable Network Names, and now this is in raspi-config.

simply use geographical addressing to assign a NIC name rather than this MAC based crap - and you're done:

[HOWTO] assign predictable WLAN device names without fiddling with MAC addrs - Raspberry Pi Forums

[Milliways]

My problem is that the Foundation FINALLY introduced Predictable Network Names,

Nothing to do with the Foundation at all. We follow Debian and this came as a result of the move to Stretch.

only to get cold feet 3 weeks later

There was a flood of people complaining and saying it's the worst thing ever. Also, at the time of release, dhcpcd would grab the interface and the rename would fail. Having it only sort of kind of work defeats the point of it. Based on the feedback on the forum, a discussion in the office and the renaming issue, we took it out. Recognising that some users would prefer predictable names, the option was added to raspi-config. A later version of dhcpcd fixed the interface renaming issue.

I understand the fact that Foundation follows Debian, and I was anticipating Predictable Network Names. My problem was with the backflip.

The reaction was ENTIRELY PREDICTABLE, as anyone who monitors other distributions would have expected. This makes the lack of documentation doubly inexcusable.

I had never experienced any problem, on Raspbian, or other distributions (although this may reflect the fact that they were using updated dhcpcd). My questions on this site have not elucidated any further information about these alleged problems.

[ShiftPlusOne]

I understand the fact that Foundation follows Debian, and I was anticipating Predictable Network Names

Then why come across so aggressive and say were over a year behind when we definitely weren't? I can understand getting frustrated when things don't work the way you want, but that's no excuse to take it out on other people. We reverted back to the old naming scheme because that's what people seem to prefer here.

This makes the lack of documentation doubly inexcusable.

What documentation is missing? How would you have liked to have been presented with the information?
All the necessary information is the first hit on any search engine if you search for anything relating to predictable network interface names.
https://www.freedesktop.org/wiki/Softwa ... faceNames/

My questions on this site have not elucidated any further information about these alleged problems.

I can't answer every single question. If somebody asks politely and the information isn't easy to find, I make an effort.

I don't know what the "failing predictable interface names" is supposed to be but apparently the 2017-09-07 release

Rudeness aside, that was already addressed on the first page of the thread:

I also spotted this:

Code: Select all

Aug 16 01:22:50 raspberrypi systemd-udevd[152]: error changing net interface name 'eth0' to 'enx8cae4cf9e087': Device or resource busy
Aug 16 01:22:50 raspberrypi systemd[1]: Started Load/Save RF Kill Switch Status.
Aug 16 01:22:50 raspberrypi systemd-udevd[152]: could not rename interface '3' from 'eth0' to 'enx8cae4cf9e087': Device or resource busy

That problem has since been fixed.

Can you please explain HOW so I can undo the change. (I know I could do a forensic analysis to find this myself.)

I didn't see that question, but again, https://www.freedesktop.org/wiki/Softwa ... faceNames/

[Milliways]

I understand the fact that Foundation follows Debian, and I was anticipating Predictable Network Names

Then why come across so aggressive and say were over a year behind when we definitely weren't? I can understand getting frustrated when things don't work the way you want, but that's no excuse to take it out on other people. We reverted back to the old naming scheme because that's what people seem to prefer here.

This makes the lack of documentation doubly inexcusable.

What documentation is missing? How would you have liked to have been presented with the information?
All the necessary information is the first hit on any search engine if you search for anything relating to predictable network interface names.
https://www.freedesktop.org/wiki/Softwa ... faceNames/

My questions on this site have not elucidated any further information about these alleged problems.

I can't answer every single question. If somebody asks politely and the information isn't easy to find, I make an effort.

I don't know what the "failing predictable interface names" is supposed to be but apparently the 2017-09-07 release

Rudeness aside, that was already addressed on the first page of the thread:

I also spotted this:

Code: Select all

Aug 16 01:22:50 raspberrypi systemd-udevd[152]: error changing net interface name 'eth0' to 'enx8cae4cf9e087': Device or resource busy
Aug 16 01:22:50 raspberrypi systemd[1]: Started Load/Save RF Kill Switch Status.
Aug 16 01:22:50 raspberrypi systemd-udevd[152]: could not rename interface '3' from 'eth0' to 'enx8cae4cf9e087': Device or resource busy

That problem has since been fixed.

Can you please explain HOW so I can undo the change. (I know I could do a forensic analysis to find this myself.)

I didn't see that question, but again, https://www.freedesktop.org/wiki/Softwa ... faceNames/

I am sorry if you took my comments as aggressive, that was not my intention, although I often seem to tread on people's toes. Your "quote" misrepresents my statement, by omitting the remainder of the sentence I actually posted.

Unless I missed something the announcements about the Stretch release https://www.raspberrypi.org/blog/raspbian-stretch/ did not mention this significant change of behaviour.

Neither was I critical of the late implementation of predictable interface names, which I understand. I admit I was anticipating the change, and was surprised when it was dropped - admittedly mentioned in the release notes (which I suspect few people read), but again conspicuously absent from the Blog.

[PorterDon]

Unbelievable and unacceptable the Foundation somehow allowed these issues to flood us. I still can't get my Zero to bloody connect to wifi correctly on a static IP after hours of chasing rabbits! I don't know how the upgrade to Stretch was "managed" for wifi connection -- but I'd say somebody deserves a little "chat" at the water cooler. The Foundation has taken many, many harmful hits as a result of all this totally avoidable nonsense.

What issues would that be and how would you have done it instead? Every change has been made for a good reason and has been the result of changes upstream.

I would advise a centralized, public, issue-tracking and resolution mechanism which is meticulously monitored and maintained by technical staff. We search there first to see if a particular issue has been reported (e.g. Wifi connections under Stretch), if a resolution has yet been sanctioned by the development team, or if not, to report a problem (issue). Googling is a killer, points to every bottomless rabbit hole on the planet, so frustrating! The Foundation's Issue logs should be on the RaspberryPi.org website under the Troubleshooting or (perhaps new) Issue Logs designation.

[ShiftPlusOne]

I would advise a centralized, public issue-tracking and resolution mechanism which is meticulously monitored and maintained by technical staff. We search there first to see if a particular issue has been reported (e.g. Wifi connections under Stretch) and if a resolution has yet been sanctioned by the development team. Googling is a killer, points to every bottomless rabbit hole on the planet, so frustrating! The Foundation's Issue logs should be on the RaspberryPi.org website under the Troubleshooting or Issues Logs designation.

https://github.com/rpi-distro/repo/issues or the forum are both suitable places.
Did you post a thread about the problem you're having?

I am sorry if you took my comments as aggressive, that was not my intention, although I often seem to tread on people's toes.

No problem, I probably just misread the tone of the messages.

Unless I missed something the announcements about the Stretch release https://www.raspberrypi.org/blog/raspbian-stretch/ did not mention this significant change of behaviour.

Neither was I critical of the late implementation of predictable interface names, which I understand. I admit I was anticipating the change, and was surprised when it was dropped - admittedly mentioned in the release notes (which I suspect few people read), but again conspicuously absent from the Blog.

Yeah, that's understandable.
The blog is intended for a non-technical audience that tends to stick to the GUI, where interface names aren't particularly relevant.

Our release notes have the more technical changes, but not the ones we get from upstream. Debian's release notes for stretch are a 42 page document, which we can't really merge with ours.
https://www.debian.org/releases/stretch ... face-names

Perhaps we should include a link to upstream release notes when applicable.

[Milliways]

Our release notes have the more technical changes, but not the ones we get from upstream. Debian's release notes for stretch are a 42 page document, which we can't really merge with ours.
https://www.debian.org/releases/stretch ... face-names

Perhaps we should include a link to upstream release notes when applicable.

One of the problems with Raspberry Pi users (as distinct from users of most mainstream GUI based distributions) is that they seem to have an unreasonable fixation with setting static IP addresses, and thus need to know details of interfaces, and any changes are significant to a large number of users.

[PorterDon]

I would advise a centralized, public issue-tracking and resolution mechanism which is meticulously monitored and maintained by technical staff. We search there first to see if a particular issue has been reported (e.g. Wifi connections under Stretch) and if a resolution has yet been sanctioned by the development team. Googling is a killer, points to every bottomless rabbit hole on the planet, so frustrating! The Foundation's Issue logs should be on the RaspberryPi.org website under the Troubleshooting or Issues Logs designation.

https://github.com/rpi-distro/repo/issues or the forum are both suitable places.
Did you post a thread about the problem you're having?

No, I thought the RaspberryPi.org was the best place to get the most current, official response. Forum posts can be duplicative or yet more misleading, and are also pulled by Google. That is why I specified "centralized". I've learned I am best off staying away from Github. Tends to be more low-level than I usually want.

Thank you for your reply.

[ShiftPlusOne]

Last reply, since I've really got to get to work.

One of the problems with Raspberry Pi users (as distinct from users of most mainstream GUI based distributions) is that they seem to have an unreasonable fixation with setting static IP addresses, and thus need to know details of interfaces, and any changes are significant to a large number of users.

Noted.

I hate to blame the user, but those are advanced users and should know to check upstream release notes. If not, it should still be one of the first things they'd noticed after booting for the first time.

No, I thought the RaspberryPi.org was the best place to get the most current, official response. Forum posts can be duplicative or yet more misleading, and are also pulled by Google. That is why I specified "centralized". I've learned I am best off staying away from Github. Tends to be more low-level than I usually want.

Raspberry Pi is not a large company, especially on the engineering side. We appreciate and rely on community support and volunteers. I think what we have (the forum and github) is a good combination of community support and direct input from the engineers who work on the hardware and software. If it was all centralised in a single issue tracker, I don't think we'd be able to keep up and get work done at the same time.

[saxicola]

I see:

Code: Select all

dnsmasq[449]: unknown interface wlan0
dnsmasq[449]: dnsmasq: unknown interface wlan0
systemd[1]: dnsmasq.service: Control process exited, code=exited status=2
dnsmasq[449]: FAILED to start up
systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server

in journalctl

The problem I see is that dnsmasq is up before the wlan0 interface, so obviously it fails. I fixed this by adding:

Code: Select all

Restart=on-failure

to the [service] section of /lib/systemd/system/dnsmasq.service.

[SurferTim]

I see:

Code: Select all

dnsmasq[449]: unknown interface wlan0
dnsmasq[449]: dnsmasq: unknown interface wlan0
systemd[1]: dnsmasq.service: Control process exited, code=exited status=2
dnsmasq[449]: FAILED to start up
systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server

in journalctl

The problem I see is that dnsmasq is up before the wlan0 interface, so obviously it fails. I fixed this by adding:

Code: Select all

Restart=on-failure

to the [service] section of /lib/systemd/system/dnsmasq.service.

If you are using dnsmasq, do you also have hostapd running?

Do you have any entries in /etc/network/interfaces?

[RaspiConnect]

I had the same problem with wifi after upgrading from Jessie to Stretch.
After checking and setting all of the above, I think the problem was the service "wpa_supplicant". It wasn't enabled after the upgrade !

So enabling the service and a restart did the trick:
sudo systemctl enable wpa_supplicant

[ShiftPlusOne]

wpa_supplicant should be started by dhcpcd, not the service. If it's not starting, you're working around another issue.

[scott_sch]

I don't quite understand the purpose of this change.

Seems contrary to the unix philosophy to have networking configurations spread across the file system and doing similar things.

I haven't enjoyed spending another morning trying to understand why the older method has been made more complicated. I'm still getting errors on a fresh install and I guess I'll need to read more about it, but I'm downgrading to jessie for now because i need this done today and im getting frustrated.

I build roughly a pi a month and Id like to know if this this change is a good thing I would benefit by accepting, or some kind of bug?

[Schorschi]

Putting the wpa-supplicant.conf file on /boot is not working for me. I am using just a Pi Zero with WIFI dongle, RTL8818EUS chip based. I have to do # ip link set wlx00... up, to get the dongle to be recognized. For DHCP IP address offer/acceptance to initiate. Clean raspbian build as well. Do not see this on my PiZero W or my Pi 3. But when I enable predictable network interface names on Pi 3s they still only show wlan0 as well, which seems odd.

[stocksp]

I have 3 pi 3's running fine on my wifi. They are 3 months old. headless stretch-lite.
Brand new piZwero W with latest stretch-lite. Raspi-configed with my localization ('US').
On boot it gives me

Code: Select all

started disabled WiFi if country not set.

and I don't have any WiFi.
I've set and reset the local, timezone, wifi country, etc.. My wpa_supplicant.conf is the same on all machines and what is recommended here.
Could someone be so kind as to tell me what 'started disabled ...' is telling me and what I might do about it?

UPDATE
I've fixed mine: I believe there is a problem with raspi-config in the 2018-03-13 release. I've done 3 fresh images and I could see perl errors briefly when I was setting my US locale. Googling the error I found
http://www.xappsoftware.com/wordpress/2 ... an-solved/
I ran these and rebooted my wifi works:

Code: Select all

pi@raspberrypi:~$  sudo -s
pi@raspberrypi:~$  export LANGUAGE=en_US.UTF-8
pi@raspberrypi:~$  export LANG=en_US.UTF-8
pi@raspberrypi:~$  export LC_ALL=en_US.UTF-8
pi@raspberrypi:~$  locale-gen en_US.UTF-8
pi@raspberrypi:~$  dpkg-reconfigure locales

[Schorschi]

I have a different issue, I have a Pizero W and and older Model B (512 MB) that both work some of the time with Wifi. Right after a reboot, I often seen no wlan0 interface, and if kill dhcpcd and run it again, I often get the classic no carrier issue. But I know the Wifi dongle on the Model B is good, I insert it into my Windows 10 PC and it never fails to work. No sure what the deal with the Pizero W is, it seems to have very poor range, compared to Pizero with a Wifi dongle, such is my experience. I finally wrote a small python script that runs every few minutes and when it sees the Wifi interface is down or missing, it reboots the Pi. This is a horrible band-aid, but it works for now. What is odd is that i have several other Pi devices that run the same OS, OS version, etc. same make and model of Wifi dongle, and don't have this issue as bad, sometimes but rarely.

[mattmiller]

No sure what the deal with the Pizero W is, it seems to have very poor range, compared to Pizero with a Wifi dongle

Simple physics - your WiFi dongles generally have a better antenna than the one built into the PiZeroW board.

Having said that, all my PiZeroW (3) scattered around my house doing IoT stuff work fine so I've not noticed any real-world difference

[Schorschi]

I am in one of the areas where the Wifi space is just buried in overlapping and overloaded channel assignments. At any given time of the day, I can scan between 25 and 50 different cells. Everyone just layered on top of everyone else. So the transmit power level from Pi (client) to access or router points is key. Moreover, many of the people in my area have been sold by local tech support like Geek Squad, etc. That the only way to improve signal quality is to blast everyone else... so almost everyone is over casting their signals into everyone else. I think I am the only one in the area that tried to limit the broadcast range to the boundaries of my property. Go figure right? Finally added a few access points linked by a wired backbone, to get consistent use and quality. Was really tempted to build a jammer... I have the technical knowledge, but no, that would be ugly.

[owendelong]

I think I may have tracked down part of this problem.

It seems that on the stock image, the directory /var/run/wpa_supplicant does not exist. It is not automatically created. The wpa supplicant apparently balks at this and aborts on boot, but may succeed when run manually or with other variants (e.g. interface-specific). I haven't thoroughly tried all cases, but I have found that creating the /var/run/wpa_supplicant directory did resolve the issue for me.

[Schorschi]

I solved the issue backwards, I rebuilt my OS image, redid the configuration from scratch, installed kernel, kernel sources, and compiled the driver again, and validated the wpa_supplicant setup again, using a interface named file. And now I think it is working. The predictable names feature does not seem to be a factor per say. I got it work either with or without that feature enabled. Neither is the kernel version, I have P1 and P2 both on 4.14.32+ and 4.14.33-v7+ respectively working.

Oh, and the driver version for RTL8811AU device, is 4.3.14 compiled from RTL8812AU sources, but this is the only version that seems to work, if I try anything newer (for driver source) it fails to see the RTL8811AU device. I can compile fine, model loads, but after USB dongle plugin, nothing.

[mud2005]

I got stuck on this for hours, the only fixed that I got to work was in the 2nd post of this thread
viewtopic.php?t=191061#p1199672

After running wpa_supplicant from the command line it looked like it was failing due to the process already running, I think creating the new service is what allowed it to work.

I'm not really sure why this was happening or if this is the best fix, I'm just happy to have wifi working again.

EDIT: wifi stopped working again, it worked after a few reboots, but now won't connect

[aaamitsingh]

I don't understand the wpa_supplicant subsystem at all but here is a workaround to my issue:

Rather than run the generic wpa_supplicant.service I am now running the interface specific version.

Here are the commands I used:

sudo cp wpa_supplicant.conf wpa_supplicant-wlan0.conf
sudo systemctl disable wpa_supplicant.service
systemctl enable wpa_supplicant@wlan0.service

After this I now have Wifi working across reboots. With any luck someone with actual knowledge will fill in some of the blanks.

BTW, sudo ifup wlan0 still returns ifup: unknown interface wlan0.

Ugh.

This work for me... But is it good idea to use this in production???

[dliloch]

Hello,

I am using stretch

4.9.48+ #1034 on a pizerow. I have observed that if my wlan0 goes off I have a script to do a reboot. The wlan0 does not always come back..however if I power off and on It works. Is there a difference between reboot and a power off and on that anyone knows of?
Thanks
-don

[JCTJ]

For students at the school where I teach, I need to make a number of adjustments to the Raspberry Pi's floating around, so I have an 'update' script that will do a good number of things (install latest version of Python, create a 'Programs' directory, create a pipenv in that directory, etc.). This way I have the students download the Raspbian img onto an SSD card and then just run my script. Getting around the WiFi issues has been a bear, but I found that:
1) I needed to update a number of things such as WiFi Country, network info, keyboard layout, language (locale), etc.
2) Get the internet connection up and running
3) update/upgrade
4) Download (Python, pipenv install's)
5) reboot

In order to do the first 2 items I:
1) use (in my bash script) "sudo dhcpcd -k" to release all dhcp connections
2) use " echo 'my text for the file' | sudo tee /etc/wpa_supplicant/wpa_supplicant.conf" to change the wpa_supplicant.conf file to what I want it to be, and
3) start up dhcp again with "sudo dhcpcd -n"
4) use a loop to wait until the connection actually *is* established

and then I can start downloading, etc.

It took hours to get this all figured out, and I went through at least 5 different solutions from different forums before I found this (dhcpcd commands) at: https://manpages.debian.org/stretch/dhc ... .8.en.html. Here is my full script for those who are interested (or have improvements to suggest! ):

Code: Select all

#!/bin/bash

my_network='192.168.1.1'    # used to ping my network router to confirm WiFi connection

# Change WiFi Country by editting /etc/wpa_supplicant/wpa_supplicant.conf
echo 'Stopping current network service'
sudo dhcpcd -k

echo 'Changing network settings (and restarting the network)'
echo 'ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=US

network={
        ssid="my_home_network"
        psk="my_home_password"
        key_mgmt=WPA-PSK
        id_str="home"
        priority=5
}

network={
        ssid="my_school_network"
        psk="my_school_password"
        key_mgmt=WPA-PSK
        id_str="school"
        priority=1
}
' | sudo tee /etc/wpa_supplicant/wpa_supplicant.conf > /dev/null
# Restart the network
sudo dhcpcd -n

# Change preferences for US, Central Time
# Edit keyboard in /etc/default/keyboard
echo 'Update keyboard layout to US English'
echo '# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="pc105"
XKBLAYOUT=us
XKBVARIANT=""
XKBOPTIONS=""

BACKSPACE="guess"
' | sudo tee /etc/default/keyboard > /dev/null

# Change locale (local language used) by editting /etc/locale.gen and using locale-gen
echo 'Update locale to US English'
echo '# File generated by update-locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8
' | sudo tee /etc/default/locale > /dev/null
sudo locale-gen en_US.UTF-8

# Change timezone with timedatectl
echo 'Updating the timezone to US Central Time'
sudo timedatectl set-timezone US/Central

# Change Interfaces by
# Add SSH
echo 'Enabling SSH'
sudo systemctl enable ssh

# Add VNC
echo 'VNC is *not* enabled yet'

# Add update alias ('up') to ~/.bashrc file to allow you to run frequent commands easily
echo 'Adding aliases'
ALIASES_FILE_PATH=$HOME/.bash_aliases

# Deleting dublicate aliases
sed -i "/alias up/d" $ALIASES_FILE_PATH

echo 'alias up="sudo dpkg --configure -a; sudo apt install --fix-broken; sudo apt update; sudo apt upgrade -y; sudo apt dist-upgrade -y; sudo apt autoremove --purge -y; sudo apt autoclean -y"' >> $ALIASES_FILE_PATH

# Loading aliases
source $ALIASES_FILE_PATH

# wait for network to be up (since it was changed) before proceeding
while ! ping -c 1 -W 1 ${my_network}; do
    echo "Waiting for the network (WiFi) to come up..."
    sleep 3
done

# Update a new Raspberry Pi system (using just-created 'up' alias)
up

# Netatalk -- allows Pi to be seen as a networked device on Mac OS (and Windows?)
sudo apt install netatalk -y

# Expect
sudo apt install expect -y

# Reset password from 'raspberry'
password_commands='
set timeout -1
set username "pi"
set password "a very short password"
spawn sudo passwd $username
expect "New password:"
send "$password\r"
expect "Retype new password:"
send "$password\r"
expect "passwd: password updated successfully"
'
/usr/bin/expect -c "${password_commands//
/;}"

# Python Version to be installed (here 3.6.5 - change as needed)
python_version='3.6.5'

# future: use "$ python3.6 --version" for find out the exact version, and update only if older

cd ~
sudo apt install -y gcc make libssl-dev zlib1g-dev build-essential
sudo apt install -y libncurses5-dev libncursesw5-dev libreadline-dev libsqlite3-dev 
sudo apt install -y libgdbm-dev libdb5.3-dev libbz2-dev libexpat1-dev liblzma-dev tk-dev
wget https://www.python.org/ftp/python/${python_version}/Python-${python_version}.tar.xz
tar xJf Python-${python_version}.tar.xz
cd Python-${python_version}
./configure --enable-optimizations
make -j 8
sudo make altinstall
cd ..
sudo rm -r Python-${python_version}
rm Python-${python_version}.tar.xz*

sudo apt autoremove --purge -y

# Pipenv
sudo pip3 install pipenv
mkdir programs
cd programs
pipenv --python ${python_version}
exit
cd ~

# Re-start the Pi
sudo reboot

Now all I have to do is boot the new image (start up the Raspberry Pi), plug in a USB Flash drive w/ this script on it, copy the update.sh file to the desktop in the GUI, open the Command Line window, and run the following three commands:

Code: Select all

$ cd Desktop
$ sudo chmod +x update.sh
$ ./update.sh

And then I walk away and let the poor Pi work its brains out updating and compiling Python.

I still haven't figure out how to:
1) Update VNC to run (i.e. System Preferences ==> Interfaces ==> Enable VNC) from the command line
2) figure out if the specified version of Python is already installed
3) Get the kids to actually THINK about Python rather than just mimicking the dance moves (but I don't expect a script to do that...).

Thanks - and I hope this helps someone else.