I am new to using Windump (TCPDump) and I need to write a filter and save it the output to a text file. I start the command as "Windump>Practice". (I named the output file Practice) Would I type the filter in between Windump and Practice?
Writing a WinDump filter
tcpdump
Related Solutions
A standard TCPDump, without any modifications to the mode of the Wireless NIC, will not display ALL frames traversing the wireless network. It will only display frames directed at (and capable of being received by) your station. TCPDump is just grabbing the information that is specifically delivered to your station, decrypted, and presented to the OS at the normal Ethernet/IP level.
To listen to ALL frames reaching your station on the wireless network, you'll need have a NIC capable of running in Monitor mode, and then put your NIC into Monitor mode. While in Monitor mode, you won't be able to send traffic, only to observe all frames on the channel. This is done similarly to the following:
iw phy phy0 interface add wlan2 type monitor
iw dev wlan2 set freq 2412
ifconfig wlan2 up
tcpdump -i wlan2
Read the documentation on iw for more information, and also, see this page for some good information on using iw for monitoring, with an example.
As noted by @ylearn in the comments, your station will only be able to capture frames under specific circumstances (Some more obvious than others):
- Be in range of the sending station (duh)
- Be of the same type as the sending station (single vs multiple spacial streams for example)
- Be listening to the same channel/frequency as the sending station (listening to 2.4 GHz channels won't help you capture 5Ghz traffic, etc)
And there are more conditions, but the bottom line is that wireless networks are wireless, so there's no guarantee of delivery of traffic and therefore no guarantee of receipt on your Monitoring station. :)
Now with all of that said, you may have all the frames that are being transmitted, but you would still need to decrypt the frames. This a large topic in and of itself, however the basics are this: the frames that any 802.11 station sends into the air are sent encrypted so that not just anyone can sniff all connections.
Wireshark has a nice intro page on Decyrypting 802.11. I recommend reading that, understanding it, and moving on from there.
Edit to respond to your comments, @phenetas:
First, as alluded to in my response, I was assuming your OS was Linux in my answer so I recommended using iw. If you're serious about learning more about penetrating 802.11 networks, I'd recommend looking into a linux distro such as Kali Linux, which is designed for exactly that purpose. (Use this power only for good please; with great power comes great responsibility, etc, etc.)
However, if you're insistent on using MAC OSX, you have other options as well to put the NIC into monitor mode (including just using Wireshark instead of TCPDump). Some Googling around for MAC OSX monitor mode should help you there.
Finally, I would look into reading more about IP Broadcasts and mDNS (Multicast DNS) as that is what you're seeing initially from the other devices. These are not "intercepted" packets, this IS traffic destined to your device, that is why TCPDump is displaying the packets.
Basic information about how to interpret tcpdump output can be found in the tcpdump man page. Just do man tcpdump on your machine and read (and make some notes, there's a lot of stuff there). Next, you may find google and query tcpdump tutorial helpful, as again - a lot of information shown by tcpdump will be protocol-specific. Couple of good, introductory tutorials:
- https://danielmiessler.com/study/tcpdump/
- http://dillonhale.com/blog/linux-tutorials/tcpdump-primer/
You may also find Wireshark, an GUI tool built on tcpdump fundamentals a good resource to use in daily work and as a base reference for protocol decoding.
Answering your specific question: why you're trying to monitor multicast on this specific node? If you want to monitor multicast in core of the network, you should SPAN/RSPAN your traffic to this host and then sniff it using favorite tool - be it tcpdump. If that's a switched network you're connected to, you'll see few if any multicast packets - your station doesn't have (by default) means to become active destination of all multicast traffic unless it registers to be it (and that requires additional work, besides running sniffer alone).
Best Answer
It depends on how the command interpreter you're using works, but the convention generally used on UN*X (from which Windows took the output redirection conventions) is to put the redirection at the end, so
will work.
(Note, however, that the filter definitely has to appear after command-line options, so you have to do
rather than
for example.)