linux-kernel - Re: [BUG] v4.20 - bridge not getting DHCP responses? (works in 4.19.13)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 10 Jan 2019 01:38:49 +0100
From:   Ian Kumlien <ian.kumlien@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        jeffrey.t.kirsher@...el.com,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        nikolay@...ulusnetworks.com,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [BUG] v4.20 - bridge not getting DHCP responses? (works in 4.19.13)

Confirmed, sending a new mail with summary etc

On Thu, Jan 10, 2019 at 1:16 AM Ian Kumlien <ian.kumlien@...il.com> wrote:
>
> On Wed, Jan 9, 2019 at 12:17 AM Ian Kumlien <ian.kumlien@...il.com> wrote:
> > On Wed, Jan 9, 2019, 00:09 Florian Fainelli <f.fainelli@...il.com wrote:
>
>  [--8<---]
>
> >> > when looking at "git log v4.19...v4.20
> >> > drivers/net/ethernet/intel/ixgbe/" nothing else really stands out...
> >> > The machine is also running NAT for my home network and all of that
> >> > works just fine...
> >> >
> >> > I started with tcpdump, prooving that packets reached all the way
> >> > outside but replies never made it, reboorting
> >> > with 4.19.13 resulted in replies appearing in the tcpdump.
> >> >
> >> > I don't quite know where to look - and what can i do to test - i tried
> >> > disabling all offloading (due to the UDP
> >> > offloading changes) but nothing helped...
> >> >
> >> > Ideas? Patches? ;)
> >>
> >> Running a bisection would certainly help find the offending commit if
> >> that is something that you can do?
> >
> > I was hoping for a likely suspect but this was on my "Todo" for Friday night anyway... (And I already started testing with some patches reversed)
>
> So after lengthy git bisect sections, both from the latest stable i
> was using (not the best of ideas)
> and from 4.19.
>
> The latest stable yielded 72b0094f918294e6cb8cf5c3b4520d928fbb1a57 -
> which is incorrect...
>
> However, the proper bisect gave me this:
> fb420d5d91c1274d5966917725e71f27ed092a85 is the first bad commit
> commit fb420d5d91c1274d5966917725e71f27ed092a85
> Author: Eric Dumazet <edumazet@...gle.com>
> Date:   Fri Sep 28 10:28:44 2018 -0700
>
>     tcp/fq: move back to CLOCK_MONOTONIC
>
>     In the recent TCP/EDT patch series, I switched TCP and sch_fq
>     clocks from MONOTONIC to TAI, in order to meet the choice done
>     earlier for sch_etf packet scheduler.
>
>     But sure enough, this broke some setups were the TAI clock
>     jumps forward (by almost 50 year...), as reported
>     by Leonard Crestez.
>
>     If we want to converge later, we'll probably need to add
>     an skb field to differentiate the clock bases, or a socket option.
>
>     In the meantime, an UDP application will need to use CLOCK_MONOTONIC
>     base for its SCM_TXTIME timestamps if using fq packet scheduler.
>
>     Fixes: 72b0094f9182 ("tcp: switch tcp_clock_ns() to CLOCK_TAI base")
>     Fixes: 142537e41923 ("net_sched: sch_fq: switch to CLOCK_TAI")
>     Fixes: fd2bca2aa789 ("tcp: switch internal pacing timer to CLOCK_TAI")
>     Signed-off-by: Eric Dumazet <edumazet@...gle.com>
>     Reported-by: Leonard Crestez <leonard.crestez@....com>
>     Tested-by: Leonard Crestez <leonard.crestez@....com>
>     Signed-off-by: David S. Miller <davem@...emloft.net>
>
> :040000 040000 06615f5ed4486fd0af77a8fb59775a9f2346aebc
> 7f883c7753cb3d5d881e0edbef2989f4e6db6a1f M include
> :040000 040000 767c5e93fe5cfd609f90834d93978511c284ea01
> cc47bd361516622c0b21602e188181fdfc6b2995 M net
> ----
>
> Which could actually be the culprit - I'm having problems *with* UDP
> traffic (DHCP) and I am using fq
>
> Lets hope it's so, since this was kinda boring:
> ls /lib/modules |grep 4.19.0 |wc -l
> 27
>
> Testing 4.20.1 and then 4.20.1 with the suspected patch reverted, will
> report shortly!