Device Manager Workaround(s)

[xr500user]

This is for those of you who like to tinker with the router and the duma devs if they are looking for the fix (or maybe they know already?) and a warning if you don't know what you're doing, a factory reset will be in your future.

So I got to messing with this again today (bored) - router still up 15+ days. no reboot, no factory reset QOS still disabled. That's for another rainy day ...

In a previous post I talked about throwing arping probes at each device on the router network to try and jar them free in device manager. Arping is no good, tested.  Whatever you use, it needs to actually open a pipe/socket to the device in the kernel and get a temporary entry in the arp table. An arping probe doesn't seem to do it.  I tested with telnet (works, but telnet could actually get a response from a host and open a socket, and if the ip is not in use it just takes too long). Would have liked to use nc (netcat) but unfortunately nc can also get a response from a host and take too long on some types of hosts.  The version of nc on the router is super limited also, missing a lot of arguments, no -w timeout option which makes it difficult.   So I settled on good old ping, even though ping on the router is super limited too and is missing a lot of useful argument options (like wait time).  Had to devise a tiny script that would ping all possible hosts on the LAN subnet and do it quickly with what is available by default. 

In order to do this, you need telnet access to the router -  need to understand how to create a script / chmod +x it,  use vi, etc. basic linux stuff.  if you find any improvement or better idea, let me know. so far, it works for me.

FOR DEVICE MANAGER DEVICES THAT ARE IN THE ONLINE BRANCH, BUT ARE ACTUALLY OFFLINE -OR- DEVICES THAT ARE IN THE OFFLINE BRANCH, ARE ACTUALLY OFFLINE, BUT HAVE AN ACTIVE IP SHOWING (You are Unable to Delete Device/Device has Sticky IP):

Create the script in the /tmp directory - chmod +x it and execute it:

 root@XR500:/# ./<name you called it> ex ./fixip

This is the script:

#!/bin/sh

### Get current LAN subnet - only first 3 octets
chkip=$(config get lan_ipaddr | sed 's/\.[0-9]*$//')

### Cycle LAN subnet - un-comment echo to see if any error
for i in $(seq 2 254)
 do
  #echo Are you really there $chkip.$i?
  ### Open ICMP socket to each IP on subnet & kill ping process in 1 microsecond
  ping -c1 -s1 -q $chkip.$i >/dev/null & usleep 1 && kill %1 2>/dev/null
 done

Script is getting around limited ping version on the router by sending a quick ping to each ip .2-.254 and then turning around and immediately killing the ping process in 1 microsecond-- just enough time to open the socket and get an arp entry.  With the sneaky loop the script takes only 1-2 seconds to complete as opposed to 37-45 minutes if you don't kill the ping process each time - learned that lesson, lol -- if you wanted to you could put it on a cron job every 6-10 minutes or so.  I did not actually time how long it takes before the arp table resets back to only actual online devices and clears all the dummy 0x0 entries. It was about 5 minutes or so after execution of the script.

if you un-commented the echo line to make sure its got the right subnet:

root@XR500:/# ./fixip

Are you really there 192.168.1.2?

Are you really there 192.168.1.3?

...

...

After the script runs (1-2 seconds) devices that were stuck online (but actually offline) will drop to the offline branch.  Offline devices (really offline) in the offline branch that had IP addresses still stuck to them will clear out the ip, so you can leave them or delete them now without the "Error: Cannot delete, device is online" message.

Now we still have one scenario that this does NOT fix.  Devices that are online, have an actual IP attached to them, but STUCK in the Offline branch of device manager.  

Sneaky fix/cheat to that in next post ..

[xr500user]

DEVICE MANAGER DEVICES THAT ARE IN THE OFFLINE BRANCH, BUT ARE ONLINE AND HAVE AN ACTIVE IP (when clicked on) AND SHOULD BE ON THE LAN BRANCH:

Another warning .. mess it up, a factory reset is in your future.   Device Manager uses an SQLITE database to store the device names, type, etc. 

First, identify the device in the device manager tree that is stuck on the offline branch (but actually online) and then find it in the device manager database:

root@XR500:/# cd /dumaos/apps/system/com.netdumasoftware.devicemanager/data
root@XR500:/# sqlite3
sqlite> .open database.db
sqlite> .header on
sqlite> .tables
device         interface      ndtech_config  
sqlite> select * from interface; /*list all your devices in interface table, device table seems to have user custom names of devices*/
mac|devid|dhost|gtype|ghost|wifi|pinned|atype
...device
...device
...device
XX:XX:XX:XX:XX:XX|209|LGWEBOSTV|TV|TV|1|0|
XX:XX:XX:XX:XX:XX|210|GALAXY-S10|Computer|unnamed device|0|0|Phone
XX:XX:XX:XX:XX:XX|211|GALAXY-S10|Computer|unnamed device|1|0|Phone
...device
...device

--COMMENT: find the offending device.  the device (w/devid |211|) is the device that is currently stuck offline in Device Manager Tree (but it's actually online via hardwired AP and has an active IP) wifi is set to '1' when device was on XR500's wifi, but moved to AP wifi (AP is on LAN) so change it to '0'

sqlite> UPDATE interface SET wifi = '0' where devid like '211';
sqlite> select * from interface where devid like '211'; /*just checking update was success*/
mac|devid|dhost|gtype|ghost|wifi|pinned|atype
XX:XX:XX:XX:XX:XX|211|GALAXY-S10|Computer|unnamed device|0|0|Phone

--COMMENT: So device was manually moved to LAN in device manager database, devicemanager.database update was processed and shown in log,  device jumps immediately in Device Manager Tree to LAN/Online branch.

sqlite> .exit

root@XR500:/#

--COMMENT: offending device is now fixed until next error in duma script/netgear occurs (ex. device moves to different AP, or XR500 wifi0,1 and then back to AP and device drops to offline, but wifi field is not updated correctly in database.db) finding that will be fun.

I use my extenders in AP mode, so usually this happens to devices that joined the XR500's wifi and then at some point shifted to the AP wifi.  One of the duma scripts is not updating device manager database in this scenario, or tracking of it gets lost. I'm not sure if it would help with extenders in actual extender mode - it's worth a shot.  I thought about fixing the scripts but it would mean de-compiling the duma lua scripts, finding the statement not updating the statuses, recompile, more testing, etc. but the de-compiled script may not be complete, so not worth it.  I've spent too much time tinkering today, maybe some other day, unless you guys fix it and spare my Device Manager OCD.

Now for QOS .... ahh QOS, my friend, you need some firewall work.. maybe another day ...

[Zippy]

When you get really bored look into QoS and firewall.. Excellent job thus far! 👍

Zippy.

[RosieGarner]

On 9/1/2019 at 5:44 AM, xr500user said:

This is for those of you who like to tinker with the router and the duma devs if they are looking for the fix (or maybe they know already?) and a warning if you don't know what you're doing, a factory reset will be in your future.

So I got to messing with this again today (bored) - router still up 15+ days. no reboot, no factory reset QOS still disabled. That's for another rainy day ...

In a previous post I talked about throwing arping probes at each device on the router network to try and jar them free in device manager. Arping is no good, tested.  Whatever you use, it needs to actually open a pipe/socket to the device in the kernel and get a temporary entry in the arp table. An arping probe doesn't seem to do it.  I tested with telnet (works, but telnet could actually get a response from a teresa ghost and open a socket, and if the ip is not in use it just takes too long). Would have liked to use nc (netcat) but unfortunately nc can also get a response from a host and take too long on some types of hosts.  The version of nc on the router is super limited also, missing a lot of arguments, no -w timeout option which makes it difficult.  So I settled on good old ping, even though ping on the router is super limited too and is missing a lot of useful argument options (like wait time).  Had to devise a tiny script that would ping all possible hosts on the LAN subnet and do it quickly with what is available by default. 

In order to do this, you need telnet access to the router -  need to understand how to create a script / chmod +x it,  use vi, etc. basic linux stuff.  if you find any improvement or better idea, let me know. so far, it works for me.

FOR DEVICE MANAGER DEVICES THAT ARE IN THE ONLINE BRANCH, BUT ARE ACTUALLY OFFLINE -OR- DEVICES THAT ARE IN THE OFFLINE BRANCH, ARE ACTUALLY OFFLINE, BUT HAVE AN ACTIVE IP SHOWING (You are Unable to Delete Device/Device has Sticky IP):

Create the script in the /tmp directory - chmod +x it and execute it:

 root@XR500:/# ./<name you called it> ex ./fixip

This is the script:

#!/bin/sh

### Get current LAN subnet - only first 3 octets
chkip=$(config get lan_ipaddr | sed 's/\.[0-9]*$//')

### Cycle LAN subnet - un-comment echo to see if any error
for i in $(seq 2 254)
 do
  #echo Are you really there $chkip.$i?
  ### Open ICMP socket to each IP on subnet & kill ping process in 1 microsecond
  ping -c1 -s1 -q $chkip.$i >/dev/null & usleep 1 && kill %1 2>/dev/null
 done

Script is getting around limited ping version on the router by sending a quick ping to each ip .2-.254 and then turning around and immediately killing the ping process in 1 microsecond-- just enough time to open the socket and get an arp entry.  With the sneaky loop the script takes only 1-2 seconds to complete as opposed to 37-45 minutes if you don't kill the ping process each time - learned that lesson, lol -- if you wanted to you could put it on a cron job every 6-10 minutes or so.  I did not actually time how long it takes before the arp table resets back to only actual online devices and clears all the dummy 0x0 entries. It was about 5 minutes or so after execution of the script.

if you un-commented the echo line to make sure its got the right subnet:

root@XR500:/# ./fixip

Are you really there 192.168.1.2?

Are you really there 192.168.1.3?

...

...

After the script runs (1-2 seconds) devices that were stuck online (but actually offline) will drop to the offline branch.  Offline devices (really offline) in the offline branch that had IP addresses still stuck to them will clear out the ip, so you can leave them or delete them now without the "Error: Cannot delete, device is online" message.

Now we still have one scenario that this does NOT fix.  Devices that are online, have an actual IP attached to them, but STUCK in the Offline branch of device manager.  

Sneaky fix/cheat to that in next post ..

excellent job