This patch introduces TUN/TAP device creation support
to networkd.
Example conf to create a tap device:
file: tap.netdev
------------------
[NetDev]
Name=tap-test
Kind=tap
[Tap]
OneQueue=true
MultiQueue=true
PacketInfo=true
User=sus
Group=sus
------------------
Test:
1. output of ip link
tap-test: tap pi one_queue UNKNOWN_FLAGS:900 user 1000 group 1000
id:
uid=1000(sus) gid=10(wheel) groups=10(wheel),1000(sus)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Modifications:
Added:
1. file networkd-tuntap.c
3. netdev kind NETDEV_KIND_TUN and NETDEV_KIND_TAP
2. Tun and Tap Sections and config params to parse
conf and gperf conf parameters
[tomegun: tweak the 'kind' checking for received ifindex]
Send hostname (option 12) in DISCOVER and REQUEST messages so the
DHCP server could use it to register with dynamic DNS and such.
To opt-out of this behaviour set SendHostname to false in [DHCP]
section of .network file
[tomegun: rebased, made sure a failing set_hostname is a noop and moved
config from DHCPv4 to DHCP]
We failed to take a ref when waiting for udev synchronization. Fix that and also
make unreffing in callbacks simpler throughout by using _cleanup_ macros.
Fixes <https://bugs.freedesktop.org/show_bug.cgi?id=80556>.
The logic otherwise is that we leave anything preconfigured alone, but in the case of DHCP
we actually need to update it whenever the lease is renewed.
This adds support for DHCP options 33 and 121: Static Route and
Classless Static Route. To enable this feature, set UseRoutes=true
in .network file. Returned routes are added to the routing table.
If there are v4 or v6 specific options we can keep those in separate sections,
but for the common options, we will use only one.
Moreovere only use DHCP=[yes/both|no/none|v4|v6] to enable or disable the clients.
We used to check if e.g. IFLA_BOND_MAX is defined and provide fallback
values in missing.h is it wasn't. But over time, various kernel
versions added IFLA_* defines, so checking for IFLA_BOND_MAX is not
enough if the kernel is new enough to have some of them but too old to
have all. In case we detect that the latest known enum value is
missing, #define most of them.
https://bugs.freedesktop.org/show_bug.cgi?id=80095
When an address is configured to be all zeroes, networkd will now
automatically find a locally unused network of the right size from a
list of pre-configured pools. Currently those pools are 10.0.0.0/8,
172.16.0.0/12, 192.168.0.0/16 and fc00::/7, i.e. the network ranges for
private networks. They are compiled in, but should be configurable
eventually.
This allows applying the same configuration to a large number of
interfaces with each time a different IP range block, and management of
these IP ranges is fully automatic.
When allocating an address range from the pool it is made sure the range
is not used otherwise.
We could still have an old interface name and/or mac address when libudev
tells us that the device is initialized, as the up-to-date info could still
be on its way from the kernel.
This reverts (and rewrites) commit 7d95c772cb.
The issue blocking this feature has now been fixed in the kernel, and backported
to the various stable kernels.
Our netdevs will now have stable MAC addresses, even if one is not specified.
It may sometimes be necessary to specify the MAC address of a netdev.
Let us set the correct one from the get-go, rather than having the
kernel generate a random one, and then change it after.
It should not be possible to have a DHCP lease on a link without also having
an associated network. Add assert() to avoid compiler warnings.
Reported by Thomas H. P. Andersen
When enabled in [Network] it will set up a dhcp server on the interface, listening
on one of its statically configured IPv4 addresses and with a fixed size pool of
leases determined from it.
Example:
[Match]
Name=ve-arch-tree
[Network]
Address=192.168.12.5/24
DHCPServer=yes
[Route]
Gateway=192.168.12.5
Destination=192.168.12.0/24
In this case we will configure ve-arch-tree with the address 192.168.12.5 and
hand out addresses in the range 192.168.12.6 - 192.168.12.38.
In the future, we should (as suggested by Lennart) introduce a syntax to pick the
server address automatically.
Tom Gundersen
Susant Sahani
Lennart Poettering
Filipe Brandenburger
Eugene Yakubovich
Eugene Yakubovich
Patrik Flykt
Zbigniew Jędrzejewski-Szmek
Steven Noonan
Thomas Hindoe Paaboel Andersen