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.
I think we can only toggle while the handler is not active.
I toggled to ON and got the script running. But then I couldn't toggle
OFF, presumingly because the script was still running.
By sending it to the background I hope it will allow me to toggle OFF.
We can probably set the IMEI through the gl_modem command.
Currently, the Web interface times out when calling random-imei. I want
to separate the steps so that each step does not take as long.
Somehow it disconnects me from the wifi, I guess it's related to
restarting the gl-tertf service. I wonder whether the installation
completes so I make a message appear.
rather than deleting everything.
It seems that the device stops working when deleting the database. That
is, the connection to the Internet stops working which is very safe as
it does not leak any data but arguably defeats the purpose of the
device.
So with the commas only, it installed without complaining. Which is
weird, because what does it recognise as dependency that it think is
fulfilled? The long name with all the commas?
The intention is to have the system recognise our dependencies and to
reject installation if the dependencies are not met. Better yet, have it
install the dependencies!
This is a snapshot only. It does not work and serves as a prototype
only. Now, we can see how to add a menu item and how to call our
executable on the flash.
The switch doesn't work yet but "uci get switch-button.@main[0].func"
gets the currently active configured action for button.
I guess that /etc/rc.button/switch is called on every press of the
button.
I don't know whether this works. On the v4 firmware, we can see files in
/etc/gl-switch.d but I don't know yet how the system determines which
file to choose. I assume it's dependend on the "page" of the display.
But I haven't figured out yet how or rather where those pages are
organised.
I have rsynced the whole device before associating with a new device and
after. The only file that got modified was /etc/oui-tertf/client.db.
We intend to have it stored in memory rather than on flash. This should
be okay since the kernel also holds the MAC addresses in memory.