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 <[email protected]>
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.
Eric
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 <[email protected]>
> 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
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 <[email protected]>
>> 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