NNSquad - Network Neutrality Squad

NNSquad Home Page

NNSquad Mailing List Information

 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ NNSquad ] Re: Visualizing your bandwidth... 


On Nov 26, 2007, at 10:26 PM, Lauren Weinstein wrote:


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.

Yup, I had originally thought of just polling from the inside, but my issue with that was that the data collection only happens when the collector machine is turned on, etc. I imagined a scenario where little Johnny is doing huge amounts of PtP, but only at night after Mom and Dad have turned of their office PC -- this would skew the results horribly.

I had also considered the open source firmware idea, but I have seen too many bricked routers to feel comfortable doing that (I once bought a pile of 12 WRT-54s from some bloke for $4. Seems he worked at a school that handed them out to students and these were the ones that the students had returned as defective -- of the 12, 1 of them looked like it had soda poured in and the other 11 seemed to have failed a firmware upgrade -- I managed to get them all working again and gave them away, used them as low power machines, etc.)

W 

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


For every complex problem, there is a solution that is simple, neat, and wrong.
-- H. L. Mencken