WiFi Unreliable When Booting Into Maintenance Mode

The fix from https://hummy.tv/forum/threads/wifi...onally-incorrect-on-startup.9657/#post-139964 is definitely in the new wifi-up (including an actual reference to the forum thread). Something else must be causing any issues in Maintenance Mode.

The files should all have executable permission and if extracted directly over /mod should preserve those permissions from the archive. If, say, mod/boot/xinit.d/wifi should not be executable, the original CF code will run instead. However, this appears not to be the problem in the two reports above.

The file /mod/tmp/wlan.log may be useful: it contains the WiFi keys in plaintext, so redact those, if you care, before posting.
 
Last edited:
My wlan.log does not contain anything useful, and certainly not the WiFi key. Does the logging level have anything to do with this? (I don't think so, but thought I would check)
 
Last edited:
Which of us does that apply to, and why make remarks which have the possibility of backfiring?
That was just me being annoyed at that time. Can we draw a line and move on?

Assuming yes, I'll point these out in case they may be useful for diagnosing .
..
My xinit.log does not appear to contain anything useful.

My wlan.log does not contain anything useful, and certainly not the WiFi key. Does the logging level have anything to do with this? (I don't think so, but thought I would check)
Can you post these 2 logs so that someone can double check?
xinit.log
wlan.log
look over them first and sanitise if necessary. The fact that you don't see your WiFi key may suggest it's not getting far into the network negotiation, so maybe @/df will ask for further logs later
 
The fix from https://hummy.tv/forum/threads/wifi...onally-incorrect-on-startup.9657/#post-139964 is definitely in the new wifi-up (including an actual reference to the forum thread). Something else must be causing any issues in Maintenance Mode.

The files should all have executable permission and if extracted directly over /mod should preserve those permissions from the archive. If, say, mod/boot/xinit.d/wifi should not be executable, the original CF code will run instead. However, this appears not to be the problem in the two reports above.

The file /mod/tmp/wlan.log may be useful: it contains the WiFi keys in plaintext, so redact those, if you care, before posting.
Results for a normal boot with successful wireless connection.
Code:
# I created a new dir to hold the tar and work with the files
humax2324# cd beta1
humax2324# tar -vtf beta1/wifi-up.tgz
drwxrwxr-x 1000/1000         0 2022-04-17 13:15:56 mod/
drwxrwxr-x 1000/1000         0 2022-04-17 13:13:26 mod/etc/
drwxrwxr-x 1000/1000         0 2022-04-17 13:49:06 mod/etc/init.d/
-rwxr-xr-x 1000/1000       159 2022-04-17 13:49:06 mod/etc/init.d/S00wlan
drwxrwxr-x 1000/1000         0 2022-04-17 13:15:56 mod/boot/
drwxrwxr-x 1000/1000         0 2022-04-17 13:16:21 mod/boot/xinit.d/
-rwxrwxr-x 1000/1000        94 2022-04-17 13:16:21 mod/boot/xinit.d/wifi
drwxrwxr-x 1000/1000         0 2022-04-17 13:15:50 mod/boot/2/
-rwxrwxr-x 1000/1000      8074 2022-04-17 13:15:42 mod/boot/2/wifi-up
humax2324# ls -l  /mod/etc/init.d/S00wlan
-rwxr-xr-x 1 root root 159 Apr 17 13:49 /mod/etc/init.d/S00wlan
humax2324# ls -l  /mod/boot/xinit.d/wifi
-rwxrwxr-x 1 root root 97 Apr 18 23:02 /mod/boot/xinit.d/wifi
humax2324# ls -l  /mod/boot/2/wifi-up
cannot access /mod/boot/2/wifi-up: No such file or directory
humax2324# ls -l  /var/lib/humaxtv_backup/mod/wifi-up
-rwxrwxr-x 1 root root 8074 Apr 17 13:15 /var/lib/humaxtv_backup/mod/wifi-up
humax2324# ls -l /mod/boot/2/
total 1
lrwxrwxrwx 1 root root 27 Apr 18 15:36 mod -> /var/lib/humaxtv_backup/mod
humax2324# ls -l /var/lib/humaxtv_backup/mod/
total 262
-rwxr-xr-x 1 root root 33260 Jan  8  2017 abduco
-rwxr-xr-x 1 root root  6264 Jan 12  2015 checkpin
-rwx------ 1 root root 19354 Jan  7  2017 fix-disk
-rwx------ 1 root root 11092 Nov 16  2011 libdustbin.so
-rwx------ 1 root root 11092 Jan 22  2012 libdustbin.so.install
-rwx------ 1 root root  5824 Nov 16  2011 libfan.so
-rwx------ 1 root root  5824 Sep 14  2013 libfan.so.install
-rwxr-xr-x 1 root root 27048 Nov 16  2011 libir3.so
-rwxr-xr-x 1 root root 27048 Oct 16  2020 libir3.so.install
-rwx------ 1 root root 44888 Nov 16  2011 libnugget.so
-rwx------ 1 root root 44888 Apr 24  2019 libnugget.so.install
drwxr-xr-x 2 root root     0 Mar 28 11:14 opkg
-rwxr-xr-x 1 root root  4524 Feb  8  2012 setclock
-rwxr-xr-x 1 root root 16729 Jan 15  2017 tmenu
drwxr-xr-x 2 root root     0 Aug 26  2020 vdisk
drwxr-xr-x 2 root root     0 Aug 26  2020 webshell
-rwxrwxr-x 1 root root  8074 Apr 17 13:15 wifi-up

#Initially I used these to copy over the files
humax2324#cp -a beta1/mod/etc/init.d/S00wlan /mod/etc/init.d/S00wlan
humax2324#cp -a beta1/mod/boot/xinit.d/wifi  /mod/boot/xinit.d/wifi
humax2324#cp -a beta1/mod/boot/2/wifi-up     /mod/boot/2/wifi-up

#eventually I replaced the last one with this
humax2324#cp -a beta1/mod/boot/2/wifi-up  /var/lib/humaxtv_backup/mod/wifi-up
Code:
[/var/lib/humaxtv/mod/xinit.d/ahw]
AHW: Already done.
[/var/lib/humaxtv/mod/xinit.d/bootset]
Setting MENUCONFIG:AUTOMATIC_POWER_DOWN = (Value)1
Setting MENUCONFIG:DISPLAY_CRID = (Value)1
Setting MENUCONFIG:DMS_START_ON = (Value)1
Setting MENUCONFIG:INSTANT_REPLAY = (Value)305
Setting MENUCONFIG:PIN_CODE = (Text)6060
Setting MENUCONFIG:PWR_SAVING_ON_STANDBY = (Value)0
Setting MENUCONFIG:RESOLUTION = (Value)5
Setting MENUCONFIG:SKIP_FORWARD = (Value)300
Setting MENUCONFIG:SOUND_DIGITALOUTPUT = (Value)3
Setting MENUCONFIG:TV_SCART = (Value)2
Setting USERCONFIG:LCN = (Value)4
    Mapped LCN 4 to hSvc 262238
Setting USERCONFIG:CUR_SVC = (Value)262238
Setting USERCONFIG:VOLUME = (Value)10
[/var/lib/humaxtv/mod/xinit.d/dbupdate]
SQLite3: 3.7.5
[/var/lib/humaxtv/mod/xinit.d/forcedate]
[/var/lib/humaxtv/mod/xinit.d/install_dustbin]
[/var/lib/humaxtv/mod/xinit.d/install_fan]
[/var/lib/humaxtv/mod/xinit.d/install_ir3]
[/var/lib/humaxtv/mod/xinit.d/install_nugget]
[/var/lib/humaxtv/mod/xinit.d/opkg-beta]
[/var/lib/humaxtv/mod/xinit.d/rsvsync]
[/var/lib/humaxtv/mod/xinit.d/vdisk]
Loaded kernel module dummy_hcd.ko
Loaded kernel module g_file_storage.ko
[/var/lib/humaxtv/mod/xinit.d/wifi]
[/var/lib/humaxtv/mod/xinit.d/xota]
SQLite3: 3.7.5
Opening /var/lib/humaxtv/rsv.db
XOTA: Removing any auto-update scheduled events.
XOTA: Removed 0
Reminder checking disabled.
Code:
++++++++++++++ S00wlan - Tue Apr 19 06:57:27 UTC 2022 ++++++++++++++
Wireless interface: wlan0
== swifi
ssid=<redacted>
key=<redacted>
manual=1
auth=8
ip=192.168.2.24
mask=255.255.255.0
gw=192.168.2.1
dns=192.168.2.1
Set CountryRegion=31
Set AuthMode=WPA2PSK
Set EncrypType=AES
Set SSID=<redacted>
Set WPAPSK=<redacted>
Set SSID=<redacted>
== iwpriv show
wlan0     show:    Infra
wlan0     show:    WPA2PSK
wlan0     show:    AES
wlan0     show:
wlan0     show:    PMK = <redacted>
wlan0     show:    <redacted>
Manual config:
+ eth_check
+ local eth=eth0
+ ifconfig eth0
+ grep -q RUNNING
+ echo Link found on eth0.
Link found on eth0.
+ swifi ip
+ swifi mask
+ ifconfig wlan0 192.168.2.24 netmask 255.255.255.0 up
+ swifi gw
+ route add -net default gw 192.168.2.1
route: SIOCADDRT: File exists
+ swifi dns
+ echo nameserver 192.168.2.1
+ isConnected wlan0
+ iwgetid --raw --ap wlan0
+ [ -n D8:7D:7F:BE:A2:D6 ]
+ type swifi
+ grep -qF function
+ save_settings
+ local conf
+ [ -w /mod/etc ]
+ swifi
+ conf=ssid=<redacted>
key=<redacted>
manual=1
auth=8
ip=192.168.2.24
mask=255.255.255.0
gw=192.168.2.1
dns=192.168.2.1
+ echo ssid=<redacted>
key=<redacted>
manual=1
auth=8
ip=192.168.2.24
mask=255.255.255.0
gw=192.168.2.1
dns=192.168.2.1
+ grep -cF =Failed:
+ [ 0 = 0 ]
+ echo # these settings are used if no settings are configured
+ echo ssid=<redacted>
key=<redacted>
manual=1
auth=8
ip=192.168.2.24
mask=255.255.255.0
gw=192.168.2.1
dns=192.168.2.1

Results for a Safe Mode boot with unsuccessful wireless connection (but it's normal for this to not work in safe mode)
Code:
humax# ls -l tmp
total 12
-rw-r--r-- 1 root root 233 Apr 19  2022 boot.log
-rw-r--r-- 1 root root   4 Apr 19  2022 dnsmasq.pid
-rw-r--r-- 1 root root   6 Apr 19  2022 ifstate
-rw-r--r-- 1 root root   0 Apr 19  2022 utmp
-rw-r--r-- 1 root root   0 Apr 19  2022 xinit.log
humax# ls -l /mod/tmp
total 916
-rw-rw-rw- 1 root root  66365 Apr 19 09:01 activity.log
-rw-rw-rw- 1 root root      0 Apr 12 11:11 auto.20220412111102.log
-rw-rw-rw- 1 root root 117565 Apr 19 08:39 auto.log
-rw-rw-rw- 1 root root 212733 Apr 18 22:13 chaseget.log
-rw-rw-rw- 1 root root     62 Nov 19 20:25 crash.log
-rw-rw-rw- 1 root root  65857 Apr 18 22:00 detectads.log
-rw-rw-rw- 1 root root  86843 Apr 19 07:46 empty_dustbin.log
-rw-r--r-- 1 root root  60913 Apr 18 23:27 nugget.log
-rw-rw-rw- 1 root root      0 Feb 24 09:45 qtube.log
-rw-rw-rw- 1 root root 128609 Apr  6 11:21 recmon.log
-rw-rw-rw- 1 root root 134064 Apr 19 09:01 rsvsync.log
drwxr-xr-x 2 root root   4096 Aug 26  2020 webif_auto
drwxr-xr-x 2 root root   4096 Apr 18 22:02 webif_autoq
-rw-rw-rw- 1 root root    976 Apr 19 09:01 wlan.log
humax# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:03:78:B8:C2:2E
          inet addr:192.168.2.23  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1114 errors:0 dropped:0 overruns:0 frame:0
          TX packets:671 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:222911 (217.6 KiB)  TX bytes:137261 (134.0 KiB)
          Interrupt:16

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 70:F1:1C:06:C7:93
          inet addr:192.0.2.200  Bcast:192.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1810 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1998 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:431426 (421.3 KiB)  TX bytes:160080 (156.3 KiB)
Code:
++++++++++++++ S00wlan - Tue Apr 19 08:01:06 UTC 2022 ++++++++++++++
Wireless interface: wlan0
== swifi
ssid=<redacted>
key=<redacted>
manual=1
auth=8
ip=192.168.2.24
mask=255.255.255.0
gw=192.168.2.1
dns=192.168.2.1
Set CountryRegion=31
Set AuthMode=WPA2PSK
Set EncrypType=AES
Set SSID=<redacted>
Set WPAPSK=<redacted>
Set SSID=<redacted>
== iwpriv show
wlan0     show:       Infra
wlan0     show:       WPA2PSK
wlan0     show:       AES
wlan0     show:
wlan0     show:       PMK = <redacted>
wlan0     show:       <redacted>
Manual config:
+ eth_check
+ local eth=eth0
+ ifconfig eth0
+ grep -q RUNNING
+ echo Link found on eth0.
Link found on eth0.
+ swifi ip
+ swifi mask
+ ifconfig wlan0 192.168.2.24 netmask 255.255.255.0 up
+ swifi gw
+ route add -net default gw 192.168.2.1
route: SIOCADDRT: File exists
+ swifi dns
+ echo nameserver 192.168.2.1
+ isConnected wlan0
+ iwgetid --raw --ap wlan0
+ [ -n  ]

Results for a Normal boot with unsuccessful wireless connection.
Code:
humax2324# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:03:78:B8:C2:2E
          inet addr:192.168.2.23  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:536 errors:0 dropped:0 overruns:0 frame:0
          TX packets:409 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:183161 (178.8 KiB)  TX bytes:36936 (36.0 KiB)
          Interrupt:16

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:183 errors:0 dropped:0 overruns:0 frame:0
          TX packets:183 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:18780 (18.3 KiB)  TX bytes:18780 (18.3 KiB)

wlan0     Link encap:Ethernet  HWaddr 70:F1:1C:06:C7:93
          inet addr:192.0.2.100  Bcast:192.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1594 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1149 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:320801 (313.2 KiB)  TX bytes:131564 (128.4 KiB)

humax2324# date
Tue Apr 19 09:20:17 BST 2022

humax2324# ls -l tmp
total 116
-rw-r--r-- 1 root root     5 Apr 19 09:15 atd.pid
-rw-r--r-- 1 root root  2622 Nov 16  2011 boot.log
-rw-r--r-- 1 root root     4 Apr 19  2022 dnsmasq.pid
-rw-rw-rw- 1 root root     5 Apr 19 09:16 dropbear.pid
-rw-rw-rw- 1 root root     0 Apr 19 09:15 editMonitor.log
-rw-rw-rw- 1 root root    79 Apr 19 09:17 epgd.log
-rw-r--r-- 1 root root   143 Nov 16  2011 forcedate.log
-rw-r--r-- 1 root root    42 Apr 19 09:16 hosts
-rw-rw-rw- 1 root root     0 Apr 19 09:16 if-up
-rw-r--r-- 1 root root     6 Apr 19  2022 ifstate
-rw-r--r-- 1 root root     5 Apr 19 09:15 lighttpd.pid
-rw-r--r-- 1 root root  6320 Apr 19 09:17 log.nmbd
-rw-r--r-- 1 root root   139 Apr 19 09:16 log.smbd
-rw-r--r-- 1 root root 10495 Apr 19 09:16 modinit.log
drwxr-xr-x 2 root root    60 Apr 19 09:16 nmbd
-rw-r--r-- 1 root root     5 Apr 19 09:16 nmbd.pid
-rw-rw-rw- 1 root root   224 Apr 19 09:17 ntpclient.log
-rw------- 1 root root   314 Apr 19 09:16 portmap_mapping
-rw-rw-rw- 1 root root  8621 Apr 19 09:16 rag.log
-rw-rw-rw- 1 root root     0 Apr 19 09:16 rpc.statd.pid
-rw-rw-rw- 1 root root 14513 Apr 19 09:20 scanmounts.log
-rw-r--r-- 1 root root     5 Apr 19 09:16 smbd.pid
-rw-r--r-- 1 root root     0 Apr 19  2022 utmp
-rw-rw-rw- 1 root root   160 Apr 19 09:16 virtual-disk.log
-rw-r--r-- 1 root root     0 Apr 19 09:15 webif-error.log
-rw-r--r-- 1 root root    71 Apr 19 09:15 webif.log
-rw-r--r-- 1 root root  1369 Nov 16  2011 xinit.log
humax2324# ls -l /mod/tmp
total 920
-rw-rw-rw- 1 root root  66427 Apr 19 09:15 activity.log
-rw-rw-rw- 1 root root      0 Apr 12 11:11 auto.20220412111102.log
-rw-rw-rw- 1 root root 119311 Apr 19 09:19 auto.log
-rw-rw-rw- 1 root root 212733 Apr 18 22:13 chaseget.log
-rw-rw-rw- 1 root root     62 Nov 19 20:25 crash.log
-rw-rw-rw- 1 root root  65857 Apr 18 22:00 detectads.log
-rw-rw-rw- 1 root root  86843 Apr 19 07:46 empty_dustbin.log
-rw-r--r-- 1 root root  60913 Apr 18 23:27 nugget.log
-rw-rw-rw- 1 root root      0 Feb 24 09:45 qtube.log
-rw-rw-rw- 1 root root 128609 Apr  6 11:21 recmon.log
-rw-rw-rw- 1 root root 134397 Apr 19 09:15 rsvsync.log
drwxr-xr-x 2 root root   4096 Aug 26  2020 webif_auto
drwxr-xr-x 2 root root   4096 Apr 18 22:02 webif_autoq
-rw-rw-rw- 1 root root   1622 Apr 19 09:16 wlan.log
humax2324#
Code:
++++++++++++++ S00wlan - Tue Apr 19 08:15:55 UTC 2022 ++++++++++++++
Wireless interface: wlan0
== swifi
ssid=<redacted>
key=<redacted>
manual=1
auth=8
ip=192.168.2.24
mask=255.255.255.0
gw=192.168.2.1
dns=192.168.2.1
Set CountryRegion=31
Set AuthMode=WPA2PSK
Set EncrypType=AES
Set SSID=<redacted>
Set WPAPSK=<redacted>
Set SSID=<redacted>
== iwpriv show
wlan0     show:       Infra
wlan0     show:       WPA2PSK
wlan0     show:       AES
wlan0     show:   
wlan0     show:       PMK = <redacted>
wlan0     show:       <redacted>
Manual config:
+ eth_check
+ local eth=eth0
+ ifconfig eth0
+ grep -q RUNNING
+ echo No link found on eth0, disabling.
No link found on eth0, disabling.
+ ifconfig eth0 down
+ ip route flush dev eth0
+ /sbin/modinit setup_hosts
+ swifi ip
+ swifi mask
+ ifconfig wlan0 192.168.2.24 netmask 255.255.255.0 up
+ swifi gw
+ route add -net default gw 192.168.2.1
+ swifi dns
+ echo nameserver 192.168.2.1
+ isConnected wlan0
+ iwgetid --raw --ap wlan0
+ [ -n D8:7D:7F:BE:A2:D6 ]
+ type swifi
+ grep -qF function
+ save_settings
+ local conf
+ [ -w /mod/etc ]
+ swifi
+ conf=ssid=<redacted>
key=<redacted>
manual=1
auth=8
ip=192.168.2.24
mask=255.255.255.0
gw=192.168.2.1
dns=192.168.2.1
+ echo ssid=<redacted>
key=<redacted>
manual=1
auth=8
ip=192.168.2.24
mask=255.255.255.0
gw=192.168.2.1
dns=192.168.2.1
+ grep -cF =Failed:
+ [ 0 = 0 ]
+ echo # these settings are used if no settings are configured
+ echo ssid=<redacted>
key=<redacted>
manual=1
auth=8
ip=192.168.2.24
mask=255.255.255.0
gw=192.168.2.1
dns=192.168.2.1
 

Attachments

  • logs5 -standard boot - failed wireless.zip
    6.2 KB · Views: 1
Last edited:
Results for a normal boot with successful wireless connection

It has an Ethernet connection that is RUNNING (ie actually connected and exchanging frames).

This wifi-up script follows the OEM script in ignoring the Ethernet connection if it's connected (TBH I've never run it with a cable connected). The script in wireless-tools explicitly disables the Ethernet interface if the WiFi interface is available (and not in test mode).

The on-screen Network configuration UI seems to work like this:
  • if there's no WiFi dongle, it uses the Ethernet interface and the static network parameters go in the ETHERNET_CONF_1ST item in TBL_MENUCONFIG of setup.db; those parameters, or the result of the DHCP lease if DHCP is being used, are shown in and can be set by the 'Configure LAN' menu;
  • if WiFi is being used, the static network parameters go in the ETHERNET_CONF_2ND item; those parameters, or the result of the DHCP lease if DHCP is being used, are shown in and can be set by the menu now named 'Configure LAN(WiFi)'.

As setting IP addresses for both interfaces is not supported, having both interfaces active at once seems like an experimental configuration. A new line 194 might be in order:
Code:
 ifconfig "$wif" up
+ifconfig eth0 down
 # enable all allowed channels
Results for a Safe Mode boot with unsuccessful wireless connection (but it's normal for this to not work in safe mode)

Somewhat surprisingly, the new wifi-up script is run in this case. I assume that because it has the same pathname as the OEM script, it gets run by the settop program. Somehow the WiFi interface acquires the built-in default settings anyway.

Results for a Normal boot with unsuccessful wireless connection.

This looks like the previous case. Perhaps the settop program sees the active Ethernet interface and applies the default settings for WiFi.

It would be interesting to see what happens with the Ethernet cable unplugged (either end).
 
..
This looks like the previous case. Perhaps the settop program sees the active Ethernet interface and applies the default settings for WiFi.

It would be interesting to see what happens with the Ethernet cable unplugged (either end).
I can do that test - ie multiple reboot with the Ethernet disconnected/unplugged.
But you should know that I've had to connect something onto the end of it to try and retrieve logs etc. Without that connection I have no way of accessing the HDR when WiFi fails. If it fails in Maintenance Mode then I'll have no network nor monitor. Also some one time logs will be renewed on next reboot.
Before this new set of files, I have always had a cable attached to the Ethernet socket - but without anything powered/connected on the other end so that the HDR will not perceive it as an active connection. This has worked fine for over 20 months.

Edit1: I've tried multiple reboots (without Ethernet connection) - where it boots in normal mode, followed by maintenance mode, then repeat the cycle. Worked fine for 3-4 cycle, but now I have it in maintenance mode - no WiFi , no monitor (static picture on the TV). Can't access that particular HDR. Usually switching it off and on again will recover it, but at the expense of the one time logs.
Edit2: Let me try multiple normal reboots and report back later.
Edt3: Managed to recreate Maintenance Mode with unsuccessful wireless, logs attached.
 

Attachments

  • 20220419_185949.zip
    3.2 KB · Views: 1
Last edited:
  • Like
Reactions: /df
But that appeared to have been successful?
Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 wlan0
    Interface: [wlan0]
    IP: [192.168.2.24]
=== Tue Apr 19 18:59:38 UTC 2022 - complete ===========================
Code:
++++++++++++++ S00wlan - Tue Apr 19 18:59:26 UTC 2022 ++++++++++++++
Wireless interface: wlan0
Already connected to '<redacted>'
No link found on eth0, disabling.
Initially the Ethernet interface was enabled (UP) but not connected, while the WiFi was RUNNING at the default IP address 192.0.2.200 but finally it was set up at 192,168.2.24. Was it not accessible via ping or telnet?
 
Is there something useful I can provide if I connect Ethernet while in MM with WiFi failed to connect?

I am still curious about this working sometimes. So far as I can see it has to be that the dongle is ready on occasion and not on others, and yet the link always seems to establish when not in MM. Where lies the difference?
 
But that appeared to have been successful?
.....
Initially the Ethernet interface was enabled (UP) but not connected, while the WiFi was RUNNING at the default IP address 192.0.2.200 but finally it was set up at 192,168.2.24. Was it not accessible via ping or telnet?
I'm so sorry. I made a silly mistake during my tests. You're right in that wireless was working fine because that was the results of a normal boot. I wasn't able to capture the logs with failed wireless during maintenance mode.
I tried introducing a script in /mod/etc/init.d/S99 to capture logs but failed to realise it won't get called during maintenance mode (or safe mode - which I was aware of).
How should I execute a script for each maintenance mode boot?
 
Is there something useful I can provide if I connect Ethernet while in MM with WiFi failed to connect?

I am still curious about this working sometimes. So far as I can see it has to be that the dongle is ready on occasion and not on others, and yet the link always seems to establish when not in MM. Where lies the difference?
I'm trying to get the logs (but failing) wlan.log , modinit.log, xinit.log from an unsuccessful WiFi connection boot.
If you can do the same - maybe @/df will have more useful data to work with?
 
That was just me being annoyed at that time. Can we draw a line and move on?
I'll half-heartedly accept that very half-hearted apology, in the spirit of collaboration. Damage has been done. I willingly accept criticism where it is justified, but that was not.

Can you post these 2 logs so that someone can double check?
So you're not willing to accept when I say there's nothing useful in them? Okay...

Code:
[/var/lib/humaxtv/mod/xinit.d/ahw]
Micom Timestamp: 13 - Thu Jan  1 00:00:13 1970
Power cycle detected.
Boot: 4
[/var/lib/humaxtv/mod/xinit.d/dbupdate]
SQLite3: 3.7.5
[/var/lib/humaxtv/mod/xinit.d/install_dustbin]
[/var/lib/humaxtv/mod/xinit.d/install_fan]
[/var/lib/humaxtv/mod/xinit.d/install_ir3]
[/var/lib/humaxtv/mod/xinit.d/install_nugget]
[/var/lib/humaxtv/mod/xinit.d/opkg-beta]
[/var/lib/humaxtv/mod/xinit.d/rsvsync]
[/var/lib/humaxtv/mod/xinit.d/webshell]
[/var/lib/humaxtv/mod/xinit.d/wifi]
[/var/lib/humaxtv/mod/xinit.d/xdso]
Opening /var/lib/humaxtv/rsv.db
XDSO: Removed DSO scheduled events.
[/var/lib/humaxtv/mod/xinit.d/xota]
SQLite3: 3.7.5
Opening /var/lib/humaxtv/rsv.db
XOTA: Removing any auto-update scheduled events.
XOTA: Removed 0
Found 0 existing OTA reminders.
Reminder already set.

Code:
++++++++++++++ S00wlan - Mon Apr 18 16:13:34 UTC 2022 ++++++++++++++
Wireless interface: wlan0
Already connected to '##########'
No link found on eth0, disabling.
 
I'm trying to get the logs (but failing) wlan.log , modinit.log, xinit.log from an unsuccessful WiFi connection boot.
If you can do the same...
How? What's needed is to make them cumulative rather than starting from scratch each boot. Is there some code we can tweak so that the log output becomes a ">>" rather than a ">"?
 
I'll half-heartedly accept that very half-hearted apology, in the spirit of collaboration. Damage has been done. I willingly accept criticism where it is justified, but that was not.
I did not intentionally apologise.
So you're not willing to accept when I say there's nothing useful in them? Okay...
There may be a mis-understanding there.
I wanted to see the logs for myself to see what the differences were - in detail. The interpreted result of something like 'there is nothing useful there' is insufficient/too generic. Also it may help for someone like @/df to diagnose it. Eg your wlan log is useful because it differs significantly from mine posted earlier.
There is also a difference between our xinit.log - that may be because I manually copied by files incorrectly. So that would have been useful for me to know earlier.
How about the modinit.log?
 
Last edited:
Among things that may vary:
  • static vs DHCP
  • HDR vs HD
  • what network settings have historically been committed via the on-screen UI
  • WiFi dongle type

This executable file snaplogs in the xinit.d directory should save the previous logs if (a) the system is left up for more than 3 minutes (b) after rebooting the saved files in mod/tmp/prev are moved to a safe place within 3 minutes of the restart (obvs adjust the number of minutes to suit using the 60x table):
Code:
#!/bin/sh

LOGS="/mod/tmp/wlan.log /tmp/modinit.log /tmp/xinit.log"
PREV=/mod/tmp/prev
SNAPDELAY=180

(
    sleep "$SNAPDELAY"
    mkdir -p "$PREV"
    for f in $LOGS; do
        if [ -f "$f" ]; then
            cp  "$f" "$PREV"
        else
            rm -f "${PREV}/${f##*/}"
        fi
    done
) &
 
Took a while and multiple reboots. This time the wireless connection failed, (without Ethernet connection to the HDR).
This only fails on normal boot occasionally - eg 5-10%.
 

Attachments

  • logs7 -standard boot - failed wireless.zip
    3.3 KB · Views: 2
There's some difference in the way iwgetid is working.

The log says "already connected to <redacted>". That means that iwgetid --raw wlan0 is showing "<redacted>" as the SSID and iwgetid --raw --ap wlan0 is showing the MAC address of the AP (ie the wireless interface of the modem/router). In testing with my dongles the latter only happened when the SSID was connected -- how else could the MAC address be known? Unless wlan0 is not in Managed mode (see iwconfig wlan0) and is reporting its own MAC address?
 
There's some difference in the way iwgetid is working.

The log says "already connected to <redacted>". That means that iwgetid --raw wlan0 is showing "<redacted>" as the SSID and iwgetid --raw --ap wlan0 is showing the MAC address of the AP (ie the wireless interface of the modem/router). In testing with my dongles the latter only happened when the SSID was connected -- how else could the MAC address be known? Unless wlan0 is not in Managed mode (see iwconfig wlan0) and is reporting its own MAC address?
Unfortunately some of that goes over my head.
The only observations (during testing) I can offer are
originally my HDR using static IP for Eth and WiFi lost WiFI connectivity on occasions
your change in #11 https://hummy.tv/forum/threads/wifi...onally-incorrect-on-startup.9657/#post-139964 resolved that (or greater than 90% success rate)
the new files in #46 https://hummy.tv/forum/threads/wifi...ionally-incorrect-on-startup.9657/post-161532 seems to make it behave much like before the #11 change (even though I can see the #11 change in the wifi-up script).

It may be that I've made a mistake somewhere on this HDR, and I'll need to start from scratch with this box, ie reinstall everything which will take me a while.
 
Last edited:
I've tried many maintenance reboots since installing the log capture script, and so far failed to produce an instance of the connection failure mode. Surely a coincidence, but...
 
And another uncommanded HD Fox-T2 reset was overcome with the combination of this and the fixed auto-schedule-update (also tunefix, etc, etc) as usual:
  • Inst: go through the setup and retune palaver, after which the wifi is connected
  • Restart to trigger SChEd rEST
  • After restart, channels, favourites, schedule all OK, except custom favourite group names which seem to resist restoration.
 
Last edited:
Back
Top