Hi Or, On Tue, Oct 02, 2018 at 03:21:18PM +0300, Or Gerlitz wrote: > On Thu, Sep 27, 2018 at 3:53 PM Phil Sutter <p...@nwl.cc> wrote: [...] > > Hmm, I can't reproduce this. My HEAD is at the commit you mentioned: > > > > | % sudo ./tc/tc filter add dev d0 protocol ip parent ffff: flower skip_sw > > ip_flags nofirstfrag action drop > > | RTNETLINK answers: Operation not supported > > | We have an error talking to the kernel, -1 > > | % echo $? > > | 2 > > > > Are you sure you tested the right binary? > > double checked now, seems broken on my end: > > $ git log --oneline -3 > b45e300 libnetlink: don't return error on success > 5dc2204 testsuite: add libmnl > 8804a8c Makefile: Add check target > > $./tc/tc filter add dev enp33s0f0 protocol ip parent ffff: flower > skip_sw ip_flags frag action drop && echo "success" || echo "failed" > success > > $ ./tc/tc filter add dev enp33s0f0 protocol ip parent ffff: flower > skip_sw ip_flags firstfrag action drop && echo "success" || echo > "failed" > RTNETLINK answers: Operation not supported > success
Interestingly, your output lacks the "We have an error" message mine shows. So in your case, the call to rtnl_talk_iov() from tc_filter_modify() does not return < 0. In my case, commands always fail with 'skip_sw' since I only test on a dummy interface. So maybe we hit different error paths? Could you please check what happens for you in __rtnl_talk_iov()? I guess the "RTNETLINK answers:" message should come from rtnl_talk_error(). In my case it does at least, and I haven't found an alternative place where that message could come from. Cheers, Phil
