: > > Apparently, this is a means to send packets to user space. I want to do
: > > something very simple. I want to grab the destination ip address of
: > > html packets and keep a log for the day of where the internal host was
: > > going that can be browsed on a public local area network web page.
: >
: > You're making it too complicated. Your NAT router is running Linux, right?
: > Just use tcpdump or tshark. Or just add an IPTables LOG rule.
Agreed. Use tcpdump and save the PCAP file for later digestion.
(Your cat really enjoys PCAPs, right?)
: Well okay, but how do I say count the number of packets and
: decide who should be delayed in the future to ensure fairness?
That's a left turn at Albuquerque.
It sounds like you are hoping to get a better feel for what's going
on in your network, and you are thinking that it would be helpful to
know which hosts inside are talking (and for how long and how much)
as well as which hosts outside you are talking with.
Perhaps I could suggest a few tools to get started. First, as Aaron
Burt suggested, try out tcpdump. Here's a command-line to get you
started, (along with a few assumptions):
tcpdump -nn -i eth0 -s0 -G 900 -w /tmp/pcap/eth0-%F-%T.pcap -- \
not port 22
Assumption 0, you can record all traffic through the device without
any legal ramifications
Assumption 1, the interface you are interested in is 'eth0'.
Assumption 2, you don't care to capture ssh/sshd communication.
Assumption 3, you have plenty of space in /tmp/pcap/.
Assumption 4, not so much traffic that 15 minute PCAPs would be big
Options:
-nn no name lookup, no port lookup
-i eth0 interface
-s0 capture complete packets (LOTS of data)
-G 900 create a new PCAP file every 900 seconds
-w <file> file naming scheme ('man 3 strftime')
-- end of options
not port 22 a Berkeley Packet Filter (BPF) expression
OK, so this should allow you to collect a reasonable amount of data.
Now, let's say that this is really not good, because (like me), you
are too lazy to sift through piles and piles of PCAP data, and are
only interested in what is happening in the instant. If so, then
'iptraf' is for you. Give it a whirl.
If you want to count packets, use a LOG rule. Note that this could
yield prodigious logging.
At the end of your message, you took a left turn, apparently in an
endeavor to visit my old friend Bugs Bunny (somewhere far from
Albuquerque). You asked 'who should be delayed in the future to
ensure fairness'. Networks and protocols are, of course, not
intrinsically fair. To boot, identifying fairness is a difficult
matter, not least because some people want to pay extra for 'more
fairness'. Some are more equal than others.
I worked with an experienced research and education (R&E) backbone
engineer once who said that if you are considering traffic control,
you simply don't have enough bandwidth. If you are on the backbone,
I buy that argument in spades. If you are an end user, you may
benefit from it.
It sounds like you need to identify your usage and define your
fairness before you can think about delaying traffic for some users.
Good luck--this is a (fun) can of worms you are opening,
-Martin
--
Martin A. Brown
http://linux-ip.net/
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug
