• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Wifi - Static/Manual Gateway IP occasionally incorrect on startup

bottletop

Active Member
I use a clone RT3070 USB WiFi adapter (black shell, bright blue flashing LED) on 50cm extension cable with my HDR FOX T2.
pic6.png
The issue is that it doesn't always start up with full internet connectivity.

As far as I can tell, the issue is with the Gateway IP is set back to 0.0.0.0 for some reason. All other settings are fine. So basically it sometimes forgets the the Gateway IP but remembers all the rest.
I can't see a pattern to it. It seems to do this 10-20% of the time I start the box, regardless of type of start (eg scheduled timer or remote control).
The way I can correct it is to use manually enter ip using Menu/Settings/System/Internet Setting/Configue LAN(Wi-Fi)/Gateway Address

I use Manual/Static IP, the router uses a fixed channel.
I use up to date CFW and CFW/Network Settings are static & correct, because if I reboot without changing anything, it may connect ok on next reboot.
Nothing is connected to the ethernet port.

I've had a look at this and don't think this applies.

In Linux terms, it appears to me as though the default route is not set correctly on the HDR. But I don't know what to do or diagnose further.
I attach some modinit and wlan logs from the box when it failed to connect properly 22a- & 22b-. Also 22c- for comparison when it connected ok.
In the modinit logs, I think the 'Kernel IP routing table' entries are significant but not sure what to do next.
I guess it may be a timing issue with the starting WiFi processing.

I use these packages for WiFi
wireless-helper
wireless-tools
wpa-supplicant

edit1 added packages I use and changed title from 'Intermittant WiFi connectivity' to 'Wifi - Static/Manual Gateway IP occasionally incorrect on startup'
edit2 added image of the dongle
 

Attachments

Last edited:
So why don't you use 'Manual' IP setting permanently?
I do! It's just that when this hiccup occurs, I have to re-enter only 1 of the manual IP - for the Gateway IP.
It retains the other manual IPs fine (so the other manual entries - IP Address, Netmask, DNS Address are kept)
 
What setting do you have in :- Webif >> Settings >> Network Settings >> Wireless Interface ?

wifi-settings.jpg
 
Last edited:
I had connection problems which went away when I changed the dongle, but haven't come back when I swapped the dongle again. Make of that what you will, but I think it has to do with WiFi signal strength.
 
Ah OK, As you posted in the Custom Firmware section I'm assuming you have that installed, what setting do you have in :- Webif >> Settings >> Network Settings >> Wireless Interface ?



Sure. I have both manually set. This is so that if I plug an ethernet cable it will also work.
My settings.

humax-network-settings.png
 
I had connection problems which went away when I changed the dongle, but haven't come back when I swapped the dongle again. Make of that what you will, but I think it has to do with WiFi signal strength.
i have a feeling that is correct, try sourcing the "corect" wifi dongle which i think a search on here may reveal, mine is the white one with rotating antenna.
 
I had connection problems which went away when I changed the dongle, but haven't come back when I swapped the dongle again. Make of that what you will, but I think it has to do with WiFi signal strength.

That's a good point. I may try testing that by extending the usb WiFi dongle so that it has unhindered line of sight to the router to minimise signal loss
 
Both ours can be reluctant to start when the box comes out of standby.
Using 'Static' on the box seems to just lose the IP every so often which is a pain.

I have the best results for me by leaving the boxes in DHCP and setting the router to apply a fixed IP.
If the WiFi fails to connect then 'all' that's needed is to go into the settings on the box and hit the network 'Apply' button. It always seems to retain the IP, password, etc., so this is much easier than having to re-enter the address.
 
Looking at the logs originally posted, it appears that the system has a static setting for eth0 using the same subnet details as the WiFi, with a default route via .1. The script /sbin/wifi-up finds wlan0 and disables eth0 which (I assume) isn't connected, but in the wrong order:
Code:
if [ "`swifi manual`" = 1  ]; then                                        
        echo "Manual config:"                                             
        set -x                                                            
        ifconfig $wif "`swifi ip`" netmask "`swifi mask`" up              
        route add -net default gw "`swifi gw`"                            
        echo "nameserver `swifi dns`" > /etc/resolv.conf                  
        eth_check                                                         
else                                                                      
...
When route was executed, the original default route was still in place, and the command failed "SIOCADDRT: File exists". Then eth_check ran, calling ifconfig eth0 down. According to the logs this had the effect of deleting the default route for the subnet, even though the system had another active interface connected to the same subnet. I use DHCP so had never seen this problem.

The log where the WiFi worked shows that it was already up before the script /sbin/wifi-up ran, so the code quoted above didn't run: instead it did this:
Code:
        echo "Already connected to '$ssid'"             
        eth_check                                            
        exit 0
In this case eth0 was disabled but it wasn't on the same subnet (the built-in default 192.0.2/24 instead of 192.168.2/24) and the default route wasn't affected.

If the WiFi is configured by DHCP, this failure mode isn't possible, because the DHCP configuration is run after disabling a disconnected eth0.

If your router allows, you may find that setting the static configuration in the router and serving it via DHCP solves the problem (though perhaps brings back whatever originally led to the manual settings). Otherwise it should be possible to fix the static configuration.

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.

If this test fix can be verified it might be possible to get a modified /sbin/wifi-up into the forthcoming CF 3.14.
 
Does this mean WiFi connection issues could be down to CF code? I'm not clear why CF is fiddling with that, except through wireless-helper (which I don't have installed), although I guess it's the WebIF "restore network configuration" (my quotes) settings doing it.

However, that said, I have had no further incidents with this sort of thing since I raised it in Jan/Feb.

https://hummy.tv/forum/threads/hdr-lan-wi-fi-settings-mysteriously-corrupted.9511/
 
Where is the networking configuration stored? It doesn't appear to be in the setup database so we can't take advantage of the Boot settings package to restore lost settings,

My humax has a wired connection to the router (so not directly applicable to this thread) and I usually address it by host name, humax, rather than by numerical ip address (192...). This has been working well for years but a couple of times recently it has lost the host name access after it working for hours without problem, the humax continues to operate normally and I can still access it via webif and telnet but only using the numerical address. Normal service is resumed at reboot.
Very strange! :eek:
 
Thank you /df for the detailed reply. I will read it slowly and perform the changes you suggest. It may take a while before I can see if it works because the fault only shows up on start up and even then only some times.

For info my stupid router doesn't have the ability to reserve static/manual IPs for given MAC addresses! However if I did have that facility, it means the IP will be assigned by the router for the particular USB WiFi device, which isn't what I want (eg what if I move the USB dongle to another device etc?)
 
Last edited:
networking configuration stored?
WebIF >> Settings >> Network Settings

The ability to configure WiFi passwords via WebIF is a boon (the SUI doesn't allow all possible characters to be entered, and times out on you when trying to enter a long password).
 
WebIF >> Settings >> Network Settings

The ability to configure WiFi passwords via WebIF is a boon (the SUI doesn't allow all possible characters to be entered, and times out on you when trying to enter a long password).
That's where it is being displayed not the underlying storage location.

If I was sufficiently interested I could start reading the code but I was a bit surprised that it isn't in the the setup.db along with the other SUI configuration data
 
Does this mean WiFi connection issues could be down to CF code? I'm not clear why CF is fiddling with that, except through wireless-helper (which I don't have installed), although I guess it's the WebIF "restore network configuration" (my quotes) settings doing it.
...
Well, yes. Prompted by this question I checked the contents of the official HDR 1.03.12 firmware and the Humax binaries: it was unobvious how the WiFi gets started; I assume it's built into the Humax blob. The standard and custom firmwares both have the Debian script /etc/network/if-pre-up.d/wireless-tools which would set the WiFi parameters from environment variables (eg IF_WIRELESS_ESSID) when the interface is brought up, but I can't see any sign of this being used.

You would have to go back to the origin of the CF, before my Hummy time, to understand what problems are being fixed by the way it handles WiFi startup. One possible feature is that it might allow both interfaces to be used at once.

Incidentally the standard 1.03.02 HD-Fox T2 firmware which is no longer linked from the Humax site made its way to the Internet Archive.

Where is the networking configuration stored? It doesn't appear to be in the setup database so we can't take advantage of the Boot settings package to restore lost settings, ...
It is but not necessarily in a form accessible to boot-settings:
Code:
humax# sqlite3 /var/lib/humaxtv/setup.db
SQLite version 3.27.2 2019-02-25 16:06:06
Enter ".help" for usage hints.
sqlite> select ItemName, ItemValue from TBL_MENUCONFIG where ItemName like 'WLAN%' or ItemName like 'ETHER%';
WLAN_IS_CONNECTED|1
WLAN_CONNECTED_AP|0
WLAN_AUTH_TYPE|1
ETHERNET_CONF_1ST|0
ETHERNET_CONF_2ND|0
sqlite>
I'm not sure about the Ethernet settings but WLAN_CONNECTED_AP is a binary blob whose format was successfully investigated in some ancient thread here. The program /mod/bin/swifi can be used to decode it. This is a Jim version of it, which I think worked when I tried it:
Code:
#!/mod/bin/jimsh

package require sqlite3
package require pack

if {$argc == 0 } {
        set argv "ssid key manual auth ip mask gw dns"
} 

proc getvar {field {type itemBlob}} {
        global db
        set r [$db query "
                select $type from TBL_MENUCONFIG
                where itemName = '%s'
                " $field]
        if {![llength $r]} { return "" }
        return [lindex [lindex $r 0] 1]
}

proc getip {field} {
        set ip [format {%8x} [unpack [getvar $field] -uintbe 0 32]]
        if {[scan $ip "%2x%2x%2x%2x" oct1 oct2 oct3 oct4] != 4} { return "" }
        return "$oct1.$oct2.$oct3.$oct4"
}

if {[catch {set db [sqlite3.open /var/lib/humaxtv/setup.db]} msg]} {
        puts "ERROR: $msg"
        exit
}

foreach parm $argv {
        switch $parm {
                ssid -
                key {
                        set ap [getvar WLAN_CONNECTED_AP]
                        break
                        }
        }
}

foreach parm $argv {
        if {$argc == 0 } {
                puts -nonewline "$parm="
        } 
        switch $parm {
                ssid {puts [string trim [string range $ap 0 20]]}
                key {puts [string trim [string range $ap 120 239]]}
                auth {puts [getvar WLAN_AUTH_TYPE itemValue]}
                static {puts [getvar ETHERNET_CONF_2ND itemValue]}
                ip {puts [getip ETHERNET_CONF_2ND_IP]}
                mask {puts [getip ETHERNET_CONF_2ND_NETMASK]}
                gw {puts [getip ETHERNET_CONF_2ND_GATEWAY]}
                dns {puts [getip ETHERNET_CONF_2ND_DNS]}
        }
}

$db close
 
Last edited:
WLAN_IS_CONNECTED|1 WLAN_CONNECTED_AP|0 WLAN_AUTH_TYPE|1 ETHERNET_CONF_1ST|0 ETHERNET_CONF_2ND|0
interesting the only ethernet field i have in setup.db is
Code:
sqlite3 /var/lib/humaxtv/setup.db
SQLite version 3.27.2 2019-02-25 16:06:06
Enter ".help" for usage hints.
sqlite> select ItemName, ItemValue from TBL_MENUCONFIG where ItemName like 'WLAN%' or ItemName like 'ETHER%';
ETHERNET_CONF_1ST|0
sqlite>
which I suppose is enough to say use DHCP, other settings are only added to the database when needed and some of those are encoded within the blob which makes it incompatible with the current boot-settings package which can only deal wih simple numeric/text values
 
Just to confirm tests so far shows that the changes works fine for my HDR, no detrimental effect.

It works fine (as expected) when I have:
USB WiFI dongle plugged in & Ethernet unplugged;
USB WiFI dongle & Ethernet both plugged in (ethernet takes precedence);
USB WiFI dongle unplugged in & Ethernet plugged in (still works if further in I unplug Ethernet then plug in USB WiFi while switched on - perfect!)

I have rebooted on several occasions,so far so good - WiFi connects properly on startup and has access to the internet (via manual Gateway IP).
I will need to try more reboots in the coming weeks just to make sure.
I am extremely grateful to all and will monitor the connection during startup to check that it behaves itself.

Just as an aside, before /df's solution, I was going to bodge it by adding the following to /mod/etc/anacrontab
Code:
1 1 a_net_restart /etc/init.d/S40networking  restart


To recap, the changes I made to implement this TEST FIX proposed by /df in post #11
New file - /mod/sbin/wifi-up-test
(copied file /sbin/wifi-up - with change: moving up 'eth_check')
Rich (BB code):
if [ "`swifi manual`" = 1  ]; then
    echo "Manual config:"
    set -x
    eth_check
    ifconfig $wif "`swifi ip`" netmask "`swifi mask`" up
    route add -net default gw "`swifi gw`"
    echo "nameserver `swifi dns`" > /etc/resolv.conf
else
    ....

Make new file executable
Rich (BB code):
chmod a+x /mod/sbin/wifi-up-test

Modify file - /mod/etc/init.d/S00wlan
(to call the new file instead of the original one)
Rich (BB code):
...
    if [ "`cat /etc/modversion`" -lt 302 ]; then
        /mod/sbin/wifi-up
    else
#      /sbin/wifi-up
#                                <replaced with the line below>
       /mod/sbin/wifi-up-test
    fi
) &

exit 0

For anyone who can update WebIF code, the above TEST FIX can be done by
- please change /sbin/wifi-up - move up 'eth_check' by 3 or 4 lines similar to /mod/sbin/wifi-up-test above
 
Last edited:
Back
Top