Hi all,

I'm attempting to create a shell script that will allow me to monitor the amount of broadcast packets being picked up on the LAN I'm using. I'm doing this on a Fedora Core 1 box that I happen to have here, though my "native" environment is Debian and Windows.

Basically I'm not sure where to start. I'm looking at tcpdump but can't fathom a way to count packets from that - my end objective is to be able to graph the results (or have results in a graphable form) so I can see what's happening with the traffic being received. I'm looking to have this happen in real time as opposed to analysing past captures - to have something running continuously to provide up-to-the-minute data.

Any advice to this end would be greatly appreciated! Thank you for taking the time to read this.

Biggs

Almost all packet counters in one or another way are based on tcpdump or the libcap libraries. Maybe you can steal some ideas from there.

Another idea might be to use iptables. Either you match the broacast packets and log them to a file (if you are interested where they come from) and you read & process the file.

Or you could use the internal counters of iptables, which you can read and reset.

jlinkels

Thanks for your response. I'm not intimately familiar with iptables (and more's the pity) but I will read up and see what I can find.

If I were to set up a script to log the iptables counter value and then reset it each minute - would that seem a reasonable thing to do? I should explain that I'm on a large University network on which each node receives a fair amount of broadcast traffic, and I'm looking to see how that "chatter" varies over time.

Thanks again for your reply.

Biggs

If you have large amounts of traffic iptables is definitely the best way to go. See, the script will only be querying iptables each minute (not much overhead), and some additional rules have to be added.

Here's the basic gist:

1. You create a new chain (in the filter table) that will be soley for broadcast packets (maybe call it bcast or similar).
2. In your INPUT chain, you put an appropriate `jump' to said chain.
3. Since there is nothing actually in the bcast chain, the packet will only `touch' the chain, and then resume what it was doing.
4. So then, you need to parse the output of iptables's query of the netfilter chains in a loop.
   • This can be viewed with `iptables -nvL' (verbosely list the chains with numbers instead of DNS)
   • You should see a chain bcast with counters for pkts and bytes
   • You can zero the counters on a chain by using `iptables -Z bcast'
   • Then sleep for 60 seconds
   • Lather, rinse, repeat.

There is plenty of docs around on the Internet. Unfortunately the learning curve is quite steep.

As soon as you understand what forwarding and masquerading is, you can get a kickstart by installing the ipmasq debian package. You need to understand forwarding because that is most likely what you are going to disable on this box. ipmasq creates a firewall script for you based on your current computer configuration and provides an excellent example.

I would say so. I know of at least one traffic counting package that works in that way (ipac-ng). Unfortunately that package is broken.

jlinkels

Okay, that's great, thanks to you both.

My next question is: if I'm looking to count IP and Ethernet broadcast packets, and IP and Ethernet multicast packets (all together in one rule), what protocols/options am I going to have to give iptables?

Thanks again,

Biggs

I should add that I want to include ARP and ICMP traffic in the count with the IP and Ethernet broad/multicasts, and that the counts would ideally include all packets received, even if they're ultimately dropped by the system (the packet count on the normal INPUT chain seems lower than what tcpdump shows coming in). Thanks again.

AFAIK, broadcast and multicast are strcitly on the IP level (although UDP is often used with multicast). A broadcast address will apply to a specific network. For example, if I have a network 192.168.18.0/24, then any packet with a destination of the broadcast address (192.168.18.255) will (theoretically) reach all hosts on that network. So to match broadcast, you just have to match all packets with destinations of 192.168.18.255.

Similarly, multicast traffic is sent to a specific destination address. Any packet with a destination in the range 224.0.0.0/4 should be considered multicast. Thus, you only have to make a rule to match packets with that destination address.

I do not think iptables can do arp (anyone?). For that there is arp_tables. ICMP traffic can be matched with `--protocol icmp'. If you put the jump to the dummy chain at the very beginning of INPUT, then its count will reflect the number of attempted packets/bytes. If you put it after any ACCEPT, DROP, or REJECT jumps, it will not be accurate (for example, if you put it after all DROP and REJECT targets, then it will show only those that were accepted). Also, make sure that none of the PREROUTING chains is messing up your count.

Also, when doing packet/byte counts, use `iptables -nvxL' instead of just `iptables -nvL'. The -x makes sure that the `byte-count' will be measured in powers of 2 instead of 10 (for example: without -x 5 kilobytes = 5*10^3 bytes, but with -x 5 kilobytes = 5*2^10 bytes).

Thanks again for your reply. I take it I should put all the testing conditions on the INPUT chain, then only jump to my chain (bcast) if those are met, thus allowing me to count from the bcast chain - right?

Edit: Ignore this, I've got the logic of it worked out in my head now .

Thanks again,

Biggs

Also, should I add seperate rules for each "condition" I'm testing for (broadcast, or icmp, or etc) or is there a way to conveniently combine them in one rule? Thanks. B

The normal thing to do is to write many rules whose destination is a single chain. Then count the packets/bytes on that chain. The rules should be located close to each other in the script.

E.g., in your firewall script:

Got it - and it seems to be working!

Now for some fun with rrdtool. Many thanks to both of you for your helpful replies!

Best regards,

Biggs