gurth

I will be at work 30 miles away during most of those hours. If I turn on 'Allow Remote Access to Tech Support' will it give you the access you need to diagnose?

Share excess has been enabled for all tests. IPv6 is disabled for both WAN and LAN and has been disabled for all of the testing. I disabled DNS Override and ran a couple tests. QoS Off - 125 Mbit/s down, 18 Mbit/s up Qos On - 20 Mbit/s down, 10.85 Mbit/s up

Here is the QoS page. I had to shrink the browser down so it could all fit in one screenshot. Hopefully you can read it still.

The dsl modem does do PPPoE, but I am not bridging the connection to the R1 to perform PPPoE there. I'll put a picture of my WAN setup below. After checking 'Disable QoS' in the Anti-Bufferbloat settings, my speedtest was: 131.19 Mbit/s and 20.23 Mbit/s, which is what I would have expected. So what's going on with QoS that totally kills my connection? How many features get disabled when I check that box? It says it prevents the router from doing deep packet inspection and 'other features'. What are the other features?

Just performed this test: Rolled back to 1.03.6j There was no option to 'preserve settings' or anything like that, but it appears that all the settings from DumaOS were kept. Without changing anything, immediately speedtest from host that was 3 minutes ago getting 8 Mbit/sec 128.96 Mbit/s down, 20.58 Mbit/s up. Update R1 to DumaOS 2.1.2.10. Without changing anything, speedtest from same host in step 2. 18 Mbit/s down, 7.37 Mbit/s up. At this point, I don't know what else to test or check. It seems with my setup, there is something inherent in DumaOS that is killing throughput.

Speedtests from multiple hosts (using speedtest-cli in ubuntu) are consistent, so it's not isolated to a specific host.

DHCP vs Static for the hosts? I have static IP's for the R1 WAN to talk to the dsl modem. Everything else is dhcp (including the host I am speedtesting from), but from a different dhcp server I manage outside of the R1. The R1 dhcp options don't allow me to set a custom dns server for the dhcp clients, which I need. I just ran this test: Disable other dhcpd. Enable dhcp on R1. Set R1 WAN dns to dsl modem (previously this was pointing to a dns I manage). Release/Renew ip on host. Verify it displays as a lease on R1. Speedtest. Result: 100% cpu displaying on Duma and 5.95 Mbit/s download speed. Immediately retested and got 7.88 Mbit/s

Thanks Fraser. Factory reset solved the get_dhcp exception, however, speeds are still pretty horrible. Before the upgrade, my speedtests would hit 120+megabit. Currently I am only seeing a max of 19. I noticed if I watch the CPU Usage on the dashboard of the Netduma that the CPU pegs at 100% during the speedtest. While the factory reset was happening I rebooted the desktop I was testing from as well as the DSL modem. My network layout is desktop->netduma->dsl modem. Anti-Bufferbloat is set to never for testing and Share Excess is checked. Download Bandwidth is set to 151Mbps and Upload is set to 22Mbps. 'Goodput' is checked, which was the default after I reset to factory. Thoughts? I was going to immediately roll back to the old firmware, but if my issues can help solve some bugs in DumaOS, I'm happy to help.

Rebooting does not solve the problem. I am going to try a factory reset. Also, I don't know if it's related, but my wired download speeds are abyssal now. I checked immediately prior to installing DumaOS and I am now running about 1/8th the download/upload speed.

I had DHCP disabled on the NetDuma before upgrading to DumaOS. Now when I go to the Network Settings link, it generates the following exception: Mon Oct 15 16:08:24 2018 user.warn com.netdumasoftware.settings: RPC call 'get_dhcp' exception 'bad argument #1 to 'match' (string expected, got nil) -> stack traceback: ?: in function <?:73> [C]: in function 'match' ?: in function '?' ?: in function <?:163> ?: in function <?:324> [C]: in function 'xpcall' ?: in function 'try' ?: in function <?:290> [C]: in function 'run' ?: in function <?:345> [C]: in function 'xpcall' ?: in function 'try' ?: in function <?:261> (tail call): ? At this point none of the Network Settings show up.

Sorry, I didn't see it in the supported list and incorrectly assumed it wouldn't be supported if unlisted. It's still downloading for me, so I will have to report back once it's done.

Since For Honor has peer to peer networking, it would be awesome to have the GeoFilter work for that game.