diff options
| author | Richard Maw <richard.maw@codethink.co.uk> | 2015-03-12 18:14:58 +0000 |
|---|---|---|
| committer | Tom Gundersen <teg@jklm.no> | 2015-03-12 19:34:35 +0100 |
| commit | d422e52a3523ad0955bec4f9fbed46e234d28590 (patch) | |
| tree | 29aa2c22199501aa8150f4a7ead958de12623872 | |
| parent | b83cbcb7d95482baa588706227f01bbbe44b9d12 (diff) | |
networkd: Begin with serial number 1 for netlink requests
"Notifications are of informal nature and no reply is expected, therefore the
sequence number is typically set to 0."[1]
If networkd is started soon after recent netlink activity, then there
will be messages with sequence number 0 in the buffer.
The first thing networkd does is to request a dump of all the links. If
it uses sequence number 0 for this, then it may confuse the dump request's
response with that of a notification.
This will result in it failing to properly enumerate all the links,
but more importantly, when it comes to enumerate all the addresses, it
will still have the link dump in progress, so the address enumeration
will fail with -EBUSY.
[1]: http://www.infradead.org/~tgr/libnl/doc/core.html#core_msg_types
[tomegun: sequence -> serial]
Notes
Backport: bugfix
| -rw-r--r-- | src/libsystemd/sd-rtnl/sd-rtnl.c | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/src/libsystemd/sd-rtnl/sd-rtnl.c b/src/libsystemd/sd-rtnl/sd-rtnl.c index ae49c77e0..7cdcc5d96 100644 --- a/src/libsystemd/sd-rtnl/sd-rtnl.c +++ b/src/libsystemd/sd-rtnl/sd-rtnl.c @@ -61,6 +61,11 @@ static int sd_rtnl_new(sd_rtnl **ret) { sizeof(struct nlmsghdr), sizeof(uint8_t))) return -ENOMEM; + /* Change notification responses have sequence 0, so we must + * start our request sequence numbers at 1, or we may confuse our + * responses with notifications from the kernel */ + rtnl->serial = 1; + *ret = rtnl; rtnl = NULL; |