[SOLVED] Spike in bandwidth monitor graph

Discussion in 'Tomato Firmware' started by Ole Juul, Mar 13, 2018.

  1. Ole Juul

    Ole Juul Networkin' Nut Member

    A while ago I started getting the occasional spike in my bandwidth monitor graph. The number peaks to over 17 million kbps so is obviously not real. These spikes are occurring much more often now, but seemingly not regularly. I'm guessing every half hour or so. I have not been able to coordinate it with any particular IP or event. However, I just noticed that the router uptime resets at that moment.

    It is showing up on all IPs. There is nothing in the logs to suggest anything wrong. I am running Tomato Shibby AIO 1.28 on an Asus RT-N16.
     

    Attached Files:

  2. koitsu

    koitsu Network Guru Member

    This is known to happen sometimes if/when you reboot the router. It's a known issue people have been trying to solve (albeit badly) for some time.

    It's not a problem specific to TomatoUSB either; MRTG and rrdtool (general software for graphing/monitoring network interface traffic) have this issue as well.
     
  3. Ole Juul

    Ole Juul Networkin' Nut Member

    Funny that this should show up now, after having run that router for some years. I also have a problem with a remote Win10 computer, connected through a remote wireless access point, losing connectivity - no idea if it's related but it seems that I'm having several problems here which never used to happen. Note that it is not me rebooting the router. So if it's not caused by the spike then it would seem logical to conclude that thee is a problem with the router - and that would be consistent with an increased frequency.

    I am thinking that getting another router and updating Shibby may solve the problems. That wouldn't be a bad idea anyway, but if it's unrelated would be less urgent.
     
  4. koitsu

    koitsu Network Guru Member

    The spike is for WAN (vlan2) interface traffic specifically (not wireless). Your WAN port couldn't reach those kinds of speeds, so it's caused by a router reboot. That can happen as a result of a crash (kernel panic), memory exhaustion scenarios, loss of power, or several other things. Status -> Overview -> Uptime will show you if it rebooted, and maybe you can correlate the two. Otherwise, if you're using PPPoE/PPPoA, it could be possibly caused by a PPP session drop/reset but I'm not entirely sure (I don't have this setup, so I don't know if WAN with PPPoE is vlan2 or if it's, say, ppp0 interface).

    It's very difficult to troubleshoot a crash/kernel panic due to the fact that there are no permanent/persistent logs -- all you'd know is your Uptime would show, say, N days, then suddenly your network stops working for a few minutes, restores, and Uptime would say 0 days 2 minutes. There are known crash scenarios though, such as when using QoS and BW Limiter features together simultaneously (use one or the other), but those are tribal knowledge.

    Your wireless drop-out issue is completely unrelated to the bandwidth spike issue. Wireless reliability/connectivity issues are one of the most difficult things to troubleshoot and solve reliably. I generally do not recommend "tweaking" anything in Advanced -> Wireless, no matter what people on this forum tell you. You have to know exactly what the situation is before you go tinkering with stuff in there. I tend to recommend people use wired Ethernet instead, if at all possible.

    Off-topic, but I stopped using my Asus RT-N66U and Asus RT-AC56U for wireless (disabled both 2.4GHz and 5GHz interfaces) some time ago, and instead bought a Ubiquiti UniFi AP AC Lite. It works fine with Tomato, handling just the 802.11 (wireless) part. It's fairly inexpensive and awesomely reliable. You can read my post about it here, both pros and cons.
     
  5. Ole Juul

    Ole Juul Networkin' Nut Member

    Thanks for all the info koitsu. It seems that the rebooting/restarting problem is most likely a router issue. The power source is good. I'm just watching uptime, and can now see that it correlates with the spikes. I use a pretty plain setup and it's basically been the same for years.

    Regarding the wireless, that is not the wireless on this router that is being used, but the AP is connected here. No doubt everything else is being stopped for a couple of seconds, but that's not a deal breaker for ethernet. So now that I know that we're getting a restart here, that explains why the AP would drop it's connection to the laptop which has also been solid for a couple of years until now.

    So, it seems that I would do well to replace the router. I have a strong preference for Shibby so it seems the ASUS RT-AC66U B1 would be a good choice. It's the routing that's important to me though. Wireless is just "meh" in my world.
     
  6. koitsu

    koitsu Network Guru Member

    Some Asus RT-N16 routers are known to have bad (cheap) electrolytic capacitors that end up bulging (leaking) over time, causing voltage drops and thus power failures/reboots. Just Google "RT-N16 capacitors" and you'll find lots of details. A visual inspection + knowing what to look for can sometimes rule this out, but not always. Another problem I heard of in the wild were questionable transformers (AC adapters). I ran my RT-N16 for several years with success, so I think I just got lucky. Toastman also used them extensively throughout MDUs. Sad, because they were the pinnacle of routers for me.

    I tend to like my RT-AC56U/RT-AC56R (they're the same thing, and both work with TomatoUSB; I run Toastman's builds), but doing the stock firmware -> TomatoUSB upgrade can be extremely finnicky (it's a commonly reported issue/quirky thing here), especially relating to NVRAM variables post-firmware-replacement (the router can be accessible via telnet/etc. but the NVRAM variables are wrong/botched).
     
  7. Ole Juul

    Ole Juul Networkin' Nut Member

    I read about the capacitor issue. There's good info on the net about that, and I've always got a hot soldering iron ready here. I don't want to have loss of connectivity for very long though, so I think I'm just going to get the RT-AC66U B1 so that I will just be able to switch them out. Then I will also have the old one as a pre-configured emergency backup. I have had some good years of service from the RT-N16, so can't complain.

    I see the B1 model also has a 1 GHz dual-core CPU and is on sale for CAN$149.99 with free shipping from Newegg.ca. I have the tomato-K26USB-1.28.AT-RT-N5x-MIPSR2-3.5-140-AIO.trx image and I assume that is the latest one that will work for me.
     
  8. Ole Juul

    Ole Juul Networkin' Nut Member

    The problem is found. I simply wiggled the power adapter and the spikes stopped. I have no idea what kind of flakiness could cause a disconnect or issue there that would be so short and with so long in between and persist for two months while sitting still in an untouched area. In any case, that was it. There has not been a spike for 19 hours now. I'll leave it as is for now and consider replacing the psu if the issue comes back.

    Also, a bit of research and I see that the RT-AC66U B1 is not supported by Shibby. Too bad, because that's a good price for a 2 core 1 Gig CPU. I might look at the Netgear R6250 instead.
     
  9. koitsu

    koitsu Network Guru Member

    Sounds good. On my RT-N66U I did find that after doing some cable management the AC plug had almost come out of the unit. I really dislike "wall wart" AC adapters/transformers and prefer PSUs be integrated + device use a universal power cord. The device-end of wall warts tend to come loose very easily.

    I did track down the source bits. I don't know if this is in other branches (ex. Shibby), but they are in latest Toastman:

    Toastman-ARM7:
    https://github.com/tomatofirmware/tomato/commit/0041e12636bba20c6f27271d46336675256f3202
    https://github.com/tomatofirmware/tomato/commit/4757dbf5caea183ab52df725fc5dfcd262a74ee0
    https://github.com/tomatofirmware/tomato/commit/1631a65331d70e69cb101bd7c401826d330e2238

    Toastman-RT-AC (MIPSR2):
    https://github.com/tomatofirmware/tomato/commit/984bd331075bf5c98fbc3e53ed70a6f053025e79
    https://github.com/tomatofirmware/tomato/commit/c4ea335a19ca6369158b3f1aaa2f002d1a0b8bf5

    However I'm not really sure these fixes are truly correct -- rollover things like this are often problematic and tricky. There's a forum thread about it (I participated), but I'd have to dig through this forum to find it again. It might be in the massive Toastman thread. But the point is, those are in Toastman firmware.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice