Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

/lib/systemd/systemd-networkd: complains about invalid config section #5205

Closed
1 of 2 tasks
rickysarraf opened this issue Feb 2, 2017 · 9 comments
Closed
1 of 2 tasks

/lib/systemd/systemd-networkd: complains about invalid config section #5205

rickysarraf opened this issue Feb 2, 2017 · 9 comments
Labels
network not-a-bug

Comments

@rickysarraf
Copy link

Submission type

  • Bug report
  • Request for enhancement (RFE)

systemd version the issue has been seen with

Package: systemd
Version: 232-14

Used distribution

Debian
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852806

Bug report

As per the documentation:

[TUN] SECTION OPTIONS
       The "[Tun]" section only applies for netdevs of kind "tun", and accepts the
       following keys:

       OneQueue=
           Takes a boolean argument. Configures whether all packets are queued at the
           device (enabled), or a fixed number of packets are queued at the device and the
           rest at the "qdisc". Defaults to "no".

       MultiQueue=
           Takes a boolean argument. Configures whether to use multiple file descriptors
           (queues) to parallelize packets sending and receiving. Defaults to "no".

       PacketInfo=
           Takes a boolean argument. Configures whether packets should be prepended with
           four extra bytes (two flag bytes and two protocol bytes). If disabled, it
           indicates that the packets will be pure IP packets. Defaults to "no".

       VNetHeader=
           Takes a boolean argument. Configures IFF_VNET_HDR flag for a tap device. It
           allows sending and receiving larger Generic Segmentation Offload (GSO) packets.
           This may increase throughput significantly. Defaults to "no".

       User=
           User to grant access to the /dev/net/tun device.

       Group=
           Group to grant access to the /dev/net/tun device.

[TAP] SECTION OPTIONS
       The "[Tap]" section only applies for netdevs of kind "tap", and accepts the same
       keys as the "[Tun]" section.

And here's my configuration accordingly.

rrs@learner:~$ cat /etc/systemd/network/tap.netdev 
[NetDev]
Name=tap0
Kind=tap

[Tap]
Group=uml-net
User=uml-net
2017-01-27 / 19:07:13 ♒♒♒  ☺

I keep getting the following warning/error in journal logs.

Jan 27 19:10:10 learner systemd[1]: Starting Network Service...
Jan 27 19:10:10 learner systemd-networkd[923]: [/etc/systemd/network/tap.netdev:5] Unknown section 'TAP'. Ignoring.
Jan 27 19:10:10 learner systemd-networkd[923]: tap0: TUNSETIFF failed on tun dev: Device or resource busy
Jan 27 19:10:10 learner systemd-networkd[923]: [/etc/systemd/network/localBridge.network:9] Unknown lvalue 'PoolOffset' in section 'Network'
Jan 27 19:10:10 learner systemd-networkd[923]: sysbr0: netdev ready
Jan 27 19:10:10 learner systemd-networkd[923]: sysbr0: Gained IPv6LL
Jan 27 19:10:10 learner systemd-networkd[923]: wlan0: Gained IPv6LL
Jan 27 19:10:10 learner systemd-networkd[923]: Enumeration completed
Jan 27 19:10:10 learner systemd-timesyncd[27499]: Network configuration changed, trying to establish connection.
Jan 27 19:10:10 learner systemd-networkd[923]: sysbr0: netdev exists, using existing without changing its parameters
Jan 27 19:10:10 learner systemd[1]: Started Network Service.
@poettering
Copy link
Member

the logs you see suggest that your section in the file is actually spelt "[TAP]", not "[Tap]". Not that the formatting of the man page is a bit confusing there, as the man tool automatically uppercases section names.

@poettering poettering added needs-reporter-feedback ❓ There's an unanswered question, the reporter needs to answer network labels Feb 2, 2017
@mbiebl
Copy link
Contributor

mbiebl commented Feb 2, 2017

@poettering See the config @rickysarraf posted. The relevant part

[Tap]
Group=uml-net
User=uml-net

@poettering
Copy link
Member

well, networkd doesn't uppercase this on its own. Somehow I'd bet that @rickysarraf's file /etc/systemd/network/tap.netdev actually doesn't look like what he posted. @rickysarraf are you sure that that file contains the [Tap] capitalization, and not [TAP]?

networkd, like all other systemd tools (and most of UNIX) is case-sensitive when it comes to these things...

@rickysarraf
Copy link
Author

It does seem to be a mess-up on my end. :-(

I just verified the history of that file in etckeeper and currently it was using the [TAP]. When I filed the Debian bug report, I played around with [Tap] setting without a reboot, and it turns out it doesn't reflect the right behavior with just a restart of systemd-networkd.

Jan 27 18:51:39 learner systemd[1]: Stopping Network Service...
Jan 27 18:51:39 learner systemd[1]: Stopped Network Service.
Jan 27 18:51:39 learner systemd[1]: Starting Network Service...
Jan 27 18:51:39 learner systemd-networkd[27549]: [/etc/systemd/network/tap.netdev:5] Unknown section 'TAP'. Ignoring.
Jan 27 18:51:39 learner systemd-networkd[27549]: tap0: TUNSETIFF failed on tun dev: Device or resource busy
Jan 27 18:51:39 learner systemd-networkd[27549]: [/etc/systemd/network/localBridge.network:9] Unknown lvalue 'PoolOffset' in section 'Network'
Jan 27 18:51:39 learner systemd-networkd[27549]: sysbr0: netdev ready
Jan 27 18:51:39 learner systemd-networkd[27549]: sysbr0: Gained IPv6LL
Jan 27 18:51:39 learner systemd-networkd[27549]: wlan0: Gained IPv6LL
Jan 27 18:51:39 learner systemd-networkd[27549]: Enumeration completed
Jan 27 18:51:39 learner systemd-networkd[27549]: sysbr0: netdev exists, using existing without changing its parameters
Jan 27 18:51:39 learner systemd[1]: Started Network Service.
Jan 27 18:51:39 learner systemd-networkd[27549]: sysbr0: Configured
Jan 27 19:08:47 learner systemd[1]: Stopping Network Service...
Jan 27 19:08:47 learner systemd[1]: Stopped Network Service.
Jan 27 19:08:47 learner systemd[1]: Starting Network Service...
Jan 27 19:08:48 learner systemd-networkd[714]: [/etc/systemd/network/tap.netdev:5] Unknown section 'TAP'. Ignoring.
Jan 27 19:08:48 learner systemd-networkd[714]: tap0: TUNSETIFF failed on tun dev: Device or resource busy
Jan 27 19:08:48 learner systemd-networkd[714]: [/etc/systemd/network/localBridge.network:9] Unknown lvalue 'PoolOffset' in section 'Network'
Jan 27 19:08:48 learner systemd-networkd[714]: sysbr0: netdev ready
Jan 27 19:08:48 learner systemd-networkd[714]: sysbr0: Gained IPv6LL
Jan 27 19:08:48 learner systemd-networkd[714]: wlan0: Gained IPv6LL
Jan 27 19:08:48 learner systemd-networkd[714]: Enumeration completed
Jan 27 19:08:48 learner systemd-networkd[714]: sysbr0: netdev exists, using existing without changing its parameters
Jan 27 19:08:48 learner systemd[1]: Started Network Service.
Jan 27 19:08:48 learner systemd-networkd[714]: sysbr0: Configured
Jan 27 19:09:14 learner systemd[1]: Stopping Network Service...
Jan 27 19:09:14 learner systemd[1]: Stopped Network Service.

What perhaps systemd should do is to not ignore error tap0: TUNSETIFF failed on tun dev: Device or resource busy during a systemd-networkd restart

For the actual issue, after switching to "[Tap]" and a reboot, it does not complain anymore.

@poettering
Copy link
Member

Well, what else would it do then log and proceed? I am mean, it should certainly not abort, otherwise failure on the TUN device might cause your entire networking to break...

Anyway, closing this here, as the problem appears not to be in systemd.

@poettering poettering added not-a-bug and removed needs-reporter-feedback ❓ There's an unanswered question, the reporter needs to answer labels Feb 2, 2017
@fsateler fsateler mentioned this issue Feb 2, 2017
Closed
2 tasks
@rickysarraf
Copy link
Author

Perhaps, have 2 sets of error types. For failures like these, you could return with a non-fatal error code, which will result in networkd failing, while still, the network remaining operational.

@poettering
Copy link
Member

Well, this this is kinda what happens... we log about it but continue...

@yardenac
Copy link

I'm having the same problem on an up-to-date Arch Linux (systemd 236.81-1) and the solution doesn't seem to work for me. I followed these instructions exactly:

$ cat /etc/systemd/network/vpn.netdev 
[NetDev]
Name=tun5
Kind=tun

[Tun]
User=vpn
Group=network

$ cat /etc/systemd/network/vpn.network 
[Match]
Name=tun5

[Address]
Address=192.168.200.2/24

But I still get this error:

Jan 19 23:47:06 hostname systemd[1]: Starting Network Service...
-- Subject: Unit systemd-networkd.service has begun start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit systemd-networkd.service has begun starting up.
Jan 19 23:47:07 hostname systemd-networkd[10233]: /etc/systemd/network/vpn.netdev:5: Unknown section 'Tun'. Ignoring.
Jan 19 23:47:07 hostname systemd-networkd[10233]: tun5: Gained IPv6LL
Jan 19 23:47:07 hostname systemd-networkd[10233]: wlan0: Gained IPv6LL
Jan 19 23:47:07 hostname systemd-networkd[10233]: Enumeration completed
Jan 19 23:47:07 hostname systemd[1]: Started Network Service.
-- Subject: Unit systemd-networkd.service has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit systemd-networkd.service has finished starting up.
--
-- The start-up result is RESULT.
Jan 19 23:47:07 hostname systemd-networkd[10233]: wlan0: found matching network '/etc/systemd/network/00-wireless-dhcp.network', based on potentially unpredictable ifname
Jan 19 23:47:07 hostname systemd-networkd[10233]: wlan0: DHCPv4 address 192.168.1.200/24 via 192.168.1.1
Jan 19 23:47:08 hostname systemd-networkd[10233]: tun5: Lost carrier

@z3ntu
Copy link
Contributor

z3ntu commented Jan 22, 2018

I also get

Jan 22 10:15:42 pi3 systemd-networkd[4363]: /etc/systemd/network/tap0.netdev:5: Unknown section 'Tap'. Ignoring.

with

==> tap0.netdev <==
[NetDev]
Name=tap0
Kind=tap

[Tap]
#PacketInfo=true
User=nobody

==> tap0.network <==
[Match]
Name=tap0

[Network]
Bridge=bridge0

I cannot say if it worked before because I just put the config in today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
network not-a-bug
Milestone
No milestone
Development

No branches or pull requests
5 participants
@rickysarraf @yardenac @poettering @mbiebl @z3ntu