Posts: 509
Joined: Sun Mar 29, 2015 12:12 am

stretch WAP suddenly not working.

Thu Jul 18, 2019 5:57 am

I know....

I've asked about this before.

Something has happened and the WAP now won't come back to life.
(Headless RPI 2B running Stretch)

It has been there quite happily for a long time.

The power was lost to it and when it powers back up, no WAP.

I tried the second USB port: Same.

To check the dongle, I tried another one - same brand - no luck.

To check myself again, I have a python script that runs to scan for WAP names.

It works. I see the little blue LED in the dongle blink.

When I get down to the part:

Code: Select all

sudo systemctl start hostapd
and press enter.
I get a few more key strokes in then the machine is dead.

Trying to PING it from the main machine: It isn't responding.
A power reset is all I can do.

This is the hostapd.conf file:

Code: Select all

[email protected]:~ $ sudo cat /etc/hostapd/hostapd.conf 
##  The two lines below are toggled when the BRIDGE
##  line is added.
bridge=br0                  ##
#driver=nl80211          ##   These two lines may be part of the problem.
Seems I can't attach the PDF I use to set it up. But it is from the RPI site.
Quick search: This is the link:
https://www.raspberrypi.org/documentati ... s-point.md

Or it really looks like what I have.

Anyone had similar problems?

If I check the status of hostapd this is what I get back:
[email protected]:~ $ sudo systemctl status hostapd
● hostapd.service - Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator
Loaded: loaded (/lib/systemd/system/hostapd.service; disabled; vendor preset: enabled)
Active: inactive (dead)
[email protected]
Dead doesn't look good. But as I explaind: as soon as I try to start the daemon the link to the Pi is lost.

In the hostpad.conf file you can see the two lines about them possibily being the problem.
There does seem to be something going on with them and I thought they needed to be the other way around (wrt comments/active) but I tried them as shown and it has the same end result: the RPI just locks up.

Here are the other files:


Code: Select all

interface wlan0
static ip_address=
nohook wpa_supplicant
static routers=
static domain_name_servers=
static domain_search=


Code: Select all


Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2648
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: stretch WAP suddenly not working.

Fri Sep 06, 2019 10:02 am

For somebody who has "asked about this before", your post is light on important information such as which USB dongle you are using.

Are you saying that the only thing that happened between a working system and a dead one was a power outage? That sounds like either the card has become corrupted or the hardware has been damaged in some way.

Start with a clean Raspbian image on a spare card and verify that the dongle works in normal (non-AP) mode. Then try activating HostAP mode.

Posts: 509
Joined: Sun Mar 29, 2015 12:12 am

Re: stretch WAP suddenly not working.

Fri Sep 06, 2019 9:41 pm

I am NEW to this kind of OS. Though I despise windows, I am not a guru with where things are, the commands and the association of things in Debian.

The RasPi is a great little machine with so much potential. I am using/enjoying it but I a now limited because of what happened.

I ask for help from people who are (or claim) to be gurus and they simply dismiss me as unworthy of knowing.
If I don't give "correct" account of things that happen, it is because I am stupid. Not malicious.
I don't like wasting people's time.

I am also torn between TOO LITTLE and TOO MUCH information given.
Until I know the happy medium, what am I supposed to do?

After a lot of messing around I discovered that the kernel was updated and this is the cause.

The story:
Jessie was working fine as a WAP with an EDIMAX (leadtec) WiFi dongle.

I know that Jessie is a bit old, but it is an old RPI and it worked.

To update I would have to get a list of installed programs/packages and re-install them on Stretch (or now: Buster)

I didn't see the need to do that, and don't know how to get the list.

So, one day I did a `sudo apt update` and `sudo apt upgarde` and all seemed to go ok.
Other than when I ssh into it I got a message something about the WPA_SUPPLICANT file and compatibility.

I put this on low priority as the machine is on 24/7. (Silly me)

After a power outage the machine would boot, but then just lock up.

(This part took weeks)
With the help of a linux person it was determined that there was a kernel panic AND it wasn't being logged.

This made it difficult to see what was actually going on. Doing some smart stuff we saw the error and and a search of the net confirmed it was a kernel panic.
I don't have the details but a LOT OF PEOPLE were having the same problem.
It was caused by the USB dongle, NOT hostapd - which I suspected - as when I started hostapd, shortly there after it would lock up 100% dead.

Further searches determined that it was specifically the EDIMAX dongle. Someone decided to release the kernel with that in the blacklist.
Deleting that entry made no difference.

Further research people were saying to re-complie the kernel with "these two lines changed as so.....".
WAY beyond me.

So, because it was pretty much the dongle I was using, I had an "AHA!" moment. I have an OFFICIAL WiPi dongle at home. I'll use it instead!

Got home, swapped the dongle, edited the required file and. . . . . . locks up.

With the notes I have for it - line in hostapd.conf file - it gets changed from NL80211 to RTL2870.

Search that. The results are worse for it than the EDIMAX drivers.

It is claimed that its drives (The WiPi) are **WORSE** than the EDIMAX's.

Given that with the EDIMAX dongle plugged in, I can scan for visible WiFi WAPs, it means it is working.
(Well, considering it has been determined that it is the kernel which is the problem)

So that is the longer story.

I now don't have a WAP because someone decided to release a kerenel which panics if/when it sees that dongle for a WAP.

Yes, getting a "new" image will fix the problem until the update invokes a kernel update to what is now already installed and I will be back to where I am now.

I don't see that as a real solution.

Am I now missing anything in my description?

Return to “Troubleshooting”