• 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.

HDR LAN(Wi-Fi) Settings Mysteriously Corrupted

Black Hole said:
For the record, Edimax dongle:
Code: 
HDRFOX4# iwconfig wlan0                                                                       
wlan0     RT2870 Wireless  ESSID:"XXXXXXXXXXXXXXXX"  Nickname:"RT2870STA"                     
          Mode:Managed  Frequency=2.452 GHz  Access Point: 44:94:FC:E8:34:9A                   
          Bit Rate=54 Mb/s                                                                     
          RTS thr:off   Fragment thr:off                                                       
          Encryption key:XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX [2]                           
          Link Quality=100/100  Signal level:-57 dBm  Noise level:-83 dBm                     
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0                             
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
Click to expand...

And my unbranded dongle (after a reboot):
Code: 
HDRFOX4# iwconfig wlan0                                                                          
wlan0     RT2870 Wireless  ESSID:"XXXXXXXXXXXXXXXX"  Nickname:"RT2870STA"                        
          Mode:Managed  Frequency=2.452 GHz  Access Point: 44:94:FC:E8:34:9A                      
          Bit Rate=54 Mb/s                                                                        
          RTS thr:off   Fragment thr:off                                                          
          Encryption key:XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX [2]                              
          Link Quality=79/100  Signal level:-61 dBm  Noise level:-83 dBm                          
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0                                
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
Link Quality 79 might have something to do with the problem. What do you suppose 'Nickname:"RT2870STA"' means?

I expected the Access Point MAC to change.
 
Black Hole said:
I expected the Access Point MAC to change.
Click to expand...
Why? Presumably you are using the same access point - that's your Netgear router's Wireless interface MAC. The MAC address of the RT2870 will have changed, but that's not what is being displayed here.
If you want that, then you need ifconfig wlan0 or ip link or something like cat /sys/class/net/wlan0/address
 
prpr : Huawei :eek:
Click to expand...
Ah well it will give BH another reason not to like them :)
EDIT
Ah, that is the router not the dongle?, the router was supplied by Talktalk, I'm certainly no fan of Huawei (I worked for a company who were their rivals) , but I have to say if they are sending stuff back to China via 5G or my router it's about time someone came up with some evidence
 
Last edited:
The evaluation centre reported that Huawei's software development practices and quality management weren't adequate to ensure that their products could be trusted to do what and only what they were meant to do. So they could be hacked by any bad actor -- and were.

A state actor with stooges installed by law throughout the organisation might be particularly well placed to exploit a product defect, even if it hadn't actually ordered or covertly arranged the defect. No doubt there is some sort of Chinese version of the secret National Security Letter used in the USA to compel cooperation, except with the bonus possibility of a bullet in the back of the head for non-compliance.

A "bullet in the back of the head" approach to quality management would certainly concentrate minds as the auditors' visit looms.
 
Last edited:
The unbranded dongle is behaving itself at the moment.

I have an idea: periodically collect data into a log file (say every hour) which gives a timestamp, the current IP address, and the iwconfig lines. I think I know how to do that, just have to look up creating persistent scripts and cron entries...

Anything I need to know to make a cron job survive a reboot?
 
In case anybody else wants to have a go (all done through WebIF >> Diagnostics >> File Editor, which can create text files wherever you want (and edit existing ones... but be careful!) and has a button to give execute permission... other tools are available):-

Create file wlanmonitor in /mod/bin (updated to track further discussion below):
Code: 
#! /bin/sh
date >> /mod/tmp/wlanmonitor.log
ifconfig wlan0 >> /mod/tmp/wlanmonitor.log
iwconfig wlan0 >> /mod/tmp/wlanmonitor.log
dhcp=$(pgrep dhcp) && ps -l $dhcp >> /mod/tmp/wlanmonitor.log
swifi manual >> /mod/tmp/wlanmonitor.log
...and make it executable. Output is to a file /mod/tmp/wlanmonitor.log, and will be listed in WebIF Diagnostics with all the other log files. OK, it's not very elegant and more data gets dumped into the log file than is strictly necessary (but who knows – it might come in handy when debugging), but it gets the job done with minimum fuss.

For newbies: the lines in the script are exactly what could be used on the command line, prepended by a special comment line which tells the system what tool to use to execute the commands which follow - ie the standard command interpreter /bin/sh. Any other line starting "#" will be ignored and can be used to insert comments. ">>" simply sends the response to each command to the named file (instead of displayed on the console), adding to the existing contents or creating the file if it doesn't exist.

Add this line to file /mod/var/spool/cron/crontabs/root:
Code: 
15 * * * * /mod/bin/wlanmonitor
This makes wlanmonitor run on the 15th minute of each hour.

Now reboot (or restart the cron service).

For newbies: the lines in the existing crontab file "root" schedule various routine actions for the CF, according to what packages you have chosen to install, and can be added to (as here). In this case, the script file /mod/bin/wlanmonitor will be run just as if "wlanmonitor" were typed on the command line, on the recurring schedule "15 * * * *". The five parameters represent minute, hour, date, month, day, where "*" means "any". So each time the system time matches minute=15, wlanmonitor gets run (ie once an hour, at quarter past the hour). "Day" is the day of the week, and if not "*" should be read as "also" (by which I mean "on this date and month and also this day"). See here for full details.

The WebIF >> Diagnostics log file viewer displays log files in reverse order, ie newest lines first, so if using that to view the output one has to read each new multi-line log entry from the bottom up, which is a little awkward but is a small price to pay (and I will only need to do that once the IP address has changed and I am trying to find out why – the whole point of this exercise). I did say this isn't very elegant, but it doesn't need to be! Sometimes too much effort goes into making things pretty.

For search hits ('cos I'll never remember the details and have to look it all up next time): How to write/create a script/program which executes on a regular schedule using cron.
 
Last edited:
Oh yesh, a whole five lines!

FWIW, it is currently logging quality 100/100 and still on the right IP address.
 
Bloody thing's been performing flawlessly since installing logging. Sometimes the link quality is less than 100, but there have been no loss of IP address incidents.
 
Caught one! (Actually, I had two recent occurrences, but the first was when I was playing with it and might have caused it, and I sorted it out before my hourly logging would have noticed anyway.)

None jump from my manually-set 192.168.1.14 to the DHCP 192.168.1.107 (despite it remaining manual in Settings):

720AE2FE-CF0E-49A0-8516-D11349DF9709.jpeg (listing is in reverse time order)

...and I can't see any reason for it (not in the logged detail, anyway). Clearly something has triggered a spontaneous DHCP request. The signal reports look consistent, although that does not rule out a temporary glitch between logging points.

I can imagine I might have tried to access the WebIF about that time, but I'm not at all certain about that (I know I found it not responding on .14 that day, but it could have been later rather than coincident).

Nothing should have been going on at the time, and yet there seems to be traffic of about 10MB per hour. Anybody know what that's about? Seems high for WiFi "I'm here" signals.
 
Black Hole said:
Caught one! (Actually, I had two recent occurrences, but the first was when I was playing with it and might have caused it, and I sorted it out before my hourly logging would have noticed anyway.)

None jump from my manually-set 192.168.1.14 to the DHCP 192.168.1.107 (despite it remaining manual in Settings):
View attachment 4698 (listing is in reverse time order)
...and I can't see any reason for it (not in the logged detail, anyway). Clearly something has triggered a spontaneous DHCP request. The signal reports look consistent, although that does not rule out a temporary glitch between logging points.
...
Click to expand...
It could be interesting to know if the udhcpc daemon is running and what launched it. If procps is installed you can use this, maybe in the monitor script:
Code: 
dhcp=$(pgrep dhcp) && ps -l $dhcp
Otherwise a bit more gnarly, as the Busybox ps is a bit crippled:
Code: 
dhcp=$(ps -l) && dhcp=$(echo "$dhcp" | grep dhcp) && { ps -l | head -1; echo "$dhcp"; }
Nothing should have been going on at the time, and yet there seems to be traffic of about 10MB per hour. Anybody know what that's about? Seems high for WiFi "I'm here" signals.
Click to expand...
Presumably that's the LAN-level traffic, including anything that the WiFi driver might see, so broadcast frames as well as frames whose destination address is the device's MAC address.
 
Last edited:
/df said:
If procps is installed
Click to expand...
It is. Does this tell you anything, or does it have to be at the time of the event?:
Code: 
# dhcp=$(pgrep dhcp) && ps $dhcp                                                                               
  PID TTY      STAT   TIME COMMAND                                                                                     
 2386 ?        Ss     0:00 udhcpc -t 5 -T 10 -p /var/lib/humaxtv/udhcpc.wlan0.pid -i wlan0
 
My script now reads:
Code: 
#! /bin/sh
date >> /mod/tmp/wlanmonitor.log
ifconfig wlan0 >> /mod/tmp/wlanmonitor.log
iwconfig wlan0 >> /mod/tmp/wlanmonitor.log
dhcp=$(pgrep dhcp) && ps -l $dhcp >> /mod/tmp/wlanmonitor.log
 
Last edited:
More useful as part of the monitor script; also let's use ps -l $dhcp, as I meant to type.
 
Here ya go, it doesn't look like that tweak revealed anything useful (see below)

Code: 
4361    Sun Jun  7 00:15:01 BST 2020
4362    wlan0     Link encap:Ethernet  HWaddr [redacted]
4363              inet addr:192.168.1.14  Bcast:192.168.1.255  Mask:255.255.255.0
4364              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
4365              RX packets:7036054 errors:0 dropped:0 overruns:0 frame:0
4366              TX packets:1862327 errors:0 dropped:0 overruns:0 carrier:0
4367              collisions:0 txqueuelen:1000
4368              RX bytes:1638570105 (1.5 GiB)  TX bytes:162555133 (155.0 MiB)
4369
4370    wlan0     RT2870 Wireless  ESSID: [redacted]
4371              Mode:Managed  Frequency=2.452 GHz  Access Point: [redacted] 
4372              Bit Rate=54 Mb/s 
4373              RTS thr:off   Fragment thr:off
4374              Encryption key: [redacted] [2]
4375              Link Quality=100/100  Signal level:-57 dBm  Noise level:-83 dBm
4376              Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
4377              Tx excessive retries:0  Invalid misc:0   Missed beacon:0
4378
4379    F S UID PID  PPID C PRI NI ADDR SZ  WCHAN  TTY TIME CMD
4380    5 S 0   2386 1    0 75  0  -    446 select ?   0:00 udhcpc -t 5 -T 10 -p /var/lib/humaxtv/udhcpc.wlan0.pid -i wlan0

4381    Sun Jun  7 01:15:01 BST 2020
4382    wlan0     Link encap:Ethernet  HWaddr [redacted]
4383              inet addr:192.168.1.107  Bcast:192.168.1.255  Mask:255.255.255.0
4384              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
4385              RX packets:7079552 errors:0 dropped:0 overruns:0 frame:0
4386              TX packets:1866277 errors:0 dropped:0 overruns:0 carrier:0
4387              collisions:0 txqueuelen:1000
4388              RX bytes:1649624357 (1.5 GiB)  TX bytes:163165947 (155.6 MiB)
4389
4390    wlan0     RT2870 Wireless  ESSID: [redacted]
4391              Mode:Managed  Frequency=2.452 GHz  Access Point: [redacted] 
4392              Bit Rate=54 Mb/s 
4393              RTS thr:off   Fragment thr:off
4394              Encryption key: [redacted] [2]
4395              Link Quality=100/100  Signal level:-57 dBm  Noise level:-83 dBm
4396              Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
4397              Tx excessive retries:0  Invalid misc:0   Missed beacon:0
4398
4399    F S UID PID  PPID C PRI NI ADDR SZ  WCHAN  TTY TIME CMD
4400    5 S 0   2386 1    0 78  0  -    446 select ?   0:00 udhcpc -t 5 -T 10 -p /var/lib/humaxtv/udhcpc.wlan0.pid -i wlan0

Is the change from PRI = 75 to PRI = 78 significant?
 
Last edited:
The DHCP client is running, started by the init process (1).

Apparently the only way for that to happen is through /sbin/wifi-up or some jiggery-pokery (say, launching it from a fork that then exits) by the settop binary.

Clearly relevant is the value of swifi manual (0 - DHCP; 1 - static address), which could be added to the monitor script.

I don't believe the difference in scheduling priorities is significant.

If the DHCP client daemon is running and inactive, it should reactivate on receipt of a USR1 signal. Perhaps something is doing that?
 
You must log in or register to reply here.
Back
Top