RPC call 'get_dhcp' exception 'bad argument #1 to 'match' (string expected, got nil)

[gurth]

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.  

 

[gurth]

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.

[Netduma Fraser]

Okay thanks for this, we'll try to reproduce it. Let us know if the factory reset fixes both this and the speed issue.

[gurth]

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.

[Netduma Fraser]

Great to hear that. If you use DHCP instead of static does that resolve the speed issue?

[gurth]

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:

1. Disable other dhcpd.
2. Enable dhcp on R1.
3. Set R1 WAN dns to dsl modem (previously this was pointing to a dns I manage).
4. Release/Renew ip on host.
5. Verify it displays as a lease on R1.
6. Speedtest.

Result:  100% cpu displaying on Duma and 5.95 Mbit/s download speed.  Immediately retested and got 7.88 Mbit/s

[gurth]

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

[gurth]

Just performed this test:

1. Rolled back to 1.03.6j
   1. There was no option to 'preserve settings' or anything like that, but it appears that all the settings from DumaOS were kept.
2. Without changing anything, immediately speedtest from host that was 3 minutes ago getting 8 Mbit/sec
   1. 128.96 Mbit/s down, 20.58 Mbit/s up.
3. Update R1 to DumaOS 2.1.2.10.
4. Without changing anything, speedtest from same host in step 2.
   1.  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.

[Netduma Fraser]

Are you using PPPoE or anything like that? If you disable QoS completely from Anti-Bufferbloat options do your speeds increase?

[gurth]

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?

 

 

[Netduma Fraser]

Can you send me a screenshot of your entire QoS page please and I'll see if theres anything that could have caused it. It won't prioritize games ahead of the network queue and the application breakdowns etc of Network Monitor won't go into detail

[gurth]

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.

[Netduma Fraser]

All looks fine there assuming share excess is enabled. Did you enable IPv6 for LAN or WAN by any chance? Also remove the DNS, that might be a cause as it will get DNS from the upstream router anyway but you're overwriting that and saying don't get it from the upstream router get it from the upstream router and oh if it fails get it from the upstream router again! So those options don't make sense. Disable that or use Google DNS or Cloudflare or something like that then rerun the test with QoS enabled but off

[gurth]

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

 

 

[Netduma Fraser]

Will you be available at some point tomorrow 11:30am-5:30pm GMT for a 1 on 1 to look further into the issue?

[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?  

[Netduma Fraser]

It would yes but we need to be able to make changes on the frontend also. Would you be available tomorrow during the day or perhaps in the evening tomorrow?