OpenWrt Forum Archive

Topic: iptables port mirroring?

The content of this topic has been archived on 26 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello,

Background:
After installing and running tcpdump on my old WRT54GL, I could never get it running perfect.  The router has only 2MB of memory, so I was saving the tcpdump outputs (pcap) on my local machine via an SSH connection.  tcpdump, however, would also copy the data from my SSH connection and snowball into oblivion.  I could never get tcpdump functioning perfectly, mostly I believe, because vlan and/or ipv6 were not playing well with my commands.  I messed with vlan settings in OpenWRT and eventually locked myself out of the router, thinking it was bricked.  Lots of troubleshooting and I'm now back to square one on a clean OpenWRT build (firmware- OpenWrt Backfire 10.03.1 / LuCI 0.10.0, and kernal-2.4.37.9).

More research led me to "Port-Mirroring".  I think this may be a simpler way to accomplish my goal.  I want to analyze packets from a wireless client (smartphone app) on my local machine with wireshark.  This is in a lab setting, and seems like it should be straight forward.

Bottom line:
Can anyone tell me if port mirroring is a function in openwrt? I cannot find that info.  If it is not, is the iptables TEE command still a viable option for me?  To be clear, I want to copy and forward (mirror) all my router's wireless traffic to my PC over ethernet. I'll continue reading about the subject, but I'm hoping an experienced person can point me in the right direction as I fumble through.

Time to upgrade to a 1900acs or 3200acm where you can simply log pcaps directly to USB smile    With tcpdump, you can set it to roll the logs when the USB device is full. Set up a file share on the USB and pull those PCAPS down to your machine when needed.

Sorry, I've never set up port mirroring, but don't know how well it will work that that dinosaur anyway smile

If anything the 1900ac old Version 1 is available on Ebay pretty cheap these days, and it will easily do the job.

thanks for the heads-up.  You're probably right that I should stop trying to make this dinosaur work; it just seems like such a simple task.  With that said, I've got at least 5x WRT54x's in my lab so no one would bat an eye if I brick one (like i thought I did before).

I've got a handfull of other devices, I may need to just go through them 1 by 1 and look up the specs. Some may be running openwrt already, or something similar, and meet my needs out of the box.  The buffalo I messed with has a USB port, but it's somehow configured by factory to only be used for firmware upgrades.

You've motivated me to go through these various models 1 by 1 now wink

(Last edited by paddy1337 on 14 Sep 2017, 17:49)

Since ssh works, you could pipe the output of tcpdump to 'nc' which you would catch the stream on another machine. Netcat 'nc' is very handy for these kinds of things. But you will want to run a filter on tcpdump, since you don't want to capture (and forward) your nc & ssh sessions.

cvmiller wrote:

Since ssh works, you could pipe the output of tcpdump to 'nc' which you would catch the stream on another machine. Netcat 'nc' is very handy for these kinds of things. But you will want to run a filter on tcpdump, since you don't want to capture (and forward) your nc & ssh sessions.

Thanks.

That's exactly what I did before.  I was able to CAT the save location to my local machine, completely solving my problem of limited space on the router.  The problem was getting the filters to work. Logically, it's easy to assme my filters were not correct, but I spent literally days trying to figure it out.  According to the internet, my commands should work.  Ignoring port 22 is just 1 example that could have helped, but did not.  tcpdump accepted the syntax, it just seemed to have no affect on output.

I was even willing to just accept the copious data, but it really seemed to grow exponentially, and TCPdump would quickly get over-run and drop packets.

edit: I should probably add, I'm running a tcpdump-mini load so it'll fit the router's limited space.  I strongly considered this as the limiting factor.  I just feel like if I'm calling for a command that was removed from tcpdump for tcpdump-mini, it should give me an error for calling on a command that doesn't exist.

(Last edited by paddy1337 on 18 Sep 2017, 15:10)

Sorry about the filters. It does sound like if tcpdump-mini is ignoring your filter. A simple way to test this is to run something like this:

tcpdump -i br-lan -c 100 not port 22

If you see SSH in the capture, then the filter isn't working. BTW, I put the 'count' in there so I don't loose control of tcpdump if there is too much output.

The discussion might have continued from here.