How To Prioritize a Wired Router Port/High Priority Detected Not Working?

[NBA]

I would like to be able to prioritize traffic from my PC which is wired to the xr500 via LAN port 1.   Is there a way to prioritize LAN port 1? 

I used to be able to on my older netgear router but cannot seem to find the option in DUMAOS.  I gave my PC most bandwidth and selected "Battlefield" under traffic prioritization but I still get the packet loss symbol in Battlefield V.

Also, high priority traffic is not detecting Battlefield V even though I have added it as a high priority service as well as my PC. Any ideas on how to fix that?

[Netduma Jack]

6 hours ago, NBA said:

I would like to be able to prioritize traffic from my PC which is wired to the xr500 via LAN port 1.   Is there a way to prioritize LAN port 1? 

I used to be able to on my older netgear router but cannot seem to find the option in DUMAOS.  I gave my PC most bandwidth and selected "Battlefield" under traffic prioritization but I still get the packet loss symbol in Battlefield V.

Also, high priority traffic is not detecting Battlefield V even though I have added it as a high priority service as well as my PC. Any ideas on how to fix that?

Hi, welcome to the forum! First off, packet loss usually originates upstream on your connection, and can be tested for before it reaches the game itself. The packet loss icon in-game may not be particularly accurate, so it's worth testing whether there's any on your line. I'd recommend grabbing Pingplotter and running tests using that.

Prioritising a specific LAN port is actually the same difference as prioritising the device connected to that LAN port, which is why our developers saw a way to simplify the process using our QoS. Giving more bandwidth to that connected device and using Anti-Bufferbloat (at about 70/70) is a great way to prioritise that device.

As for High Priority Traffic not properly detecting, I believe this only affects PC games. You may be able to use the workaround however, which is to set your PC to a console in the Device Manager. (The Device Type option changes how the router treats that device). See if that works for you

[NBA]

On 1/22/2019 at 5:08 AM, Netduma Jack said:

Hi, welcome to the forum! First off, packet loss usually originates upstream on your connection, and can be tested for before it reaches the game itself. The packet loss icon in-game may not be particularly accurate, so it's worth testing whether there's any on your line. I'd recommend grabbing Pingplotter and running tests using that.

Prioritising a specific LAN port is actually the same difference as prioritising the device connected to that LAN port, which is why our developers saw a way to simplify the process using our QoS. Giving more bandwidth to that connected device and using Anti-Bufferbloat (at about 70/70) is a great way to prioritise that device.

As for High Priority Traffic not properly detecting, I believe this only affects PC games. You may be able to use the workaround however, which is to set your PC to a console in the Device Manager. (The Device Type option changes how the router treats that device). See if that works for you

Hi, thank you for trying to help.

Unfortunately, 

there is no option for "console" and selecting either PlayStation or XBox has no effect.   The High Priority Traffic light stays unlit/inactive.  

QOS seems to have no effect as I get lag, ping spikes as other devices use bandwidth.

Factory resets did not help.

Manually, adding Battlefield ports to Traffic Prioritization (very tedious process) did activate the the High Priority Traffic light/function but it did so regardless of being in game or not which permanently imposes the bufferbloat of 70% whether it is needed or not.  

It seems to me that this version of DUMAOS or the way it is implemented with the xr500 is unfinished and buggy.  There should not have to be workarounds.  This should not be for a $300 router.  I had better luck with my old r6300 where I could set things manually and it worked.  xr500 seems to sell itself on a lot of great gaming features which, so far, have yet to work correctly.

The features are great in theory but after troubleshooting for the last 4 days, multiple restarts, resets, reading through the best settings guide and following the instructions, I still cannot get it to work. 

Any help is appreciated but I am beginning to lose hope in being able to correct the issues.

 

[Netduma Jack]

Not to worry NBA, lets see what we can do. I think this high priority traffic issue with Battlefield V happened to someone else here as well. The solution should be to add your PC to Traffic Prioritisation and select the 'Games Console' service. Hopefully with that setup everything will run smoothly - traffic like YouTube shouldn't be prioritised while your gaming traffic will be.

Let me know if that works. Also, what's your setup like? Are all devices connected to the XR500? QoS won't be able to properly prioritise / share bandwidth if some of the devices are connected to something else, like your Modem.

What other features do you feel aren't working for you? Battlefield V lets you select a server region in-game, but the Geo-Filter should be able to get you the best server in that region. (Changing your PC device type to a console before adding it to the Geo-Filter is important here!)

As a final note I'd say your investment is in really safe hands. I'd argue to the death about the current quality of DumaOS compared to other routers, but we're also going to be upgrading this faster and for longer than other routers as well. PC games will be getting a lot of love since there's a big appetite for it - workaround solutions won't be necessary soon enough.

[NBA]

Setting it to console does nothing.  Even if it did work, PS4 and xbox use different ports than PC for BF V (see below).  There is only one or two port ranges that overlap so that is not a viable solution.  Additionally, QOS keeps switching the bandwidth I set to something else as devices come online and go offline.  All is connected to the XR500 which is connected to a modem. I am on PC so I do not need or use the Geo Filter.  

Battlefield V -

Playstation 4

• TCP: 1935,3478-3480,9988,10000-10100,17502,42127
• UDP: 3074,3478-3479,3659,14000-14016

Battlefield V - Xbox One

• TCP: 3074
• UDP: 88,500,3074,3544,4500

Battlefield V - PC

• TCP: 5222,9988,17502,20000-20100,22990,42127
• UDP: 3659,14000-14016,22990-23006,25200-25300

[Netduma Fraser]

The games console service encompasses ports 1024-65000 so it more than covers all the ports for BFV for PC so the fact it's not working is slightly odd. Are you referring to bandwidth on Bandwidth Allocation? Thats normal as when devices are connected they need a share of the bandwidth available but gaming doesn't require much bandwidth at all, a lot less than 1mbps. 

Could you take a screenshot of the entire QoS page please with the option menus open so we can take a look? Are you using VPN Hybrid, PPPoE, VLAN or IPv6?

[NBA]

All my settings are correct.  It is a firmware bug/s that is the issue as pointed out here 

...by xr500user.  I followed the reboot sequence he recommends and QOS and High Traffic Prioritization began to work correctly with the console service workaround which should still be fixed.  The packet loss detection symbol in BFV has also disappeared. 

The instructions below should be stickied and included with the manual until the bugs are corrected.  Thank you xr500user and everyone else for helping!

xr500user

Posted yesterday at 03:21 AM

"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!"

 

[Netduma Fraser]

Glad you got it working. The team should be aware and assuming they can reproduce they'll be able to work on a fix

[xr500user]

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

 

[Zippy]

20 hours ago, Netduma Fraser said:

Glad you got it working. The team should be aware and assuming they can reproduce they'll be able to work on a fix

Fraser I know you guys are working hard.. Make no mistake about that.. But when I read this post and others alike I see a lot of similarities that point there is something wrong.. You guys have to be taking notice of this. When I get some free time im going to use what xr500user suggested for a startup/setup procedure.. But I have a few questions if you could help.

1) Have you guys yourselves used other browsers other than google to test this router?

2) When I log into the router can one go wireless or should we always be hardwired?

3) Since you recommend using google for a browser what settings should we make sure we enable or don't in googles browser? Since this router focuses so much on cookies what would you recommend for settings?

Thanks! 

Zippy..

[Netduma Fraser]

1. Yes we do, we test the main browsers - Chrome, Firefox, Edge, IE11 and Safari for MAC.
2. That doesn't matter, you can access from WiFi or ethernet shouldn't affect anything on the interface.
3. There's no settings specifically from Chrome I would set but I would suggest whitelisting the interface on any Adblocking extensions you may be using or any extensions that could affect network packets. Allowing the browser to cache and accept cookies as well. Nothing else I could suggest. We use a very default state for Chrome and always make sure it's up to date

[Zippy]

1 hour ago, Netduma Fraser said:

1. Yes we do, we test the main browsers - Chrome, Firefox, Edge, IE11 and Safari for MAC.
2. That doesn't matter, you can access from WiFi or ethernet shouldn't affect anything on the interface.
3. There's no settings specifically from Chrome I would set but I would suggest whitelisting the interface on any Adblocking extensions you may be using or any extensions that could affect network packets. Allowing the browser to cache and accept cookies as well. Nothing else I could suggest. We use a very default state for Chrome and always make sure it's up to date

Thanks Fraser!