[Linux Smiths <linuxsmiths@xxxxxxxxx>]

Thanks John, that was really helpful!

This isn't documented and also Google search for "wireshark 4GB limit" doesn't yield anything helpful.

What makes things worse is if we split capture files into say 2GB chunks wireshark/tshark cannot correctly decode the individual files also since the RPC record marker may lie in the middle of a TCP segment and hence the RPC decoder misses it, so overall decoding >4GB NFS captures is pretty much impossible.

Thanks,

LS

On Fri, Jan 26, 2024 at 5:16 PM John Thacker <johnthacker@xxxxxxxxx> wrote:

On Fri, Jan 26, 2024, 4:27 AM Linux Smiths <linuxsmiths@xxxxxxxxx> wrote:

Can someone confirm this or if anyone has used wireshark/tshark to decode RPC streams greater than 4GB your confirmation will be helpful too. Btw I've tried all the protocol preferences and nothing helps.

Thanks,

LS

It's a known issue, sorry, that affects anything over TCP that needs desegmentation. That's when the TCP sequence number rolls over. See here:

https://gitlab.com/wireshark/wireshark/-/issues/10503

https://gitlab.com/wireshark/wireshark/-/issues/19331

Fixing it involves having some kind of extended sequence number and changing certain lookups for old segments. Unlike an ordinary network stack, Wireshark (and and also tshark, even in one pass mode) can't just discard old segments but keeps information around so that random packet access is possible.

John Thacker 

___________________________________________________________________________
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