Multiple Issues With R2.

[Hungstick]

Hello everyone! It has been a while, but I’ll try to make this as detailed as possible.

I noticed we are on the DumaOS 4 web GUI, as when I plugged in my R2 for the first time in about a year, it showed it. I factory reset it and got it connected.

I noticed the speed test in the auto setup wizard wouldn’t complete—no problem, I skipped it. I went to the Ping Optimizer and had the same issue, so I skipped that as well.

I loaded into the GUI dashboard and selected the only device on my network for testing purposes: my PC. I selected the server region via my location, which, by the way, does not do anything when I click it (I had to manually enter my state).

Upon trying to join a game, I noticed it was throwing me into Dublin, as shown in this picture (or at the least trying to connect to it), even though Strict Filter Mode was turned on. It did let me connect twice into a server with a ping of 27. After that, I was placed once into a server with 147 ping.

So I reflashed the R2 firmware and factory reset it once again. Upon coming back online and selecting all the settings again, the speed test and Ping Optimizer worked. But now we fail to connect to Call of Duty servers. I allowed that Dublin server, thinking it was an official COD server it was failing to connect to due to the strict filter. Same issue.

I tried to resync the cloud multiple times, and even went to Device Manager and set my PC as a console (as I was told years ago this would work).

We seem to be struggling with multiple issues, and I’ve kind of exhausted all ideas on what to do next. We are also experiencing high latency while on Ethernet, along with packet loss, as shown in this state:

Ping statistics for 1.1.1.1:
Packets: Sent = 234, Received = 232, Lost = 2 (0% loss),
Approximate round-trip times in milliseconds:
Minimum = 10ms, Maximum = 442ms, Average = 22ms

Any ideas? I would love to hear them. What seems to have stopped me from using the Netduma R2 a year or so back was the GUI crashing constantly. While that is no longer an issue, the connection is now. I've included some pictures, along with the Logs file. I hope this helps!

R2_2026-05-22T03_45_47.263Z_logs.txt

[Paulo_81]

R2 is outdated, forget about it.... the last update was a beta test of DumaOS4, which is almost 2 years old now, and there haven't even been any improvements to the stable version since.... their focus is on R3! They promised a version in December, I don't know if it will be beta or final, but so far nothing!

[Netduma Fraser]

The dublin server is an authentication server required for online play so you may need to allow servers appearing blocked there a few more times and then it should work just fine. If you could then provide the IDs we can get the cloud updated with them. 

[Hungstick]

4 hours ago, Netduma Fraser said:

The dublin server is an authentication server required for online play so you may need to allow servers appearing blocked there a few more times and then it should work just fine. If you could then provide the IDs we can get the cloud updated with them. 

While that may fix the connection error, you seemed to have not looked through the provided log files i uploaded. 

• Why is hostapd failing every 6 seconds for 15+ minutes straight?
• Why are the interfaces constantly reloading?
• Why is QoS throwing RTNETLINK errors?

[Hungstick]

5 hours ago, Paulo_81 said:

R2 is outdated, forget about it.... the last update was a beta test of DumaOS4, which is almost 2 years old now, and there haven't even been any improvements to the stable version since.... their focus is on R3! They promised a version in December, I don't know if it will be beta or final, but so far nothing!

Seems like their track record looking through other issues from people in the forums. 

[Netduma Fraser]

I did miss that part, my apologies. The logs are primarily for the devs to look at if needed and as such they're quite verbose, they contain backend entries that can look like issues but are normal processes. I doubt they specifically will be causing you issues but if it ends up that they are I can pass them on for more investigation.

• What is the model of the modem/router the R2 is connected to and how have you set that to ensure all traffic flows to the R2? E.g R2 in its DMZ, modem/bridge mode
• Are ALL devices connected to the R2?
• What are the speeds you pay for/receive & have you entered those speeds into the router?
• How have you setup Congestion Control?
• How have you setup SmartBOOST?

[Netduma Fraser]

5 hours ago, Paulo_81 said:

R2 is outdated, forget about it.... the last update was a beta test of DumaOS4, which is almost 2 years old now, and there haven't even been any improvements to the stable version since.... their focus is on R3! They promised a version in December, I don't know if it will be beta or final, but so far nothing!

1 minute ago, Hungstick said:

Seems like their track record looking through other issues from people in the forums. 

The R2 was sold with DumaOS 3, DumaOS 4 wasn't advertised as a reason to buy the R2, it was developed on the R3 itself and to get it on the older R2 hardware was a challenge that we didn't need to do but wanted to for our customers. We've explained why there have been delays and this hasn't just been for the R2 either. We never promise firmware because it's always subject to change, I've said many times we don't provide ETAs. The next R2 DumaOS 4 firmware would be the final firmware so the more time we take the more stable it will be overall. Also it is a support forum so there are only people posting issues here.

[Hungstick]

3 hours ago, Netduma Fraser said:

I did miss that part, my apologies. The logs are primarily for the devs to look at if needed and as such they're quite verbose, they contain backend entries that can look like issues but are normal processes. I doubt they specifically will be causing you issues but if it ends up that they are I can pass them on for more investigation.

• What is the model of the modem/router the R2 is connected to and how have you set that to ensure all traffic flows to the R2? E.g R2 in its DMZ, modem/bridge mode
• Are ALL devices connected to the R2?
• What are the speeds you pay for/receive & have you entered those speeds into the router?
• How have you setup Congestion Control?
• How have you setup SmartBOOST?

To clarify my setup:

The Arris SB8200 (DOCSIS 3.1) feeds directly into the R2. The R2 is my main router for all wired/ethernet devices. I have a second router connected to the R2, but that is only used for WiFi devices — all gaming and primary devices are on ethernet directly through the R2, so all relevant traffic is going through it.

To answer your questions:
- Speeds: 120 down / 20 up, and yes those are entered into the router
- Congestion Control: set at 50/50 for both upload and download
- SmartBOOST: not currently enabled
- The R2 is not in DMZ or bridge mode as it is the primary router — the SB8200 is a modem only

I also want to flag some errors from my system logs that weren't addressed: hostapd is throwing "Failed to set beacon parameters" repeatedly every few seconds, cfront bottomch is constantly reloading interface IPs, and QoS is generating RTNETLINK errors. These seem like they could be contributing to instability and I'd appreciate those being looked at as well.

[Netduma Fraser]

Is Congestion Control set to Always or Auto? Have you found 50/50 gives you the best results or just randomly set? SmartBOOST should be used so the devices/applications you care about get prioritized above traffic you don't care about as much, if there was something impacting your ping results then this would help it. Given the ping statistics you provided, you had a maximum of 442ms but over 232 successful packets your ping averaged 22ms which indicates that you only experienced a couple of quick spikes rather than a consistently high ping and so it was relatively stable overall with 2 packets lost at just under 1% that's quite acceptable and I assume they would have happened with those couple of spikes which makes sense. So far then it indicates it's more of an isolated incident of spikes rather than a persistent one. 

The logs contain entries that can look like issues but are normal processes, that's why it's best for a user not to try to diagnose issues solely based on logs, if issues are occurring that can't be diagnosed through normal means then logs can be looked at for more information by the devs but its very rare this is needed and the entries you've mentioned aren't anything I haven't seen before. For example the hostapd entry can occur when Ping Optimizer fails and that could occur for any number of reasons such as the server times out and so it can't set the correct Congestion Control percentages etc. Some can appear when it's not using a certain setting but it looks like an issue because that setting isn't active and fails, that's what I mean by verbose, we're not heavily restricting the output to the log, normal processes appear there that can seem troubling if you're not used to them. cfront & RTNETLINK errors weren't in the logs you provided but again they're not necessarily any immediate cause for concern.

[Hungstick]

2 hours ago, Netduma Fraser said:

Is Congestion Control set to Always or Auto? Have you found 50/50 gives you the best results or just randomly set? SmartBOOST should be used so the devices/applications you care about get prioritized above traffic you don't care about as much, if there was something impacting your ping results then this would help it. Given the ping statistics you provided, you had a maximum of 442ms but over 232 successful packets your ping averaged 22ms which indicates that you only experienced a couple of quick spikes rather than a consistently high ping and so it was relatively stable overall with 2 packets lost at just under 1% that's quite acceptable and I assume they would have happened with those couple of spikes which makes sense. So far then it indicates it's more of an isolated incident of spikes rather than a persistent one. 

The logs contain entries that can look like issues but are normal processes, that's why it's best for a user not to try to diagnose issues solely based on logs, if issues are occurring that can't be diagnosed through normal means then logs can be looked at for more information by the devs but its very rare this is needed and the entries you've mentioned aren't anything I haven't seen before. For example the hostapd entry can occur when Ping Optimizer fails and that could occur for any number of reasons such as the server times out and so it can't set the correct Congestion Control percentages etc. Some can appear when it's not using a certain setting but it looks like an issue because that setting isn't active and fails, that's what I mean by verbose, we're not heavily restricting the output to the log, normal processes appear there that can seem troubling if you're not used to them. cfront & RTNETLINK errors weren't in the logs you provided but again they're not necessarily any immediate cause for concern.

Congestion Control was likely set to Always, and the 50/50 was just whatever it defaulted to — I didn't manually set that.

The main issue I want to focus on is the Geo-filter itself. When the Geo-filter is enabled, I cannot get into a Call of Duty match at all and have to disable it just to connect. I have my location set to Oklahoma, but even with that set it was still trying to connect through the Dublin server.

Also, I want to make sure I understand this correctly — if I'm already in a match and I click block on a server showing in the Geo-filter, does that drop me from the match since I'm blocking an active connection? Just want to understand the right way to use it so I'm blocking servers before matchmaking rather than during. So we have looking at a few issues. One being that connection error when trying to login to the server in itself, two is the packet loss. There should be 0% loss. Reason i say 0 is because there's no latency spike on anther router. But i can assume that's due to how the duma os handles routing. So that might worth checking into, because that still doesn't explain still If you click the heat map, ping the call of duty servers every singel one get's NA/ on the latency test. so we can't actually see were the servers are, it's notforcing the geo filter by just limiting me to the oklahoma servers, and it's failing to connect if, geofilter is enabled. a lot of back and forth having to turn it on and off, connect, disconnect to get it to even allow the connection. 

[Hungstick]

looks like the Server IP for Dublin might be 185.34.106.103

[Netduma Fraser]

Try with 70% as that's our suggested starting point and adjust from there based on how it feels/until you don't see any spikes - keep in mind that during peak times spikes like that are more likely to occur due to ISP peak time congestion. It will always try to connect to the Dublin server as its for authentication and required for online play so if you allow it you can play with the filter enabled but you will need to do so a few times as there will be multiple servers in that location. Once you've got all the ones that appear blocked there it will work. If you block a server it should keep you connected to it until that connection has been severed and then it would be blocked. It's nothing to do with Ping Heatmap, it has a pre-compiled list of servers, they have become out of date and when they do they're unable to be pinged, by default they then show N/A -1000ms because it timed out once it hit 1000ms without a response. Everyone with Ping Heatmap is seeing the same for CoD at the moment, myself included and it will stay that way until we've updated the pre-compiled list with an updated set until they inevitably get out of date again. Here are the server locations, they never change:

[Hungstick]

10 minutes ago, Netduma Fraser said:

Try with 70% as that's our suggested starting point and adjust from there based on how it feels/until you don't see any spikes - keep in mind that during peak times spikes like that are more likely to occur due to ISP peak time congestion. It will always try to connect to the Dublin server as its for authentication and required for online play so if you allow it you can play with the filter enabled but you will need to do so a few times as there will be multiple servers in that location. Once you've got all the ones that appear blocked there it will work. If you block a server it should keep you connected to it until that connection has been severed and then it would be blocked. It's nothing to do with Ping Heatmap, it has a pre-compiled list of servers, they have become out of date and when they do they're unable to be pinged, by default they then show N/A -1000ms because it timed out once it hit 1000ms without a response. Everyone with Ping Heatmap is seeing the same for CoD at the moment, myself included and it will stay that way until we've updated the pre-compiled list with an updated set until they inevitably get out of date again. Here are the server locations, they never change:

Awesome. Will give it a go. I've noticed on the Duma os4 it would say the ping is like 23 ms to Dallas,  but call of duty reads 48+ on the latency. Is this just because one's testing actual server latency. And one's testing something else?  I noticed too that majority of the time, if I'm doing some testing for instance. Let's say Dublin.   It will still put me into servers in the US. Despite having the location set over there. I would imagine how it's supposed to work is if I place my location at x. With a mile radius of x, it shouldn't connect to anything outside of that range. How it used to work if I recall, was it would keep rising your ping let's say it started at searching for a match with 36 latency, it would keep going up til it found a game. It doesn't do that now. I use the ping to determine if im connected to another location server, besides us. Because anywhere in the US since that's where I reside,  it's under 100. So for some reason trying to connect to other servers in other countries,  it still puts me in the US lobby. 

[Netduma Fraser]

So the Geo-Filter is measuring the latency to the server itself and the in game ping is showing that calculation + processing delay. All games have it but not all choose to show it in their ping calculations. As a rough guide up to ~30ms on top is okay though it can be lower so it can indicate that server is under a heavier load, in which case forcing a different server even if it has a slightly higher ping shown on the Geo-Filter might actually play better for you. 

It's essential the Geo-Filter is enabled before the game client (e.g. Steam etc) if on PC or the game have been launched. If you change Geo-Filter settings when you're on the game then you will need to restart the game for those changes to take effect, otherwise it will use the previous Geo-Filter settings and appear not to be working.

Strict Mode should also be enabled & Fast Search should be disabled, they are by default so if you haven't changed them you can ignore it. If you have changed or want to check them can be found in the Geo-Filter menu that can be found by clicking ⋮ in the top right hand corner of the page and go to Settings. If you do these things then it will stick to the radius you've set, other than any servers on the global whitelist (for example Dublin usually) or manually allowed servers (like the Dublin servers).