KI4STU
commented
5 years ago The startup script is set to wait for "network" before trying to start the logging server process. This has worked until recently, though it isn't the best way to handle things. With the latest raspbian image (and possibly other images), although "network" is up by the time the process starts, it is not fully up. Likely, the server's IP address (when in AP mode) isn't quite up when the logging server process starts. This causes the logging server to fail to start cleanly, as it can't bind to that IP.
For now, the fix is to bind to 0.0.0.0 instead. This should solve the problem, but poses a security concern: if the Pi is not on an isolated network (i.e. not in AP mode), someone nefarious could potentially connect to the logging server and do bad things. The risk here seems quite low, because:
- the logging server will probably be run in AP mode, creating its own isolated network that only HamLog clients are connected to. if you can't trust yourself (or your FD team), you've got bigger problems.
- If the logging server is on some publicly accessible network, someone would have to discover it, decode the protocol, and then do something nefarious (like injecting bad data into the server). While this is technically possible and not altogether difficult (in fact, this is what I essentially did when I first started working on this logging server), there isn't much reward for someone who does this. Talk about a niche within a niche within a niche.
Long term, it may be better to have the logging server process itself monitor the real IP that it should bind to, and not try to connect to the socket until that IP is up and usable. But for now, it'll just listen on any interface that's available.
Fix is in testing.
Server is starting up and trying to bind to an IP before that IP is available. Networking is up when it starts, but not fully up.