Is it possible to use capture filters to capture only traffic sent from a device running Wireshark and ignore any packets received? Also when viewing a capture file from another device - it is possible to use display filters for the same purpose? asked 04 Feb '13, 18:55  rocket72 |
2 Answers:
Is it possible to use capture filters to capture only traffic sent from a device running Wireshark and ignore any packets received? Yes, this is possible. Assuming the host running Wireshark has an IP address of 192.168.1.1, an appropriate capture filter to use to capture only outbound traffic from that host would be: " Also when viewing a capture file from another device - it is possible to use display filters for the same purpose? Yes, this is also possible. After loading a capture file, if you want to filter that capture file to only display packets sent from a particular host (again, I'll assume the host of interest is 192.168.1.1), then an appropriate Wireshark display filter would be: " answered 04 Feb '13, 19:47  cmaynard ♦♦ |
At the moment, this can not be done with wireshark on the host itself, as the direction of the traffic is not recorded. However, pcap-ng can record this info if someone implements it. An alternative would be to use a switch that can do port mirroring and is able to select the direction of traffic. Like on a cisco switch you can do the following: It will copy only the packets received on interface Fa0/24 to port Fa0/10. You can then attach a laptop with wireshark on interface Fa0/10. answered 05 Feb '13, 02:39  SYN-bit ♦♦ If someone implements it, including getting the packet direction when capturing (a problem that pcap-ng, by itself, won't solve; there are some platforms where that would require OS kernel changes, for example.) (05 Feb '13, 10:00) Guy Harris ♦♦
why is that? As I see it, there are there possible options: 1.) Sniffing traffic that does not belong to the capturing machine, so there is no traffic direction. 2.) TX: Sniffing traffic that was sent from the capturing machine. In that case the SRC MAC and/or SRC IP address of the packet will be one of the machine address, maybe except for some L2 broadcast traffic (but then, what kind of protocol would that be, if it's impossible to answer the request !?!). 3.) RX: Sniffing traffic that was directed to capturing machine. In that case the DST MAC and/or DST IP address of the packet will be one of the machine address, maybe except for some L2 broadcast traffic, in which it would be counted as "INCOMING" (depending on the broadcast address). For 1.) there is nothing to do/change. I did not really think this through, but for what case do you think there is a kernel change required? Regards (05 Feb '13, 13:32) Kurt Knochner ♦ For 3), there's also multicast traffic. For 2) and 3), there's no guarantee that there is an IP address, so it'd be based purely on the MAC address. There's also PPP, where you don't have a MAC address. If you want the direction supplied by libpcap to reflect whether the machine sent or received the packet, that would require kernel changes in BPF, for example. If you want a mechanism separate from a capture filter, newer versions of BPF have APIs that let you control whether you want sent, received, or both packets, but not all options are supported on all OSes. (05 Feb '13, 13:56) Guy Harris ♦♦
Yes, that's traffic that you can't distinguish from case 1.). And that's also true for broadcast traffic. But then, how do you make that decision even with a kernel change? How do you know why the packet entered the machine? How do you decide if it was INCOMING traffic or just traffic that entered the machine due to promiscuous mode?
Yes, as I said: MAC or IP address. Good enough for a simple approach, that might work on every platform without any changes to the kernel.
yes that's a problem. As I said, I did not really think it through. How do you solve that with a kernel change? (05 Feb '13, 14:06) Kurt Knochner ♦ The OP has a valid case. What if the system spoofs the IP and MacAddresses, but you still want to know if it was sent by the host. Information in the packet will not help you there, you need to know from the OS whether the packet was received by the system or sent by the system. (05 Feb '13, 14:54) SYN-bit ♦♦ address spoofing is a good point. I did not see the OPs comment on that. In that case only the kernel will be able to tell if the packet was sent (with a spoofed address) or received (due to promiscuous mode). That's a real benefit for outgoing traffic. Now let's look at incoming traffic. How much value does it add to write that information into a pcap-ng if you are capturing traffic. Are all packets that enter the machine (promiscuous mode, multicast, broadcast, directed) incoming traffic or just those packets that are destined for the machine (dst mac/ip of the machine)? How do you handle multicast + broadcast? Is that also incoming traffic or flow by and captured traffic? (05 Feb '13, 15:26) Kurt Knochner ♦
Well, if incoming packets include an FCS, then knowing whether the packet is incoming or outgoing could let Wireshark not have to use the current heuristic to determine whether an Ethernet packet has an FCS or not - outgoing packets won't have it, as it's added by the hardware, and outgoing packets are captured by being wrapped around. Similarly, if we know that an interface is doing IP/TCP/UDP/etc. checksum offloading, Wireshark could disable the checksum check for outgoing packets. (05 Feb '13, 19:49) Guy Harris ♦♦
Yes.
No.
Yes.
No. A packet is incoming if the network adapter received it. A packet is outgoing if it was handed to the network adapter driver to transmit on that adapter. "Received unicast" vs. "received multicast/broadcast" vs. "received promiscuously" is a subdivision of "incoming". (05 Feb '13, 19:51) Guy Harris ♦♦ O.K. now I see the value of direction information if you capture data on a system itself. So, how would you treat traffic captured on a tap or on a mirror port? Would that be '(fake) incoming' traffic as well, as there is no method to detect the tap and/or mirror port, except maybe by looking at the capture file at the end, and if there is only incoming traffic, chances are good that you were capturing on a tap/mirror port, or would you make it a user configurable option (record traffic direction)? (05 Feb '13, 22:09) Kurt Knochner ♦
Yes. If you're passively capturing on a non-broadcast medium, such as a PPP link or a connection to an X.25 network or an ISDN connection, there should perhaps be a separate direction indicator in a pseudo-header - some of the non-pcap/pcap-ng formats have that, and there are some LINKTYPE_XXX_WITH_DIR link-layer header types for pcap/pcap-ng that have such a pseudo-header. (06 Feb '13, 00:33) Guy Harris ♦♦ Thanks for the clarification. (06 Feb '13, 12:06) Kurt Knochner ♦ showing 5 of 11 show 6 more comments |
I am trying to troubleshoot an issue with possible suspect ARP's where a device may be spoofing MAC addresses, for this I am not able to filter based on IP or even MAC as I cant be sure which MAC the device may be using - if I can filter based on only sent traffic then I can be sure all packets I see are generated by the device in question, otherwise in the case of ARP packets I can not know if they are generated by this device or another device on the network.
Is there any known way to do this?