This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I use a software called PeakHour to monitor internet traffic from my Mac. It uses UPnP to obtain this information from the router. There appears to be a bug in the router where it stops reporting once it reaches MAXINT (4294967295 bytes). It appears to be very similar to this post here from 2019.
Re: UPnP not reporting stops responding values for data sent/received
> Is there a possibility that PeakHour is not actually connected to and monitorint the RBR850 at all?
Thanks for your answer!I wasn't using SNMP but UPnP. If it weren't connected, it would never work, and the thing is it works for a few hours before starting to report zero. Using upnpc we can clearly see that both "Sent" and "Recv" report 4294967295 then, which is *exactly* 2^32 (unsigned maxint). So this does look like simply too small a data type to be able to track the bytes.
Oberon:~ remco$ upnpc -s
upnpc : miniupnpc library test client, version 2.2.3.
(c) 2005-2021 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
desc: http://192.168.1.1:5000/rootDesc.xml
st: urn:schemas-upnp-org:device:InternetGatewayDevice:1
Found valid IGD : http://192.168.1.1:5000/ctl/IPConn
Local LAN ip address : 192.168.1.13
Connection Type : IP_Routed
Status : Connected, uptime=12553209s, LastConnectionError : ERROR_NONE
Time started : Fri Jul 9 00:54:28 2021
MaxBitRateDown : 1000000000 bps (1000.0 Mbps) MaxBitRateUp 1000000000 bps (1000.0 Mbps)
ExternalIPAddress = 179.27.215.90
Bytes: Sent: 4294967295 Recv: 4294967295
Packets: Sent: 37829630 Recv: 36722583
Just for completeness, I've given up. I'm probably being a bit of a **bleep** about this but I just don't like NetGear's attitude about what for me is so clearly a data type bug, like I've seen many. What happened after I submitted the bug was that I got a mail with a request for a LOT of information (of which 40% was already in my original bug report). I then got the instruction to install the firmware again, even though it was the same version. Fair enough, it could have been a faulty install. But what they wanted me to do next is to do a clean install and not use a backup. I know I do that, configure all again from scratch to prove it is STILL broken en then load the backup again but I just feel this case is not being treated correctly by NetGear. So I just sent them this:
I’ve thought about this and let’s just close the ticket. I just get annoyed thinking about this bug and postponing. Reason being that it’s so obvious for me that this is a bug and has nothing to do with a backup (data) that I just don’t want to spend the time on this, losing hours on executing useless instructions to make it reproducible. I already spent too much time on it and even went out of my way to provide you a way of querying UPnP yourself. NetGear is clearly not interested in solving it. For me the logical response would be that you guys set up an Orbi yourself and query the UPnP parameters, potentially showing me that it works FOR YOU instead of making me go through more hoops. It just feels to me like this approach shows the wrong attitude on NetGear’s end. Nothing personal, you’ve been friendly enough and I’m sure you’re just following orders. Me for my part will just simply not use UPnP and I know I shouldn’t be getting a NetGear next time.
I'm just leaving this here for the next poor sucker that wants to submit a bug to NetGear and is willing to be their unpaid debugging department.
For anyone interested and for completeness; this was solved in the firmware version that broke the admin panel and still works in the patch they released for that.
For anyone interested and for completeness; this was solved in the firmware version that broke the admin panel and still works in the patch they released for that.
