Bug 12585

Summary: Update with core 154 stops hostapd on some hardware.
Product: IPFire Reporter: Erik Kapfer <ummeegge>
Component: hostapdAssignee: Arne.F <arne.fitzenreiter>
Status: CLOSED FIXED QA Contact:
Severity: Major Usability    
Priority: - Unknown - CC: andreas.deicke, gitlab, Manfred.Knick, michael.tremer, plaporte, wbaudler, wusselpowa
Version: 2   
Hardware: unspecified   
OS: Unspecified   
Attachments: Doubled Wifi-adapter in Zone Configuration

Description Erik Kapfer 2021-03-09 05:44:57 UTC
Hi all,
the hostapd update from 2.9 to dev version 581dfcc stops hostapd after update process without further logging information. Manual starting shows an OK from loadproc, the hostapd.cgi delivers also a running but no process and no SSID at all.

I know the information are very less the only thing which we could find out on the community platform --> https://community.ipfire.org/t/core-update-154/4765/4 that two from three have a Ralink chipset, no infos from the third problem candidate about his used hardware.

Best,

Erik
Comment 1 Michael Tremer 2021-03-10 11:29:21 UTC
Could you please provide any log files that show any errors?
Comment 2 Erik Kapfer 2021-03-10 14:01:22 UTC
Hi Michael,
sadly no, the last logs comes from Pakfire. After the Pakfire update and a reboot hostapd was completely down.

Best,

Erik
Comment 3 Michael Tremer 2021-03-10 14:03:12 UTC
I do not really know what I can do with such a report.

hostapd starts and generally does not crash. It would report why it is unhappy or misconfigured.
Comment 4 Erik Kapfer 2021-03-10 15:16:01 UTC
I can understand that. Am also only one of three of the above mentioned topic so in general it seems to work even all three needed to make a downgrade to get the WLAN back.
Comment 5 Wussel Powa 2021-03-11 19:30:04 UTC
I have the same issue with a WLE200NX Wifi-Adapter on an APU2C4 board.

I also did not find any information in dmesg or the log facilities offered via the web-ui that I could relate to this hostapd-issue.

However, in the "Zone Configuration" menu, two Wifi-Adapters (wlan0 and wlan1) were listed, although I only have one. 

Also, when trying to change something for BLUE, I always get error message “A zone that is not in bridge mode can’t have more than one NIC assigned” upon saving (regardless whether I assigned one or two NICs, or if I try to change any of the other settings on BLUE).

I then reverted back to the previous hostapd-version. Wifi then works again, and also the "Zone Configuration" menu turned back normal, with only one Wifi-Adapter listed.

I attached screenshots of the erroneous "Zone Configuration" menu.

I hope this helps analyzing the bug. Let me know if I can assist further.


Best,

Chris
Comment 6 Wussel Powa 2021-03-11 19:39:45 UTC
Created attachment 862 [details]
Doubled Wifi-adapter in Zone Configuration
Comment 7 Wolf B 2021-03-15 23:20:26 UTC
I have the exact same problem with a

Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter

Downgrading hostapd from 581dfcc-54 to 2.9-52 fixed it.

Since pakfire doesn't seem to support downgrading, this is what I did to do the downgrade:

cd /var/cache/pakfire
cp hostapd-581dfcc-54.ipfire hostapd-581dfcc-54.ipfire.backup
cp hostapd-2.9-52.ipfire hostapd-581dfcc-54.ipfire
pakfire install hostapd

It worked, but if someone knows a better way to downgrade ipfire pakfire packages, please let me know.
Comment 8 Wolf B 2021-03-15 23:22:49 UTC
The reason there are no logs about a problem is that the startup script /etc/init.d/hostapd pipes all output to /dev/null:

/usr/bin/hostapd -P /var/run/hostapd /etc/hostapd.conf >/dev/null 2>&1
Comment 9 Michael Tremer 2021-03-22 14:01:54 UTC
(In reply to Wolf B from comment #8)
> The reason there are no logs about a problem is that the startup script
> /etc/init.d/hostapd pipes all output to /dev/null:
> 
> /usr/bin/hostapd -P /var/run/hostapd /etc/hostapd.conf >/dev/null 2>&1

Could you please add "-d" to the command line and redirect the output to a file which you can upload here? Otherwise I do not know where to look for a fix.
Comment 10 Manfred Knick 2021-04-03 17:40:55 UTC
(In reply to Wolf B from comment #7)

Following your lines,

> pakfire install hostapd

PAKFIRE INFO: hostapd is already installed

PAKFIRE ERROR: No packages to install. Exiting...
Comment 11 Manfred Knick 2021-04-03 18:13:34 UTC
(In reply to Manfred Knick from comment #10)
> (In reply to Wolf B from comment #7)

It just needed a

# pakfire remove hostapd

beforehand to work.

Thanks!
Comment 12 Pierre Laporte 2021-04-19 09:17:45 UTC
Hi there,
I had same problem here.
My WiFi adapter is not a Ralink but an Intel Wireless 3165 (rev 81).
First of all I removed hostapd-581dfcc-54. Then I performed all the steps suggested by Wolf B. I had to change SSID, passphrase and HT Caps. Before filling the field HT Caps I checked ' iw list ' in order to enter the correct values.

On saving everything worked fine again. Nevertheless Zone Configuration continues showing up two WiFi adapter. I wonder whether this solution is persistent.
Comment 13 Michael Tremer 2021-04-19 09:50:57 UTC
(In reply to Pierre Laporte from comment #12)
> On saving everything worked fine again. Nevertheless Zone Configuration
> continues showing up two WiFi adapter. I wonder whether this solution is
> persistent.

No it isn't. There will be another update for hostapd in the upcoming core update which brings various changes to the scripts around it. However, there is no fix for this ticket because of lack of log files.
Comment 14 Andreas Deicke 2021-04-20 14:26:28 UTC
I'm using a Raspberry 3B+ (with build-in WIFI-chip sdio: brcmfmac) and experiencing the same issue.

Using the command from comment #8 without the redirection, i.e.

/usr/bin/hostapd -P /var/run/hostapd /etc/hostapd.conf

I get the following output:

Line 5: Invalid country_code '00'
Cannot enable IEEE 802.11d without setting the country_code
2 errors found in configuration file '/etc/hostapd.conf'
Failed to set up interface with /etc/hostapd.conf
Failed to initialize interface
Comment 15 Andreas Deicke 2021-04-20 14:46:04 UTC
(In reply to Andreas Deicke from comment #14)
> I'm using a Raspberry 3B+ (with build-in WIFI-chip sdio: brcmfmac) and
> experiencing the same issue.
> 
> Using the command from comment #8 without the redirection, i.e.
> 
> /usr/bin/hostapd -P /var/run/hostapd /etc/hostapd.conf
> 
> I get the following output:
> 
> Line 5: Invalid country_code '00'
> Cannot enable IEEE 802.11d without setting the country_code
> 2 errors found in configuration file '/etc/hostapd.conf'
> Failed to set up interface with /etc/hostapd.conf
> Failed to initialize interface

changing the value of the county_code entry in '/etc/hostapd.conf' from '00' to 'DE' solved the issue.

Kind Regards,
Andreas
Comment 16 Andreas Deicke 2021-04-20 15:08:57 UTC
Initially I did the change of the country_code value directly in the file '/etc/hostapd.conf, but the better and correct way is probably to set the value in the IPFire GUI (menu IPFire >> WlanAP).

This value has been ignored obviously so far, and that's why I have it ignored until now. Therefore the default value '00' has been used.

As I said setting the parameter to a correct value solved the issue (at least for me). I do not know, if is the solution for other people too.

Kind Regards,
Andreas
Comment 17 Erik Kapfer 2021-05-07 07:40:07 UTC
Hi all,

(In reply to Andreas Deicke from comment #16)
> Initially I did the change of the country_code value directly in the file
> '/etc/hostapd.conf, but the better and correct way is probably to set the
> value in the IPFire GUI (menu IPFire >> WlanAP).
> 
> This value has been ignored obviously so far, and that's why I have it
> ignored until now. Therefore the default value '00' has been used.
> 
> As I said setting the parameter to a correct value solved the issue (at
> least for me). I do not know, if is the solution for other people too.
> 
> Kind Regards,
> Andreas

i can confirm this fixes the problem here too.

Best,

Erik
Comment 18 Arne.F 2021-05-17 15:30:32 UTC
Newer hostapd versions not allow "00"

But choosing a correct Country code should work. Also the double entries should already fixed with the latest core156 build.