Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Debian 11: netplan and dnsmasq race condition

Linux Kernel, Network, and Services configuration.
Post Reply
Message
Author
manuelino
Posts: 5
Joined: 2023-03-14 18:29
Has thanked: 1 time

Debian 11: netplan and dnsmasq race condition

#1 Post by manuelino »

Hello people.

I'm looking for tips about a problem I have been facing on my Debian 11 system.

Some context: I use an old laptop as a network router with external USB WiFi adapters, powered by Debian 11. Network configuration is handled by netplan, which takes care of creating a bridge to which the dongles and the wired cards are enslaved. Then, dnsmasq listens on the bridge and starts serving IPs to clients.

Normally, after boot everything works fine. But sometimes (about once a week) the system is unable to assign IP addresses. The logs says that dnsmasq could not start because the designated interface to listen on did not exist. This makes me think that somehow dnsmasq is started before network configuration is complete, despite its unit containing both "Requires" and "After" referring to network.target. The docs for network.target say:
At start-up, any configured synthetic network devices (i.e. not
physical ones that require hardware to show up and be probed,
but virtual ones like bridge devices and similar which are
created programmatically) that do not depend on any underlying
hardware should be allocated by the time this target is
reached. It is not necessary for these interfaces to also have
completed IP level configuration by the time network.target is
reached.
Since the bridge is a virtual device, it should be created by the time network.target completes and dnsmasq should see it. However, it also depend on underlying hardware indirectly (because of the physical slave NICs). So I don't get if this is some kind of bug or expected behavior, and most of the time this setup works out of pure luck.

As a workaround, I've tried adding Before and BindsTo referring the unit representing the bridge as extensions to dnsmasq via a drop-in.

Aki
Global Moderator
Global Moderator
Posts: 2823
Joined: 2014-07-20 18:12
Location: Europe
Has thanked: 69 times
Been thanked: 385 times

Re: Debian 11: netplan and dnsmasq race condition

#2 Post by Aki »

Hello,
Thanks for the detailed report. Many software components are at stake. Configuration samples to reproduce it and a copy of system logs when the issue occurs could be useful. I suggest to report it as a bug report to the Debian Bug Tracking System [1], too.

---
[1] https://bugs.debian.org
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀

manuelino
Posts: 5
Joined: 2023-03-14 18:29
Has thanked: 1 time

Re: Debian 11: netplan and dnsmasq race condition

#3 Post by manuelino »

@Aki thank you for your answer. I'll open an issue. As for the logs, I'll dig them up from a previous boot.

reinob
Posts: 1189
Joined: 2014-06-30 11:42
Has thanked: 97 times
Been thanked: 47 times

Re: Debian 11: netplan and dnsmasq race condition

#4 Post by reinob »

maybe you want to add the "--bind-interfaces" (aka -z) option to dnsmasq, so that:
On systems which support it, dnsmasq binds the wildcard address, even when it is listening on only some interfaces. It then discards requests that it shouldn't reply to. This has the advantage of working even when interfaces come and go and change address. This option forces dnsmasq to really bind only the interfaces it is listening on. About the only time when this is useful is when running another nameserver (or another instance of dnsmasq) on the same machine. Setting this option also enables multiple instances of dnsmasq which provide DHCP service to run in the same machine.

This option has been patched to always use SO_BINDTODEVICE socket option when binding to interfaces. As consequence, dnsmasq WILL NOT ANSWER to any DNS Queries that come to the socket with the correct destination IP address, but originally on different interface. This behavior differs from the original dnsmasq upstream version and is used for security reasons.

manuelino
Posts: 5
Joined: 2023-03-14 18:29
Has thanked: 1 time

Re: Debian 11: netplan and dnsmasq race condition

#5 Post by manuelino »

Sorry for the late response, but I had to migrate the whole router system to a new machine and it took me a good amount of time, in between other stuff.
While ugly, I have been able to solve the problem via the oldest trick... adding a delay in hostapd's service unit:

Code: Select all

cat hostapd@.service.d/delay.conf 
[Service]
ExecStartPre=-/usr/bin/sleep 10
With this drop-in, the system has been 100% reliable for months. Now this is clearly not a real solution but has proven effective.
With the release of Debian 12, I'll wait and see if the same problem without the delay still occurs after upgrading.

Post Reply