Fw: [Bug 213581] New: Change in ip_dst_mtu_maybe_forward() breaks WebRTC connections

2 messages, 2 authors, 2021-06-25 · open the first message on its own page

Fw: [Bug 213581] New: Change in ip_dst_mtu_maybe_forward() breaks WebRTC connections

From: Stephen Hemminger <stephen@networkplumber.org>
Date: 2021-06-25 15:36:41


Begin forwarded message:

Date: Fri, 25 Jun 2021 11:54:19 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 213581] New: Change in ip_dst_mtu_maybe_forward() breaks WebRTC connections


https://bugzilla.kernel.org/show_bug.cgi?id=213581

            Bug ID: 213581
           Summary: Change in ip_dst_mtu_maybe_forward() breaks WebRTC
                    connections
           Product: Networking
           Version: 2.5
    Kernel Version: 5.13.0-rc7
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
          Assignee: stephen@networkplumber.org
          Reporter: godlike64@gmail.com
        Regression: No

Recent Linux kernel versions (>=5.9 if my calculations are correct), 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:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=02a1b175b0e92d9e0fa5df3957ade8d733ceb6a0

This patch was backported to linux-stable 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.

I have also reverted this patch in 5.13.0-rc7 and WebRTC works with the patch
reverted. Without reverting the patch, it's broken.

No other protocol/connection seems to be affected.

Reproducible: Always

Steps to Reproduce:
1. Install any kernel >5.4.9 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;

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

Re: Fw: [Bug 213581] New: Change in ip_dst_mtu_maybe_forward() breaks WebRTC connections

From: Vadim Fedorenko <hidden>
Date: 2021-06-25 16:26:20

On 25.06.2021 16:36, Stephen Hemminger wrote:

Begin forwarded message:

Date: Fri, 25 Jun 2021 11:54:19 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 213581] New: Change in ip_dst_mtu_maybe_forward() breaks WebRTC connections


https://bugzilla.kernel.org/show_bug.cgi?id=213581

             Bug ID: 213581
            Summary: Change in ip_dst_mtu_maybe_forward() breaks WebRTC
                     connections
            Product: Networking
            Version: 2.5
     Kernel Version: 5.13.0-rc7
           Hardware: All
                 OS: Linux
               Tree: Mainline
             Status: NEW
           Severity: normal
           Priority: P1
          Component: IPV4
           Assignee: stephen@networkplumber.org
           Reporter: godlike64@gmail.com
         Regression: No

Recent Linux kernel versions (>=5.9 if my calculations are correct), 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:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=02a1b175b0e92d9e0fa5df3957ade8d733ceb6a0

This patch was backported to linux-stable 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.

I have also reverted this patch in 5.13.0-rc7 and WebRTC works with the patch
reverted. Without reverting the patch, it's broken.

No other protocol/connection seems to be affected.

Reproducible: Always

Steps to Reproduce:
1. Install any kernel >5.4.9 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;
I'm trying to deal with this function right now, so I can try to reproduce this 
bug too. Actually, the change should only affect configuration with route with 
mtu specified explicitly. What is the routing configuration for this case? Does 
it use any kind of tunnels to connect networks?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help