Hi,

can I configure my Linksys 54GS in a way, that it captures and displays all send packets (and its contents) on a wlan as a client on that wlan?
Sort of like Wireshark on Win for SSH on a WRT?

Help much appreciated.

Thanks, yanky.

P.S.: Dont worry, nothing illegal , just my NIC dosnt support promiscuous mode and I need to analyze the traffic on my home wlan for studies ...

If you put the wireless into a monitor mode, you'll get a new interface called prism0 which will provide the data you're looking for.

Thanks for the very fast reply.
Is there any more detailed advice available, since I'm not that familiar with Linux?
Thanks a lot.

* Install, configure and run the kismet-drone at the WRT device.
* Install the kismet server and client at your machine (there is even a port for windows but linux is preferred)

So, search for kismet and wrt54. This will lead you the way.

By the way, look into the source of wiviz, it attaches to this prism0 device and captures the packets with libpcap. You can simply store those data packets to a file or send them via network - but it requires a few lines of coding...

Read more:
http://www.churchofwifi.org/Project_Display.asp?PID=16
http://renderlab.net/projects/wrt54g/openwrt.html
http://devices.natetrue.com/wiviz/

(Last edited by Tom on 1 Oct 2006, 17:48)

I hope I can help you. But first three thinks;
I’m not an expert, second; I sniff on a WRT which is in Bridge-Mode, third; the kernel drops a lot of packets.

My setup; I use two WRT’s, one as router the other as bridge (pointing to the neighbor’s AP, he is sharing his DSL to me). The router routes all my Internet requests to the neighbor’s router over my bridge. In my case, the bridge is the last instance of my network; therefore I take sniff-samples from there.

I use two ways to sniff

1. I login via ssh and do
tcpdump -Al -vvv -s 1516 -i eth1

where -A is ASCII-output, -l is line buffered, -vvv is much verbose, -s 1516 is to see the payload and -i eth1 is the Wlan-Interface

If I abort tcpdump, it stops with following:
315 packets captured
1783 packets received by filter
1119 packets dropped by kernel

As you can see, nearly 50% is lost. Maybe the CPU is to slow?!

2. I have a sh-script on my powerbook, which I use to trigger to start the sniffing:
#!/bin/sh

ssh root@192.168.0.100 /usr/sbin/tcpdump -Al -vvv -s 1516 -i eth1 > /Users/admin/Desktop/fullbridge.log

Here I use the same options. The advantage to use this script is, that I save the sniff direct on my powerbook and I can look at it in real-time with the application console, which affords me to filter the entire sniff also in real-time.

Thank you all for the very informational advice, will try to get it to work.

@mortem: did you try to increase the cpu clock?

No I did not. How to do this?

On the bridge is also kismet installed, but I don’t use this, because I don’t know to handle it (yet). My experience with it until now is not very positive. But I did not spend much time with it yet…
Tcpdump is easy and default installed with open-wrt.

For other purposes I use kismac direct on my Powerbook, which has a GUI and it’s very easy to handle. Kismac is the Mac-Version of kismet.

Under DD Wrt one can set the cpu clock via the web interface, so I guess Open Wrt should have an option to change the cpu clock as well.

Install airodump-ng then u can follow the easy howtos for this great util

ipkg install http://downloads.openwrt.org/backports/ … mipsel.ipk

(Last edited by Setsquare on 1 Oct 2006, 19:12)

I would be very nice of you, if you could test tcpdump on you’re wrt, because I suspect miss configuration on my wrt. It would help me to troubleshooting this very fast. Thanks.

Login via ssh and do: tcpdump -Al -vvv -s 1516 -i eth1

Make some traffic on you’re WLan and abort tcpdump after some minutes and watch how many packets dropped by the kernel.

Thanks…

So far, I'm running dd Wrt, which does not support tcpdump.
But I plan to install open wrt in the next few days ... then I'll test your command.

tcpdump works fine i use it all the time

@Setsquare
Hi, thanks for this advise. Can you confirm, that you have no packets dropped by the Kernel, when you use the option -vvv and -s 1500 (read the entire payload)?
If so, then it is worth to troubleshooting this on my side, later.

(Last edited by mortem on 2 Oct 2006, 17:12)

@Setsquare: Which version of dd wrt are you using? Got the latest SP2, I guess and it reports unknown command ... ??!

This is an OPENWRT forum........

Never mind
but i posted, that I'm using dd wrt, which doesn't seem to support tcpdump in the original version

Ok, tried your tcpdump command, always reports "0 packets dropped by kernel"

(Last edited by yanky on 2 Oct 2006, 19:44)

ok, managed to connect my router to my wep secured wlan, put it in montor mode and ran a tcpdump on prism0
I get quite a lot of packages, but all with "PRIVACY".
Does tcpdump not decode the packets on my wlan or am I missing an option to display/retrieve the paylod of the packets

Thanks a lot so far, think my linux knowledge tripled so far

If I abort tcpdump, it stops with following:
315 packets captured
1783 packets received by filter
1119 packets dropped by kernel

Gee. That looks like you have a filter dropping packets. Maybe you are dropping  all the packets in your neighbour's subnet.

@yanky, thanks that you did the test for me. To see payload the only option is -s 1500 or bigger (1500 is the package size (MTU), for tcp/ip = 1500). I don't get something like "PRIVACY", but I did not to try to get into the Monitor-Mode. I think is no need for that, because you are not wardriving (monitor-mode = be silent in the network (I think)). You're nic should be in PROMISC-mode, thats happen automatic, when you start tcpdump. But maybe I'm wrong...

@strider22, I don't know what went wrong. I have no Filter set and of course I "drop" all Internet packets into the neighbour's subnet. The wrt is in Bridge-Mode and the interface I sniff has no IP assigned, maybe this is the reason. I can't/want troubleshooting this at this time, because: never touch a running system, I have no fallback and if something goes wrong: no Internet = no Information...