data usage metering by IP on openwrt.
Does anyone know of a simple way of showing which of my machines on my home network is hogging all my data? I recently discovered that something on my network is using ~30M per hour all day and night and I'd like to find out what it is. I guess I could go around and turn each thing off and check my ISP's usage meter over a few hours, but there must be a better way of doing it. I have a WRT54GL running: Firmware OpenWrt Kamikaze - With X-Wrt Extensions 8.09 Kernel Linux 2.4.35.4 #15 Fri Jan 22 11:36:55 CST 2010 MAC 00:18:39:ED:A2:73 Device Linksys WRT54G/GS/GL Board Broadcom BCM5352 chip rev 0 Username root Web mgt. console Webif² Version r4838 I'm very lazy, so an installable package that can do this over a web interface would be ideal, but not necessary. anyone?
On 2013-09-17 20:28, cory seligman wrote:
Does anyone know of a simple way of showing which of my machines on my home network is hogging all my data?
I recently discovered that something on my network is using ~30M per hour all day and night and I'd like to find out what it is. I guess I could go around and turn each thing off and check my ISP's usage meter over a few hours, but there must be a better way of doing it.
I have a WRT54GL running:
Firmware OpenWrt Kamikaze - With X-Wrt Extensions 8.09 Kernel Linux 2.4.35.4 #15 Fri Jan 22 11:36:55 CST 2010 MAC 00:18:39:ED:A2:73 Device Linksys WRT54G/GS/GL Board Broadcom BCM5352 chip rev 0 Username root
Web mgt. console Webif² Version r4838
I'm very lazy, so an installable package that can do this over a web interface would be ideal, but not necessary.
anyone?
Given you're running Kamikaze, you're unlikely to have the iptables-utils package installed (you may be able to install it, giving you the iptables-save and iptables-restore commands; a script using these would be quicker), so in its absense: # Create a chain calle log_outgoing iptables -N log_outgoing # Create a chain calle log_incoming iptables -N log_incoming # For every IP address in an IP class C: let ip=1 while [ "$ip" -lt 254 ] do # Add a null iptables rule that does nothing but match the IP address # and count the packets both for incoming and outgoing traffic # (Specify your own subnet unstead of '192.168.2' below) iptables -I log_outgoing -s "192.168.2.$ip" iptables -I log_incoming -d "192.168.2.$ip" let ip=ip+1 done # Ensure that all traffic passing through the router goes to the new # chains we created. iptables -I FORWARD -j log_incoming iptables -I FORWARD -j log_outgoing Then, to show how much traffic each host used: iptables -vnL log_incoming | grep -v '^ \+0' iptables -vnL log_outgoing | grep -v '^ \+0' To remove the iptables rules added above: # Remove the redirects from the forward chain iptables -D FORWARD -j log_incoming iptables -D FORWARD -j log_outgoing # Delete the custom chains we created iptables -X log_incoming iptables -X log_outgoing Also, if you were running a newer version of OpenWRT (I run Backfire), I think you can see the counters for each iptables rule from the web interface. I'm not sure if this is available in Kamikaze. -- Regards, Matthew Cengia
Oops, missed a bit: On 2013-09-17 22:23, Matthew Cengia wrote: [...]
# Remove the redirects from the forward chain iptables -D FORWARD -j log_incoming iptables -D FORWARD -j log_outgoing
# Clear the custom chains before deletion iptables -F log_incoming iptables -F log_outgoing
# Delete the custom chains we created iptables -X log_incoming iptables -X log_outgoing
-- Regards, Matthew Cengia
On 09/17/2013 10:23 PM, Matthew Cengia wrote:
Given you're running Kamikaze, you're unlikely to have the iptables-utils package installed (you may be able to install it, giving you the iptables-save and iptables-restore commands; a script using these would be quicker), so in its absense:
I should probably mention at this point that custom firewall rules for OpenWrt should be entered as iptables commands in /etc/firewall.user (basically a glorified shell script, but it gets called at the appropriate point during network initialisation). I would *not* encourage the use of iptables-{save,restore} on OpenWrt, as you will be overwriting the existing rules, and any network interface changes will not be reflected in the firewall structure if you're modifying an old and shaggy iptables dump. If you absolutely *insist* on loading your rules with iptables-restore (NOT recommended), you should probably disable the built-in firewall script (I'll leave doing that as an exercise to the reader *cough*/etc/init.d/firewall disable*cough*).
On 2013-09-17 23:45, Jeremy Visser wrote:
On 09/17/2013 10:23 PM, Matthew Cengia wrote:
Given you're running Kamikaze, you're unlikely to have the iptables-utils package installed (you may be able to install it, giving you the iptables-save and iptables-restore commands; a script using these would be quicker), so in its absense:
I should probably mention at this point that custom firewall rules for OpenWrt should be entered as iptables commands in /etc/firewall.user (basically a glorified shell script, but it gets called at the appropriate point during network initialisation).
I would *not* encourage the use of iptables-{save,restore} on OpenWrt, as you will be overwriting the existing rules, and any network interface changes will not be reflected in the firewall structure if you're modifying an old and shaggy iptables dump.
If you absolutely *insist* on loading your rules with iptables-restore (NOT recommended), you should probably disable the built-in firewall script (I'll leave doing that as an exercise to the reader *cough*/etc/init.d/firewall disable*cough*).
Yes, care must be taken in this instance, and you make a couple of good points here. It's worth remembering that running iptables-restore needn't blow away your entire ruleset, specifically when passed '-n'. Historically, I had something like this in /etc/firewall.rules: iptables -N log_incoming iptables -N log_outgoing { echo '*filter' ip=1 while [ "$ip" -lt 255 ]; do echo "-A log_incoming -d 192.168.2.$ip" echo "-A log_outgoing -s 192.168.2.$ip" let ip=ip+1 done echo 'COMMIT' } | iptables-restore -n iptables -I FORWARD -j log_incoming iptables -I FORWARD -j log_outgoing This saves *lots* of time because you're only running 5 iptables commands instead of over 200, and given that each change made using 'iptables' basicaly reads, edits, and write the full table every time, this is much neater. Also, worth noting is that at least in this instance, it's not necessary to specify a network interface. -- Regards, Matthew Cengia
On 17 September 2013 12:28, cory seligman <coryms.luv@gmail.com> wrote:
Does anyone know of a simple way of showing which of my machines on my home network is hogging all my data?
I recently discovered that something on my network is using ~30M per hour all day and night and I'd like to find out what it is. I guess I could go around and turn each thing off and check my ISP's usage meter over a few hours, but there must be a better way of doing it.
I have a WRT54GL running:
Firmware OpenWrt Kamikaze - With X-Wrt Extensions 8.09 Kernel Linux 2.4.35.4 #15 Fri Jan 22 11:36:55 CST 2010 MAC 00:18:39:ED:A2:73 Device Linksys WRT54G/GS/GL Board Broadcom BCM5352 chip rev 0 Username root
Web mgt. console Webif² Version r4838
I'm very lazy, so an installable package that can do this over a web interface would be ideal, but not necessary.
anyone?
Netflow seems like the ideal tool for the job. My job for the last week has been getting netflow data from our University core switches to analyse our network traffic, so I've done a search for Netflow support for OpenWrt. This looks pretty nice - http://weblog.etherized.com/posts/127 No guarantees, but it looks simple enough.... Sean
cory seligman <coryms.luv@gmail.com> writes:
Does anyone know of a simple way of showing which of my machines on my home network is hogging all my data?
netflow is the right answer (as already mentioned). But I'm too stupid and lazy for that, so what I generally do is timeout 5m tcpdump -i wan -w tmp.pcap # on the wrt wireshark -r tmp.pcap # on a bloated GUI desktop[0] Then poke around the Statistics menu, in particular IPv4 endpoints and TCP conversations. Then I have this conversation: "Hey, <flatmate>, why are you talking to Russia so much?" "I'm not." "You are, look." "WTF, that's not me." "Looks like your shitty Windows box is a botnet zombie. Fix it." [0] actually I use tshark -z, but the sentiment is the same.
participants (5)
-
cory seligman -
Jeremy Visser -
Matthew Cengia -
Sean Crosby -
trentbuck＠gmail.com