Pflang, as implemented by both pflua and libpcap, compiles pflang expressions to checks against fixed offsets, before looking at any packets. The consequence of their current implementations is that in the presence of IPv6 extension headers (aside from the special case of exactly one extension header, IPv6-frag), pflang expressions such as tcp or udp do not match packets that they would match in the absence of IPv6 extension headers.
% ./env pflua-compile "ip6 and tcp"
local cast = require("ffi").cast
return function(P,length)
if length < 54 then return false end
if cast("uint16_t*", P+12)[0] ~= 56710 then return false end
local var2 = P[20]
if var2 == 6 then return true end
if length < 55 then return false end
if var2 ~= 44 then return false end
return P[54] == 6
end
% tcpdump -d "ip6 and tcp"
(000) ldh [12]
(001) jeq #0x86dd jt 2 jf 8
(002) ldb [20] <-- IPv6 next header field
(003) jeq #0x6 jt 7 jf 4 <-- TCP
(004) jeq #0x2c jt 5 jf 8 <-- IPv6 fragment
(005) ldb [54] <-- IPv6 next header field of the fragment header
(006) jeq #0x6 jt 7 jf 8 <-- TCP
(007) ret #65535
(008) ret #0
In both libpcap and pflua, byte 20 (the IPv6 'next header') field is being checked against values 6 (TCP) and 0x2c (44, IPv6 fragment header). [1] If there is an IPv6 fragment header, byte 54 is then checked to see whether that header's "next header" field value is 6 (TCP).
If the next header is an IPv6 extension header other than an IPv6 fragment header, or there is more than one IPv6 extension header, the encapsulated protocol will not be matched by either pflang implementation.
This is a known shortcoming of libpcap, and is somewhat awkward to fix while targeting BPF; the tcpdump-workers bugtracker and mailing list have occasional discussions about how to address it.
Pflang, as implemented by both pflua and libpcap, compiles pflang expressions to checks against fixed offsets, before looking at any packets. The consequence of their current implementations is that in the presence of IPv6 extension headers (aside from the special case of exactly one extension header, IPv6-frag), pflang expressions such as
tcporudpdo not match packets that they would match in the absence of IPv6 extension headers.In both libpcap and pflua, byte 20 (the IPv6 'next header') field is being checked against values 6 (TCP) and 0x2c (44, IPv6 fragment header). [1] If there is an IPv6 fragment header, byte 54 is then checked to see whether that header's "next header" field value is 6 (TCP).
If the next header is an IPv6 extension header other than an IPv6 fragment header, or there is more than one IPv6 extension header, the encapsulated protocol will not be matched by either pflang implementation.
This is a known shortcoming of libpcap, and is somewhat awkward to fix while targeting BPF; the tcpdump-workers bugtracker and mailing list have occasional discussions about how to address it.
[1] The values are enumerated at http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml