I just wanted to share what I’ve experienced and the solution I am currently using in the event it helps others.
I recently updated to 189 and realized my blue (WiFi) network wasn’t available anymore. When I check IPFire the hostapd was stopped. I tried turning it on, left the page and came back, and again it reported stopped. After google searching and reading on this forum I ran across this thread talking about checking hostapd.
When I SSH into IPFire and checked /etc/hostapd.conf with a text editor, I found that it no longer matched a backup version I had.
As you can see there are several parameters missing from the new conf that the old one had. When I replace the new conf with the old one, hostapd starts working again and my WiFi is back. If I make any change via the IPFire GUI to my wireless settings and save, the conf file gets overwritten back the the “new” format and hostapd once again refuses to start. Currently, the only way to change any setting for my WiFi configuration is via text editor while SSH into my IPFire box.
@bbitsch You would be correct, I can not select a channel. Thanks for the script update.
@bonnietwin I was kind of figuring that was the case. I thought I would throw the issue on here in the interim. The blue side is only used for guests, and there is seldom any. Total fluke that I even realized it was down.
So I figured I should say what I did and where I left things. The solution I used was to manually edit the hostapd.conf file and leave it at that. WiFi is functioning and if a change is needed I can edit the conf file.
If anybody is reading this BEFORE 190 is released and has the same issue, you can just copy the “Old (working) conf” section and paste is over your hostapd.conf file. Backup your original first, of course. Make sure to edit the different parameters to your needs, i.e. SSID, Password, Channel, etc. This would need to be done from the SSH terminal, not the WUI.
While I’m sure Bernhards’ solution is a good one, I myself didn’t implement it since I already had the conf file edited and WiFi back running. The other reservation I had is when CU190 is released, will this cause me issues since it’s a deviation from OEM. That could be totally unwarranted, but that was my reasoning. WiFi is working, I’ll wait for CU190.
@mo1010427, your solution is functioning.
I’ve tried only to do it without manual modifications to the .conf files. The ‘standard’ process in IPFire is to do configuration by the WUI. This keeps the state of the WUI ( settings files ) and the program(s) ( .conf files ) consistent.
Core Updates assume that process, therefore they can overwrite manual editings.
My find generated a couple of minor modifications, the change in wlanap.cgi is one of them. My experience showed, that it is sufficient for a running system which isn’t altered to often.
I’ll check the other modifications in the next days. But it isn’t so easy to do this, remainder of the family is connected wirless.
@bbitsch I agree with you, using the WUI is the way to go, and your solution would allow this. I do know that I can’t use the WUI, with my method, or it will undo the changes I made.
I can relate to the family part. Nothing will make them find you faster than no internet.
I have checked through the CU189 and next (CU190) gir repo entries and I have to say I can not see why the backported changes did not work with CU189. All the ones in what will be CU190 are in CU189 and including the PAK_VER bump for hostapd to ensure that the wlanap.cgi code is shipped with the update.
All of the changes were made in CU189 on 8the Oct so were in place for the release date of CU189 of Oct 16th.
When I can get the time in a week and a half or so I will do a CU189 install into my Prime system and see if that works without problems or not and then also try doing a CU188 install and then updating it to CU189, to see if there is any difference between a fresh install and an update.
I would like to see if I can reproduce what is being experienced and then to try and understand why it has happened, because at the moment I can’t see any reason for wlanap.cgi being different between CU189 and CU190 but there must be some reason.
@bonnietwin To be fair, it very well may have been an issue since CU188 or earlier. Thinking about it, I use the blue network as a guest, as I had mentioned, and that is the network I use when flying my Mavic.
For the last 3 months or so, if I was to guess, it was telling me no network available. This seemed odd since I never had that issue before, but I chalked it up to poor signal perhaps and continued on. Only by chance did I recently figure out the blue network was not running, which in turn would explain why the Mavic was complaining.
I can tell you I have the same setup running at a family members home, running CU188 and that is where I got the conf file to compare. Their blue network is functioning, but I’ve never tried to make any changes to the settings through the WUI on theirs for quite some time.
I did not stumble very deep into the git history of wlanap.cgi.
But reading the interface id from a cgi variable could have made sense some core updates before. I remember there was a selection of the interface in the WUI page ‘once upon a time’. Usually there were no choice, many systems including mine have one wifi card only, so the section isn’t recognised my most users.
The odd line may be a remainder from these versions.
