| Message ID | 1300986084.3747.101.camel@edumazet-laptop |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
On Thu, Mar 24, 2011 at 6:01 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > Le jeudi 24 mars 2011 à 17:15 +0100, Eric Dumazet a écrit : > >> I am testing following patch : >> >> diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c >> index 622ac4c..654ef5b 100644 >> --- a/net/ipv4/fib_semantics.c >> +++ b/net/ipv4/fib_semantics.c >> @@ -251,7 +251,7 @@ static struct fib_info *fib_find_info(const struct fib_info *nfi) >> nfi->fib_prefsrc == fi->fib_prefsrc && >> nfi->fib_priority == fi->fib_priority && >> memcmp(nfi->fib_metrics, fi->fib_metrics, >> - sizeof(fi->fib_metrics)) == 0 && >> + sizeof(u32) * RTAX_MAX) == 0 && >> ((nfi->fib_flags ^ fi->fib_flags) & ~RTNH_F_DEAD) == 0 && >> (nfi->fib_nhs == 0 || nh_comp(fi, nfi) == 0)) >> return fi; >> >> > > This works. Here is the formal submission : > > Thanks ! > > [PATCH] ipv4: fix fib metrics > > Alessandro Suardi reported that we could not change route metrics : > > ip ro change default .... advmss 1400 > > This regression came with commit 9c150e82ac50 (Allocate fib metrics > dynamically). fib_metrics is no longer an array, but a pointer to an > array. > > Reported-by: Alessandro Suardi <alessandro.suardi@gmail.com> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> > --- > net/ipv4/fib_semantics.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c > index 622ac4c..75b9fb5 100644 > --- a/net/ipv4/fib_semantics.c > +++ b/net/ipv4/fib_semantics.c > @@ -251,7 +251,7 @@ static struct fib_info *fib_find_info(const struct fib_info *nfi) > nfi->fib_prefsrc == fi->fib_prefsrc && > nfi->fib_priority == fi->fib_priority && > memcmp(nfi->fib_metrics, fi->fib_metrics, > - sizeof(fi->fib_metrics)) == 0 && > + sizeof(u32) * RTAX_MAX) == 0 && > ((nfi->fib_flags ^ fi->fib_flags) & ~RTNH_F_DEAD) == 0 && > (nfi->fib_nhs == 0 || nh_comp(fi, nfi) == 0)) > return fi; Tested-by: Alessandro Suardi <alessandro.suardi@gmail.com> I will however make one more bug report, as vpnc is broken before and after this patch - have to dig out what vpnc-script tries to do, which results in Error: either "to" is duplicate, or "ipid" is a garbage. after establishing the VPN tunnel. Thanks, --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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le jeudi 24 mars 2011 à 19:14 +0100, Alessandro Suardi a écrit : > > I will however make one more bug report, as vpnc is broken before > and after this patch - have to dig out what vpnc-script tries to do, > which results in > > Error: either "to" is duplicate, or "ipid" is a garbage. > > after establishing the VPN tunnel. > try following patch http://git2.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=406b6f974dae76a5b795d5c251d11c979a4e509b -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Eric Dumazet <eric.dumazet@gmail.com> Date: Thu, 24 Mar 2011 18:01:24 +0100 > [PATCH] ipv4: fix fib metrics > > Alessandro Suardi reported that we could not change route metrics : > > ip ro change default .... advmss 1400 > > This regression came with commit 9c150e82ac50 (Allocate fib metrics > dynamically). fib_metrics is no longer an array, but a pointer to an > array. > > Reported-by: Alessandro Suardi <alessandro.suardi@gmail.com> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Applied, thanks a lot Eric. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 24, 2011 at 7:45 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > Le jeudi 24 mars 2011 à 19:14 +0100, Alessandro Suardi a écrit : > >> >> I will however make one more bug report, as vpnc is broken before >> and after this patch - have to dig out what vpnc-script tries to do, >> which results in >> >> Error: either "to" is duplicate, or "ipid" is a garbage. >> >> after establishing the VPN tunnel. >> > > try following patch > > http://git2.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=406b6f974dae76a5b795d5c251d11c979a4e509b That one doesn't work. On a -git14 kernel + both the fib metrics and the above git diff, I strace'd vpnc and found out this (first triplet of public IP masked intentionally) [root@duff tmp]# egrep 'execve|garbage' strace.log |egrep '/ip|garbage' [pid 4228] execve("/sbin/ip", ["/sbin/ip", "route", "get", "xxx.9.13.212"], [/* 32 vars */]) = 0 [pid 4231] execve("/sbin/ip", ["/sbin/ip", "route", "replace", "10.175.0.0/19", "dev", "tun0"], [/* 32 vars */]) = 0 [pid 4232] execve("/sbin/ip", ["/sbin/ip", "route", "flush", "cache"], [/* 32 vars */]) = 0 [pid 4234] execve("/sbin/ip", ["/sbin/ip", "route", "get", "xxx.9.13.212"], [/* 32 vars */]) = 0 [pid 4237] execve("/sbin/ip", ["/sbin/ip", "route", "add", "xxx.9.13.212", "via", "192.168.1.1", "dev", "eth1", "src", "192.168.1.8", "ipid", "0x043f", "advmss", "1400"], [/* 32 vars */]) = 0 [pid 4237] write(2, "Error: either \"to\" is duplicate,"..., 57Error: either "to" is duplicate, or "ipid" is a garbage. 192.168.1.1 is my DSL router and 192.168.1.8 is my computer's wireless IP. Does this ring any bell ? Thanks, --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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le jeudi 24 mars 2011 à 23:11 +0100, Alessandro Suardi a écrit : > On a -git14 kernel + both the fib metrics and the above git diff, I > strace'd vpnc > and found out this (first triplet of public IP masked intentionally) > > [root@duff tmp]# egrep 'execve|garbage' strace.log |egrep '/ip|garbage' > [pid 4228] execve("/sbin/ip", ["/sbin/ip", "route", "get", > "xxx.9.13.212"], [/* 32 vars */]) = 0 > [pid 4231] execve("/sbin/ip", ["/sbin/ip", "route", "replace", > "10.175.0.0/19", "dev", "tun0"], [/* 32 vars */]) = 0 > [pid 4232] execve("/sbin/ip", ["/sbin/ip", "route", "flush", > "cache"], [/* 32 vars */]) = 0 > [pid 4234] execve("/sbin/ip", ["/sbin/ip", "route", "get", > "xxx.9.13.212"], [/* 32 vars */]) = 0 > [pid 4237] execve("/sbin/ip", ["/sbin/ip", "route", "add", > "xxx.9.13.212", "via", "192.168.1.1", "dev", "eth1", "src", > "192.168.1.8", "ipid", "0x043f", "advmss", "1400"], [/* 32 vars */]) = > 0 > [pid 4237] write(2, "Error: either \"to\" is duplicate,"..., 57Error: > either "to" is duplicate, or "ipid" is a garbage. > > 192.168.1.1 is my DSL router and 192.168.1.8 is my computer's wireless IP. > > Does this ring any bell ? > > Not a kernel error, but a tool error ? (ipid is only displayed by "ip ro show") grep ipid */*.c ip/iproute.c: fprintf(fp, " ipid 0x%04x", ci->rta_id); -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 24, 2011 at 11:18 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > Le jeudi 24 mars 2011 à 23:11 +0100, Alessandro Suardi a écrit : > >> On a -git14 kernel + both the fib metrics and the above git diff, I >> strace'd vpnc >> and found out this (first triplet of public IP masked intentionally) >> >> [root@duff tmp]# egrep 'execve|garbage' strace.log |egrep '/ip|garbage' >> [pid 4228] execve("/sbin/ip", ["/sbin/ip", "route", "get", >> "xxx.9.13.212"], [/* 32 vars */]) = 0 >> [pid 4231] execve("/sbin/ip", ["/sbin/ip", "route", "replace", >> "10.175.0.0/19", "dev", "tun0"], [/* 32 vars */]) = 0 >> [pid 4232] execve("/sbin/ip", ["/sbin/ip", "route", "flush", >> "cache"], [/* 32 vars */]) = 0 >> [pid 4234] execve("/sbin/ip", ["/sbin/ip", "route", "get", >> "xxx.9.13.212"], [/* 32 vars */]) = 0 >> [pid 4237] execve("/sbin/ip", ["/sbin/ip", "route", "add", >> "xxx.9.13.212", "via", "192.168.1.1", "dev", "eth1", "src", >> "192.168.1.8", "ipid", "0x043f", "advmss", "1400"], [/* 32 vars */]) = >> 0 >> [pid 4237] write(2, "Error: either \"to\" is duplicate,"..., 57Error: >> either "to" is duplicate, or "ipid" is a garbage. >> >> 192.168.1.1 is my DSL router and 192.168.1.8 is my computer's wireless IP. >> >> Does this ring any bell ? >> >> > > Not a kernel error, but a tool error ? > > > (ipid is only displayed by "ip ro show") > > grep ipid */*.c > ip/iproute.c: fprintf(fp, " ipid 0x%04x", ci->rta_id); Don't think so. This tool has been working since I built it (29 June 2010) and still works in -git2 :) --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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le jeudi 24 mars 2011 à 23:27 +0100, Alessandro Suardi a écrit : > Don't think so. This tool has been working since I built it (29 June 2010) > and still works in -git2 :) > 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Eric Dumazet <eric.dumazet@gmail.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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit : > From: Eric Dumazet <eric.dumazet@gmail.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@edumazet-laptop:~$ ping 4.4.4.4 PING 4.4.4.4 (4.4.4.4) 56(84) bytes of data. ^C edumazet@edumazet-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@edumazet-laptop:~$ ping -s 2000 4.4.4.4 PING 4.4.4.4 (4.4.4.4) 2000(2028) bytes of data. ^C edumazet@edumazet-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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 24, 2011 at 11:44 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit : >> From: Eric Dumazet <eric.dumazet@gmail.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@edumazet-laptop:~$ ping 4.4.4.4 > PING 4.4.4.4 (4.4.4.4) 56(84) bytes of data. > ^C > > edumazet@edumazet-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@edumazet-laptop:~$ ping -s 2000 4.4.4.4 > PING 4.4.4.4 (4.4.4.4) 2000(2028) bytes of data. > ^C > > edumazet@edumazet-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: [root@duff oldconfigs]# vpnc --version vpnc version 0.5.3-449M Copyright (C) 2002-2006 Geoffrey Keating, Maurice Massar, others vpnc comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of vpnc under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. Built with openssl certificate support. Be aware of the license implications. Supported DH-Groups: nopfs dh1 dh2 dh5 Supported Hash-Methods: md5 sha1 Supported Encryptions: null des 3des aes128 aes192 aes256 Supported Auth-Methods: psk psk+xauth hybrid(rsa) 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@duff ~]# ip -V ip utility, iproute2-ss100804 [root@duff ~]# 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 :) Thanks, --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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Alessandro Suardi <alessandro.suardi@gmail.com> Date: Fri, 25 Mar 2011 01:12:11 +0100 > If some change in the kernel broke my userspace, this usually > qualifies as a regression. Not if userspace was working on an assumption it was not allowed to make, which we believe it is in this case. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Mar 24, 2011 at 20:12, Alessandro Suardi <alessandro.suardi@gmail.com> wrote: > On Thu, Mar 24, 2011 at 11:44 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: >> Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit : >>> From: Eric Dumazet <eric.dumazet@gmail.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@edumazet-laptop:~$ ping 4.4.4.4 >> PING 4.4.4.4 (4.4.4.4) 56(84) bytes of data. >> ^C >> >> edumazet@edumazet-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@edumazet-laptop:~$ ping -s 2000 4.4.4.4 >> PING 4.4.4.4 (4.4.4.4) 2000(2028) bytes of data. >> ^C >> >> edumazet@edumazet-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@duff ~]# ip -V > ip utility, iproute2-ss100804 > [root@duff ~]# 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 25, 2011 at 1:53 AM, Kyle Moffett <kyle@moffetthome.net> wrote: > On Thu, Mar 24, 2011 at 20:12, Alessandro Suardi > <alessandro.suardi@gmail.com> wrote: >> On Thu, Mar 24, 2011 at 11:44 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: >>> Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit : >>>> From: Eric Dumazet <eric.dumazet@gmail.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@edumazet-laptop:~$ ping 4.4.4.4 >>> PING 4.4.4.4 (4.4.4.4) 56(84) bytes of data. >>> ^C >>> >>> edumazet@edumazet-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@edumazet-laptop:~$ ping -s 2000 4.4.4.4 >>> PING 4.4.4.4 (4.4.4.4) 2000(2028) bytes of data. >>> ^C >>> >>> edumazet@edumazet-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@duff ~]# ip -V >> ip utility, iproute2-ss100804 >> [root@duff ~]# 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 25, 2011 at 2:04 AM, Alessandro Suardi <alessandro.suardi@gmail.com> wrote: > On Fri, Mar 25, 2011 at 1:53 AM, Kyle Moffett <kyle@moffetthome.net> wrote: >> On Thu, Mar 24, 2011 at 20:12, Alessandro Suardi >> <alessandro.suardi@gmail.com> wrote: >>> On Thu, Mar 24, 2011 at 11:44 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: >>>> Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit : >>>>> From: Eric Dumazet <eric.dumazet@gmail.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@edumazet-laptop:~$ ping 4.4.4.4 >>>> PING 4.4.4.4 (4.4.4.4) 56(84) bytes of data. >>>> ^C >>>> >>>> edumazet@edumazet-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@edumazet-laptop:~$ ping -s 2000 4.4.4.4 >>>> PING 4.4.4.4 (4.4.4.4) 2000(2028) bytes of data. >>>> ^C >>>> >>>> edumazet@edumazet-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@duff ~]# ip -V >>> ip utility, iproute2-ss100804 >>> [root@duff ~]# 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 :) ...which didn't take that long - one last bugging question and I'm happily off to sleep; does ipid always come in the form of 0x followed by four bytes representing hex values ? In a perhaps inelegant but working way (I'm now writing through the VPN tunnel), sed 's/cache//;s/metric \?[0-9]\+ [0-9]\+//g;s/hoplimit [0-9]\+//g;s/ipid 0x....//g' appears to be Work For Me (TM). Thanks loads, --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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2011-03-25 at 02:25 +0100, Alessandro Suardi wrote: > > ...which didn't take that long - one last bugging question and I'm happily > off to sleep; does ipid always come in the form of 0x followed by four > bytes representing hex values ? In a perhaps inelegant but working way > (I'm now writing through the VPN tunnel), > > sed 's/cache//;s/metric \?[0-9]\+ [0-9]\+//g;s/hoplimit > [0-9]\+//g;s/ipid 0x....//g' > > appears to be Work For Me (TM). Please could I have a tested patch for vpnc-script? It now lives in its own repository at git://, http://git.infradead.org/users/dwmw2/vpnc-scripts.git because it's used by openconnect too, and has had various bug fixes for cross-platform support and IPv6 since it was forked from vpnc.
On Fri, May 27, 2011 at 11:27 AM, David Woodhouse <dwmw2@infradead.org> wrote: > On Fri, 2011-03-25 at 02:25 +0100, Alessandro Suardi wrote: >> >> ...which didn't take that long - one last bugging question and I'm happily >> off to sleep; does ipid always come in the form of 0x followed by four >> bytes representing hex values ? In a perhaps inelegant but working way >> (I'm now writing through the VPN tunnel), >> >> sed 's/cache//;s/metric \?[0-9]\+ [0-9]\+//g;s/hoplimit >> [0-9]\+//g;s/ipid 0x....//g' >> >> appears to be Work For Me (TM). > > Please could I have a tested patch for vpnc-script? > > It now lives in its own repository at > git://, http://git.infradead.org/users/dwmw2/vpnc-scripts.git because > it's used by openconnect too, and has had various bug fixes for > cross-platform support and IPv6 since it was forked from vpnc. I downloaded the git version and checked - the one I use is the Fedora version which seems updated to perhaps two revisions behind git... anyway, attaching (in order to not mangle whitespace) the one-liner change that I've been using since without issues - to the point that I actually forgot having patched the script... --alessandro "There's always a siren singing you to shipwreck" (Radiohead, "There There")
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c index 622ac4c..75b9fb5 100644 --- a/net/ipv4/fib_semantics.c +++ b/net/ipv4/fib_semantics.c @@ -251,7 +251,7 @@ static struct fib_info *fib_find_info(const struct fib_info *nfi) nfi->fib_prefsrc == fi->fib_prefsrc && nfi->fib_priority == fi->fib_priority && memcmp(nfi->fib_metrics, fi->fib_metrics, - sizeof(fi->fib_metrics)) == 0 && + sizeof(u32) * RTAX_MAX) == 0 && ((nfi->fib_flags ^ fi->fib_flags) & ~RTNH_F_DEAD) == 0 && (nfi->fib_nhs == 0 || nh_comp(fi, nfi) == 0)) return fi;