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 <reichert@xxxxxxxxxxx> 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 <reichert@xxxxxxxxxxx>
> > BSD admin/developer at large
> > ___________________________________________________________________________
> > Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> > Archives: https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> > mailto:wireshark-dev-request@xxxxxxxxxxxxx
> > ?subject=unsubscribe
> >
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
--
Brian Reichert <reichert@xxxxxxxxxxx>
BSD admin/developer at large