programs should return e.g. 65535, not 1 for a match

Question

programs should return e.g. 65535, not 1 for a match

Closed this issue 9 years ago · 8 comments

Thanks for bpftools!

I've just got them working (after a fashion) on FreeBSD using ng_bpf , but found that for desired operation I needed the dns_gen.py generated programs not to ret 1, since that causes any matched packet that's forwarded to be truncated to that length.

Answer 1 · 2016-01-11T10:33:06.000Z

interesting. so you want it to return 0 or 65535?

Answer 2 · 2016-01-11T10:47:31.000Z

Well, I'm actually using 8192, although 4096 would be fine given normal EDNS0 implementations. The main point though is that returning 1 in any filter seems prone to causing problems since the return value is supposed to indicate the length of data to forward, and doesn't just represent a boolean match / don't match value.

FWIW, On FreeBSD 10 tcpdump -ddd always gives ret 65535 for a "match" and on Fedora 23 it generates ret 262144.

Answer 3 · 2016-01-11T14:59:24.000Z

@raybellis please confirm the fix.

Answer 4 · 2016-01-11T15:27:40.000Z

Looks good to me - for DNS the patch was trivial but I didn't want to touch the non-DNS modules myself. I see a couple of extraneous commas in the modified lines (from before the patch) in bpftools/gen_badrand.py ?

Answer 5 · 2016-01-11T23:33:52.000Z

Not a Python expert, but I think the comma before the parenthesis is the Python syntax for turning a variable into a tuple or something like that. bpftools code is not very consistent on this (sometimes a comma is used sometimes it's not). It doesn't seem to matter either way though, it's probably just a cosmetic issue. @majek?

Answer 6 · 2016-01-12T04:18:46.000Z

Correct, to make sure it's a tuple. Actualy badrand was never working. We should just remove it.

Answer 7 · 2016-01-12T11:34:23.000Z

Correct, to make sure it's a tuple

But it's not used consistently (not just in badrand, but all over the code) when the % operator (whatever it's called) is used, should we change that or is it on purpose?

Answer 8 · 2016-01-15T02:56:11.000Z

In practice the difference between

"%s" % variable

and

"%s" % (variable,)

is very subtle. The first one will fail if variable is a tuple itself (of lenght > 1), the second won't. Since in our case the "variable" is not a tuple (but a string I believe), both notations are identical. I prefer the latter one to make it explicit. It's details.