Jump to content
Killhippie

XR500 Firmware version 2.3.2.56 released.

Recommended Posts

Hmm interesting...

Shouldn't be too long until the DumaOS app is ready...

I mean obviously that's no workaround but I'm just saying...

Share this post


Link to post
Share on other sites
7 hours ago, e38BimmerFN said:

I just setup my XR450 with v56 yesterday on a 200/10 ISP and speed testing is to spec, via wired PC and NG Nighthawk app on iPhone 6sP and Android Galaxy Tab S2 pad. 

QoS set for 70% on both sliders using "When High Priority Traffic is Detected." 

Also have 2x EX7700 extenders connected. Smart Connect is enabled on the XR450. 

I did find an issue, has to do with the NH app. Device Manager reports "Sorry, the action was failed. Please try again." when selecting this on iPhone. On Android pad reports "Connected devices not found." Both iPhone and pad have up to date NH apps. I posted this in the NG Nighthawk app forum as well: 

https://community.netgear.com/t5/Nighthawk-App/Device-Manager-in-the-NH-app-fails/td-p/1790832/jump-to/first-unread-message

So far the XR system is stable and running nicely. 

You went from an XR500 to an XR450?

Share this post


Link to post
Share on other sites

Never owned a XR500. I did demo one when they first came out. Sent it back after I was done testing it out. I saw that Costco offered the 450 for $200 at the time so I picked that one up. Same HW as the 500 accept for the 2.4Ghz radio connection rates are different is all. I've had the 450 since summer of 2017. Zero issues with it. 😁

16 hours ago, crawlgsx said:

You went from an XR500 to an XR450?

 

Share this post


Link to post
Share on other sites
21 hours ago, xr500user said:

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

 I find it interesting what you post.. To me its not rambling.. Your info maybe the only hope there is to get this corrected. I know what this router can do when it is performing as it should. DumaOS is very much point on when its working. What worries me by what you have posted sounds like something that wont be fixed though. It took 8 months to get this last update. That really didn't fix anything tbh. Even when the new milestone is out what and when will Netgear release. With these issues like we have sounds like it would take to much time they don't have to spend on this router to correct these issues. If it was already known and simple I feel it would have been corrected by now. Come Sept. I will have had this router for a full year. I by no means see any light at the end of this tunnel. The one feature I like and need is Traffic Prioritization. I can see when something starts blocking my connection. It usually happens on the incoming traffic because I will notice that packet number will begin to slow down. While it seems all out going traffic continues okay. But my incoming basically comes to a crawl. When its working correctly both in coming and out going move very fluid. And the number between outgoing and incoming will be either the same or incoming will be more. I think what maybe happening is what you have pointed out in your description. Something either loses QoS tagging and the firewall begins to block incoming traffic.. And once that takes place it really falls apart fast. Im very observant. But you know more in depth under the hood info. I really wish this router would work. I still might get my hands on a R1. Id love to compare the two in regards of these issues. Something tells me the R1 doesn't experience any of these..

Zippy.

Share this post


Link to post
Share on other sites

 

19 hours ago, Zippy said:

 I find it interesting what you post.. To me its not rambling.. Your info maybe the only hope there is to get this corrected. I know what this router can do when it is performing as it should. DumaOS is very much point on when its working. What worries me by what you have posted sounds like something that wont be fixed though. It took 8 months to get this last update. That really didn't fix anything tbh. Even when the new milestone is out what and when will Netgear release. With these issues like we have sounds like it would take to much time they don't have to spend on this router to correct these issues. If it was already known and simple I feel it would have been corrected by now. Come Sept. I will have had this router for a full year. I by no means see any light at the end of this tunnel. The one feature I like and need is Traffic Prioritization. I can see when something starts blocking my connection. It usually happens on the incoming traffic because I will notice that packet number will begin to slow down. While it seems all out going traffic continues okay. But my incoming basically comes to a crawl. When its working correctly both in coming and out going move very fluid. And the number between outgoing and incoming will be either the same or incoming will be more. I think what maybe happening is what you have pointed out in your description. Something either loses QoS tagging and the firewall begins to block incoming traffic.. And once that takes place it really falls apart fast. Im very observant. But you know more in depth under the hood info. I really wish this router would work. I still might get my hands on a R1. Id love to compare the two in regards of these issues. Something tells me the R1 doesn't experience any of these..

Zippy.

Funny you mention this.

 

I don’t know as much as you guys about what’s under the hood. I did however compare the R1 to XR500 as I own both and I could swear I had better in game connections on the R1. The issue with this though is that it’s very hard to compare this since one night of R1 usage doesn’t really say much since other variables like connection to the server are not consistent.

My my main issue is that I need PPPoE and the geofilter. If I didn’t I could just run the R1 all the time since I don’t use any of the wifi features etc.

following this discussion with interest though.

Share this post


Link to post
Share on other sites
On 8/17/2019 at 12:18 AM, Newfie said:

I’ve noticed if you use the Nighthawk app on iOS the speed test now shows live results as it’s tested so I’m guessing they added some compatibility to the app

I noticed it too, and the speeds seem satisfactory

Share this post


Link to post
Share on other sites
On 8/16/2019 at 9:52 AM, Netduma Alex said:

I realize this update is quite small, but the changelog isn't exhaustive, and we do have big updates on the way.

Keep an eye out next week because we're planning a blog post that will reveal some exciting information about our plans for the next milestone.

So where is this blog post?

Share this post


Link to post
Share on other sites

 I just wanted to let everyone know I updated my router and did a factory reset after. Somehow it completely took my 5G band off-line. It was constantly making my devices go on And off-line and losing connection very often. I would lose phone calls also and I had to turn off Wi-Fi calling. I don’t know what it was but it happened as soon as I updated the router. I downgraded the firmware and didn’t even do a factory reset and everything went to normal immediately, and there was my 5G band back up and running like normal. Btw I have smart connect on and left everything on auto. Just in case anybody else was also having this issue. I am in pass-through mode with AT&T router. 

 I didn’t see any other post with issues like I was having. I’m hoping it is just a fluke. 

Share this post


Link to post
Share on other sites
6 hours ago, Netduma Alex said:

This week for sure. The post is written and ready to go, we're waiting to get the go ahead from various parties.

Sounds good! Looking forward to it.  

Share this post


Link to post
Share on other sites
7 hours ago, Netduma Alex said:

This week for sure. The post is written and ready to go, we're waiting to get the go ahead from various parties.

I'm suuuuuuper  green personally !!!!

Share this post


Link to post
Share on other sites

I’ve discovered something that I’ve not noticed before.

I'm running 2 extenders which are the ex8000 extenders and on one of these I have connected an Arlo base station which is the Netgear’s security camera system. 

I’ve noticed under network monitor the base station (VMB4000) is active yet the extender is showing very little activity. I’m fairly sure before anything connected via an extender could not be controlled ie controlling QoS for example. 

 

Share this post


Link to post
Share on other sites
22 minutes ago, Netduma Alex said:

So you can't see much activity on the extender's web interface? Or are you talking about DumaOS?

Yes, I’m looking at DumaOS. if I for example pull up the live camera then the network monitor shows the VMB4000 is active and you can see the download and upload yet the extender shows nothing. It’s as if you can now control devices attached to an extender where as I’m sure I could not do that before.

Share this post


Link to post
Share on other sites

That’s great, thanks.

i was sure before I could not control devices behind an extender. There has been updates to the extender but I was surprised to see I could control a device behind an extender.

I’ve included some pics.

29E95E50-D232-4C54-8CE2-8478C40D609B.jpeg

445AC0B6-3ED5-47F8-83B0-D88F9F8C758D.png

DBE3D391-C8B0-4880-9632-28CB85EE111F.png

Share this post


Link to post
Share on other sites

You know I was pretty sure that you couldn't control devices behind an extender. It might be something unique about the extender you're using. I mean, it IS a Netgear extender, maybe there's a compatibility there.

Share this post


Link to post
Share on other sites

That’s great, perhaps the recent updates achieved this. All I need to do now is sort out my Arlo camera which has a mind of its own. 

Thanks again for your help.

Share this post


Link to post
Share on other sites

No problem. The reason i'm a bit vague on some of this is because on the XR series, much of this stuff is handled by Netgear.

Share this post


Link to post
Share on other sites
On 8/27/2019 at 11:05 AM, Netduma Alex said:

This week for sure. The post is written and ready to go, we're waiting to get the go ahead from various parties.

Is this news coming this week Alex, like maybe tomorrow as interseted to read...thanks

Share this post


Link to post
Share on other sites
14 minutes ago, sharpz44 said:

Is this news coming this week Alex, like maybe tomorrow as interseted to read...thanks

We'll have something VERY soon. The post is all ready to go, we just need the go ahead from various parties. I would EXPECT it to come out tomorrow but I can't promise that.

Share this post


Link to post
Share on other sites
On 8/29/2019 at 5:24 PM, Netduma Alex said:

We'll have something VERY soon. The post is all ready to go, we just need the go ahead from various parties. I would EXPECT it to come out tomorrow but I can't promise that.

Does it include bug fixes for DumaOS in between milestone launches? Because all the new features in the world wont help if you don't patch the bugs that exist after updates, like the bugs that never got patched in milestone 1.3 and were not patched in the last update for some unknown reason, I mean Netduma did have 8 months to fix these.


 There has to be a change of direction in patching DumaOS bugs, there are still major bugs from December 2018, which result in people having to turn off QoS like the VLAN tagging bug for instance. These bugs are still causing people issues 8 months into Milestone 1.3 and that's after that's a recent update too. No new feature set in Milestone 1.4 will fix what is pretty much a non existent patching cycle for bugs in DumaOS. I really hope you have thought and worked on this aspect of DumaOS's life cycle in tandem with Netgear, otherwise nothing has really changed no matter what you add feature wise. Maybe you need to slow down creating new feature's and  concentrate on fixing the broken ones first?

Share this post


Link to post
Share on other sites
On 8/16/2019 at 9:12 AM, Netduma Alex said:

Milestone 1.4 is coming soon, this one is a NETGEAR update rather than a Netduma update.

Will the XR700 be part of the Milestone 1.4 Netduma update?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...