WiFi Unreliable When Booting Into Maintenance Mode

[Black Hole]

Something like: mktemp -dp /mod/tmp $(date +"%m%d%H%M").XXX

...but I need to feed the actual folder created into the mv command. Reading up, I see I can capture that info from standard output into a variable, but I am confused about what might or might not need to be escaped:

BHTMP='mktemp -dp /mod/tmp $(date +"%m%d%H%M").XXX'
mv /mod/tmp/prev/* /mod/tmp/$BHTMP

 

[Black Hole]

Telnet to the MM machine after boot and ifconfig wlan0; route -n; cat /mod/etc/wlan.conf.

 

[prpr]

I need to feed the actual folder created into the mv command. Reading up, I see I can capture that info from standard output into a variable

BHTMP=$(mktemp -dp /mod/tmp "$(date +"%m%d%H%M").XXX")
for f in /mod/tmp/prev/* ; do
  [ -f "$f" ] && mv "$f" "$BHTMP/"
done

but I am confused about what might or might not need to be escaped

Isn't everybody...
I think the above is strictly correct (I'm sure /df will say if not), but you can probably get away without any of the double quotes here (just don't try putting a space in the date format without them).

 

[prpr]

I've packaged the stuff from posts #8 and #55 into a new wireless-helper package, available in the Beta repository.

 

[prpr]

In passing I notice that a lot of the startup routines in /etc/init.d and /mod/etc/init.d don't test whether the system is starting up or shutting down. This is reasonable if the system will never shut down partially and then restart, which was a good assumption but might be wrong as we have the fast restart now.

I've had a look through these and can't find anything that is unprotected or that matters if not protected. Unless you have something specific?

 

[Black Hole]

If I install wireless-helper beta, will that automatically revert everything - considering (IIRC) some stuff had to be edited?

The script /sbin/wifi-up is part of the CF image and can't be edited directly. Instead, for a test fix, copy it to /mod/sbin/wifi-up-test and edit the copy to move the eth_check line in the first quoted extract above so that it runs before the ifconfig; this file needs to be marked executable, either by the button in the WebIf>Diagnostics>File Editor, or by running chmod a+x /mod/sbin/wifi-up-test. Then edit the file /mod/etc/init.d/S00wlan and change the reference to /sbin/wifi-up to /mod/sbin/wifi-up-test.

 

[prpr]

It depends what you mean by "everything". It won't remove anything you have customised, unless it happens to have the same name as what's in the package, in which case it'll get overwritten.
I would suggest you remove all your customised stuff to somewhere safe first, keeping copies as required, then install the package and test (I don't use wireless devices any more, as mine are all wired, so can't test for real).

 

[/df]

... attachment ...

Looks great as long as your WiFi security is WPA2 PSK (TKIP+AES).

 

[/df]

I've packaged the stuff from posts #8 and #55 into a new wireless-helper package, available in the Beta repository.

Once we're confident that this works the wifi-up script could be rolled into CFW 3.14, but wireless-helper can't be binned completely:

• installing wireless-helper on 3.14 would enable support for hidden SSIDs and the settings save/restore function (by running the wifi-up script from the /mod/etc/init.d/... script);
• installing wireless-helper on 3.13 and earlier would additionally enable the xinit script to set up /sbin/wifi-up;
• although wireless-tools is a dep of wireless-helper, only iwgetid and iwpriv are used, and those are in 3.13 CFW: possibly the dep is required on some earlier CFW versions.

 

[/df]

... I am confused about what might or might not need to be escaped:
...

Use shellcheck.net (with #!/bin/ash as the first line of the script) to be enlightened.

 

[prpr]

Once we're confident that this works the wifi-up script could be rolled into CFW 3.14

Is this going to work on a diskless HD? There are references to /mod/etc/wlan.conf and /mod/boot/dbupdate
OK, the code referencing these seems to be protected but it's still bad style (IMHO) - reference

 

[xyz321]

...but I need to feed the actual folder created into the mv command. Reading up, I see I can capture that info from standard output into a variable, but I am confused about what might or might not need to be escaped:

BHTMP='mktemp -dp /mod/tmp $(date +"%m%d%H%M").XXX'
mv /mod/tmp/prev/* /mod/tmp/$BHTMP

I suggest changing it to the following:

BHTMP=$(mktemp -d -p /mod/tmp $(date +%m%d%H%M).XXXXXX)
mv /mod/tmp/prev/ $BHTMP

Note it does require at least 6 Xs.

 

[Black Hole]

Note it does require at least 6 Xs.

Is that special to the HDR-FOX implementation? My reading of the mktemp manual is that it just replaces however many X's with random characters chosen to avoid a conflict.

 

[prpr]

Note it does require at least 6 Xs.

It depends whether you are using the busybox version or the coreutils version.
The minimum is 3, as per the standard documentation, with the latter. Quite why busybox feels the need to change this is beyond me.

 

[Black Hole]

And if busybox is installed, that takes priority?

 

[prpr]

And if busybox is installed,

It's always installed, if you've got webif installed. And if you haven't then it uses the (cutdown) version that's baked into the firmware.

that takes priority?

No, the coreutils one will take priority, seeing as /mod/bin is in the PATH before /mod/bin/busybox

 

[Black Hole]

In other words,

Note it does require at least 6 Xs

...is incorrect however you slice it, unless the user makes specific reference to the busybox version of mktemp. For "6" read "3".

 

[xyz321]

I was assuming this was to be run on an HD/HDR. If you want something that will work with or without coreutils installed then use at least 6 Xs or alternatively test for the presence of /mod/bin/mktemp and change the template to suit.

 

[/df]

Is this going to work on a diskless HD? There are references to /mod/etc/wlan.conf and /mod/boot/dbupdate
OK, the code referencing these seems to be protected but it's still bad style (IMHO) - reference

The save_settings function needs storage that will survive a restart. I put wlan.conf on the mod device for diversity since setup.db is on the flash storage. If there's a significant constituency of diskless HD configurations, a location in /var/lib/humaxtv* could be used as an alternative. Also, the script could use the explicit path for /mod/boot/dbupdate which would work in the diskless case if the dbupdate package had been installed.

 

[Black Hole]

I was assuming this was to be run on an HD/HDR.

It is. Why are you getting different results? Here's a screenshot showing 3 X's works:

for f in /mod/tmp/prev/* ; do
  [ -f "$f" ] && mv "/mod/tmp/prev/$f" "$BHTMP/"
done

Why is that a do loop and not a simple one-off wild-card move command?