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: <Pine.LNX.4.64.0906141015130.11221@sister.anvils>
Date:	Sun, 14 Jun 2009 10:28:59 +0100 (BST)
From:	Hugh Dickins <hugh.dickins@...cali.co.uk>
To:	Eric Lammerts <eric@...merts.org>
cc:	kernel list <linux-kernel@...r.kernel.org>, gregkh@...e.de,
	netdev@...r.kernel.org
Subject: Re: 2.6.30: tun losing ip

On Sun, 14 Jun 2009, Eric Lammerts wrote:
> 
> Hi,
> I'm having problems with openvpn clients on 2.6.30. I get stuff like this:
> 
> TUN/TAP device tun0 opened
> TUN/TAP TX queue length set to 100
> /sbin/ifconfig tun0 10.2.222.50 pointopoint 10.2.222.49 mtu 1500
> /sbin/route add -net 10.2.222.0 netmask 255.255.255.0 gw 10.2.222.49
> SIOCADDRT: No such process
> 
> There is something strange going on with tun devices:
> 
> # tunctl -t tun1; ifconfig tun1 1.2.3.4; ifconfig tun1; sleep 1; ifconfig tun1
> Set 'tun1' persistent and owned by uid 0
> tun1      Link encap:Ethernet  HWaddr 1E:EF:79:F2:D9:67
>           inet addr:1.2.3.4  Bcast:1.255.255.255  Mask:255.0.0.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:500
>           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> tun1      Link encap:Ethernet  HWaddr 1E:EF:79:F2:D9:67
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:1 overruns:0 carrier:0
>           collisions:0 txqueuelen:500
>           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
> 
> First you see the ip, then you don't...
> 
> I traced it back to this commit:
> 
> $ git-bisect bad
> 05f54c13cd0c33694eec39a265475c5d6cf223cf is first bad commit
> commit 05f54c13cd0c33694eec39a265475c5d6cf223cf
> Author: Hugh Dickins <hugh@...itas.com>
> Date:   Thu Apr 16 21:55:29 2009 +0100
> 
>     Revert "kobject: don't block for each kobject_uevent".
> 
> If I take 2.6.30 and revert that commit, the problem goes away.

I'm mortified!  But it's rather odd, that's just a straight reversion
of an earlier, clearly buggy commit: I guess you have some other issue,
which reverting to a wait here now uncovers.

One likely workaround: I suspect your .config says something like
CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug, but you've no /sbin/hotplug?
Please try changing that to CONFIG_UEVENT_HELPER_PATH="", and see if
the problem comes up with that resulting kernel.

But though that should be a good workaround, it doesn't shed light
on your underlying problem.  Sorry, I've no hope of helping with
ip/tun/tap questions - Cc'ed netdev.

Hugh
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ