Remember wifi settings after random reset?

mr-b

New Member
Hi

I've just managed (after 1.5h) to remotely restore my mother's Hummy after she was confronted with the "Select Language" option, and she was sure she hadn't pressed any random buttons!
After navigating the installation wizard (which has several UI pitfalls) it turned out that the wifi dongle settings had gone too and so she had to enter those from scratch. Finally I managed to get the ip address from the router and logged in to restore her scheduled recordings and everything was Ok. But it was very painful for her!

The crash.log seems to have no obvs pattern. After some odd crashes last year I upgraded her aerial/masthead amp to ensure the signal was optimal but it seems some persist. No idea what the uptimes are.

19 Humax crashed at Thu May 7 16:21:38 UTC 2020 - Uptime: 30
18 Humax crashed at Thu Apr 9 16:31:05 UTC 2020 - Uptime: 33
17 Humax crashed at Tue Mar 24 12:36:44 UTC 2020 - Uptime: 29
16 Humax crashed at Mon Mar 23 14:55:34 UTC 2020 - Uptime: 33
15 Humax crashed at Fri Mar 20 17:26:11 UTC 2020 - Uptime: 34
14 Humax crashed at Mon Mar 16 14:40:28 UTC 2020 - Uptime: 12
13 Humax crashed at Wed Mar 11 10:18:28 UTC 2020 - Uptime: 36
12 Humax crashed at Fri Feb 28 10:03:29 UTC 2020 - Uptime: 30
11 Humax crashed at Tue Jan 28 14:51:11 UTC 2020 - Uptime: 30
10 Humax crashed at Sun Jan 26 19:42:19 UTC 2020 - Uptime: 12
9 Humax crashed at Thu Jan 23 16:06:23 UTC 2020 - Uptime: 32
8 Humax crashed at Tue Jan 21 16:17:02 UTC 2020 - Uptime: 37

She is no technophobe and can usually handle tech devices fine but sometimes unexpected events throw her and the restoration story turned into an episode of Child's Play ... Normal terminology of on-screen events is forgotten and I was left wondering what "it keeps clicking off" etc. meant ....

So, is there any way that wifi settings could be saved or easily restored?

Failing that, is this going to be a regular event i.e. do boxes go flaky due to caps etc. and are there any suggestions for reliable PVR soln's that can be remotely managed, for quiet lives all round?
 

Black Hole

May contain traces of nut
boot-settings, auto-schedule-restore, and tunefix between them can re-establish pretty much everything... except networking. A wired connection with DHCP will re-establish itself, a wireless link won't.

https://hummy.tv/forum/threads/is-there-a-good-time-to-retune.7624/post-103888

Failing that, is this going to be a regular event
Check out System Flush. We believe the Humax goes into the wizard if the databases get corrupted, but it happens and does not appear to be sinister.

are there any suggestions for reliable PVR soln's that can be remotely managed, for quiet lives all round?
No.
 
OP
M

mr-b

New Member
Ok tx - in the end I had to restore the schedule again. (I've never seen auto restore work for some reason after I had issues with the box kept losing channels last year - due to tunefix barfing on an invalid config value, now fixed apparently). I'll post that in a separate thread though.

I suppose I could use a homeplug instead of a wifi usb stick if it starts to be an issue, but I think I'd need to rethink the whole setup in that case.

Unfortunately System Flush looks to be a no go since it involves flashing firmware and it's such a long time since I did it that it sounds too risky to do remotely.
AllI can recall is lots of issues with usb sticks!

Any ideas if I can diagnose the crashes? Mine virtually never does.
 

Black Hole

May contain traces of nut
AllI can recall is lots of issues with usb sticks!
If it was flashing the firmware, that would be the case. But I don't think it is - I think it is actually having an instruction on USB available at boot time which tells the CF to flush the databases. If somebody can confirm/correct that I would be grateful (for my own knowledge).
 

/df

Active Member
I've always assumed that System Flush is a sort of automatic fix-disk for the flash filesystems.

boot-settings, auto-schedule-restore, and tunefix between them can re-establish pretty much everything... except networking. A wired connection with DHCP will re-establish itself, a wireless link won't.
...
The WiFi settings are stored in a way that boot-settings can't handle. However it would be a good thing to make these settings recoverable. Might it be a reasonable solution for current connection settings to be written to the /mod filesystem such that, if no WiFi settings are found after reboot, the saved settings can be reloaded and applied?

Actually this seems to be easy to do in the wifi-up script, something like this, which I'm running as a test (the script is a flash file that I'm overriding with a bind mount at xinit time):
Code:
--- /sbin/wifi-up
+++ /sbin/wifi-up.new
@@ -3,6 +3,28 @@
 export PATH=/sbin:/bin
 unset LD_LIBRARY_PATH
 
+WLANCONF=/mod/etc/wlan.conf
+save_settings() {
+       [ -w "${WLANCONF%/*}" ] &&
+               { echo "# these settings are used if no settings are configured"
+                 swifi; } > "$WLANCONF"
+}
+
+iwget() { # param [wid]
+       local wid="$2"
+       [ -n "$wid" ] || wid="$(iwgetid)"
+       case $1 in
+       ssid|essid)
+               echo "$wid" | sed -r 's/.*:"(.*)"/\1/'
+               ;;
+       wif)
+               echo "$wid" | sed 's/ .*//'
+               ;;
+       *)      return 1 ;;
+       esac
+}
+
+
 wid="`iwgetid`"
 if [ $? -ne 0 ]; then
        echo "No wireless dongle detected."
@@ -30,6 +52,7 @@
 if [ -n "$essid" ]; then
        echo "Already connected to '$essid'"
        eth_check
+       save_settings
        exit 0
 fi
 
@@ -39,6 +62,23 @@
        iwpriv $wif set $1=$2
 }
 
+# if no settings, fake the swifi command to restore them
+[ -z "$(swifi ssid)" ] && [ -r "$WLANCONF" ] &&
+       swifi() { # parm ...
+               local parm ptn
+               # make a search pattern parm1[|parm2...]
+               for parm in "${@:-..*}"; do
+                       ptn="${ptn}${ptn:+|}${parm}"
+               done
+               if [ $# -eq 0 ]; then
+                       grep -E "(${ptn})=" "$WLANCONF"
+               else
+                       # strip off leading "parm="
+                       sed -nr "/(${ptn})=/ {s/^..*=//;p}" <"$WLANCONF"
+               fi
+       }
+
+
 ifconfig $wif up
 wset NetworkType Infra
 
@@ -99,3 +139,6 @@
        udhcpc -t 5 -T 10 -p /var/lib/humaxtv/udhcpc.$wif.pid -i $wif &
        sleep 7
 fi
+
+[ -n "$(iwget ssid)" ] && save_settings
+
This /sbin/wifi-up script is run by the settop binary at start-up or when you Apply the Wi-Fi settings, and also by a startup script installed by the wifi-helper package. As the /mod filesystem may not be available when the settop binary runs the script, so you'd need to install wifi-helper to ensure that the new version has the desired effect (the script is supposed to operate in the old way if the configuration file or directory should be unavailable). Also, in case anyone cares, the password will be readable from the /mod/etc/wlan.conf file.

As with certain other improvements, it might be possible to get this baked into the next CF release.
 
Last edited:
OP
M

mr-b

New Member
No, it never came up in any forum or wiki searches and it wasn't in a sticky. I guess it's a vintage post! Will take a look.

Re: Sytem Flush, it seems to be a file and the wiki says:
"Install as standard firmware update to perform a full system flush and reset. "
... so I'm guessing it'll be prone to the old usb compat issues.


The wifi backup script sounds interesting. Could it be part of a package, vs firmware?
 

Black Hole

May contain traces of nut
Could it be part of a package, vs firmware?
Not sure about your nomenclature. "Firmware" is only what's baked into the flash, the rest of the CFiverse is packages or personal scripts stored on HDD and therefore software. If you mean whether the network settings can be made to backup and restore through a new or modified published package - yes, maybe, but things don't happen very fast these days (because of changed priorities in the life of the prime mover) so incorporating your own tweaks shouldn't be ruled out.

... so I'm guessing it'll be prone to the old usb compat issues.
Not sure. I inquired about this recently but don't recall a reply - it is not a literal firmware update, I believe it is a mechanism for triggering the CF to do something at boot time so the limited UPD support during firmware update might not be relevant. Some time ago I asked for the wording in the wiki to be tweaked to clarify that a System Flush is not an actual firmware update.

Another thread you might not have found (but all linked through my post signature): Glossary (click). Why aren't these "vintage" threads all pinned? Well, it would seem very self-serving to pin all the summaries I have written. I prefer to pin indexes.
 
OP
M

mr-b

New Member
My POV was for remote installation/administration, so a firmware update is definitely going to be in the too-hard pile, whereas a package/script can be installed/configured/removed/recovered from etc. remotely.

RE: the flush, if it's a file that needs to be read off a USB stick (irrespective of what happen afterwards), then I'd hazard that it would be prone to the old compat issues.

RE: vintage thread, I don't see how pinning something useful is self-serving, no matter how old it is! :) I did search extensively for crash info but couldn't find it in any index posts either ...
 

/df

Active Member
...
Re: Sytem Flush, it seems to be a file and the wiki says:
"Install as standard firmware update to perform a full system flush and reset. "
... so I'm guessing it'll be prone to the old usb compat issues.
Hmmm, I extracted the update from the System Flush download, so as to establish in my own mind what it does, but the extracted (by humidify) image files don't appear to be a valid squashfs filesystem, unlike the actual updates. However, unlike eg the IPTABLES flush update it doesn't seem to be a package update, so would depend on the USB support in the bootloader as you suggest.
The wifi backup script sounds interesting. Could it be part of a package, vs firmware?
The script is used for Maintenance Mode, so it's part of the CF itself. Ideally the existing script would be modified for the next CF version; alternatively the wifi-helper package could be modified to patch it, similar to my test setup.

In this setup, I have a copy of the script in /var/lib/humaxtv_backup/mod/wifi-up and a script named /var/lib/humaxtv/mod/xinit.d/wifi, that mounts the modified script over the original, as below (both scripts need to be marked executable):
Code:
#!/bin/sh

mount --bind \
        /var/lib/humaxtv_backup/mod/wifi-up \
        /sbin/wifi-up
This modifies /sbin/wifi-up just before the settop binary, or Maintenance Mode, starts. Note that this setup is on the flash storage that gets reinitialised by a System Flush, so you need a backup on the hard disk.
 
OP
M

mr-b

New Member
Tx for all the spadework. I look forward to my mother being a guinea-pig (!), though if it's only in a firmware flash vehicle it may have to wait until a CV19 vaccine is out! Altenatively I guess I could send a pre-tested USB drive first and hope the compat issue doesn't vary between boxes ...
 
Top