FS#35810 - [netctl] tuntap service binds to non-existing interface

Attached to Project: Arch Linux
Opened by David Kowis (BeepDog) - Sunday, 16 June 2013, 06:24 GMT
Last edited by Jouke Witteveen (jouke) - Monday, 17 June 2013, 09:09 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Jouke Witteveen (jouke)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
the tuntap Connection type doesn't ever bring up a tap0 device.

Additional info:
versions: core/netctl 1.1-1 (base) [installed]


log output:
2013-06-16T01:17:02-05:00 moebius systemd[1]: Expecting device /sys/subsystem/net/devices/tap0...
2013-06-16T01:18:32-05:00 moebius systemd[1]: Job sys-subsystem-net-devices-tap0.device/start timed out.
2013-06-16T01:18:32-05:00 moebius systemd[1]: Timed out waiting for device /sys/subsystem/net/devices/tap0.
2013-06-16T01:18:32-05:00 moebius systemd[1]: Dependency failed for Openvpn Tap Connection.

netctl file:

# cat openvpntap0
Description="Openvpn Tap Connection"
Interface=tap0
Connection=tuntap
Mode=tap
User=nobody
Group=nobody


Steps to reproduce:
I can run, by hand the ip command to get it to properly create the device, additionally, I've tried hacking /usr/lib/network/connections/tuntap and inserted a raise_error just to see if it's calling things, and it doesn't appear to ever get to the point where it'll call the ip command.

If I create the device by hand via "ip tuntap add dev tap0 mode tap" while it's waiting, the script then fails to execute claiming that the interface is already up. I can reliably repeat this.

the syslog when that happens looks more like this:
`netctl start openvpntap0`
2013-06-16T01:21:08-05:00 moebius systemd[1]: Expecting device sys-subsystem-net-devices-tap0.device...
`ip tuntap add dev tap0 mode tap`
2013-06-16T01:22:07-05:00 moebius systemd[1]: Found device /sys/subsystem/net/devices/tap0.
2013-06-16T01:22:07-05:00 moebius systemd[1]: Starting Openvpn Tap Connection...
2013-06-16T01:22:07-05:00 moebius network[4996]: Starting network profile 'openvpntap0'...
2013-06-16T01:22:07-05:00 moebius network[4996]: Interface 'tap0' already exists
2013-06-16T01:22:07-05:00 moebius network[4996]: Failed to bring the network up for profile 'openvpntap0'
2013-06-16T01:22:07-05:00 moebius systemd[1]: netctl@openvpntap0.service: main process exited, code=exited, status=1/FAILURE
2013-06-16T01:22:07-05:00 moebius systemd[1]: Failed to start Openvpn Tap Connection.
2013-06-16T01:22:07-05:00 moebius systemd[1]: Unit netctl@openvpntap0.service entered failed state.


I think there's probably some ordering problem where it's expecting the device to exist before it tries to create the device.
This task depends upon

Closed by  Jouke Witteveen (jouke)
Monday, 17 June 2013, 09:09 GMT
Reason for closing:  Fixed
Additional comments about closing:  feb66
Comment by David Kowis (BeepDog) - Sunday, 16 June 2013, 06:28 GMT
The problem lies in the .service file that is created by netctl enable openvpntap0

.include /usr/lib/systemd/system/netctl@.service

[Unit]
Description=Openvpn Tap Connection
BindsTo=sys-subsystem-net-devices-tap0.device
After=sys-subsystem-net-devices-tap0.device


It won't start the script until after the tap0 device exists, which isn't any good, because it's job is to create the tap0 device!
Comment by David Kowis (BeepDog) - Sunday, 16 June 2013, 06:32 GMT
Yeah, there's a fundamental problem with the way this is set up. The Interface identifier equates to the BindToInterface identifier, which requires that the interface exist before it will execute connection stuff.

So then, how do we prevent it from expecting the interface to be up, so that we can actually turn up the interface...

I need this so I can establish my bridge, and have the tap0 slaved to it, and then when openvpn fires up it's on the bridge.

Thanks!
Comment by David Kowis (BeepDog) - Sunday, 16 June 2013, 06:42 GMT
Ah, this only happens when one has used netctl enable <tuntap connection>

It works just fine, if you say netctl start <tuntap connection> without having enabled it. It's the service file that is generated that borks it.
Comment by David Kowis (BeepDog) - Sunday, 16 June 2013, 07:01 GMT
I hacked it by removing the After and BindTo directives in the generated service file. workaround:
# cat netctl\@openvpntap0.service
.include /usr/lib/systemd/system/netctl@.service

[Unit]
Description=Openvpn Tap Connection
#BindsTo=sys-subsystem-net-devices-tap0.device
#After=sys-subsystem-net-devices-tap0.device
Comment by Jouke Witteveen (jouke) - Sunday, 16 June 2013, 08:31 GMT
This behavior should have been fixed in 0.8 and improved in 1.1. Do the lines disappear when you `netctl reenable openvpntap0`?
Comment by David Kowis (BeepDog) - Monday, 17 June 2013, 03:51 GMT
Nope.

This behavior is trivial to reproduce btw.

Just set up any arch chroot, copy the example tuntap out into the netctl dir, and then do netctl enable tuntap.

You'll find the file filled with:
<file>
.include /usr/lib/systemd/system/netctl@.service

[Unit]
Description=Example tuntap connection
BindsTo=sys-subsystem-net-devices-tun0.device
After=sys-subsystem-net-devices-tun0.device
</file>

After doing netctl reenable tuntap, it looks exactly the same.
Comment by Jouke Witteveen (jouke) - Monday, 17 June 2013, 09:08 GMT
Apparently, this still wasn't fixed. The next version will contain another shot at it (tested).

Thanks for reporting.

Loading...