After the Update, my blue network did not come up. The log says
Jan 21 08:44:05 ipfire hostapd: Configuration file: /etc/hostapd.conf
Jan 21 08:44:05 ipfire hostapd: Line 6: Invalid country_code ‘’
Jan 21 08:44:05 ipfire hostapd: ctrl_interface_group=0
Jan 21 08:44:05 ipfire hostapd: Cannot enable IEEE 802.11d without setting the country_code
Jan 21 08:44:05 ipfire hostapd: 2 errors found in configuration file ‘/etc/hostapd.conf’
Jan 21 08:44:05 ipfire hostapd: Failed to set up interface with /etc/hostapd.conf
After some experimenting, I found that setting the Country Code to “US” instead of “CH” (I live in Switzerland) made the interface come up again.
I tried to file a bug report but I cannot. I do not have an account and the bugzilla interface has a button for “forgot password”, but not for creating a new account
What seemed to be a clear case (contry code US works, CH not) turned out to be something else. A simple back from US to CH and back to US to deliver the changes in the config files to the developpers led to a WLAN which did not come up anymore. Michael told me to turn to other sources of help, because it would be no bug report. Simply put: My ipfire delivers all sort of error messages, changing with every push of the save button. Sometimes WLAN comes up, sometimes not, sometimes with strange error messages and so on. At the moment, my most important clients can connect. Over the Weekend, I’ll get a separate WLAN router so that I can evaluate the problem without harm to my client. At the moment I’m simply afraid that I loose all my connections again. Strange fact: Everything was working fine with a certain setting, but now the same setting leads to a non starting WLAN. I will get back here, as soon as I get the separate router up and running and have my findings so far straightened. Won’t be before wednesday, though. If anybody has some tips what to check (known erros, checksums or whatever). I would be grateful
Good News, my system runs smoothly again but hers first what I did:
After moving my users to a standalone Wifi-Router I could do some tests and checks. First I checked my disk for problems, there were none. Then I checked the installed driver for differences with an ipfire cu199 I could get hands on, which runs smoothely. All was OK. So I changed the SSID on my ipfire so it could not cause problems with the users on the separate Router. After many combinations of , passwords and available 802.111 standards I found that when I used password with only ASCII-characters, WLAN behaviour was absolutely predictable:
On 2.4Ghz, everyting goes smooth. System strarts every time, configuration contains what I enter in the browser, client connection stable. Repeated presses of “save” does not cause problems. Some Chanegs of standard can lead to a driver not starting, but going back to what was working earlier restored the function with no problems
The driver does not start with 5Ghz, but I did not check whether this is a limitation of my hardware, since I use some clients which can not use the 5Ghz band anyway
Using 2.5Ghz, clients connect (even simple shelly switches), but the log gets flooded with warnigs
“unknown vendor specific information element ignored (vendor OUI 00:10:18 len=9)
What does not work is: Changing to my earlier password containing “&” and “=” makes the system unprdictable
Some times the driver starts, sometimes not
The generated config sometimes does not contain changes I entered in the browser
When the driver starts, sometimes all clients can connect, sometimes only newer androids., but not simpler devices like my epson inkjet
Before CU199, everything worked fine, includig passwords using “&” and “=”. As far as I know, these characters are perfectly legal in passwords and work on Fritzbox, D-Link, Android, Debian, Windows, ChromeOS and earlier ipFires, nut more important for ipfire regarding CU199 are my following findings:
Once in several hours I got a running WLAN which worked perfectly with my old password containing “&"=”, even for simple clients, so I think the problem is NOT in the driver
From time to time changes I made did not whof up in hostapd.conf, so I think the problem lies somewhere either in the code running in the Browser ore in some script on ipFire
If my findings are not reproducable on a standard machine: I use a headless AMD based board which may be rare. Of course I’d be happy to provide more information, but which? Let me know
And sorry for closed Bug Report I filed earlier. I looked so obvious that there would be a problem with the country code: Entered one, system did not work, contry was empty in the config, changed the code and - everything was OK. Simple bug, I thought, but it was not…
There may be some issues in processing the settings.
If you have the settings/hostapd.conf files of the various cases it could help for analysing. There are some patches anyway, these could be checked also with this data.
As you have experienced, it isn’t easy to ‘play’ with a working system.
Set PW to ”Eins&Zwei=3”
WLAN behaves erratically. Sometimes WLAN comes up, often not. Changes to config files seem to depend on earlier changes on my system.
Set PW to *ThisIsSomething3”
All variations of 802.11 I checked work smoothly, including ax@40Mhz
If you or somebody else can reproduce this, further analysis can be done locally. If your system works with my problem-Password, Something on/in my machine must cause this. But what?
I just tested that on my system and hostapd immediately stopped and would not restart.
Checking out those two special characters, the = is fine, the problem is with the &.
EinsZwei=3 when saved has hostapd running without any problems.
My normal 64 character password has a range of special characters in it but the ! and the & are not in there.
I have the following in the password.
/ # @ : , + = .
and that full password worked fine.
The code will be looked at to see if we need to do the filtering that is done for the password and the best way to allow the range of special characters without reducing security.
Ah, glad to hear that the problem is reproducable by now. Sorry I did not get it earlier. Restriction of the “&” would not be a big problem, I think, although it once worked. For the moment and for the sake of this support isssue, Im OK now, since I know that there is nothing more lurkung somewhere, and Iwill close this thread. I’m sure the problem will be adressed in the next release. Again Thanks to all
I have just checked, nobody active but me ;).
There are crude things going on.
I had a situation, where an old config file was written to /etc/hostapd.conf. Looking at the format, I suspect it is a saved old state.
This allows to review the associated programs. Thx for the mentioning.
