Commit Graph

5 Commits

Author SHA1 Message Date
Tobias Mueller
bdc8837660 start services earlier to make the client tracking work
My hypothesis is that our script does not fully finish before the next
daemon starts. I don't fully understand why our script does not seem to
finish before the next script runs. But this appears to be working
better.
2023-10-18 22:37:12 +02:00
Tobias Mueller
948db4b6fa mac: actually delete the clients.db
This hopefully makes the client tracking work better. Before this
change, the Web UI would not be able to track clients, probably because
the database contains garbage. Now that we delete the file properly, it
will be re-generated (in the volatile tmpfs) and the Web UI should show
everything nicely.
2023-10-18 21:06:46 +02:00
Tobias Mueller
d4886a54a9 volatile-macs: define the service self-sufficiently
This makes it hopefully a bit easier to see what we're doing because you
don't need to chase the files down. We don't re-use that functionality
anywhere. Neither would we.
A more important change is not restarting the gl-tertf service.
First of all, there seems to be no process attached to gl-tertf. It is
the "Bandwidth Monitor" and part of the kmod-gl-sdk4-tertf package, so
it's kernel module. It does not appear to be holding the clients.db.
There is, however, gl_clients which also makes sense, naming wise.
That service defines that /usr/bin/gl_clients_update ought to be run.
And stracing it shows that it does indeed touch the database:
open("/etc/oui-tertf/client.db",
O_RDWR|O_CREAT|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC, 0644) = 7

It also appears to be re-creating the file when it's missing.

Anyway, we have the service stopped during installation so that we can
safely delete the file without the process complaining. We also install
our volatile mac service s.t. it runs ahead of the gl-client service so
that the clientdb gets saved in volatile memory.
2023-10-18 14:27:55 +02:00
Tobias Mueller
d47916552d volatile macs: match our service's priority to our dependencies
The value of 20 is probably a copy and paste leftover from the
blue-merle service. The real START value that we care about is 60.
2023-10-18 13:24:47 +02:00
Tobias Mueller
8b4d371c9f functions: Do not automatically restart the wifi on RESET_BSSIDS
Instead of restarting the service we have the service started *after*
our modification to its configuration.
This makes it slightly more inconvenient to reset the WiFi BSSIDs while
the device is booted but that capability can be restored and made better
through an executable, say, /usr/bin/reset-wifi-bssids or something.

We also split the volatile client MACs into its own service to have
a bit of a clearer separation of duties. This will allow us to eventually
split the package more easily into sub-packages with finer-grained control.
2023-10-17 19:52:11 +02:00