NNSquad - Network Neutrality Squad
[ NNSquad ] Re: Visualizing your bandwidth...
Warren, This is most certainly *not* a stupid idea! SNMP seems ripe for leveraging, even with its limitations. I agree that there are some issues, though. I am not very comfortable with the concept of people opening up their WAN routers' SNMP to the outside world, even with changed community strings. Some routers are difficult to configure for WAN SNMP access without also opening up the HTTP and TELNET configuration interfaces to the WAN. In general, I prefer to keep the SNMP interface per se behind the firewall. There is another topology that we could use to collect the SNMP data from volunteers. We could make available a script/program that users could run themselves, that would collect the SNMP data from the *inside* of their networks, package the data up and send it out encrypted to the data collection server. This solves the dynamic IP problem, and provides what I'd consider to be a necessary security/privacy layer. It also gives the user absolute control over when and how often data is collected and sent. Admittedly, it also opens up the possibility of easier tampering with or falsifying of the data, but this is an issue that we have to deal with in a variety of contexts, I suspect largely through statistical analysis. For ease of portability (though not necessarily readability) a perl-based system might be a useful starting point that could be run on most deployed consumer and business platforms likely to be enrolled in the project. Both the user scripts and the data server will need to meet a variety of security and privacy requirements, and decisions will need to be made regarding which collected data is suitable for public release, when it should be made available, in what form, and with what sort of accompanying analysis. There will also need to be detailed explanations, the usual disclaimers, and associated boilerplate so that participants understand as much as possible about what the project is doing and how their participation fits into the project's work. An SNMP data collection system could indeed be a worthwhile effort to get us rolling! --Lauren-- NNSquad Moderator - - - > > Hi, > > So, I was thinking that it might be useful for consumers to be able to > see how much bandwidth they are actually using -- sure there are many > consumer applications that will monitor the bandwidth that the local > machine is using, but monitoring the bandwidth that all of the > machines behind your NAT is somewhat trickier for most users. > > I was thinking of setting up a website where users can sign up (they > will need to be willing to share their provider and general geographic > location). The site will provide simple instructions for configuring > (RO!) SNMP access for most of the consumer NAT devices (and each user > will use a unique SNMP community). I will then start polling the > device and generating MRTG type graphs for the user. The general > location and provider information will also allow for the generation > of aggregate / average information that can be publicly posted / > shared (individual users graphs will only be available to them...). > > Issues: > [1]: Dynamic addresses -- when the user first signs up it is easy > enough to figure out their (external) address (assuming that they sign > up form hom)e. If they do not have a static address, they will either > need to use some sort of dynamic DNS system (DynDNS?) or run a client > app that tells the poller when their IP has changed. > > [2]: Allowing SNMP to their external interface -- AFAIK, many of the > consumer NAT devices already allow SNMP polling (many with the > community "public" (I just scanned my /24 and 14 devices answered an > SNMP poll with 'public' as the community!)) > > [3]: Is this a stupid idea? > > > Anyway, thoughts? > > W