Make MAXIMUM_SNAPLEN higher #389
Assignees
Labels
Comments
|
It seems that the root cause is that while MTU on lo is 65536, the maximum-length packet combined with its pcap header is larger than that. |
|
No, the pcap header, in the sense of However, the MTU is _NOT_ the maximum link-layer packet size; it's the maximum link-layer payload size. The loopback interface, on Linux, adds a fake Ethernet header, so an MTU of 65535 implies a maximum link-layer packet size of at least 65549. |
|
@guyharris Oh, I see. Still, it seems like a good case for raising MAXIMUM_SNAPLEN, even if slightly. |
|
Should be fixed by d033c1b and libpcap a8cd00e, which raise the maximum to 131072. |
|
I also boosted the maximum in Wireshark's libwiretap to 131072, so it won't reject files with a snaplen > 65535; that change is in the trunk, the 1.12 branch, and the 1.10 branch. |
|
Further boosted (in libpcap, tcpdump, and Wireshark {trunk, 1.12 branch, 1.10 branch}) to 262144, so that USBPcap captures, which, as per Wireshark bug 8808, can have packets > 131072 bytes, could be handled without being cut short by an arbitrary snaplen. |
|
Thanks! |
assafmo
added a commit
to google/gopacket
that referenced
this issue
Jun 25, 2018
SetSnaplen sets the snapshot length of the capture file. This is useful when a pcap file contains packets bigger than then snaplen. Pcapgo will error when reading packets bigger than snaplen, then it dumps those packets and reads the next 16 bytes, which are part of the "faulty" packet's payload, but pcapgo thinks it's the next header, which is probably also faulty because it's not really a packet header. **This can lead to a lot of faulty reads.** The SetSnaplen function can be used to set a bigger snaplen to prevent those read errors. This snaplen situation can happen when a pcap writer doesn't truncate packets to the snaplen size while writing packets to file. E.g. In Python, dpkt.pcap.Writer sets snaplen by default to 1500 (https:dpkt.readthedocs.io/en/latest/api/api_auto.html#dpkt.pcap.Writer) but doesn't enforce this when writing packets (https:dpkt.readthedocs.io/en/latest/_modules/dpkt/pcap.html#Writer.writepkt). When reading, tools like tcpdump, tcpslice, mergecap and wireshark ignore the snaplen and use their own defined snaplen. E.g. When reading packets, tcpdump defines MAXIMUM_SNAPLEN (https:github.com/the-tcpdump-group/tcpdump/blob/6e80fcdbe9c41366df3fa244ffe4ac8cce2ab597/netdissect.h#L290) and uses it (https:github.com/the-tcpdump-group/tcpdump/blob/66384fa15b04b47ad08c063d4728df3b9c1c0677/print.c#L343-L358). For further reading: - https:github.com/the-tcpdump-group/tcpdump/issues/389 - https:bugs.wireshark.org/bugzilla/show_bug.cgi?id=8808 - https:www.wireshark.org/lists/wireshark-dev/201307/msg00061.html - https:github.com/wireshark/wireshark/blob/bfd51199e707c1d5c28732be34b44a9ee8a91cd8/wiretap/pcap-common.c#L723-L742 - https:github.com/wireshark/wireshark/blob/f07fb6cdfc0904905627707b88450054e921f092/wiretap/libpcap.c#L592-L598 - https:github.com/wireshark/wireshark/blob/f07fb6cdfc0904905627707b88450054e921f092/wiretap/libpcap.c#L714-L727 - https:github.com/the-tcpdump-group/tcpdump/commit/d033c1bc381c76d13e4aface97a4f4ec8c3beca2 - https:github.com/the-tcpdump-group/tcpdump/blob/88e87cb2cb74c5f939792171379acd9e0efd8b9a/netdissect.h#L263-L290
traetox
pushed a commit
to traetox/gopacket
that referenced
this issue
Jan 2, 2019
SetSnaplen sets the snapshot length of the capture file. This is useful when a pcap file contains packets bigger than then snaplen. Pcapgo will error when reading packets bigger than snaplen, then it dumps those packets and reads the next 16 bytes, which are part of the "faulty" packet's payload, but pcapgo thinks it's the next header, which is probably also faulty because it's not really a packet header. **This can lead to a lot of faulty reads.** The SetSnaplen function can be used to set a bigger snaplen to prevent those read errors. This snaplen situation can happen when a pcap writer doesn't truncate packets to the snaplen size while writing packets to file. E.g. In Python, dpkt.pcap.Writer sets snaplen by default to 1500 (https:dpkt.readthedocs.io/en/latest/api/api_auto.html#dpkt.pcap.Writer) but doesn't enforce this when writing packets (https:dpkt.readthedocs.io/en/latest/_modules/dpkt/pcap.html#Writer.writepkt). When reading, tools like tcpdump, tcpslice, mergecap and wireshark ignore the snaplen and use their own defined snaplen. E.g. When reading packets, tcpdump defines MAXIMUM_SNAPLEN (https:github.com/the-tcpdump-group/tcpdump/blob/6e80fcdbe9c41366df3fa244ffe4ac8cce2ab597/netdissect.h#L290) and uses it (https:github.com/the-tcpdump-group/tcpdump/blob/66384fa15b04b47ad08c063d4728df3b9c1c0677/print.c#L343-L358). For further reading: - https:github.com/the-tcpdump-group/tcpdump/issues/389 - https:bugs.wireshark.org/bugzilla/show_bug.cgi?id=8808 - https:www.wireshark.org/lists/wireshark-dev/201307/msg00061.html - https:github.com/wireshark/wireshark/blob/bfd51199e707c1d5c28732be34b44a9ee8a91cd8/wiretap/pcap-common.c#L723-L742 - https:github.com/wireshark/wireshark/blob/f07fb6cdfc0904905627707b88450054e921f092/wiretap/libpcap.c#L592-L598 - https:github.com/wireshark/wireshark/blob/f07fb6cdfc0904905627707b88450054e921f092/wiretap/libpcap.c#L714-L727 - https:github.com/the-tcpdump-group/tcpdump/commit/d033c1bc381c76d13e4aface97a4f4ec8c3beca2 - https:github.com/the-tcpdump-group/tcpdump/blob/88e87cb2cb74c5f939792171379acd9e0efd8b9a/netdissect.h#L263-L290
traetox
pushed a commit
to traetox/gopacket
that referenced
this issue
Jan 2, 2019
SetSnaplen sets the snapshot length of the capture file. This is useful when a pcap file contains packets bigger than then snaplen. Pcapgo will error when reading packets bigger than snaplen, then it dumps those packets and reads the next 16 bytes, which are part of the "faulty" packet's payload, but pcapgo thinks it's the next header, which is probably also faulty because it's not really a packet header. **This can lead to a lot of faulty reads.** The SetSnaplen function can be used to set a bigger snaplen to prevent those read errors. This snaplen situation can happen when a pcap writer doesn't truncate packets to the snaplen size while writing packets to file. E.g. In Python, dpkt.pcap.Writer sets snaplen by default to 1500 (https:dpkt.readthedocs.io/en/latest/api/api_auto.html#dpkt.pcap.Writer) but doesn't enforce this when writing packets (https:dpkt.readthedocs.io/en/latest/_modules/dpkt/pcap.html#Writer.writepkt). When reading, tools like tcpdump, tcpslice, mergecap and wireshark ignore the snaplen and use their own defined snaplen. E.g. When reading packets, tcpdump defines MAXIMUM_SNAPLEN (https:github.com/the-tcpdump-group/tcpdump/blob/6e80fcdbe9c41366df3fa244ffe4ac8cce2ab597/netdissect.h#L290) and uses it (https:github.com/the-tcpdump-group/tcpdump/blob/66384fa15b04b47ad08c063d4728df3b9c1c0677/print.c#L343-L358). For further reading: - https:github.com/the-tcpdump-group/tcpdump/issues/389 - https:bugs.wireshark.org/bugzilla/show_bug.cgi?id=8808 - https:www.wireshark.org/lists/wireshark-dev/201307/msg00061.html - https:github.com/wireshark/wireshark/blob/bfd51199e707c1d5c28732be34b44a9ee8a91cd8/wiretap/pcap-common.c#L723-L742 - https:github.com/wireshark/wireshark/blob/f07fb6cdfc0904905627707b88450054e921f092/wiretap/libpcap.c#L592-L598 - https:github.com/wireshark/wireshark/blob/f07fb6cdfc0904905627707b88450054e921f092/wiretap/libpcap.c#L714-L727 - https:github.com/the-tcpdump-group/tcpdump/commit/d033c1bc381c76d13e4aface97a4f4ec8c3beca2 - https:github.com/the-tcpdump-group/tcpdump/blob/88e87cb2cb74c5f939792171379acd9e0efd8b9a/netdissect.h#L263-L290
bedestall5
added a commit
to bedestall5/gopacket
that referenced
this issue
Aug 10, 2024
SetSnaplen sets the snapshot length of the capture file. This is useful when a pcap file contains packets bigger than then snaplen. Pcapgo will error when reading packets bigger than snaplen, then it dumps those packets and reads the next 16 bytes, which are part of the "faulty" packet's payload, but pcapgo thinks it's the next header, which is probably also faulty because it's not really a packet header. **This can lead to a lot of faulty reads.** The SetSnaplen function can be used to set a bigger snaplen to prevent those read errors. This snaplen situation can happen when a pcap writer doesn't truncate packets to the snaplen size while writing packets to file. E.g. In Python, dpkt.pcap.Writer sets snaplen by default to 1500 (https:dpkt.readthedocs.io/en/latest/api/api_auto.html#dpkt.pcap.Writer) but doesn't enforce this when writing packets (https:dpkt.readthedocs.io/en/latest/_modules/dpkt/pcap.html#Writer.writepkt). When reading, tools like tcpdump, tcpslice, mergecap and wireshark ignore the snaplen and use their own defined snaplen. E.g. When reading packets, tcpdump defines MAXIMUM_SNAPLEN (https:github.com/the-tcpdump-group/tcpdump/blob/6e80fcdbe9c41366df3fa244ffe4ac8cce2ab597/netdissect.h#L290) and uses it (https:github.com/the-tcpdump-group/tcpdump/blob/66384fa15b04b47ad08c063d4728df3b9c1c0677/print.c#L343-L358). For further reading: - https:github.com/the-tcpdump-group/tcpdump/issues/389 - https:bugs.wireshark.org/bugzilla/show_bug.cgi?id=8808 - https:www.wireshark.org/lists/wireshark-dev/201307/msg00061.html - https:github.com/wireshark/wireshark/blob/bfd51199e707c1d5c28732be34b44a9ee8a91cd8/wiretap/pcap-common.c#L723-L742 - https:github.com/wireshark/wireshark/blob/f07fb6cdfc0904905627707b88450054e921f092/wiretap/libpcap.c#L592-L598 - https:github.com/wireshark/wireshark/blob/f07fb6cdfc0904905627707b88450054e921f092/wiretap/libpcap.c#L714-L727 - https:github.com/the-tcpdump-group/tcpdump/commit/d033c1bc381c76d13e4aface97a4f4ec8c3beca2 - https:github.com/the-tcpdump-group/tcpdump/blob/88e87cb2cb74c5f939792171379acd9e0efd8b9a/netdissect.h#L263-L290
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have a specific practical use case that requires it to be over 65535: transferring large messages over ZeroMQ over loopback interface on Linux 3.13 results in packets of size 65545, which results in various breakage downstream, mainly the inability of Wireshark's desegmenter to process the packet.
I think a value of 131072 would be fine, in light of the comment in netdissect.h.
The text was updated successfully, but these errors were encountered: