On 03/03/2011 01:52 AM, akpm@linux-foundation.org wrote:
quoted
The mm-of-the-moment snapshot 2011-03-02-16-52 has been uploaded to
Hi, I'm seeing this with tun (also with earlier versions):
The name of the attribute was changed to netdev_group in order to
fix this problem, in fact quite some time ago.
See the last entry of the net_class_attributes array in
net/core/net-sysfs.c, if it isn't called "netdev_group"
something is awry.
On 03/03/2011 01:52 AM, akpm@linux-foundation.org wrote:
quoted
The mm-of-the-moment snapshot 2011-03-02-16-52 has been uploaded to
Hi, I'm seeing this with tun (also with earlier versions):
The name of the attribute was changed to netdev_group in order to
fix this problem, in fact quite some time ago.
See the last entry of the net_class_attributes array in
net/core/net-sysfs.c, if it isn't called "netdev_group"
something is awry.
<idiocy>
Aha, sorry for the noise, I booted the old kernel.
</idiocy>
thanks,
--
js
On 03/03/2011 01:52 AM, akpm@linux-foundation.org wrote:
quoted
The mm-of-the-moment snapshot 2011-03-02-16-52 has been uploaded to
Hi, I'm seeing this with tun (also with earlier versions):
The name of the attribute was changed to netdev_group in order to
fix this problem, in fact quite some time ago.
See the last entry of the net_class_attributes array in
net/core/net-sysfs.c, if it isn't called "netdev_group"
something is awry.
<idiocy>
Aha, sorry for the noise, I booted the old kernel.
</idiocy>
Ok, so I booted the new kernel, and tun is broken there completely. If I
try to ping a vpn peer:
...
capget(0x20080522, 0, NULL) = 0
capset(0x20080522, 0, {0, 0, 0}) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(1025),
sin_addr=inet_addr("10.20.11.1")}, 16) = -1 EINVAL (Invalid argument)
the route is:
10.20.11.1 dev tun0 proto kernel scope link src 10.20.11.33
When I try to ping a router on eth0 10.0.28.10, it works as expected.
Maybe the changes in ipv4 routing cause this? But my amateur eyes can't
see any breakage there...
Now I'm back in mmotm 2011-02-10-16-26 and it works, indeed.
regards,
--
js
suse labs
Ok, so I booted the new kernel, and tun is broken there completely. If I
try to ping a vpn peer:
-mm tree is missing this fix which went in yesterday. Please if
you are going to be testing networking a lot, test against net-next-2.6
instead of Andrew's tree which invariable lags behind:
--------------------
ipv4: Fix __ip_dev_find() to use ifa_local instead of ifa_address.
Reported-by: Stephen Hemminger <redacted>
Reported-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/devinet.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Ok, so I booted the new kernel, and tun is broken there completely. If I
try to ping a vpn peer:
-mm tree is missing this fix which went in yesterday. Please if
you are going to be testing networking a lot, test against net-next-2.6
instead of Andrew's tree which invariable lags behind:
I'm not testing networking, I'm just using my desktop :). (And
next/master is mostly unusable for these needs. In comparison to mmotm
which is some kind of a "release".)
--------------------
ipv4: Fix __ip_dev_find() to use ifa_local instead of ifa_address.
It would be great to have a References: tag or better changelog. Then I
would give the commit a shot. The way it is I ignored it when looking at
next/master inside net/ipv4/ changes for commits to test.
Going to boot with this change.
quoted hunk
Reported-by: Stephen Hemminger <redacted>
Reported-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/devinet.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
ipv4: Fix __ip_dev_find() to use ifa_local instead of ifa_address.
It would be great to have a References: tag or better changelog. Then I
would give the commit a shot. The way it is I ignored it when looking at
next/master inside net/ipv4/ changes for commits to test.
Going to boot with this change.
Ok, so I booted the new kernel, and tun is broken there completely. If I
try to ping a vpn peer:
-mm tree is missing this fix which went in yesterday. Please if
you are going to be testing networking a lot, test against net-next-2.6
instead of Andrew's tree which invariable lags behind:
I'm not testing networking, I'm just using my desktop :). (And
next/master is mostly unusable for these needs. In comparison to mmotm
which is some kind of a "release".)
I have been hit by similar issues several times already as well.
I guess that question of including -mm into linux-next should be raised
again here ... Andrew, if I remember correctly, on last kernel summit you
were stating that you'd stop eating untill you have -mm included in -next.
Seems like you must be quite hungry these days already :)
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.