regression: ip r change mss doesn't work in 2.6.38-git14

After fixing the display issue thanks to Chris Wilson, I now have
another problem
 (which didn't exist in 2.6.38-git2); most websites outside of my DSL link don't
 work properly (connection packet goes through, but the page load times out
 within Firefox) unless I do

ip r change default via 192.168.1.1 dev eth1 advmss 1400

This however doesn't change advmss anymore:

[root@duff ~]# ip r
default via 192.168.1.1 dev eth1
169.254.0.0/16 dev eth1  scope link  metric 1004
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.8
[root@duff ~]# ip r change default via 192.168.1.1 dev eth1 advmss 1400
[root@duff ~]# ip r
default via 192.168.1.1 dev eth1
169.254.0.0/16 dev eth1  scope link  metric 1004
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.8


strace of this operation doesn't appear to show errors in userspace,
 which is btw:

[root@duff ~]# ip -V
ip utility, iproute2-ss100804
[root@duff ~]# rpm -qf /sbin/ip
iproute-2.6.35-6.fc14.x86_64


execve("/sbin/ip", ["ip", "r", "change", "default", "via",
"192.168.1.1", "dev", "eth1", "advmss", "1400"], [/* 23 vars */]) = 0
brk(0)                                  = 0x2461000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f79c8d1c000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=101259, ...}) = 0
mmap(NULL, 101259, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f79c8d03000
close(3)                                = 0
open("/lib64/libresolv.so.2", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p8`12\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=113832, ...}) = 0
mmap(0x3231600000, 2202280, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3231600000
mprotect(0x3231617000, 2093056, PROT_NONE) = 0
mmap(0x3231816000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x3231816000
mmap(0x3231818000, 6824, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3231818000
close(3)                                = 0
open("/lib64/libdl.so.2", O_RDONLY)     = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\r
/2\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=22536, ...}) = 0
mmap(0x322f200000, 2109720, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x322f200000
mprotect(0x322f202000, 2097152, PROT_NONE) = 0
mmap(0x322f402000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x322f402000
close(3)                                = 0
open("/lib64/libgcc_s.so.1", O_RDONLY)  = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360(
02\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=89760, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f79c8d02000
mmap(0x3230200000, 2183032, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3230200000
mprotect(0x3230215000, 2093056, PROT_NONE) = 0
mmap(0x3230414000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14000) = 0x3230414000
close(3)                                = 0
open("/lib64/libc.so.6", O_RDONLY)      = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\357\241.2\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1956608, ...}) = 0
mmap(0x322ea00000, 3781816, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x322ea00000
mprotect(0x322eb91000, 2097152, PROT_NONE) = 0
mmap(0x322ed91000, 20480, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x191000) = 0x322ed91000
mmap(0x322ed96000, 21688, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x322ed96000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f79c8d01000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f79c8cff000
arch_prctl(ARCH_SET_FS, 0x7f79c8cff720) = 0
mprotect(0x3231816000, 4096, PROT_READ) = 0
mprotect(0x322f402000, 4096, PROT_READ) = 0
mprotect(0x322ed91000, 16384, PROT_READ) = 0
mprotect(0x322e81e000, 4096, PROT_READ) = 0
munmap(0x7f79c8d03000, 101259)          = 0
socket(PF_NETLINK, SOCK_RAW, 0)         = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0
bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=4336, groups=00000000}, [12]) = 0
sendto(3, "\24\0\0\0\22\0\1\3\330]\213M\0\0\0\0\0\0\0\0", 20, 0, NULL, 0) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000},
msg_iov(1)=[{"\344\3\0\0\20\0\2\0\330]\213M\360\20\0\0\0\0\4\3\1\0\0\0I\0\1\0\0\0\0\0"...,
16384}], msg_controllen=0, msg_flags=0}, 0) = 3020
brk(0)                                  = 0x2461000
brk(0x2482000)                          = 0x2482000
brk(0)                                  = 0x2482000
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000},
msg_iov(1)=[{"\24\0\0\0\3\0\2\0\330]\213M\360\20\0\0\0\0\0\0\1\0\0\0I\0\1\0\0\0\0\0"...,
16384}], msg_controllen=0, msg_flags=0}, 0) = 20
sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000},
msg_iov(1)=[{"8\0\0\0\30\0\5\1\331]\213M\0\0\0\0\2\0\0\0\376\3\0\1\0\0\0\0\10\0\5\0"...,
56}], msg_controllen=0, msg_flags=0}, 0) = 56
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
groups=00000000},
msg_iov(1)=[{"$\0\0\0\2\0\0\0\331]\213M\360\20\0\0\0\0\0\0008\0\0\0\30\0\5\1\331]\213M"...,
16384}], msg_controllen=0, msg_flags=0}, 0) = 36
exit_group(0)                           = ?


Thanks in advance,

--alessandro

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

   (Radiohead, "There There")

Le jeudi 24 mars 2011 à 16:08 +0100, Alessandro Suardi a écrit :

After fixing the display issue thanks to Chris Wilson, I now have
another problem
 (which didn't exist in 2.6.38-git2); most websites outside of my DSL link don't
 work properly (connection packet goes through, but the page load times out
 within Firefox) unless I do

ip r change default via 192.168.1.1 dev eth1 advmss 1400

This however doesn't change advmss anymore:

[root@duff ~]# ip r
default via 192.168.1.1 dev eth1
169.254.0.0/16 dev eth1  scope link  metric 1004
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.8
[root@duff ~]# ip r change default via 192.168.1.1 dev eth1 advmss 1400
[root@duff ~]# ip r
default via 192.168.1.1 dev eth1
169.254.0.0/16 dev eth1  scope link  metric 1004
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.8

Indeed, we'll take a look, thanks for the report.

In the time being you can do :

ip ro change default via 192.168.1.1 dev eth1 advmss 1400 mtu 1500

On Thu, Mar 24, 2011 at 4:21 PM, Eric Dumazet [off-list ref] wrote:

Le jeudi 24 mars 2011 à 16:08 +0100, Alessandro Suardi a écrit :

quoted

After fixing the display issue thanks to Chris Wilson, I now have
another problem
 (which didn't exist in 2.6.38-git2); most websites outside of my DSL link don't
 work properly (connection packet goes through, but the page load times out
 within Firefox) unless I do

ip r change default via 192.168.1.1 dev eth1 advmss 1400

This however doesn't change advmss anymore:

[root@duff ~]# ip r
default via 192.168.1.1 dev eth1
169.254.0.0/16 dev eth1  scope link  metric 1004
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.8
[root@duff ~]# ip r change default via 192.168.1.1 dev eth1 advmss 1400
[root@duff ~]# ip r
default via 192.168.1.1 dev eth1
169.254.0.0/16 dev eth1  scope link  metric 1004
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.8

Indeed, we'll take a look, thanks for the report.

In the time being you can do :

ip ro change default via 192.168.1.1 dev eth1 advmss 1400 mtu 1500

Thanks - this one works for me.

I'm available to test patches if needed, though I have a feeling you
 already have a handle on the issue and won't need that ;)

--alessandro

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

   (Radiohead, "There There")

Le jeudi 24 mars 2011 à 16:52 +0100, Alessandro Suardi a écrit :

On Thu, Mar 24, 2011 at 4:21 PM, Eric Dumazet [off-list ref] wrote:

quoted

Le jeudi 24 mars 2011 à 16:08 +0100, Alessandro Suardi a écrit :

quoted

After fixing the display issue thanks to Chris Wilson, I now have
another problem
 (which didn't exist in 2.6.38-git2); most websites outside of my DSL link don't
 work properly (connection packet goes through, but the page load times out
 within Firefox) unless I do

ip r change default via 192.168.1.1 dev eth1 advmss 1400

This however doesn't change advmss anymore:

[root@duff ~]# ip r
default via 192.168.1.1 dev eth1
169.254.0.0/16 dev eth1  scope link  metric 1004
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.8
[root@duff ~]# ip r change default via 192.168.1.1 dev eth1 advmss 1400
[root@duff ~]# ip r
default via 192.168.1.1 dev eth1
169.254.0.0/16 dev eth1  scope link  metric 1004
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.8

Indeed, we'll take a look, thanks for the report.

In the time being you can do :

ip ro change default via 192.168.1.1 dev eth1 advmss 1400 mtu 1500

Thanks - this one works for me.

I'm available to test patches if needed, though I have a feeling you
 already have a handle on the issue and won't need that ;)

;)

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;

Le jeudi 24 mars 2011 à 17:15 +0100, Eric Dumazet a écrit :

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 <redacted>
Signed-off-by: Eric Dumazet <redacted>
---
 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;

On Thu, Mar 24, 2011 at 6:01 PM, Eric Dumazet [off-list ref] wrote:

Tested-by: Alessandro Suardi <redacted>



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")

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

From: Eric Dumazet <redacted>
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 <redacted>
Signed-off-by: Eric Dumazet <redacted>

Applied, thanks a lot Eric.

On Thu, Mar 24, 2011 at 7:45 PM, Eric Dumazet [off-list ref] wrote:

Le jeudi 24 mars 2011 à 19:14 +0100, Alessandro Suardi a écrit :

quoted

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")

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);

On Thu, Mar 24, 2011 at 11:18 PM, Eric Dumazet [off-list ref] wrote:

Le jeudi 24 mars 2011 à 23:11 +0100, Alessandro Suardi a écrit :

quoted

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")

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

From: Eric Dumazet <redacted>
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.

Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit :

From: Eric Dumazet <redacted>
Date: Thu, 24 Mar 2011 23:32:26 +0100

quoted

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.

On Thu, Mar 24, 2011 at 11:44 PM, Eric Dumazet [off-list ref] wrote:

Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit :

quoted

From: Eric Dumazet <redacted>
Date: Thu, 24 Mar 2011 23:32:26 +0100

quoted

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")

From: Alessandro Suardi <redacted>
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.

On Thu, Mar 24, 2011 at 20:12, Alessandro Suardi
[off-list ref] wrote:

On Thu, Mar 24, 2011 at 11:44 PM, Eric Dumazet [off-list ref] wrote:

quoted

Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit :

quoted

From: Eric Dumazet <redacted>
Date: Thu, 24 Mar 2011 23:32:26 +0100

quoted

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

On Fri, Mar 25, 2011 at 1:53 AM, Kyle Moffett [off-list ref] wrote:

On Thu, Mar 24, 2011 at 20:12, Alessandro Suardi
[off-list ref] wrote:

quoted

On Thu, Mar 24, 2011 at 11:44 PM, Eric Dumazet [off-list ref] wrote:

quoted

Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit :

quoted

From: Eric Dumazet <redacted>
Date: Thu, 24 Mar 2011 23:32:26 +0100

quoted

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...]

quoted

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")

On Fri, Mar 25, 2011 at 2:04 AM, Alessandro Suardi
[off-list ref] wrote:

On Fri, Mar 25, 2011 at 1:53 AM, Kyle Moffett [off-list ref] wrote:

quoted

On Thu, Mar 24, 2011 at 20:12, Alessandro Suardi
[off-list ref] wrote:

quoted

On Thu, Mar 24, 2011 at 11:44 PM, Eric Dumazet [off-list ref] wrote:

quoted

Le jeudi 24 mars 2011 à 15:36 -0700, David Miller a écrit :

quoted

From: Eric Dumazet <redacted>
Date: Thu, 24 Mar 2011 23:32:26 +0100

quoted

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...]

quoted

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")

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.

-- 
dwmw2

On Fri, May 27, 2011 at 11:27 AM, David Woodhouse [off-list ref] wrote:

On Fri, 2011-03-25 at 02:25 +0100, Alessandro Suardi wrote:

quoted

...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")