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.
- Prev by Date: [Wireshark-users] mergecap: another size limitation?
- Next by Date: [Wireshark-users] minumum snapshot length IP packets
- Previous by thread: Re: [Wireshark-users] find local IP from cap-file
- Next by thread: [Wireshark-users] mergecap: another size limitation?