 | 1 | initial version |
Look here in the code: https://gitlab.com/wireshark/wireshark/-/blob/master/wiretap/wtap.h#L348
Also see a bit of discussion in this issue: https://gitlab.com/wireshark/wireshark/-/issues/19302
As noted in the code "For most link-layer types, we use 262144, which is currently libpcap's MAXIMUM_SNAPLEN."
It is still the limit in libpcap: https://github.com/the-tcpdump-group/libpcap/blob/0170672eef17995036e5374e705b1a376acfa3b3/pcap-int.h#L138
If you compile libpcap with a different maximum, then Wireshark's wiretap library could be compiled with a different number as well
| | 2 | No.2 Revision |
Look here in the code: https://gitlab.com/wireshark/wireshark/-/blob/master/wiretap/wtap.h#L348
Also see a bit of discussion in this issue: https://gitlab.com/wireshark/wireshark/-/issues/19302
As noted in the code "For most link-layer types, we use 262144, which is currently libpcap's MAXIMUM_SNAPLEN."
It is still the limit in libpcap: https://github.com/the-tcpdump-group/libpcap/blob/0170672eef17995036e5374e705b1a376acfa3b3/pcap-int.h#L138
If you compile libpcap with a different maximum, then Wireshark's wiretap library could be compiled with a different number as well
You mention IPv4 header, so these are not IPv6 jumbograms. Does IPv4 have a mechanism for packets larger than 65535 octets? I am not sure how the IPv4 header would indicate such a thing
