[<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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists