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.
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.
We can use the identifier of the SIM as a stable token to derive a
deterministic IMEI rather than the IMSI which is only available once the
SIM has been (PIN) unlocked.
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.
After shutting down the modem and before replacing the SIM, we generate
a temporary random IMEI to prevent accidental disclosure of the new IMSI
under the old IMEI. It should not happen but we do not control the modem
as much as we'd like, e.g. fully power it down. So it may not be
necessary but we consider it defense in depth.
We restore from fa11fc45ca.
We know that this worked well enough the last time as we run out of time
to test new things.
Ideally, though, we manage to consolidate the SSH use and the switch use
(and the Web use) to not have different implementations of the same
functionality so that testing gets much simpler.
We currently use a Python script to generate IMEIs. Loading Python is
relatively expensive on our target platform so I hope we can use
something quicker.
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.
This can currently only provide a random IMEI only. But we could easily
recover the deleted script. But it'd be nicer to have a central
configuration for the mode.
When toggling the switch, a lock is held for a relatively long time,
preventing another toggling of the switch to be noticed. With this
change, I hope we can first shutdown the modem, wait for a toggle, and
then continue.
We're losing the abort function but I currently don't know how we would
be able to keep that functionality given that the toggle is queued and
we don't get the notification.
I hope that this allows us to use the toggle again to advance the Blue
Merle logic.
If all goes well, the script finishes execution and the switch lock in
/var/lock/gl-switch.lock is released so that the button can be used
again.
We don't want to let it run forever because it blocks the toggle from
working. But even if it's not, we wouldn't want to have the script run
eternally.
muelli
nestire
Jakob Rieck
Tobias Mueller