Wireshark-users: Re: [Wireshark-users] find local IP from cap-file

From: Julian Fielding <jfielding@xxxxxxxxxxxxxxx>
Date: Wed, 5 Aug 2009 20:27:35 +0100

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.