On Mon, Aug 28, 2023 at 08:54:39AM -0700, Josh Clark wrote: > How controlled will the network be between the two capture locations? Are > there any firewalls, load balancers, proxies, NATs, or anything like that?
No NAT, just evidence of latency we need to nail down. > If none of those are the case and correlation is still difficult, it may be > retransmissions or dropped packets that are hindering correlation. In those > cases, you???ll see the same sequence and acknowledgement numbers over and > over again, but associated with different packets. Retransmits, fragmentation, drops, etc., I was expecting, but I'm seeing other weird things I can't explain; I'm seeing a SOAP client send multiple packets with the same TCP sequence number. I know it's not going to be a 1:1 relationship, but that confused me. > The best > individual identifier for a packet is the Identity field in the IP header ( > ip.id), and a lot of correlation solutions I???ve seen will take a hash of > multiple fields to craft a ???packet signature???. [...] > I would hash together source IP, destination IP, source port, destination > port, and IP ID. Ok; I'd be happy to explore that! I appreciate a concrete suggestion; I've been plating whack-a-mole for too long on this... > Absolute sequence numbers could be used as secondary > validation, and I would also check the time stamp of the packet to prevent > accidental correlations when that field rolls over and restarts (maybe just > ensure that the time stamps of the packets are within 5 minutes of each > other). Again, all good suggestions! I appreciate the advice! > I hope that helps! > > Regards, > > Josh Clark > > On Mon, Aug 28, 2023 at 08:22 Brian Reichert <reich...@numachi.com> wrote: > > > This question isn't specific to Wireshark, but I couldn't find a > > good forum. By all means, I'm open to suggestions as to where it > > would be more appropriate to ask about this. > > > > Anyway: > > > > I'm trying to automate the reconciliation of a pair of packet > > captures of a TCP session. > > > > This is sort of a combination of: > > > > - reconstructing a TCP 'flow' as Wireshark currently does, and > > - correlating an individual packet within one capture with packet(s) > > in the second capture. > > > > The overall goal is to generate some insight on network latency. > > > > I'm very close, but not close enough. > > > > I naively though that I could 'just' chain sets of packets by > > comparing absolute sequence numbers, and the respective ACK numbers. > > > > But, given the example captures I have, this is proving to be not > > adequate. > > > > This is obviously an open-ended request for advice. I'd be happy > > for any I can get, including a 'go ask there' suggestion. > > > > Thanks! > > > > -- > > Brian Reichert <reich...@numachi.com> > > BSD admin/developer at large > > ___________________________________________________________________________ > > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > > Archives: https://www.wireshark.org/lists/wireshark-dev > > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > > mailto:wireshark-dev-requ...@wireshark.org > > ?subject=unsubscribe > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- Brian Reichert <reich...@numachi.com> BSD admin/developer at large ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
