linux-kernel - 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: <AANLkTi=hgOcwO8ojQBtmqbROS1qrhm5HCmq7tRxesc=6@mail.gmail.com>
Date:	Fri, 25 Mar 2011 02:04:44 +0100
From:	Alessandro Suardi <alessandro.suardi@...il.com>
To:	Kyle Moffett <kyle@...fetthome.net>
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 Fri, Mar 25, 2011 at 1:53 AM, Kyle Moffett <kyle@...fetthome.net> wrote:
> 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}

Fair enough, I get it.

Looks like the fix_ip_get_output() function in /etc/vpnc/vpnc-script
 needs to be augmented from the current

  sed 's/cache//;s/metric \?[0-9]\+ [0-9]\+//g;s/hoplimit [0-9]\+//g'

 to something slightly more comprehensive.


Thanks for the explanation - will keep around -git2 for my vpnc
 needs until I get this one sorted out :)

--alessandro

 "There's always a siren singing you to shipwreck"

   (Radiohead, "There There")
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/