Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 797211 - net-misc/dhcpcd: interface_mtu option broken? (was: >sys-kernel/gentoo-sources-5.4.72 breaks webrtc (Google Meet, Discord, possibly others) when forwarding (i.e. in a gateway))
Summary: net-misc/dhcpcd: interface_mtu option broken? (was: >sys-kernel/gentoo-source...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: William Hubbs
Depends on:
Reported: 2021-06-20 22:18 UTC by godlike64
Modified: 2022-08-26 12:50 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description godlike64 2021-06-20 22:18:13 UTC
Any gentoo-sources version newer than 5.4.72, when used as a gateway on a LAN (or a similar setup) will break WebRTC protocols such as Google Meet, Discord, etc. (have not done extensive testing but would gather that most similar protocols are affected). In the case of Meet, no video for any participant is ever shown (other than my own), and nobody can see my video, although audio does work. In the case of Discord, no audio/video for other participants is ever shown. Note that every meeting is initiated or joined from inside the LAN, not on the gateway itself.

Using plain iptables, firewalld+iptables or firewalld+nftables makes no difference (it was the first thing I tried). I discovered this a few months ago when updating the kernel, and found that reverting to the previous kernel made this work again. I didn't look further into it until now, when I can no longer stay on that old of a kernel :).

Using git-bisect I was able to identify the offending commit:

This patch was backported to linux-stable (gentoo-sources) shortly after 5.4.72 released. It appears to still be there in vanilla upstream. I can confirm that reverting this patch in 5.4.109 fixes the issue and webrtc works again.

No other protocol/connection seems to be affected.

Reproducible: Always

Steps to Reproduce:
1. Install any kernel >5.4.72 on a gateway device.
2. Try to use a conferencing application that uses WebRTC (Meet, Discord, etc). Either start or join a meeting from a device that sits in the LAN.
Actual Results:  
Audio and/or video does not work when a meeting is initiated/joined from within the LAN

Expected Results:  
Both audio and video should work when inside the meeting.

My C is quite limited, but it appears that this function, from wherever it gets called, returns a different value after the mentioned commit. It used to return:

return min(READ_ONCE(dst->dev->mtu), IP_MAX_MTU);

Now it returns:

mtu = dst_metric_raw(dst, RTAX_MTU);
if (mtu)
    return mtu;
Comment 1 Mike Pagano gentoo-dev 2021-06-20 22:28:23 UTC
Can you submit this upstream, please at and CC ?

Great job on the bisect.

I'm going to ping the author directly.
Comment 2 godlike64 2021-06-25 20:17:15 UTC
Reported upstream:

Added to the CC list in the upstream bug.
Comment 3 godlike64 2021-06-27 20:30:51 UTC
Apparently related to honoring the ISP MTU parameter in DHCP. I was receiving a 576 MTU for that route:

root@manya ~ # ip route
default via W.X.Y.1 dev eno1 proto dhcp src W.X.Y.Z metric 3 mtu 576 dev enp3s0 proto kernel scope link src dev docker0 proto kernel scope link src via dev tun0 dev tun0 proto kernel scope link src 
W.X.Y.0/24 dev eno1 proto dhcp scope link src W.X.Y.Z metric 3 mtu 576 
root@manya ~ # 

Commented out the following line in /etc/dhcpcd.conf:

option interface_mtu

Restarted the eno1 card and had to restart the browsers to test again, the issue seems to be gone.

I don't know if this would warrant a change to the default dhcpcd configuration file for that, as I can't tell if it's just my crappy ISP or it could happen to someone else.
Comment 4 Mike Pagano gentoo-dev 2021-07-01 17:54:58 UTC
Looks like the kernel is doing what's it's asked to do.

Reassigning to dhcpcd maintainer to see if something should be considered there or is this a case of the ISP doing faulty things.
Comment 5 Roy Marples 2022-08-26 12:50:49 UTC
This is ISP doing faulty things - dhcpcd is just doing what it's told.

interface_mtu is the IPv4 equivalent of accept_ra_mtu in the Linux kernel which is enabled by default. dhcpcd just mirrors this.