Re: 2.6.30: tun losing ip

Re: 2.6.30: tun losing ip

[Hugh Dickins]

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@veritas.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

Re: 2.6.30: tun losing ip

[Eric Lammerts]

On 06/14/2009 05:28 AM, Hugh Dickins wrote:
> On Sun, 14 Jun 2009, Eric Lammerts wrote:
>> There is something strange going on with tun devices:
<snip>
>> 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@veritas.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.

Actually I do have an /sbin/hotplug, with I now noticed has some old 
script stuff behind it that starts a udhcpc... aarrrgh. I removed it and 
the problem's gone.

Apologies for wasting your time.

Eric