Hi Ian,
Thank you very much! That is more than I hoped for :)
Cheers,
Andrej
On Wed, Apr 7, 2010 at 8:54 AM, Ian Schorr <ian.schorr@xxxxxxxxx> wrote:
> On Tue, Apr 6, 2010 at 10:45 PM, Andrej van der Zee
> <andrejvanderzee@xxxxxxxxx> wrote:
>> What I would like to know is how to match packets on both ends of the
>> line, provided that I have the IP numbers. Are there any unique packet
>> identifiers that appear in the cap-files on both ends? What should I
>> use? For example, when I study the cap-file in Wireshark, I see under
>> "Internet Protocol" an "Identification" number that seems to be
>> incremented for packets over the same connection (or conversation?).
>> Is this Identification number generated by Wireshark or is it really
>> in the packet headers? Does it appear in both cap files? In that case,
>> I could use a tuple <IP, Identification> to match packets on both
>> ends.
>
> IP IDs are actually in the packet header. Two ways to know: 1) Click
> on the field. Notice how 4 bytes (containing the IP ID value) are
> highlighted in the bottom pane, the data portion of the packet. 2)
> Generally Wireshark-generated fields should be enclosed in square
> brackets (though those things aren't necessarily always going to be
> the case, they're generally true and are SUPPOSED to always be true)
>
> You could use an ID field like IP ID to identify your packets.
> However, IP ID is not only not guaranteed to be unique within your
> capture, but it's one of the most likely fields to not be unique. For
> one thing, it's a relatively small field (16-bit) and even if a host
> increments the ID steadily (i.e. it doesn't re-use IDs more often than
> it has to), it will re-use an ID after sending only 65536 packets. A
> reasonably busy system is going to wrap IDs pretty quickly.
>
> Incidentally, different hosts increment the IDs differently. Some
> increment it globally - once per
> packet they send. Some have an incrementing counter for each host
> they're talking to. One host that
> I was looking at yesterday does some weird things - it seems to be
> aware at IP-level what
> packets are still in-flight on the network (based on being
> unacknowledged at TCP level). It only
> generated unique IDs for each in-flight packet, but once they'd
> been acknowledged, it'd reuse that
> IP ID. So it tended to use IDs 0, 1, and maybe 2 ALL the time. Weird.
>
> And really, that's the tricky part. There aren't really any fields in
> TCP/IP packets that are guaranteed to be unique. There's always SOME
> chance of miscorrelating two packets that share the same properties
> that you're checking for.
>
> Anyway, if you were going to go that route, the TCP sequence number is
> probably much better for your you'd get better results by comparing
> TCP Sequence number (tcp.seq), plus the 4-tuple (source and
> destination IPs and ports). Although it's still not 100% guaranteed
> to be unique, it's much, much more likely. Although the numbers will
> wrap, it will only happen after 4billion bytes have been transferred.
> There's a chance that if connections are being opened and closed
> frequently, then port numbers will be reused and that the host will
> also start TCP sequence numbers at the same point, but that's also
> extremely unlikely (and a big no-no - to avoid attacks hosts typically
> should assign a random sequence ID).
>
> Now compare the IP IDs as well, and it's now very, very, VERY unlikely
> that two packets you compare match criteria but aren't actually the
> same. Theoretically there is a chance of misidentification, but
> practically, for your purposes, that's probably plenty accurate.
>
>
> Keep in mind also that if the network is modifying your packets
> enroute, you'll have troubles. If there is a TCP proxy of some kind,
> a NAT/PAT device, or even a router that "fragments" packets, it may
> seriously impact what you're comparing.
> ___________________________________________________________________________
> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>