ICMPv6 capture filter fails for MLD messages

asked 2023-06-13 08:43:56 +0000

jan.no003
1 ●3 ●2

updated 2023-06-13 09:15:39 +0000

Hi,

I have a system (vyatta NOS) with:

TShark (Wireshark) 3.4.10 (Git v3.4.10 packaged as 3.4.10-0+deb11u1)

and :

en_US.UTF-8, with libpcap version 1.9.1 (with TPACKET_V3), with GnuTLS 3.7.1,

I am able to capture IPv6 NS messages - type 135 with:

tshark -i dp0p194p1 icmp6[0]=135

but when I try any MLD message types 130 or 143 it never works ?? I find it really peculiar since the matching occurs on exactly same bytes just different value ?? Is there any workaround please ?? Tx, Jan

Comments

Can you share a sample capture file (via some file sharing site) of a packet that works with the capture filter and one that doesn't?

Jaap ( 2023-06-13 13:21:17 +0000 )edit

There is a single packet attached to 14536: MLDRv2 - Multicast address record: auxiliary data but not sure how to test - 1814: Capture filters not work when capturing from named pipes or stdin

Chuckc ( 2023-06-13 14:59:08 +0000 )edit

Thank you for looking at it so fast. I will try to share a capture file which has the MLD packets (not seen with icmp6[0]=143) and ordinary NS packets seen with icmp6[0]=135 option here: https://app.box.com/s/2r60e8dfir81klr... I hope it works for you I have never used it before ...

jan.no003 ( 2023-06-13 15:03:27 +0000 )edit

pcap good but still looking for a way to play it into dumpcap for capture.
How were the packets in the pcap generated? Easy to recreate on the command line?

Chuckc ( 2023-06-13 18:10:03 +0000 )edit

Vyatta is modified Linux machine - it has its own CLI to enable IPv6 and MLD on an interface. But it translates into those Linix dev files somewhere where you can enable it on an ordinary Linux interface:

ls /sys/class/net

dp0p161p1  dp0p162p1  dp0p192p1  dp0p193p1  dp0p194p1  dp0p224p1  dp0p225p1  dp0p256p1  dp0p257p1  lo

each of these dirs have files there to enable multicast and MLD on the interface.

And then you just tshark on that interface ...

jan.no003 ( 2023-06-13 19:27:12 +0000 )edit

see more comments

answered 2023-06-13 21:17:51 +0000

Jaap

13742 ●710 ●115

The provided capture is very informative. When you apply the display filter icmpv6.type == nnn, where nnn is either 135, 130 or 143, you'll notice that the ICMPv6 MLD packets have an IPv6 option included in the IPv6 layer, while the ICMPv6 NS packets do not have that IPv6 option in the IPv6 layer. Why is that important? Because the capture filter is expecting the IPv6 Next Header to be ICMPv6, not something else. That is what the capture filter expression says. Since in the packets with ICMPv6 MLD packets the IPv6 Next Header is the IPv6 Hop-by-Hop option, the capture filter does not accept this packet.

The method to investigate this is to use tcpdump or dumpcap to show the BPF code created for the capture filter expression (use option -d for this). if you match this to the actual packet octets, you'll see how the capture filter applies to the packets involved.

Another noticeable thing is that some packets have an VLAN layer in between as well. These will also not match the capture filter.

edit flag offensive delete link

Comments

Thank you for help and explanation - I wasn't looking at it that way, I was just checking the actual field values in the headers.

VLAN is expected on some of the packets but I would have thought it did not matter for the filter as it is underneath the IP layer ....

If I remember well Hop-by-Hop option is v6 alternative of IPv4 Router Alert option which was added in the old times to IGMP to make sure it got punted to the CPU so I guess when v6 came along they just added it to MLD as well while newly designed functionality - like NS - no longer needed it ...

jan.no003 ( 2023-06-14 08:34:26 +0000 )edit

A yes, I see, the filters translate into fixed/pre-defined offsets from the start of the Ethernet Frame, it does not lookup the particular given header - that's fairly troublesome/rather unexpected usage of the syntax tho:

icmp6[0]=143 is:

(000) ldh [12]

(001) jeq #0x86dd jt 2 jf 7

(002) ldb [20]

(003) jeq #0x3a jt 4 jf 7

(004) ldb [54]

(005) jeq #0x8f jt 6 jf 7

If I say icmp6 I expect it to find ICMPv6 header in the frame and not start counting from the start of the Ethernet ....

jan.no003 ( 2023-06-14 09:41:51 +0000 )edit

In order to be efficient (remember, this has to work at line rate) it's not that sophisticated. Certainly not as sophisticated as a Display Filter.

Jaap ( 2023-06-14 17:49:03 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

ICMPv6 capture filter fails for MLD messages

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

ICMPv6 capture filter fails for MLD messages edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

ICMPv6 capture filter fails for MLD messages