xr500user

i also have auto update off and this issue hit me as well, just noticed today that error message on the admin interface, lol. i think another option is necessary to block ALL cloud updates if you don't want them - it is a security risk if this cloud server gets compromised. imagine what may be injected into all xr routers if an overflow is found?? dangerous and very concerning. anyway, it took me a few minutes to figure out how to fix it without a reboot. you know me, JUST SAY NO TO FACTORY RESET AND REBOOTS! luckily, http://192.168.1.1/debug.htm still worked. was able to enable telnet... root@XR500:/# /rom/etc/init.d/./dumaos stop root@XR500:/# /rom/etc/init.d/./dumaos start go back to http://192.168.1.1/debug.htm and disable telnet all back up and running ... no reboot, no factory reset i hope this next update fixes all the problems w/qos and device manager

the /tmp dir gets overwritten/recreated on restart, so any changes in there you have to make again after a reboot. not sure if /etc will do the same ... i'm using the router as DNS w/google dns servers and this is what they contain: /etc/dnsmasq.conf: # filter what we send upstream domain-needed bogus-priv localise-queries no-negcache cache-size=0 no-hosts try-all-ns /tmp/resolv.conf: nameserver 8.8.8.8 nameserver 8.8.4.4 ---> you could try to recreate those 2 files and use your local nameservers in resolv.conf, if it doesn't work, just reboot and reset to what they were before changes.. (if they don't automatically do that) worst case, factory reset to restore everything

Out of curiosity try disabling QoS, see if the ssh's hold then, may be connected to firewall/qos dropping return-pipe connections (net2loc)? If it's going to drop, usually it's within 20-30 seconds - weird issue with marked pipes and since ssh are encrypted (can't read the header) could be adding to it ... returning connection from internet unknown/dropped.

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

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

i have a similar setup as well, but my 2 ex8000s are hardwired and in AP mode. my setup is like this from the XR500: xr port 1 --> switch1 --> ex8000(1) and xr port 2-->switch2-->ex8000(2) ---- one/same wifi name throughout (2.4 and 5) --- the extenders won't connect to each other this way, but you can end up with some sticky clients; for example you come home and your phone jumps on the XR500 wifi and then a little while later you are in the bedroom and it doesn't jump quickly and still hanging on to the xr wifi - eventually in time it will jump to the stronger ssid signal by itself (which drives device manager crazy) but it still works. you could just toggle wifi off/on on the wireless client (phone, laptop) and it will connect to the stronger AP. the reason why i have it like this is the ex8000s are tri-band but when not in AP mode one 5ghz band is reserved for the backhaul to the XR/router (THE BETTER ONE). You lose that 5ghz band/bandwidth. in AP wired mode the ex8000s 2.4, and BOTH 5Ghz bands are available to wireless clients as the ethernet cable is the backhaul. both switches used are managed and i only prioritize the uplink port to the xr on both switches at this time. it's not good practice to prioritize more than 1 or 2 switch ports as it starts to work against you. at a maximum maybe the uplink and a console connected to the same switch is more than enough. smart connect is enabled on the xr500 and both ex8000s (same wifi name) -- i tried this many different ways, with SC on, with it off, separate band names, etc. but i decided to leave it on and with same ssid -- because it does work most of the time, and it's easier then having 10 different wifis all over the place. the only negative from smart connect is that if you connect to the 5ghz band with the highest throughput sometimes after a while (could be a day, could be 2 days, sometimes never) smart connect will see you aren't using all that bandwidth and shift you over to the 2.4ghz band to save bandwidth for other clients. if this happens you just toggle wifi off/on and you connect back to the higher speed band. i noticed this once and a while as my laptop speed test would only be 65-95Mbps , but then toggling wifi and reconnecting-its back up to 550/600+ Mbps over the ex8000 5ghz wireless connection. if you can't run wires to the extenders, then make sure the xr500 is in the middle between both extenders (like a triangle) and you can do what Newfie suggested -- create a 5ghz guest network on the xr500 and name it 'backhaul' so your wireless clients won't know the password or connect to that ssid, but the ex8000s will. be sure to allow this guest network access to your local network (tick the box) and re-setup the ex8000s to connect to 'backhaul' ssid for internet. i have never tried this setup and my guess is it may open a whole new can of worms as now not only do you have to deal with the qos routing issues and other problems of the xr, but now throw a guest network -> local network into the mix which may make it even worse. plus i'm not 100% sure if the guest network steals bandwidth from the main xr500 5ghz radio or if its a slower speed radio then the main 5ghz (have to check that). you could also make sure you follow a proper reboot cycle, make sure the xr boots first with both extenders powered down, and then after xr is fully booted and up - then turn on the extenders one at a time (let the first one fully boot and come up before turning on the 2nd). verify in each extenders admin "connected devices" that they aren't connected to each other. you can also lock down the backhaul wifi channel to the xr so its the same as the xr radio so it doesn't look to the other extender transmit channel if you want to take advantage of the one wifi name. in theory they should NOT ever connect to each other as they identify themselves with a "-R" device name - so one extender should not accept a backhaul connection from another one with a -R as the device name. they should use ip 192.168.1.250 to hijack/be aware of each other but again, the firmwares have to be aware and actually work -- ex8000 has bugs too, xr500 has bugs, lol. this might cause a problem if guest network is used as i think it may use a different ip range then the xr too, might not be able to pull up the extender admin page which lists multiple connected extenders when using guest - never tested it, so have no idea. that's why i just settled on using them as wired APs , seems to be the least problems. netgear really needs to gear more towards ap/extender communication in their respective firmwares so they can automatically inform clients to move if needed, but i doubt we will see this soon (but one can hope) as many standards need to be followed and enforced (not only on the router and the extenders, but also the clients) and there's no settings in the router that i see to limit rssi connections to a certain level or lowest connect speed (Mbps) allowed on one band before kicking the client in the admin setups of the xr or the extenders -- it's just not that advanced - although they are both very well capable of doing this - if they spent the time...

yeah, it's a good router with qos off for me - it's doing what a router does and it stays up - and routes, so I really don't think it's the kernel, but something is not working as well as it should when qos is enabled. it could very well be effecting other modules because i don't use geofilter or any of that for quite a while. i spent a lot of time trying to track it down in .40, watching conntrack and opening connections to see what its doing - certain apps/services that open connections that get closed with qos on work just fine with the qos off. It still tries to use the marks its made but it (NOP) them so no operation. They are ignored. I really like the analytic of qos with the breakdowns of what the traffic is - gaming, web, social media, etc. but I can't use it :( I don't really need qos or the bandwidth shaping because my connection is fast but without it I lose that analytic functionality. as for apps or services that are effected by this.. it works like this.. application goes out to an internet server somewhere, so a connection is marked and tracked in the kernel, source destination, etc..(nat /netfilter) so when traffic comes back into local network its marked as allowed (firewall) and knows the proper destination (internal ip). each connection gets its own entry (there are hundreds being created all the time and closed as they are no longer needed more so the larger your network is) and each connection has a countdown timer of life 5, 15 minutes, 30 minutes, even less.. whatever. but when qos is on some information gets lost, or incorrectly added/marked so the kernel is thinking "what is this ACK from loc2net or net2loc" and it may close it in a cleanup/housekeeping or try to close it because it thinks its a security issue like an unauthorized incoming connection from the outside world to the internal network. some devices like business vpn cause this, maybe some games,don't know .. some of those iot devices that need to reach out to aws and have a connection come back from aws, etc. i see the connections opened, they appear marked correctly, but then its like one direction either net2loc to loc2net (loc=local network, net=internet) it does not identify one as an allowable connection and it just chops it when qos is on... causing things to not maintain an active connection (one sided, internet server no longer hears an ACK from the internal device). hard to explain .. i am no conntrack guru but i know what its doing and i can see which connection should be allowed, but no idea why it is deemed done/finished (to be closed), or security risk (chopped).. but whatever qos is doing or some other module is making the kernel just think its not a kosher connection, then click. vpn will disconnect, remote desktop over vpn will disconnect, loss of connection to outgoing server, etc. (security camera may not work, or claim its not reachable from the internet, etc) it's a certain type of back and forth _SYN,ACK that picks up some misleading data via qos. i get the feeling that some netgear tracking, or netgear legacy kernal code may still be running somewhere and when qos is activated it just doesn't gel well. i'm not so sure they can replicate it, so it may never be squashed? as for the device manager thing, not really sure if that's a netgear issue or duma issue, or maybe when they combine it comes out. I do know then if you try to telnet to an ip that is listed on device manager that is shown as online (and it is offline) you will get a No route to host error (from the router shell), and then it will drop off the online list (ip will appear in arp table as 0x0). some devices that are offline (if you click them) will show an ip address attached to them.. and they may be actually online (but sometimes they could be offline, but the ip is sticking in device manager) a telnet will clear the ip after a few seconds then you can delete the device (like in a situation where it says 'error: cannot delete device, because it is online' -- but the device is NOT online) right after you get the No route to host, its clear and can be deleted from device manager. i know a reboot fixes these things, but in time they return -- besides you know i am a no reboot guy.. i've had routers up for years in some cases, and still performing like champs maybe have some special script running on the router that sends ARPING (use --settings to limit to 1 second wait time, exit after 1 reply) to each ip .2-.254 so in 254 seconds or so device manager will clear itself (at least more then it does right now, but probably not 100%). only suggesting arping because its quick to come back if there is no response.. telnet sometimes takes 3-4 seconds before it reports No route to host. maybe there's something better to use? some custom script or small app needs to be written if bug can't be found - but its a really crappy workaround, need to figure out what is causing it. duma has many scripts running to watch devices with many different methods that run every X seconds (arpwatch, ipneigh, wlan stainfo whatever) but for some reason one of the tables isn't being updated properly - when the kernel itself actually tries to reach out to that ip then it knows No route to host. . when devices shift from the internal router wifi (ath0,1) to an AP wifi (wired AP) (with the same name) it will move from the 2.4ghz or 5ghz tree into the offline section (but its still online) and lan/wan qos update has been applied - sometimes it moves to the LAN/online (like it should) but then sometimes it decides to go to the offline branch (even tho its online) no rhyme or reason. device manager also doesn't like SSID's with a '\' in them. give that a try it willl turn it into \\\ in device manager, but netgear setup does not. that probably has to do with their whole config get and config set database implementation, i went through all that and saw that its limited in storage length for fields, so they had to spread out a ton of device settings over many entries, ugg. i know if a dev reads this they will know what i mean. ps. netgear stores the SSID with a \ in one config setting and with \\\ in another -- its a easy fix but low priority I guess, just change which setting field its pulling SSID name to the correct one in device manager script. probably some weird fix they did to make it show right, or a patch in the www html unfortunately a lot of the netgear base code original creators are no longer available to comment and the firmware has been shipped off to be updated in taiwan as i understand it -- they are good but i don't think they are making any major fixes or any kind of deep down work like this -- just bandaid and move on. it's the same base code on all of the routers it seems, theres orbi stuff on the xr, etc. i wonder if the new AX are also using it? probably. it's hard to maintain so many routers i know but they are all using some version of this base hodgepodge and tweaking it for each new hardware. i thought all the time they were taking (8) months they were really re-doing it all from the bottom up, but it wasn't the case - its late and im rambling, hope you guys figure it out. or a workaround ..and after you do, let me know as i'm interested in what it turned out to be...

just a little update - had some time to go back and mess with it. little over 5 days uptime .. qos must be off for me as it effects certain net functionality in a negative way. this is unfortunate because the only thing I like about the qos is the analytics of traffic. it just does not mark certain contracked connections properly and the os closes them prematurely. they conflict with the firewall net2loc loc2net..usually as soon as it sees traffic or within 30 seconds. when qos is not running this does not occur. i'm not running all games but i'm sure certain game connections may also get marked wrong and then get the chop from the firewall. got upnp working.. just had to hit Apply on the empty UPNP screen and it resets the listing file (if frozen in time): just so you can see this was the file before the apply: -rw-r----- 1 root root 0 Dec 31 1969 upnp_pmlist and after: -rw-r----- 1 root root 0 Aug 21 19:35 upnp_pmlist and to prove it's working now: log-message:454457:miniupnpd[4288]: received signal 15, good-bye //miniupnp close log-message:454460:miniupnpd[17447]: listening on xxx.xxx.xxx.xxx:5555 //miniupnp back up and it is working (forced a upnp request): log-message:454776:miniupnpd[17447]: [UPnP set event: add_nat_rule] from source xxx.xxx.xxx.xxx, log-message:454776:miniupnpd[17447]: [UPnP set event: add_nat_rule] from source xxx.xxx.xxx.xxx, and rule was created to ip addr as ACCEPT in iptables. Just a note to people using upnp - ports are opened on device/app request, and will remain open until requestor asks to close. Many requestors never ask to close their ports, so just turn off upnp, apply, turn on upnp and it will remove any open (stale) ports by poorly coded requestors. I tested this and it works. right after miniupnp restarted ports were no longer in iptables list (closed) - no reboots are required --> this file contains so much more information that can be displayed on the web interface -- name of device, service name, etc. but they choose just not to show it. same for the wifi stats. they have connection speeds of each device, idle times, etc. i don't see much difference from .40 in this update, dnsmasq changes, a couple of zombie processes from bootup still stick (detcable, check_status.sh (streamboost checker). net-scan (The attached devices demo is Running...) they are early processes during the bootup. device manager still gets confused and sends devices offline when they still have an active ip. this does effect things as other modules rely on this information to be accurate. i also saw a post about (STALE) fe80: failure to parse.. I also saw this error once, and I do not have ipv6 enabled. it was just due to bad timing of disabling qos before one of the databases updated. reactivating qos, allowing everything to settle, and clearing stuck device, then disabling qos cleared it. if a device is shifted offline and is actually still online, an update to wan/lan qos is issued - over time hell breaks loose so due to qos bad marking and some other flaws, devices can be brought out of qos managements awareness and override bandwidth restrictions., etc. i keep it disabled until figure out a better way to monitor devices .. maybe in the next update so far stable but without all features

btw, i traced the dhcp requestor .. it was a galaxy s10+ phone (authorized), i don't think it caused the wlan stainfo lockup, i think it happened prior to the dhcp request.. i've never ever seen the interface drag on the xr500 like that, but i remember reading reports of it on the xr700 -- i bet it's connected.

LOL. new firmware always has me curious to see what was done .. but getting tired of messing with it TBH - wish it would just work right. But Nope. No factory reset - I rather figure out what's wrong and fix it - it's never been reset - I had .40 up and running for 220-250+ days (forgot the #) but I made some changes to it. Haven't really looked if anything else was updated, but the kernel was recompiled on Jul 16: Linux XR500 3.4.103 #1 SMP Tue Jul 16 08:25:16 EDT 2019 armv7l unknown

Well, I fixed it. I refuse to reboot the router. wlan stainfo process was the culprit -- it was jumping between 46-50+% of cpu and cpu meters were spiked at 100%, causing the admin interface to lockup on Qos, Device Manager, and Network Monitor. 794 root R 268 313 46.8 0.0 wlan There were two wlan stainfo processes running, I killed offending 794 process and all went back to normal. Firmware is now showing .56 - admin interface quick again. It was a young process (low #) so it started during initial boot 24 hours ago.. It's possible the admin interface slow down started after a faulty dhcp request: /bin/sh -c /dumaos/apps/system/com.netdumasoftware.devicemanager/dhcp-event.lua DHCP-REQUEST 'XX:XX:XX:XX:XX:XX' 'android-dhcp-9' that hung for quite a while. Unless it started right before the request - not sure. I caught the mac address and IP of the requestor, but it disappeared from the network. Will start running traces to figure out who/what it was. Not 100% sure it wasn't an intruder at this point. Very strange firmware version was reporting .40 and then right after my post it's now .56 - weird coincidence? Also note aws script running to check in to aws servers but I thought I disabled all iot - still no where to enable privacy or NO reporting back to netgear in the interface for regular users. Can we have an option to disable all ET phone homes?

Something new: Admin interface is now refusing the load properly "took too much time" message. Some Dashboard windows spin and spin, and Device Manager sub-section will not load. Spins and Spins "This operation took longer than expected. Please briefly wait before using this R-app." Never saw this in .40 and it was working fine for at least 22 hours. admin interface seems to have slowed to a crawl. I guess it's been tested well.

Almost a year and hardly anything has been fixed. That's a shame. Tested this "new" firmware for a day... so far: Device Manager is still broken. After some time devices still shift from Online to Offline (but remain online) or vice versa. Happens to devices connected through a wireless AP (EX8000). If device connects directly to the XR500 wireless and then shifts at some point to an AP wireless this occurs. Also happens to devices connected through a switch but takes longer to start happening. QOS is still broken. Turned it back to off state -- after a while it still starts closing active connections it does not Mark properly. Especially for VPN (like Dell SonicWALL or Cisco AnyConnect) and probably many more iot devices, etc. and the XBOX UPNP list now empty. At least it had some information in prior version. System Information window still shows V2.3.2.40 as the current firmware version. No update available when checking in Settings, so it's on .56 - such a quick job..all this time and that isn't even updated? Installed R-Apps window still lists Hybrid VPN R-app size as 0.0 undefinedB dhcp.leases still showed some 1970 expiring leases, but after re-request of IP they repaired themselves (I believe this may be the only thing that was fixed that I reported) IMO don't have high hopes - nothing new on main NetDuma modules? It may be an under the hood security update, or just a bluff to calm the angry masses -- or possibly just the existing hotfix firmware re-branded since the firmware version didn't even update - but all the problems everyone is/was having will still occur. That's for sure. I only read the first few pages of posts and bugs people are complaining about I reported right after .40 dropped ages ago. Still being addressed as 'first time seen' bugs. Losing hope guys. I still want to believe but having trouble, please let us know when all bugs will be addressed and fixed?

hey! just wanted to check in. I'm still here and I do pop in from time to time, but the time between times has gone long in the tooth ..everything said was spot on. Still have all the issues I discussed in the past, and I even sent them a huge list of things I noticed to look at -- but instead of working on it they moved on to the next milestone rather then fixing 1.3 issues. I have a feeling the new milestone will come out introducing a ton more bugs and we will always be in a bugged state. NetDuma has a small team and only a handful of that team who have the skill to develop and Netgear keeps pushing new models to flavorize with DumaOS -- you can bet on it AX is taking all the time right now and everything else is just back burning... plus the fact that Netgears Taiwan developers really can't work with NetDuma OS and introduce fixes (xr700) that create more problems (they even said they didn't know netgear released an update that hosed new things in netduma for xr700 in a prior post). So Netduma has moved on to new features, Netgear is fixing things they don't know how to and at the same time overloading Netduma team to flavorize their existing hardware routers and re-brand them instead of introducing something new. So now we have an R7000 duma os?? uhh, who's even buying that. Yes, devices still hang in online and offline state in Device Manager, port numbering debacle, lack of updated modules and security fixes, buggy QoS, DNS sync problems, I can go on and on.. I know how to fix these without rebooting or flashing firmware (I haven't re-flashed it once since I owned it) but you have to correct these errors in terminal mode. I chuckle every time I see a new post from someone asking about devices or not being able to connect or internet dropping, or why doesn't my XXX device connect, and response posts are always what firmware are you on, reboot, reflash, do this do that, when it ain't gonna do a darn thing, because it needs to be fixed OS side. I do have a 100+ day uptime right now, but QoS is disabled - so I'm not really getting any benefit from this OS. And like others, soon going to be moving on to other solutions since I can't take any real advantage of what this offers in this bugged state, and not going backwards to XR700 or AXwhatever it is.. because Netgears new AX is coming out soon (the 12 streams). And I'm starting to evaluate competitor routers. Actually, the 12 stream has been ready even before the AX6 was released. It's going to Orbi also. So anyone who has that AX6 is already outdated, oh well. They have the hardware ready and do targeted releases to bring in the most money (yeah any company would do this) but instead of releasing the best and making it the one and only..... every flavor needs to be milked first. well it's been long enough now (over 4+ months) so I guess I can release one more issue now.. The Data Analytics process has been enabled by default since day 1 sending data back to Netgear. Check your web console Settings, Administration, Firmware update -- You see the option to not automatically update firmware (a plus) -- but where's the data analytics option? oh. hmm. ok. I disabled the process manually. I did not find a way to disable it from the original firmware release until I looked again today, but the latest firmware may have been updated to do this on install, I did not check. So I can't be sure. But I found this in there, and you can check if yours is on.. Go to http://192.168.1.1/simple_conditions.html to check -- or at least make sure it isn't on by forcing it off. Just to let you know I was right that Netgear has one base core they use for all their routers and tweak for each, here's an example TOS htttp://192.168.1.1/BRS_tos.html (but it's for orbi, lol) There is tons of things still in there from other routers (streamboost things, etc that are conflicting with Duma) cron jobs that are running, etc to update streamboost when the router doesn't use streamboost. Probably much more that I didn't see with the old modules, etc. These things are contributing to the problems people are having, and Netgear is focusing on the next router rather then fixing things in the firewall that are blocking peoples connections via QoS. The firewall is really complex this why it prevents most of the attacks even with the older modules, but it's got its quirks that piss off Device Manager and block some local network devices from making certain types of connections, only causing customer complaints. Maybe this time it's been so long because they are going to actually fix everything, but new milestone issues will just probably give us all a do over , if that happens, sorry to say - I'm out.

lol, reported this since day 1 of .40 firmware, also sent all my findings to NetDumaAdmin. Hopefully not falling on deaf ears? bug in duma os. network monitor not effected