Wifi - Static/Manual Gateway IP occasionally incorrect on startup

Generally bringing up Wi-Fi is done by the Humax software binary. In the core custom firmware, the /sbin/wifi-up script is only used when entering Maintenance mode to try and force the wifi connection up.

However, installing the wireless-helper package will run /sbin/wifi-up early on in boot because otherwise the wireless connection is not available in half-awake mode.

I suspect it is not that common for people to have both an Ethernet and Wi-fi connection on the same subnet.

The window is still open for changes to CFW 3.14 : )
 
af123 said:
I suspect it is not that common for people to have both an Ethernet and Wi-fi connection on the same subnet.
Click to expand...
How would they not be on the same subnet, assuming they're on the same home network?

Can we conclude the OP has the wireless-helper package installed, if tweaks to wifi-up are making a difference (edit: I see he does)? Maybe the tweaks are not making a difference and improvements are coincidental.)
 
Ezra Pound said:
I had assumed that the contents of the WebIF >> Settings >> Network Settings page was used at boot time in the same way as the boot-setting data, if not what is it for?
Click to expand...
It's a user-friendly alternative to the on-screen network configuration UI. They set the same fields AFAIK. Eg, if you initially have the box on wired LAN, you could copy and paste the WiFi password into the WebIf UI instead of the laborious clicky-clicky data entry with the on-screen UI. Sadly the settings do get wiped when the system decides to reset to defaults, and perhaps there could be an option to restore the last WiFi settings in that case.
 
Black Hole said:
How would they not be on the same subnet, assuming they're on the same home network?
Click to expand...
It's not the identity of the subnet that's unlikely, but the simultaneous connection.
Can we conclude the OP has the wireless-helper package installed, if tweaks to wifi-up are making a difference (edit: I see he does)? Maybe the tweaks are not making a difference and improvements are coincidental.)
Click to expand...
The log entries that were posted showed /sbin/wifi-up being invoked and the desired default route being trashed. New logs should show the desired default route surviving (after ifconfig eth0 down).
 
Recent logs after the small change. They look a little different and I think it works in various scenarios (not absolutely sure). WiFi settings after startup seems perfect so far.
Background info. I like to set up adjoining manual/static IPs for HDR ETH and Wifi. This is so that I can connect either port and have an expected IP.
Eg useful when moving HDR to another room to use temporarily as a media player, NAS.
I've edited/sanitised the logs a little

Also tried the sql thingy but have no idea what it means.
Code: 
HDR-Fox T2 1.03.12/3.13

humax2122# 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|1
ETHERNET_CONF_1ST_IP|1
ETHERNET_CONF_1ST_NETMASK|1
ETHERNET_CONF_1ST_GATEWAY|1
ETHERNET_CONF_1ST_DNS|1
WLAN_IS_CONNECTED|1
WLAN_CONNECTED_AP|0
ETHERNET_CONF_2ND|1
ETHERNET_CONF_2ND_IP|1
ETHERNET_CONF_2ND_NETMASK|1
ETHERNET_CONF_2ND_GATEWAY|1
ETHERNET_CONF_2ND_DNS|1
WLAN_AUTH_TYPE|8
sqlite>
 

Attachments

  • editted-logs2.zip
    15.9 KB · Views: 0
Last edited:
It looks good. Compared with the previous logs, the modinit logs don't show the WiFi coming up but the wlan logs do (except for the one where it had already connected).
 
/df said:
It looks good. Compared with the previous logs, the modinit logs don't show the WiFi coming up but the wlan logs do (except for the one where it had already connected).
Click to expand...
That's great. It looks like the change you suggested works for a range of start ups for my HDR.
I think that was the only issue I have with the USB WiFi dongle, it seems to work fine for me and is stable.
Thank you for the solution and follow up.
 
/df said:
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.
Click to expand...

Up till a year ago both HDRs were on WiFi and connected well.

Since then I have 2 HDRs one on WiFi and one plugged ethernet.

Problems, problems and poor WiFi in house, incidentally improved when HDR was powered off. That suggested to me wifi, or network, or network configuration conflicts.

Since using DFs solution this has seemed to help.

Note before when both boxes were on WiFi this was not a problem. But when one box on ethernet and WiFi it became a problem. I tried DFs solution on the HDR using WiFi and network is now stable.

I only used DFs suggestion on the HDR using WiFi dongle. I didn't use it on HDR using ethernet.
 
Black Hole said:
How would they not be on the same subnet, assuming they're on the same home network?

Can we conclude the OP has the wireless-helper package installed, if tweaks to wifi-up are making a difference (edit: I see he does)? Maybe the tweaks are not making a difference and improvements are coincidental.)
Click to expand...
I use the same subnet and one ethernet connected HDR and one HDR WiFi connected.

Sometimes connections between both boxes crashed the HDR, or the HDR froze.

Border said:
Up till a year ago both HDRs were on WiFi and connected well.

Since then I have 2 HDRs one on WiFi and one plugged ethernet.

Problems, problems and poor WiFi in house, incidentally improved when HDR was powered off. That suggested to me wifi, or network, or network configuration conflicts.

Since using DFs solution this has seemed to help.

Note before when both boxes were on WiFi this was not a problem. But when one box connected on ethernet and one on WiFi it became a problem. I tried DFs solution on the HDR using WiFi and network is now stable.

I only used DFs suggestion on the HDR using WiFi dongle. I didn't use it on HDR using ethernet.
Click to expand...
And this fix seems to improves connectivity between HDRS.

The WiFi HDR connects better and doesn't need resetting as often and the HDR ethernet hasn't crashed as often.

No recent crashing or freezing issues when interconnecting house boxes , though a little early days yet.
 
Last edited:
Just a small update. The change seems to have done the trick because my HDR wifi on start up is fine since the change. I no longer have the loss of the gateway IP that use to occur.

2nd update still fine with the update. Definitely fails sometimes without the update. When just the gateway IP is missing, local network access to the HDR is fine, but the HDR won't be able to access the internet etc.
So a way to check it is to
check the Menu/Settings/System/Internet setting/Configure LAN(Wi-Fi)/Gateway Address - it will show 0.0.0.0
or WebIF/Package Management/Check for updates - will return
!! ERROR - No network connectivity to package repository !!
Check your Internet connection and DNS service and then try again
167_2_00_Check_W2_SUB.png
Operation complete.
Close
 

Attachments

  • Screenshot from 2020-07-15 16-30-40.png
    Screenshot from 2020-07-15 16-30-40.png
    89.6 KB · Views: 4
Last edited:
Further update it still works. Please can we implement this change, as I have to apply it manually every time I update the CF for my HDR FOX T2.

I believe the change needs to be in /sbin/wifi-up, just move eth_check higher up by 3 lines.
/df kindly offered the solution in #11 https://hummy.tv/forum/threads/wifi...onally-incorrect-on-startup.9657/#post-139964

At the moment, I have to do the manual change as in last part of #20 every time I update the CF.
I found one way to test this is to use the Wifi in maintenance mode. It works with this change but doesn't without.
 
Last edited:
Still works very well.
It works most of the time for wireless ftp, smb, telnet, ssh, normal mode & maintenance mode.
It also doesn't affect a hardwired HDR connection.
However, one thing of note is the WebIF/Sysmon/Network Usage may show the wrong interface when I have both Ethernet and WiFi connected. The graph will only show one interface - the one that connected first during start up. So if I connect the other interface later on, WebIF/Sysmon/Network Usage will continue to show the initial interface. This is a very minor issue I can live with.
 
Last edited:
Black Hole said:
I take it this never got rolled into the official updates?
Click to expand...
I don't think it's been updated for a while (this is the result on the HDR with latest beta software)
Code: 
ls -l /sbin/wifi-up
-rwxr-xr-x 1 root root 1834 Feb  3  2015 /sbin/wifi-up
 
You must log in or register to reply here.
Back
Top