May contain traces of nut
That's cool, but doesn't explain why other WiFi users don't have the same problem.
/sbin/wifi-upscript is only used when entering Maintenance mode to try and force the wifi connection up.
wireless-helperpackage will run
/sbin/wifi-upearly on in boot because otherwise the wireless connection is not available in half-awake mode.
How would they not be on the same subnet, assuming they're on the same home network?I suspect it is not that common for people to have both an Ethernet and Wi-fi connection on the same subnet.
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.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?
It's not the identity of the subnet that's unlikely, but the simultaneous connection.How would they not be on the same subnet, assuming they're on the same home network?
The log entries that were posted showedCan 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.)
/sbin/wifi-upbeing invoked and the desired default route being trashed. New logs should show the desired default route surviving (after
ifconfig eth0 down).
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>
That's great. It looks like the change you suggested works for a range of start ups for my HDR.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).
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-upfinds wlan0 and disables eth0 which (I assume) isn't connected, but in the wrong order:
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 ...
routewas executed, the original default route was still in place, and the command failed "SIOCADDRT: File exists". Then
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-upran, so the code quoted above didn't run: instead it did this:
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.Code:
echo "Already connected to '$ssid'" eth_check exit 0
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.
/sbin/wifi-upis part of the CF image and can't be edited directly. Instead, for a test fix, copy it to
/mod/sbin/wifi-up-testand edit the copy to move the
eth_checkline 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/S00wlanand change the reference to
If this test fix can be verified it might be possible to get a modified
/sbin/wifi-upinto the forthcoming CF 3.14.
I use the same subnet and one ethernet connected HDR and one HDR WiFi connected.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.)
And this fix seems to improves connectivity between HDRS.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.