netdev - Re: re iproute2 - don't return error on success fix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181008124141.GB14666@orbyte.nwl.cc>
Date:   Mon, 8 Oct 2018 14:41:41 +0200
From:   Phil Sutter <phil@....cc>
To:     Or Gerlitz <gerlitz.or@...il.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        David Ahern <dsahern@...il.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Roi Dayan <roid@...lanox.com>
Subject: Re: re iproute2 - don't return error on success fix

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 <phil@....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