Andrej van der Zee wrote on Wed, 5 Aug 2009 18:49:53 +0900
>Dear Sake,
>
>Thanks for your reply.
>
>
>> If I understand correctly, the tracefile is made on a system with
>> multiple interfaces and the traffic to and from this system is captured
>> (so no port mirroring is used to capture data from other systems).
>
>
>Yes that is right.
>
>
>>
>>
>> This would mean that every *unicast* packet must be to or from a local
>> interface. If you do some statistics on the src and dst mac-addresses
>> you will be able to tell which mac-addresses are always present. You
can
>> then check which IP addresses are used for these mac-addresses.
>
>
>I wrote a small pcap application that does this directly on the src and
dst
>IP addresses. The problem is that packages are send in both directions,
so I
>can't tell wich is the local IP that was used for sniffing. I am not sure
if
>doing this on the mac-address level, and then mapping the mac to the IP,
is
>going to help. Is it?
>
>Thank you,
>Andrej
If you find one MAC associated with many IPs it's probably a router. OK,
it could be a computer with multiple IPs or acting as a router while
simultaneously capturing, but it probably isn't. As a check, see if the
OUI resolves to a well-known router manufacturer. (Enable MAC name
resolution in Wireshark.)
I normally work with non-routed systems. I have this filter in a coloring
rule at the top of my list (highest priority), normally disabled:
frame.len<60||ip.checksum_bad==1||tcp.checksum_bad==1||udp.checksum_bad==1
Explanation: The filter looks for various anomalies that are possible in
packets transmitted by the capturing computer, but are unlikely to be seen
in received packets.
Impossibly short packets (frame.len<60) happen because the NIC pads short
outgoing packets. You might have to change "60" depending on the capturing
setup. For example, if Wireshark reports that most frames' Ethernet
headers include FCS then minimum size becomes 64.
TCP checksum offloading is so common that I usually disable checksum
checking in TCP preferences so reassembly works. (It must be enabled for
tcp.checksum_bad==1 to work)
The other bad_checksums don't seem to be common. I included them anyway -
they cost nothing except (I guess) a few more ms per frame.
I expect you're using tshark, so you could use the filter:
-R"frame.len<60||ip.checksum_bad==1||tcp.checksum_bad==1||udp.checksum_bad==1"
and maybe -T fields -e eth.src -e ip.src.
BTW, don't trust switches' handling of unicast destinations unreservedly.
If you try this capture filter
not (multicast or ether host <your_mac_address>)
(in promiscuous mode of course) for some time on a big switched network
you will probably capture some packets. There are several possible causes,
such as:
- Switch mac table overflow.
- Destination has failed and source's arp cache timeout is longer than
switch's mac aging time.
- Weird network configuration (probably mistake) makes packets from A->B
follow a different path from B->A.
So your file might include some unicast packets not to or from the
capturing PC.
Julian.
