tcpdump with -i any shown invalid ip and bogus ipv4 in wireshark

[MinpuKang]

tcpdump with -i any shown invalid ip and bogus ipv4 in wireshark

[MinpuKang]

This is the-tcpdump-group/libpcap#1105, which is a libpcap bug (rather than a tcpdump bug) that is fixed in libpcap 1.10.2.

Well noted, thank you.

[infrastation]

The purpose of a packet analyser is to show accurately what is in the packet. As far as the provided output goes, both tcpdump and Wireshark seem to do that consistently and indicate an invalid value of the IP version header in a packet with IPv4 EtherType. Why this header field is invalid in this packet is a separate matter, and the best next step would be to identify the sender and to see what it is sending and why.

[guyharris]

On what version of Linux (distribution and distribution version, and kernel version) are you running tcpdump?

What does tcpdump --version print?

[guyharris]

Why this header field is invalid in this packet is a separate matter, and the best next step would be to identify the sender and to see what it is sending and why.

Assuming what the sender sent and the machine running tcpdump received isn't getting mangled either by the Linux networking stack or by libpcap.

[guyharris]

Does this also happen if you capture with -i eth0 or -i bond_port?

[MinpuKang]

On what version of Linux (distribution and distribution version, and kernel version) are you running tcpdump?

What does tcpdump --version print?

tcpdump version 4.99.1
libpcap version 1.10.1 (with TPACKET_V3)
OpenSSL 1.1.1l 24 Aug 2021 SUSE release 150400.7.16.1
SMI-library: 0.4.8

Linux OS: Suse 15.4

[MinpuKang]

Does this also happen if you capture with -i eth0 or -i bond_port?

No, with -i eth0 or -i bond_port, the printout is normal, no invalid shown, it happens only with any.

[guyharris]

No, with -i eth0 or -i bond_port, the printout is normal, no invalid shown, it happens only with any.

So probably a problem either with cooked mode in the kernel (PF_PACKET/SOCK_DGRAM rather than PF_PACKET/SOCK_RAW) or with libpcap's code for handling cooked-mode capturing.

[guyharris]

Linux OS: Suse 15.4

So that's openSuSE Leap 15.4?

[MinpuKang]

Linux OS: Suse 15.4

So that's openSuSE Leap 15.4?

SUSE Linux Enterprise Server 15 SP4,

[MinpuKang]

No, with -i eth0 or -i bond_port, the printout is normal, no invalid shown, it happens only with any.

So probably a problem either with cooked mode in the kernel (PF_PACKET/SOCK_DGRAM rather than PF_PACKET/SOCK_RAW) or with libpcap's code for handling cooked-mode capturing.

Is that possible to be fixed?

[guyharris]

Is that possible to be fixed?

If we are able to determine the cause, it might be possible for it to be fixed either in the kernel or worked around in libpcap if it's in the kernel code, and it might be possible for it to be fixed if it's in libpcap.

Unfortunately, we do not yet know the cause.

[infrastation]

@MinpuKang, does the problem reproduce in a VM or SLES needs to be running on a physical host for that?

[MinpuKang]

Is that possible to be fixed?

If we are able to determine the cause, it might be possible for it to be fixed either in the kernel or worked around in libpcap if it's in the kernel code, and it might be possible for it to be fixed if it's in libpcap.

Unfortunately, we do not yet know the cause.

understand, thank you for your answer

[MinpuKang]

@MinpuKang, does the problem reproduce in a VM or SLES needs to be running on a physical host for that?

It is a physical host.

[guyharris]

Does the network eth0 is on have VLAN traffic?

In the Wireshark capture, with the "version 8" IP, what is the raw hex value of the byte for 1000 .... = Version: 8 and what is the raw hex value of the byte after it? In particular, is the first byte 0x81 and is the byte after it 0x00?

[guyharris]

Encapsulation type: Linux cooked-mode capture v2 (210)

...

libpcap version 1.10.1 (with TPACKET_V3)

There's a bug in libpcap 1.10.1 and at least some earlier versions that cause VLAN packets not to be properly handled by default when capturing on the "any" device.

What happens if you capture with tcpdump -i any -y LINUX_SLL?

[MinpuKang]

Encapsulation type: Linux cooked-mode capture v2 (210)

...

libpcap version 1.10.1 (with TPACKET_V3)

There's a bug in libpcap 1.10.1 and at least some earlier versions that cause VLAN packets not to be properly handled by default when capturing on the "any" device.

What happens if you capture with tcpdump -i any -y LINUX_SLL?

It works well, no IP invlid. Big thanks.

[guyharris]

This is the-tcpdump-group/libpcap#1105, which is a libpcap bug (rather than a tcpdump bug) that is fixed in libpcap 1.10.2.

[drpavel777]

Faced the same issue on Ubuntu 20.04.6.
tcpdump -i any -y LINUX_SLL
works well. Thanx!

[stefanlasiewski]

Just wanted to add that upgrading from libpcap v1.10.1 to v1.10.4 fixed this issue for me. The new pcaps work with Wireshark 4.2.4 on macOS Sonoma/14.4.1 (Installed via Homebrew) and also TShark (Wireshark) 3.2.3 on Ubuntu 20.04.6 LTS.