-
Notifications
You must be signed in to change notification settings - Fork 818
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"ip6 and tcp[tcpflags] & (tcp-syn) != 0" gets "expression rejects all packets" #1207
Comments
This is a documented problem:
It would be nice to have a solution, and to that end it would help to answer two questions:
|
Given that
for Ethernet, I don't see why similar code couldn't be produced for Neither of those iterate over IPv6 headers; few if any in-kernel BPF implementations allow unbounded loops - the loop isn't really unbounded, as it advances forward through IPv6 headers and would eventually stop when it runs out of packet data, but the BPF code in the kernel doesn't know that. |
"expression rejects all packets" is only produced if the optimizer is used, which it is by default in tcpdump. The un-optimized code generated for
which is pretty much The un-optimized code generated for
which avoids those bogus tests for IPv4. Whatever's causing those bogus tests may be the sole cause of the problem. (And even the |
But the general case is more complicated, as both the LHS and RHS of the comparison operator in "expr1 relop expr2" can be fairly arbitrary expressions, with some being above the network layer and some being below the network layer, so a straightforward code generator would have to emit
for every TCP data fetch. and similar code for UDP or other transport-layer fetches. The current optimizer might not work well with that. |
I'm not a novice user. I've run this today:
I mean... I know where this comes from. In IPv6 mode tcpdump refuses to look at higher protocol stuff. However, this is plain silly, and usability nightmare. In modern internet there is not many next-headers actually in use. Also, this match is completely implementable in CBPF and EBPF. Maybe it's time to rethink usability nightmares like this?
One (not best) option is to do stuff like
tcp6
which could be an alias toip6[40]
The text was updated successfully, but these errors were encountered: