Jump to content

gisuck

DumaOS Insiders
  • Content Count

    34
  • Joined

  • Last visited

About gisuck

  • Rank
    Apprentice

Basic Info

  • DumaOS Routers Owned
    XR500
  1. This is definitely weird. CPU usage is low, but load averages is super high again.
  2. ... this is interesting, with QoS disabled the load average is still high, but it isn't in a race condition. It was at the same numbers as yesterday. Just turned it back on now and I'll check it again 24 hours later. Your theories on the QoS might be right.
  3. I'll have to do some testing, but disabling IPv6 might not be possible. Last year when this happened, it goofed up the IPTV, but it was a fairly new offering at the time. They might have isolated the issue. CPU graph is normalish, I guess? Typically hovering between 40%-60%. Wish there was a quick way to get the process list for you so you can do some debugging.
  4. At any given time, at least 18. Registered... 45ish
  5. So, while I'm not experiencing connection issues, I am noticing CPU load averages are creeping up again. Load avg is closing in on 14. I've disabled QoS but it doesn't appear to resolve the issue. I'll wait 30 mins to be sure, but is there anything else you would like me to try?
  6. Just Geo-filter and QoS in that list. I'm not even using your DHCP/DNSMasq. I have a pi-hole installed on my network for that.
  7. After reboot, the load averages are way down, but still seems to be high. Asking for close to 6 CPUs.
  8. Seems like the load average is extremely high here. I've been noticing my IPTV glitching out all evening, and streaming YouTube or Twitch isn't working well. About to do a reset, but seems like a bug here. Anyway to do a system debug to get top info as to what is using all the CPU?
  9. It would save me a ton of processing power if NetDuma supported Pi-Hole out of the box
  10. You probably shouldn't detect and kill outbound traffic as DoS, especially if it's DNS.
  11. Changing LAN subnet worked. Just proves that Cisco router was so broken to route traffic to WAN port when LAN failed.
  12. As far as I know, all you can do is identify the vendor, not the device type, by the MAC address. The vendor would get a unique ID on the first 6 characters. Tracking by MAC address isn't a bad thing until you put a switch between you and the destination device. That's why I thought IP tracking would be better. Just thought I put that out there.
  13. Just wondering why it would need to track a device at layer 2 since all the juicy stuff that DumaOS would be doing is at layer 3 and up. Can you not just track the device by IP only? All the port forwarding and stuff would be layer 3. Layer 2 wouldn't leave the network for the XR500 anyways.
  14. It doesn't look like Linksys does MAC address forwarding from it's switching hardware. At least, I don't see a visible configuration to do so. I'm pretty sure that this would be the MAC address of the WRT1900AC in wireless bridge mode. Basically the WRT1900AC is connecting to the XR500 via wireless, and then acting as a hardware switch on the WRT1900AC ethernet ports. Technically, there should only be 5 IP addresses used here. 1 for the WRT1900AC itself, and the 4 for the devices used on the ethernet ports. Not too sure why 7 IP addresses are in use here. It's possible that one of the devices did a DHCP renewal, but did not put in it's last used IP address as part of the request. In which case, the XR500 would offer a new IP address in which case the other IPs are stale. Well, if you look at the logs screenshot, you'd see there's a lot of DHCP traffic within seconds of each other. DHCP challenges are done in layer 2 broadcast ff-ff-ff-ff-ff-ff creating a very slow broadcast storm.
  15. Minimal. It would allow me to login to the cable modem to see signal strength and stuff in the event that my internet connection is showing packet loss, slow speeds, outages, etc. The only other reason would be if I wanted to convert the cable modem from bridge mode back to routing.
×
×
  • Create New...