Hi,
I was able to reproduce it with one of my wifi cards.
The problem is, that system.d starts our service too early. Out of its perspective it has done its job, because he initialized the wifi card.. but the wifi card is still initializing when hostapd starts... and after the init of the wifi card is done, hostapd crashes.
I think I found the fix.
Please edit /etc/systemd/system/piratebox.service, that it looks like that
Type=idle - means, that after the system is jumping into an idle mode.
RemainAfterExit=yes - Means, that the process forks itself.
Sorry, that took so long, I hope this helps
Matthias
edit: to find this issue, I added a few wait steps within piratebox_alt , and analyzed the output of "journalctl" in detail. There you are able to see, that some wifi-driver messages come across after hostapd is done.
With an addition wait step I was able to, see that after the wifi init, the network-step (which usually fails) worked... that was one finger-pointing clue more.
I was able to reproduce it with one of my wifi cards.
The problem is, that system.d starts our service too early. Out of its perspective it has done its job, because he initialized the wifi card.. but the wifi card is still initializing when hostapd starts... and after the init of the wifi card is done, hostapd crashes.
I think I found the fix.
Please edit /etc/systemd/system/piratebox.service, that it looks like that
[Unit] Description=PirateBox Service [Service] Type=idle RemainAfterExit=yes ExecStart=/opt/piratebox/init.d/piratebox_alt start ExecStop=/opt/piratebox/init.d/piratebox_alt stop #Restart=/opt/piratebox/init.d/piratebox_alt restart #PIDFile=/var/run/piratebox.pid [Install] WantedBy=multi-user.target
Type=idle - means, that after the system is jumping into an idle mode.
RemainAfterExit=yes - Means, that the process forks itself.
Sorry, that took so long, I hope this helps
Matthias
edit: to find this issue, I added a few wait steps within piratebox_alt , and analyzed the output of "journalctl" in detail. There you are able to see, that some wifi-driver messages come across after hostapd is done.
With an addition wait step I was able to, see that after the wifi init, the network-step (which usually fails) worked... that was one finger-pointing clue more.