From: Ed W <lists@wildgooses.com>
To: gentoo-embedded@lists.gentoo.org
Subject: [gentoo-embedded] Suggestions for per user bandwidth accounting over a router device?
Date: Fri, 11 Mar 2011 12:41:46 +0000 [thread overview]
Message-ID: <4D7A188A.6050408@wildgooses.com> (raw)
This is almost certainly the wrong place to ask, but have any clever
folks here got some ideas for doing per user (and eventually per
user/per protocol) accounting for data crossing a router box (running
gentoo)?
The situation is something like: users connect to the router, are
authenticated and then the router forwards data through one of several
WAN connections (wireless, 3g and dialup). The goal is to track usage
per user across each *WAN connection* in order to bill appropriately
(because it costs more to use dialup than to use wireless, but sometimes
dialup is all that is available - the hotspot is mobile...)
For various reasons we can't assume that the bytes in/out from the LAN
to the router are the same as the bytes sent over the WAN, eg in the
simplest case lets add a squid proxy to the router and now the billable
WAN data may be much lower than the LAN data. Additionally the router
will host a simple CMS/file share that won't cause data to go over the WAN
I guess the pieces are:
1) User authentication on the wired/wireless (LAN) input side (802.1x +
perhaps a captive portal which also auths via radius?)
2) Gateway which allows authenticated users to route through the various
WANs
3) Packet accounting that collects info on the data used over each WAN
I'm somewhat unsure what my options are though to pass through the
per-user auth info collected in step 1 to other pieces of the puzzle? I
could build a mapping of users to IP addresses and then IP becomes a
synonym for "user". Are there other packet marking techniques I could
use that will scale to hundreds of users? (eg vlans appear not to be a
sensible option?)
I think 3) will often require support from the applications running on
the router itself, eg a web connection passing through squid is hard to
account for across the WAN because it all looks like a mass of data from
the squid process. Any thoughts on a scalable way to account for the
data from each app and log it? (Radius / DB / some library which someone
already wrote?)
Ideally I would like to be able to show quite granular statistics for
each user, eg connection at 8pm for 10 mins, 200KB of email, 5KB web,
2KB DNS. Can radius be (mis) used to track accounting to this low level?
The WAN connections in this scenario are quite expensive and we have a
requirement to track quite granularly...
Thanks for any pointers to techniques I could use to solve any of the
pieces above? Note: I'm currently pulling apart wifidog and coova to
get some ideas about how some of the captive portals implement the
gateway part, but their bandwidth accounting is all measured at the user
side and I need to measure mine at the WAN side...
Thanks
Ed W
next reply other threads:[~2011-03-11 13:04 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-11 12:41 Ed W [this message]
2011-03-11 16:27 ` [gentoo-embedded] Suggestions for per user bandwidth accounting over a router device? wireless
2011-03-11 19:15 ` Ed W
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D7A188A.6050408@wildgooses.com \
--to=lists@wildgooses.com \
--cc=gentoo-embedded@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox