Skip to content
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

Compiled bpfilter doesn't load: No such file or directory #1

Closed
Haxverse opened this issue Mar 2, 2023 · 5 comments
Closed

Compiled bpfilter doesn't load: No such file or directory #1

Haxverse opened this issue Mar 2, 2023 · 5 comments
Assignees

Comments

@Haxverse
Copy link

Haxverse commented Mar 2, 2023

Hello @qdeslandes,

I have just compiled the bpfilter module on both the linux-6.1.14 branch and the bpf-next branch, both times I get the following output in dmesg:

[    4.619942] bpfilter: Loaded bpfilter_umh pid 971
[    4.622811] bpfilter: generate forward packet assessment
[    4.622823] bpfilter: generate forward packet assessment
[    4.625250] bpfilter: failed to create TC hook: No such file or directory
[    4.625348] bpfilter: failed to load chain INPUT in table filter: processed 73 insns (limit 1000000) max_states_per_insn 0 total_states 4 peak_states 4 mark_read 3
[    4.625455] bpfilter: failed to install new table 'filter': No such file or directory
[    4.625578] bpfilter: failed to created filter table: No such file or directory
[    4.625807] bpfilter: read fail 0

Would you happen to know if I did something wrong?

Thanks a lot,
Mr. Hax

@qdeslandes
Copy link
Contributor

Hi!

I tried bpfilter on latest bpf-next changes, and everything is fine on my side:

[  935.679528] bpfilter: Loaded bpfilter_umh pid 10526
[  935.680291] bpfilter: log file opened and ready to use
[  935.680393] bpfilter: generate forward packet assessment
[  935.680422] bpfilter: fixup counter for rule 0
[  935.680451] bpfilter: generate forward packet assessment
[  935.680473] bpfilter: fixup counter for rule 1
[  935.680502] bpfilter: fixup counter for rule 2
[  935.680921] bpfilter: opened BPF map with FD 3
[  935.682306] libbpf: Kernel error message: Exclusivity flag on, cannot modify
[  935.683390] libbpf: Kernel error message: Exclusivity flag on, cannot modify
[  935.684148] libbpf: Kernel error message: Exclusivity flag on, cannot modify
[  935.684190] bpfilter: installed filter table

My guess is that this error is commit from a missing configuration. Could you share your .config file?

Also, I've pushed a few new commits to fix a couple of issues I found out, although I don't expect those to solve your problem.

@qdeslandes qdeslandes self-assigned this Mar 3, 2023
@Haxverse
Copy link
Author

Haxverse commented Mar 3, 2023

Hello,

That's weird, alright. I personally think the ifindex is part of the problem, anyway, here's my current .config file: https://pastebin.com/raw/RKN6RgPJ

Thanks a lot,
Mr. Hax

@qdeslandes
Copy link
Contributor

I personally think the ifindex is part of the problem

Seems like it. I added a comment to README.md to explain how to modify the interface index. Feel free to try it! :)

@qdeslandes
Copy link
Contributor

@Haxverse did changing the ifindex solved it?

@qdeslandes
Copy link
Contributor

Closing this issue as it is most likely fixed now.

qdeslandes added a commit to qdeslandes/bpfilter that referenced this issue Sep 6, 2023
Until now, each bf_program expected its rules indexes to be sequential
for all the rules applicable to it, starting from 0. For example, with
the following set of rules:
- #0 - Block ICMP on veth1
- facebook#1 - Allow all
The program attached to veth1 would have #0 and facebook#1, while the program
attached to eth0 would only have facebook#1. Then, there would be 1 counters map
for each program, with as many entries as rules defined in the program
(following previous example, 2 entries for veth1, 1 for eth0).

However, rule->index would be used to retrieve a rule's counters in each
bf_program. Hence, the program attached to eth0 tried to access the
counters map at index 1 to get the counters of the rule with index=1,
which doesn't exist.

This changes solves this issue by ensuring the rule will update the
counters at its rule->index index, meaning all the programs from a given
codegen will have the same number of entries in their counters map, even
though some of them might remain unused.

Using the first example, both veth1 and eth0 programs would have a
counters map with 2 entries. #0 would always write to index 0, while facebook#1
would always write to index 1.

Another solution would be to have a unique counters map at the codegen
level, shared by all the codegen's programs, but we wouldn't have
per-interface counters.

Signed-off-by: Quentin Deslandes <qde@naccy.de>
qdeslandes added a commit that referenced this issue Sep 6, 2023
Until now, each bf_program expected its rules indexes to be sequential
for all the rules applicable to it, starting from 0. For example, with
the following set of rules:
- #0 - Block ICMP on veth1
- #1 - Allow all
The program attached to veth1 would have #0 and #1, while the program
attached to eth0 would only have #1. Then, there would be 1 counters map
for each program, with as many entries as rules defined in the program
(following previous example, 2 entries for veth1, 1 for eth0).

However, rule->index would be used to retrieve a rule's counters in each
bf_program. Hence, the program attached to eth0 tried to access the
counters map at index 1 to get the counters of the rule with index=1,
which doesn't exist.

This changes solves this issue by ensuring the rule will update the
counters at its rule->index index, meaning all the programs from a given
codegen will have the same number of entries in their counters map, even
though some of them might remain unused.

Using the first example, both veth1 and eth0 programs would have a
counters map with 2 entries. #0 would always write to index 0, while #1
would always write to index 1.

Another solution would be to have a unique counters map at the codegen
level, shared by all the codegen's programs, but we wouldn't have
per-interface counters.

Signed-off-by: Quentin Deslandes <qde@naccy.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants