netdev - Re: [PATCH] ipv4: fix fib metrics

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: <AANLkTinh9Li7DGgSqcZ+p9peS5XrHWomerSvKTYwHZ9-@mail.gmail.com>
Date:	Thu, 24 Mar 2011 20:53:02 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	Alessandro Suardi <alessandro.suardi@...il.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv4: fix fib metrics

On Thu, Mar 24, 2011 at 20:12, Alessandro Suardi
<alessandro.suardi@...il.com> wrote:
> On Thu, Mar 24, 2011 at 11:44 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>> Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit :
>>> From: Eric Dumazet <eric.dumazet@...il.com>
>>> Date: Thu, 24 Mar 2011 23:32:26 +0100
>>>
>>> > Then it doesnt work anymore because it parses an ipip field from
>>> > ip route get ...
>>> >
>>> > $ ip ro get 192.168.1.1
>>> > 192.168.1.1 dev wlan0  src 192.168.1.21
>>> >     cache  ipid 0x784c mtu 1500 advmss 1460 hoplimit 64
>>> >
>>> >
>>> > Maybe you upgraded iproute2
>>>
>>> I'm leaning towards app bug too.
>>>
>>> These default metrics wouldn't get printed before, but now because of
>>> how metrics are handled, they will.
>>>
>>> Userland needs to cope properly with this.
>>
>>
>> BTW, ipip is not always printed (even on old kernels) : One needs to
>> actually need ipip generation .
>>
>> edumazet@...mazet-laptop:~$ ping 4.4.4.4
>> PING 4.4.4.4 (4.4.4.4) 56(84) bytes of data.
>> ^C
>>
>> edumazet@...mazet-laptop:~$ ip ro get 4.4.4.4
>> 4.4.4.4 dev ppp0  src 10.150.51.210
>>    cache  mtu 1500 advmss 1460 hoplimit 64
>>
>> edumazet@...mazet-laptop:~$ ping -s 2000 4.4.4.4
>> PING 4.4.4.4 (4.4.4.4) 2000(2028) bytes of data.
>> ^C
>>
>> edumazet@...mazet-laptop:~$ ip ro get 4.4.4.4
>> 4.4.4.4 dev ppp0  src 10.150.51.210
>>    cache  ipid 0xf99a mtu 1500 advmss 1460 hoplimit 64
>>
>>
>> This on a 2.6.35 kernel
>>
>> I suspect Alessandro tool had a bug anyway.
>
> I still contend this is a kernel regression :)
>
>
> vpnc is a custom build from trunk as of June 2010, with openssl support
>  to talk to my corporate VPN concentrator:
>
[...snip...]
>
> My iproute package, on this up-to-date Fedora 14 x86_64, has last been
>  updated on 20 Nov 2010, and back then I was running 2.6.37-rc2-git4
>  (I keep around my historical .config files, so I know for sure).
>
> [root@...f ~]# ip -V
> ip utility, iproute2-ss100804
> [root@...f ~]# rpm -qf /sbin/ip
> iproute-2.6.35-6.fc14.x86_64
>
> The behavior of this version of 'ip' as invoked by this version of 'vpnc'
>  is something that has worked for the last 4 months, and isn't working
>  right now. Furthermore, previous versions of 'ip' in Fedora 14 were
>  also working with the same 'vpnc', which means it's actually 9 months
>  minimum of working behavior.
>
> If some change in the kernel broke my userspace, this usually qualifies
>  as a regression.
>
> That said, if you can point me to a working version of iproute with the
>  current kernel, I have no problem in upgrading it :)

Historically you could usually take the text output of "ip route get"
and feed it right back to "ip route add", and it would work, but this
was never guaranteed.

Recently, the "ip route get" command started printing extra statistics
(like "ipid") after the other information, but obviously those
statistics are not valid for an "ip route add" command.

The kernel bug was that the "ip" command was not always getting those
statistics from the kernel, so obviously they would not be printed.

Unfortunately vpnc still tries to pass the entire output of "ip route
get" as arguments to "ip route add"; the latter command reports an
error when it gets the statistics from the former command as input.

So this is certainly not a kernel bug.  At *best* it's an iproute bug,
depending on whether or not this is considered valid:
  RT="$(ip route get [...])"
  ip route flush
  ip route add ${RT}

Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html