1. Messages
  2. unknown func 13

Re: unknown func 13

O Mahony, Billy <billy.o.mahony@...>
 

Hi Daniel, Brendan,

Thanks for the tips. Unless what I'm trying to do just won't work I'll stick with kernel 4.4 and the ingress qdisc for now.

So I changed my bpf programs to look like this:
6 int eth1_ic(struct __sk_buff *skb) {
7 bpf_trace_printk ("eth1_ic\n");
8 bpf_redirect(5, 0);
9 return TC_ACT_REDIRECT;

However, I still don’t see packets being received by the traffic generator I have attached to eht1 and eth3.

If I also run BPF.trace_print in a separate console (actually hello_world.py) I can see the trace statements but not at anything like the rate that I configured the traffic generator to generate packets (100pkts/sec). Also if I vary the rate of traffic ingress on the eth1/3 the ratio of the corresponding trace lines does not change - so not sure what is going on there.

avahi-daemon-1006 [031] ..s. 10942.915221: : eth1_ic
avahi-daemon-1006 [031] ..s. 10943.100833: : eth1_ic
avahi-daemon-1006 [031] ..s. 10943.182141: : eth3_ic
avahi-daemon-1006 [031] ..s. 10943.801170: : eth1_ic
avahi-daemon-1006 [031] ..s. 10944.375068: : eth3_ic
avahi-daemon-1006 [031] ..s. 10944.560597: : eth3_ic

BTW my tc filter output looks like so:

$ tc filter show dev eth3 parent ffff:
filter protocol all pref 49152 u32
filter protocol all pref 49152 u32 fh 800: ht divisor 1
filter protocol all pref 49152 u32 fh 800::1 order 1 key ht 800 bkt 0 flowid 1:2
match 00000000/00000000 at 0
action order 1: gact action pass
random type none pass val 0
index 10 ref 1 bind 1

Thanks again,

Billy.

-----Original Message-----
From: Daniel Borkmann [mailto:daniel@...]
Sent: Thursday, March 3, 2016 9:05 PM
To: Brenden Blanco <bblanco@...>
Cc: O Mahony, Billy <billy.o.mahony@...>; iovisor-
dev@...
Subject: Re: [iovisor-dev] unknown func 13

On 03/03/2016 10:01 PM, Brenden Blanco wrote:
On Thu, Mar 3, 2016 at 11:31 AM, Daniel Borkmann
<daniel@...>
wrote:

On 03/03/2016 08:19 PM, Brenden Blanco via iovisor-dev wrote:
[...]

On Thu, Mar 3, 2016 at 5:52 AM, O Mahony, Billy
<billy.o.mahony@...
[...]

#add a filter to accept all eth frame. Attach the bpf action?
functions
to the filter?

#I have no idea what the classid, target and keys parameters mean!

ip.tc("add-filter", "u32", ifindex_eth1, ":1", parent="ffff:",

action=[action_eth1],

protocol=protocols.ETH_P_ALL, classid=1,

target=0x10002, keys=['0x0/0x0+0'])

ip.tc("add-filter", "u32", ifindex_eth3, ":1", parent="ffff:",

action=[action_eth3],

protocol=protocols.ETH_P_ALL, classid=1,

target=0x10002, keys=['0x0/0x0+0'])

Yeah, it's a bit of black magic. it's basically creating a
match-all rule (match 0 bytes and offset 0 == true), with the
matching action being the bpf program. The classid and target aren't
really meaningful with just one action and filter, so it's ok to ignore for
now.

The clsact qdisc added in 4.5 by Daniel Borkmann is a much better
abstraction for this, and I'll try to upstream some pyroute2 code to
support this.
Plus you may also want to try out cls_bpf with da (direct-action) mode.
That will save you the u32 match all classifier config and is faster.
Speaking of which, I just opened
https://github.com/svinota/pyroute2/pull/223 to add support in
pyroute2 upstream. The docstring in that pull request shows an example
usage, which I'll also add to a testcase in bcc once it merges upstream.

I've done similar additions for go in
https://github.com/vishvananda/netlink/pull/94, if go is your thing.
That's awesome, thanks Brenden!
Join iovisor-dev@lists.iovisor.org to automatically receive all group messages.