Jump to content

xr500user

Members
  • Content Count

    134
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    xr500user got a reaction from Zippy in XR500 Firmware version 2.3.2.56 released.   
    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...
  2. Like
    xr500user got a reaction from Netduma Alex in XR500 Firmware version 2.3.2.56 released.   
    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...
  3. Like
    xr500user got a reaction from Zippy in XR500 Firmware version 2.3.2.56 released.   
    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
     
  4. Thanks
    xr500user got a reaction from Sunaikinti in Xr500 firmware updates   
    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.
  5. Thanks
    xr500user got a reaction from Rhino90 in Xr500 firmware updates   
    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.
  6. Like
    xr500user got a reaction from Killhippie in Xr500 firmware updates   
    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.
  7. Like
    xr500user got a reaction from Boga in Xr500 firmware updates   
    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.
  8. Like
    xr500user got a reaction from WalkedDave in Xr500 firmware updates   
    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.
  9. Like
    xr500user got a reaction from sharpz44 in Xr500 firmware updates   
    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.
  10. Thanks
    xr500user got a reaction from Zippy in Xr500 firmware updates   
    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.
  11. Like
    xr500user got a reaction from Zippy in XR500 Mulitple Issues, port #ing, internet bandwith loss, etc   
    yes i guess you could say that, but not in routers
    there is a lot going on and i am by no means a master but getting a better understanding of whats being done with the advanced traffic shaping each time i follow another path putting the puzzle pieces together.
    there are def. some issue with the local lan <> internet <> lan <> iot when qos is on, its not all devices, i guess it depends on the connection, usually connections that go out to a server and the server comes back in on a different port or to a diff local lan device - device manager issues are only adding to it, that's a different story.
    something to do with when the connection is marked, and then OUTPUT and INPUT on the firewall side is dropping, maybe misidentify as DoS, dunno, its not blocking everything but blocking one important reply (ack? fin?) from coming back in from the internet to keep the connection alive , could be happening during prerouting - so the connection is just counting down 2 minutes and timing out/closing
    im surprised your not getting a lot of calls from people with arlo and xr500, because its effected
    the way arlo works is arlo base -> <local lan> -> router -> <internet> -> aws <ESTABLISHED> and the !reverse
    ex. say you open arlo app on phone that's on the SAME local lan ...  local lan -> router -> <internet> -> aws -> <internet> ->router ->>local lan-> base station and then its screwed on the !reverse
    all going both directions thru wan - (u have an arlo there? i think you should be able to reproduce it and maybe track down what is being dropped by qos)
    sometimes connection marked before firewall sees it come back into the base station, it can't connmark packets after the 1st one (when its NEW) ,so arlo may or may not connect or after a lucky connection -- it loses the mark --  the 2 minute countdown starts and instead of renewing you will see "your arlo appears offline." when it is online.
    All works well when QOS is disabled. so qos is influencing something no doubt
    something either the input/output is not letting ack back through and connection times out,. it could be effecting authentication servers on iphone , i know it effected port 4433 sonicwall vpns
    i sent a PM to Fraser the other day with some more things, pls read my other thread i gave some thoughts to look at (more device manager then qos)
    i will let you know if i find out what it is exactly , can't spend all time looking for it when it can be a simple ! instead of an and, or OR .. it can drive anyone nuts
    I'll forward it to you..
     
  12. Like
    xr500user got a reaction from Zippy in XR500 Mulitple Issues, port #ing, internet bandwith loss, etc   
    when i have time i poke around and gain more and more insight each time, but FYI
    port 4 table view IS the port being used by kernel, end of transmission
    additional hint VLAN /qos problems on local network -  wrong port being mapped to VLAN, actual vs netgear actual
    additional hint, people reporting  'my iphone isn't connecting','my xxx isn't connecting' -- some wifi devices not connecting because possible race condition from qos <> firewall , conntrack and marking [ASSURED] before firewall sees traffic , firewall TIME_WAIT, NO SYN, error in iptables---  time for flowcharts (dread) rework/fix script
    works when QOS disabled, because connection is not timing out as quickly, watch the count down till CLOSE
    i will post when i have time whats going on , with examples, unless you have found it by now?
  13. Like
    xr500user got a reaction from Killhippie in [DoS Attack: Ascend Kill]   
    seen this from time to time from google dns also, mostly happens on router first boot.  mis-identified dos attack
  14. Like
    xr500user got a reaction from Netduma Fraser in [DoS Attack: Ascend Kill]   
    seen this from time to time from google dns also, mostly happens on router first boot.  mis-identified dos attack
  15. Like
    xr500user got a reaction from Zippy in Should I return the Nighthawk XR500?   
    i would shoot for having it on if everything is stable, as everything works better when its on (unless its not working and causing you issues of course) if you turn it off then you lose the ability to see what the breakdown of the traffic is in network monitor area (which only seems to show the top 5 consumers at any one time, if a device is not there and you have more then 5 devices on your network - this doesn't mean its not working, and doesn't see the device, it just isn't consuming enough to be in the top 5) when qos is on you can click the upload or download bars on the device in network monitor and it will open a breakdown to the right of it of what it thinks the traffic is (games, media, web, etc) and if you go one step further and click on the color on the circle it will show additional breakdowns. if you click the upload and download bar on total usage line (first on the list) -overall usage- you can see breakdowns like what apps overall are consuming when you click the color on the circle that you want to see  (twitch, bittorrent, SSL traffic, apple, microsoft, ssl, media streaming, youtube, netflix, etc) when its off, this info will just be unknown traffic.  qos tries to prioritize whats more important and should go before someone else , in a perfect world it works. it classifys and then marks certain connections with priorities and if the connection for example say is thought to be offline in another module, for whatever reason (a monkey) you know we have an issue here , sometimes these classifications stick, even through a reboot and some chaos starts, combined with the dhcp thing, etc it could be a mess quick.. you wanna know why nobody else is doing what they are doing -  this because its a real pain in the ass and pretty difficult to get it to work for everyone and every network scenario, but credit goes where credit is due they are the only one this close to perfecting it
    upnp is another animal, netgear always had issues with it in one form or another (reporting wise), upnp is supposed to open ports for you automatically so you don't have to do the port forwarding.  but the requesting application is thought to be trusted if on the local LAN so it goes ahead and opens the port in the iptables firewall on the router.. and after a certain time its supposed to remove it, just because it shows there its most likely to be closed if after the limit..as other things on the kernel take care open connections that should not be lingering. its the upnp daemon netgear chooses  just not updating its upnp_pmlist file (whats reflected on the admin interface), and sometimes it doesn't update it on creation either.  there's a lot more information inside this file that they could show you like what app requested the upnp but they just don't show it (like Toredo, Skype, identd, etc) its in there, they are just not showing it on the interface (keeping it simple for the user) another issue is the version of upnp they are using to do all this is possibly custom modified over the years (at least we hope!) and may not have all the recent changes/fixes - future versions fixed issues of removing items from this list (just look at the changelog for miniupnpd) they did have a fix for closing the ports on the RFC on the list, and in addition to that...
    2018/05/02: option to store remaining time in leasefile which could be useful so you can restart miniunpd or reboot and not lose active upnp ports if they should still be open and devices were never switched off during the reboot, also could help in tracking these and fixing the list with a watcher if a monkey does jump in
    but this requires netgear to update its daemons and modules, something they don't seem to want to do and nobody ever has given answer to that question as to why?...
    but rest assured just because its not reporting correctly it is opening/closing the ports as it should because things wouldn't work at all if it wasn't.  the kernel has many NAT helpers built into it that do a lot of the work of upnp and bypassing upnp it seems, because I see them being managed through a different way.. certain apps like Skype will show because its old school requesting..or does not have a helper. some apps are only going to request a port once and not again until at least the time limit expires, but if you close an app and reopen it will request again and show on the list (or reboot the xbox so it requests them again)
    if anything ever jumps out at me i will report of course, and i am no expert in this, just dabbling and like to know how these things are working (and when they don't)
  16. Like
    xr500user got a reaction from Zippy in How To Prioritize a Wired Router Port/High Priority Detected Not Working?   
    what you are doing with that procedure is by hand what the kernel needs to be doing during startup (it is not a fix), there are some timing issues during boot introducing some monkeys, but at the same time even if you get a stable boot these issues can recur if the right conditions are met (miscommunication between netgears kernel and duma) 
    another guy who throws a wrench in everything is udhcpc daemon who is in charge of getting the WAN IP dhcp lease (public IP lease) from your ISP - each time the lease expires he goes through a whole sequence of events all over again just in case the IP has not been changed by your ISP to ensure that QoS gets reapplied to the correct public IP (same public ip? different public ip?) the scripts he's calling can do some things behind dumas back and may introduce a monkey there too 🙈  since duma needs the data its working with to be accurate for everything to come together -- some people may be just be doing fine for a day or two or three (so how long is your public IP lease? ->Settings, Monitoring, Connection Status --> Lease expires time?) do problems coincide with that timing? things to watch ..
     
  17. Like
    xr500user got a reaction from Zippy in Should I return the Nighthawk XR500?   
    have you tried just disabling QoS and just leave it off prior to/and after the fresh reboot? (just disable QoS, reboot, leave it off)   just to see if it works better? turning it on and off when its been up for a while creates some corruption if something is not right gets in there.  i know this because of changing some things behind duma os back and forcing/sending dummy DHCP events to device manager while trying to figure out exactly what its doing (which script triggers, etc) after an event to pinpoint the failure.. at one point I was unable to turn off QoS fully since I had removed rules that it was looking for to delete when being turned off, lol.  I have yet to factory reset once since getting this router though.. I always have been able to restore it to a very stable working state manually.
    rebooting the way i said is probably the cleanest reboot you are going to get, but yes whatever is triggering it may pop up again and throw everything out of wack (monkey wrench in the machine) the problem is the constant rebooting everyone is doing without that method creates more problems on each reboot - you never know what you're going to get, especially if some IPs get locked up on a reboot (ones that you've assigned statically) so if the static device requests an IP it can't get its permanently assigned one back so it may get a different one or just decide to up and quit and settle with a 169 non usable ip .. and then as time goes on it just gets more and more out of sync with other settings (qos, port forwards you may have set, etc) i don't think that it is unfixable, it just needs to be fixed. its the illusion that the lan port isn't working, but it is, just the device is not   i have faith they will do it. they got some smart guys there, and what they are doing is not an easy task.. i give mad props to the cross.. it's advanced traffic shaping for dummies on the interface, but deep down so much stuff is going on behind the scenes and things need to be in order for it all to come together and one link in the chain fails.. its a cascade of small failures, just a nasty bug that i'm sure they will deal with it. something has to give with netgear
  18. Like
    xr500user got a reaction from Zippy in getting DDosed   
    for peace of mind (even though you may not be getting DoS attacked, its probably something else) you may need to request a new public IP from your isp. The front line will not have a clue so you will have to escalate it to level 2 or 3 ..  it really depends on if they lock your public IP to your cable modem or ONT's mac addr. if they do they are the only ones who can release it, or just return the cable modem and get a new one that has a different mac addr, tell them its broken and you want a new modem.
    if you are sure they don't lock this, you need to check the public WAN ip lease time on Duma -- in Settings, Monitoring, Connection Status  -- take note of Lease Expires time.. when it gets close (within minutes) turn off your XR and turn off your Cable modem..  now wait..  how long you wait after that really depends on if some new customer joins the network and gets your old public IP and even waiting a few minutes is not enough -  it may re-request the one it was using and if available, get it back.  some recommended turning both off for a whole day. try to make sure your off time is during business hours when new customers are being added to the network or new modems are being activated.  You may or may not luck out , its chance gamble .. technically nobody could be added that day and you just get your old public IP back, lol.
  19. Like
    xr500user got a reaction from Zippy in Should I return the Nighthawk XR500?   
    yeah, i believe they are aware - but i think not only are there some quirks in device manager (both views) and QoS match tracking which need to be addressed, its netgears base firmware causing some issues to boot
    the issue is very apparent when using wifi extenders.  it seems to work for the most part correctly when the wifi extender is in wifi 'extender' mode.  client connects to wifi extender and gets a virtual mac addr, then gets allowed onto the local XR wifi.  device manager is good at picking up this virutal mac and merging it with the ip of the actual device (so it knows say iphone X is ab:cc:dd:xx:xx:xx and also cc:xx:dd:xx:xx:xx with IP 192.168.1.x)   -- but when extender is in AP mode there are no virtual macs assigned when connected to its wifi, and backhaul is ethernet so its just a pass thru the local LAN (mac addr is true) depending on first connection time and state, this is the issue.  if device first connects to an AP, its considered on Local LAN (since pass thru to ethernet) if it jumps off AP wifi and goes to true XR wifi then there's another problem since device manager holds last location (LAN or Wifi) and it will just stay on LAN as online and won't move to wifi side, sometimes marking gets stalled since nothing is triggered until a dhcp event and there are no dhcp events if the client is still in lease time, it won't ask for a new ip. this is one of many scenarios that can start a sh*t storm since device manager can't assume device once on wifi, always on wifi with the same mac addr -- issue that's effecting here is also effecting qos tracking module, if it can't know the device is online and active how can it mark it? it doesn't, so old info may still be in there with prior marks and wrong ip (if it switched) connections get dropped (connection tracking) and it lingers with a reboot and only gets worse after each reboot as the dhcp.leases files gets more and more out of sync along with dumas tracking of them so to say. sometimes if the client leaves the network from wifi, but was thought to be on LAN the ip isn't being cleared by device manager so theres your "Error cannot delete device because its online"  - its odd though that table view knows the ip isn't there sometimes (show's N/A) but Tree will still show the IP as online even when offline.  now xbox sleeping and waking over and over and over would work in a perfect world but if anything gets some bad info it causes the lost connectivity issue. i'm pretty sure xbox sleep mode (instant on) has no issues on R7800, there is still some legacy things interfering with duma os they have not closed it all down yet. device manager does trigger some events on dhcp renew and other modules also rely on the same information gathering method, so if its wrong, you know problems happen, some may not materialize to state where a user can notice and bitch about,  but clearly you see, some are
     
    the startup sequence (bootup) causes issues in  larger networks where multiple devices have different lease expirations.. and if the lease time is hosed in the XR (for whatever startup reason) it can cause problems because once clients notice a connection is available it will request a renew, or just start thinking hey im ok - im in lease time, and start working as normal.   XR kernel has not yet determined its mac addr (and may not know the true ntp time yet so ntp should be set immediately after WAN is up) so it will assign all 00's (incomplete) to that IP it sees data coming from or requested dhcp from, and when the router actually is up and running the device may hit a renew period or request again and oh no that IP is in use, give me a new one, so the router will assign a new IP address to the client, but qos markings are for the old IP - another sh*t storm, and if the IP has a weird lease time of like 1969 or 1970 forget it, its ip will never ever release for use
    some way the router needs to fully boot and and acquire WAN ip and internet access,  duma os needs to fully start (with empty databases and tracking) and then LAN needs to start and then Wifi radio on.  at different points of the startup process these things are seen for a split second as active (192.168.1.1) and devices think everything is ok and either request dhcp or mantain what they had before the reboot then interface may get moved to br0 interface but the damage has been done to the files and databases (bad data in there) it may only effect certain devices with just bad luck timing so that's why the more devices the more chance it has to occur.. and if a device actually tries to renew for some it may not get an ip and just give up and set itself to 169.xx.xx.xx - sometimes it works after a reboot so people think its fixed, but its not just had a lucky start up and could occur again
    yeah it will result is longer boot up times before everything is started, but so be it, just let people know it may be 2,3+ minutes before internet is available on reboot, if you imagine a boot up with multiple APs (which may have 10 clients behind them) all assaulting the dhcp server as soon as it sees some activity from the gateway and certain things are not yet known to the kernel or duma
    theres other things too that are going on causing issue, its probably best if duma just takes control of the kernel if they just can't get it to work, too many chefs in the kitchen
    xr700 is just one more complication since the 10G port and the ability to aggregate or use 10G port as uplink or WAN -
    duma bugs need to addressed, and netgear startup needs to be optimized for all scenarios .. its hard to fix bugs until netgear startup is working optimally, lol. catch .22 .. especially if work arounds were applied for prior bugs that were corrected but now after being corrected cause new bugs, a real hair puller
     
  20. Like
    xr500user got a reaction from Zippy in Should I return the Nighthawk XR500?   
    It's a firmware bug.
    Clients are jumping onto the router before router dhcp server for local LAN is up and running
    (this includes wifi clients)
    I believe it's the sequence of startup for some - with different people experiencing different things depending on ISP, LAN setup, etc.
    If you have the router up and running with the latest firmware, you can attempt to do a nice reboot but prevent all clients from jumping on..
    Turn off the Wifi (to prevent wifi clients from jumping on)
    It has to be done from a LAN client.   Turn off router Wifi. Issue a router reboot.
    As soon as you issue the reboot, wait a few seconds and disconnect all cables from behind router (WAN, LAN ethernets) Wifi should be off prior.
    Router reboots ..
    Wait until it's fully booted
    Plug in the WAN cable and wait until it's got Internet.
    Wait a tiny bit after it has Internet, then plug in your local network ethernets, then turn wifi back on
    This is just one issue.. it can cause weird things like bad dhcpd epoch times (since dhcpd running before actual time known) so IP's get locked to certain macs and they never ever expire, so when the device IP ever changes devices may be associated with multiple IPs in duma databases, and if another device happens to reconnect without renewing its lease (with it's old IP) dhcpd may gave it out to someone else who requests -- so now device manager has two different ip, but thinks it should be for a different mac addr
    for others - WAN dhcp (udhcpc) is up, but local dhcp (dhcpd) is not (yet), so client requests dhcp and gets an error (since already assigned) so defaults to 169.xx and client is locked there, no ip
    what needs to be done is run through all startup scripts on the router and make sure you hold back local LAN and wifi until WAN is fully up and ntp time is set
    then start dhcpd, sleep, then start lan and then start wifi radio and make sure to clear any saved information in device manager databases prior to reboot
     
    so it still doesn't fix bugs like sticky IPs based on last connection type for device manager, this is when last connection type was wifi for mac xx:xx:xx:xx:xx:xx and then becomes LAN for same mac.  device may stick on either side or be online or offline, but it may make your network stable enough to use for the time being, when qos devices get marked and are not thought to be online, its a problem
    You can also turn QoS completely off in settings next to Anti-Bufferbloat (disable QoS), do the reboot sequence above and leave it like that. if all is good for a day or two (so any old info expires), then turn QoS back on and see if everything behaves  - there is no way to set dhcp lease time in XR500 so its set to 1 day by default, although there is no reason why this can't be changed manually - to really know everything is working nice is to take a look at the dhcp.leases file and make sure it looks good, and not any strange epoch times, but most won't do this
    unfortunately until its fixed it will continue to some degree over time on those with effected configurations , and i believe it is part of the reason why xbox is having trouble, since it sleeps and wakes and sleeps and wakes, and if at any point something goes wrong in this process and it gets marked for QoS when its online but thought offline it can't maintain connection to its authentication servers because QoS KILLS flows that it doesn't know about in TIME_OUT state and blocks ACK (there's more to it then that, but just an idea), its watching conntrack and theres' a bug there too -- I believe they will fix it, but when -?- don't know -- maybe soon!
     
  21. Like
    xr500user got a reaction from Netduma Jack in Understanding Hybrid VPN   
    already notified about the DNS and RTC leak.
    TCP isn't going to help. It's problematic for all VPN providers.  It needs a modification to tunnel VPN DNS into the tun0 device
    ExpressVPN does push preferred 10.x.x.x DNS server upon connection - Duma ignores - uses preferred or automatic WAN DNS for resolution.  speed can be increased by setting the processor to performance mode which netgear doesn't do (ondemand)  -- you can do it yourself.
    ExpressVPN doesn't give tcp configs for download apparently, but just for the curious:
    mods to config in BOLD (make sure to uncomment with a # where needed):
    proto tcp-client
    dev tun
    #fast-io
    persist-key
    persist-tun
    nobind
    remote (vpn server you want to use.com) 443
    remote-random
    pull
    comp-lzo no
    tls-client
    verify-x509-name Server name-prefix
    ns-cert-type server
    key-direction 1
    route-method exe
    route-delay 2
    tun-mtu 1500
    #fragment 1300
    mssfix 1450
    verb 3
    cipher AES-256-CBC
    keysize 256
    auth SHA512
    sndbuf 524288
    rcvbuf 524288
    auth-user-pass
    <<add your cert, etc >>
    if you get an error on any line in logs, comment it out.
    if it connects, tcp connection is successful
  22. Like
    xr500user got a reaction from Killhippie in Should I return the Nighthawk XR500?   
    It's a firmware bug.
    Clients are jumping onto the router before router dhcp server for local LAN is up and running
    (this includes wifi clients)
    I believe it's the sequence of startup for some - with different people experiencing different things depending on ISP, LAN setup, etc.
    If you have the router up and running with the latest firmware, you can attempt to do a nice reboot but prevent all clients from jumping on..
    Turn off the Wifi (to prevent wifi clients from jumping on)
    It has to be done from a LAN client.   Turn off router Wifi. Issue a router reboot.
    As soon as you issue the reboot, wait a few seconds and disconnect all cables from behind router (WAN, LAN ethernets) Wifi should be off prior.
    Router reboots ..
    Wait until it's fully booted
    Plug in the WAN cable and wait until it's got Internet.
    Wait a tiny bit after it has Internet, then plug in your local network ethernets, then turn wifi back on
    This is just one issue.. it can cause weird things like bad dhcpd epoch times (since dhcpd running before actual time known) so IP's get locked to certain macs and they never ever expire, so when the device IP ever changes devices may be associated with multiple IPs in duma databases, and if another device happens to reconnect without renewing its lease (with it's old IP) dhcpd may gave it out to someone else who requests -- so now device manager has two different ip, but thinks it should be for a different mac addr
    for others - WAN dhcp (udhcpc) is up, but local dhcp (dhcpd) is not (yet), so client requests dhcp and gets an error (since already assigned) so defaults to 169.xx and client is locked there, no ip
    what needs to be done is run through all startup scripts on the router and make sure you hold back local LAN and wifi until WAN is fully up and ntp time is set
    then start dhcpd, sleep, then start lan and then start wifi radio and make sure to clear any saved information in device manager databases prior to reboot
     
    so it still doesn't fix bugs like sticky IPs based on last connection type for device manager, this is when last connection type was wifi for mac xx:xx:xx:xx:xx:xx and then becomes LAN for same mac.  device may stick on either side or be online or offline, but it may make your network stable enough to use for the time being, when qos devices get marked and are not thought to be online, its a problem
    You can also turn QoS completely off in settings next to Anti-Bufferbloat (disable QoS), do the reboot sequence above and leave it like that. if all is good for a day or two (so any old info expires), then turn QoS back on and see if everything behaves  - there is no way to set dhcp lease time in XR500 so its set to 1 day by default, although there is no reason why this can't be changed manually - to really know everything is working nice is to take a look at the dhcp.leases file and make sure it looks good, and not any strange epoch times, but most won't do this
    unfortunately until its fixed it will continue to some degree over time on those with effected configurations , and i believe it is part of the reason why xbox is having trouble, since it sleeps and wakes and sleeps and wakes, and if at any point something goes wrong in this process and it gets marked for QoS when its online but thought offline it can't maintain connection to its authentication servers because QoS KILLS flows that it doesn't know about in TIME_OUT state and blocks ACK (there's more to it then that, but just an idea), its watching conntrack and theres' a bug there too -- I believe they will fix it, but when -?- don't know -- maybe soon!
     
  23. Thanks
    xr500user got a reaction from Netduma Admin in XR500 Mulitple Issues, port #ing, internet bandwith loss, etc   
    yes i guess you could say that, but not in routers
    there is a lot going on and i am by no means a master but getting a better understanding of whats being done with the advanced traffic shaping each time i follow another path putting the puzzle pieces together.
    there are def. some issue with the local lan <> internet <> lan <> iot when qos is on, its not all devices, i guess it depends on the connection, usually connections that go out to a server and the server comes back in on a different port or to a diff local lan device - device manager issues are only adding to it, that's a different story.
    something to do with when the connection is marked, and then OUTPUT and INPUT on the firewall side is dropping, maybe misidentify as DoS, dunno, its not blocking everything but blocking one important reply (ack? fin?) from coming back in from the internet to keep the connection alive , could be happening during prerouting - so the connection is just counting down 2 minutes and timing out/closing
    im surprised your not getting a lot of calls from people with arlo and xr500, because its effected
    the way arlo works is arlo base -> <local lan> -> router -> <internet> -> aws <ESTABLISHED> and the !reverse
    ex. say you open arlo app on phone that's on the SAME local lan ...  local lan -> router -> <internet> -> aws -> <internet> ->router ->>local lan-> base station and then its screwed on the !reverse
    all going both directions thru wan - (u have an arlo there? i think you should be able to reproduce it and maybe track down what is being dropped by qos)
    sometimes connection marked before firewall sees it come back into the base station, it can't connmark packets after the 1st one (when its NEW) ,so arlo may or may not connect or after a lucky connection -- it loses the mark --  the 2 minute countdown starts and instead of renewing you will see "your arlo appears offline." when it is online.
    All works well when QOS is disabled. so qos is influencing something no doubt
    something either the input/output is not letting ack back through and connection times out,. it could be effecting authentication servers on iphone , i know it effected port 4433 sonicwall vpns
    i sent a PM to Fraser the other day with some more things, pls read my other thread i gave some thoughts to look at (more device manager then qos)
    i will let you know if i find out what it is exactly , can't spend all time looking for it when it can be a simple ! instead of an and, or OR .. it can drive anyone nuts
    I'll forward it to you..
     
  24. Like
    xr500user got a reaction from Netduma Admin in XR500 hybrid VPN DNS leak test   
    i reported this, dec 20th.
    http://forum.netduma.com/topic/27539-hybrid-vpn-speeds/?do=findComment&comment=204382
     
     
  25. Thanks
    xr500user got a reaction from Netduma Admin in XR500 Mulitple Issues, port #ing, internet bandwith loss, etc   
    when i have time i poke around and gain more and more insight each time, but FYI
    port 4 table view IS the port being used by kernel, end of transmission
    additional hint VLAN /qos problems on local network -  wrong port being mapped to VLAN, actual vs netgear actual
    additional hint, people reporting  'my iphone isn't connecting','my xxx isn't connecting' -- some wifi devices not connecting because possible race condition from qos <> firewall , conntrack and marking [ASSURED] before firewall sees traffic , firewall TIME_WAIT, NO SYN, error in iptables---  time for flowcharts (dread) rework/fix script
    works when QOS disabled, because connection is not timing out as quickly, watch the count down till CLOSE
    i will post when i have time whats going on , with examples, unless you have found it by now?
×
×
  • Create New...