DHCP server 'randomly'(?) sets client NICs to mtu 1280

RainmakerRaw commented 1 year ago

Prerequisites

[X] I have checked the Wiki and Discussions and found no answer
[X] I have searched other issues and found no duplicates
[X] I want to report a bug and not ask a question

Operating system type

Linux, Other (please mention the version in the description)

CPU architecture

64-bit ARM

Installation

GitHub releases or script from README

Setup

On one machine

AdGuard Home version

v0.107.21

Description

What did you do?

Disabled DHCP server on my router. Enabled DHCP server on AGH, then entered known LAN clients as static leases (i.e. MAC, IP, hostname).

Expected result

AGH should serve as the LAN DHCP server, giving out IPs to clients and keeping a list thereof in the db to show in the AGH webUI. No other changes 'exotic' settings without user input.

Actual result

Linux clients on my LAN (Fedora 37, Debian 11.6, Arch, AlmaLinux 8.7) are dropping their NIC MTU down to 1280 without notice or warning after gaining a lease from AGH's DHCP server.

Screenshots (if applicable)

Additional information

Running bare-metal on a Radxa ROCK 5 model B. OS is Radxa's Ubuntu 20.04.5 LTS server with their 5.10.110-34-rockchip kernel.

$ uname -a
Linux rock-5b 5.10.110-34-rockchip-gca15bbe36e6c #rockchip SMP Wed Dec 7 06:54:05 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

I spent hours troubleshooting sudden speed issues on WireGuard interfaces with the inability to connect to web pages (despite ping/traceroute being functional).

I finally realised the physical NIC MTU had dropped its MTU from 1500 to 1280 after renewing its lease with AGH's DHCP server, which meant the wg interface's MTU was mismatched to such a degree (higher) it couldn't function. Manually setting the physical NIC MTU back as a test (sudo ifconfig eth0 mtu 1500) fixed the issues immediately, but the MTU resets to 1280 after reboot (naturally).

Disabling AGH's DHCP server, re-enabling the DHCP server on my x86 router and rebooting local devices fixes this entirely. With my router running the DHCP server, all devices go back to setting their NIC's MTU to 1500 as one would expect.

I have checked the AGH verbose log as well as webUI and there seems to be no mention of, or cause for, this to happen. I have checked the Wiki to see if I need to manually specify MTU (really), but no. The AGH verbose log lists many entries for DHCP, but they're all banal and don't seem relevant. Attached is an excerpt regardless, in case it helps. The log is huge so I less AdGuardHome.log | grep -i dhcp and saved one of the sections to the attached result here.

I hope this is helpful. Thanks in advance.

agh.verbose.log

phckopper commented 1 year ago

Bump as I have the same issue. MTU on clients dropped from 1500 to 1280 in all clients and made Tailscale (which uses Wireguard) stop working over Ethernet. Clients via Wi-Fi can still connect, probably due to the different size of the frames. As stated above, setting the MTU manually fixed the issue.

Version 4.8.0 installed as a Home Assistant Add-on

phckopper commented 1 year ago

Screenshot_20230129_130023

Wireshark capture of the DHCP response given by the AdGuard Home server

phckopper commented 1 year ago

Apparently, the developers chose 576 bytes as the default MTU due to RFC2131.

That is, strictly speaking, correct but outdated, as most home DHCP routers will default to 1500 MTU nowadays.

Increasing can be done by adding this to your configuration file:

dhcp:
  dhcpv4:
    options:
      - '22 u16 1500'

For the devs, please note that setting a very low MTU due to a recommendation from 1997 can lead to significantly decreased performance. I encourage you to raise the default value.

megamorf commented 1 year ago

This very uncommon setting has been breaking Docker containers on my Ubuntu servers.

  ▶ ip a
  1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
      inet 127.0.0.1/8 scope host lo
         valid_lft forever preferred_lft forever
      inet6 ::1/128 scope host
         valid_lft forever preferred_lft forever
- 2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc mq state UP group default qlen 1000
      link/ether 00:0c:29:a2:fd:08 brd ff:ff:ff:ff:ff:ff
      altname enp3s0
      inet 192.168.39.128/24 metric 100 brd 192.168.39.255 scope global dynamic ens160
         valid_lft 85472sec preferred_lft 85472sec
      inet6 2001:9e8:1007:2c00:20c:29ff:fea2:fd08/64 scope global dynamic mngtmpaddr noprefixroute
         valid_lft 6790sec preferred_lft 3190sec
      inet6 fe80::20c:29ff:fea2:fd08/64 scope link
         valid_lft forever preferred_lft forever
  3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
      link/ether 02:42:f9:e4:82:2f brd ff:ff:ff:ff:ff:ff
      inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
         valid_lft forever preferred_lft forever
  4: br-f1e1462f76a7: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
      link/ether 02:42:7d:f3:6a:4a brd ff:ff:ff:ff:ff:ff
      inet 172.18.0.1/16 brd 172.18.255.255 scope global br-f1e1462f76a7
         valid_lft forever preferred_lft forever

The result is that regular containers have issues reaching external networks, name resolution works but anything remotely more complex such as http calls fail. If the very same container is started with host networking --net=host the problem is gone. This is because the docker bridge network was set to a higher MTU than the physical interface of the host that got a low MTU setting from Adguard. This has cost me needless hours of troubleshooting.

megamorf commented 1 year ago

Apparently, the developers chose 576 bytes as the default MTU due to RFC2131.

That is, strictly speaking, correct but outdated, as most home DHCP routers will default to 1500 MTU nowadays.

Increasing can be done by adding this to your configuration file:
dhcp:
  dhcpv4:
    options:
      - '22 u16 1500'
For the devs, please note that setting a very low MTU due to a recommendation from 1997 can lead to significantly decreased performance. I encourage you to raise the default value.

Note that MTU is option 26, not 22.

EugeneOne1 commented 1 year ago

@RainmakerRaw, @phckopper, @megamorf, hello and apologies for the late response. We've finally pushed the edge build which doesn't specify the Interface MTU option at all. Could you please check if it improves the situation?

ainar-g commented 1 year ago

We're going to close this issue. Please let us know if the option is still sent.

AdguardTeam / AdGuardHome