From owner-freebsd-current@freebsd.org Wed Apr 15 20:27:45 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 02D362C15DF; Wed, 15 Apr 2020 20:27:45 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 492YnX6F3Cz4N2q; Wed, 15 Apr 2020 20:27:44 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from mx.bofh.network (mx.bofh.network [IPv6:2001:19f0:5001:2b77:5400:2ff:fe7b:aa2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.bofh.network", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: bofh/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 3461619AC0; Wed, 15 Apr 2020 20:27:44 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from [IPv6:2402:54c0:ffff:ffff:9188:3af7:1bd8:3b5d] ( [2402:54c0:ffff:ffff:9188:3af7:1bd8:3b5d]) by mx.bofh.network (OpenSMTPD) with ESMTPSA id 74b240b3 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Wed, 15 Apr 2020 20:27:41 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: FreeBSD CI Weekly Report 2020-04-12 From: Muhammad Moinur Rahman In-Reply-To: <885331586982061@myt5-bc0f9d8e5f27.qloud-c.yandex.net> Date: Thu, 16 Apr 2020 02:27:36 +0600 Cc: Kristof Provost , "freebsd-testing@freebsd.org" , "freebsd-current@freebsd.org" , "freebsd-stable@freebsd.org" , =?utf-8?Q?Olivier_Cochard-Labb=C3=A9?= Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200414223710.GB33328@freefall.freebsd.org> <885331586982061@myt5-bc0f9d8e5f27.qloud-c.yandex.net> To: "Alexander V. Chernikov" X-Mailer: Apple Mail (2.3608.60.0.2.5) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 20:27:45 -0000 Hi Alexandar, I have changed net/scapy to apply a simple patch as a workaround for the = time being. ports@r531789 should do the trick for now. So no need to = revert. Kind Regards, Moin > On 16 Apr, 2020, at 02:21, Alexander V. Chernikov = wrote: >=20 >=20 >=20 > 15.04.2020, 15:10, "Kristof Provost" : >> On 15 Apr 2020, at 15:34, Kristof Provost wrote: >>> On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: >>>> (Please send the followup to freebsd-testing@ and note Reply-To is >>>> set.) >>>>=20 >>>> FreeBSD CI Weekly Report 2020-04-12 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> Here is a summary of the FreeBSD Continuous Integration results = for >>>> the period >>>> from 2020-04-06 to 2020-04-12. >>>>=20 >>>> During this period, we have: >>>>=20 >>>> * 1801 builds (94.0% (+0.4) passed, 6.0% (-0.4) failed) of = buildworld >>>> and >>>> buildkernel (GENERIC and LINT) were executed on aarch64, amd64, >>>> armv6, >>>> armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, = riscv64, >>>> sparc64 architectures for head, stable/12, stable/11 branches. >>>> * 288 test runs (25.1% (-24.6) passed, 29.9% (+10.6) unstable, = 45.1% >>>> (+14.1) >>>> exception) were executed on amd64, i386, riscv64 architectures = for >>>> head, >>>> stable/12, stable/11 branches. >>>> * 30 doc and www builds (83.3% (-1.3) passed, 16.7% (+1.3) failed) >>>>=20 >>>> Test case status (on 2020-04-12 23:59): >>>> | Branch/Architecture | Total | Pass | Fail | Skipped >>>> | >>>> | ------------------- | --------- | ---------- | -------- | = -------- >>>> | >>>> | head/amd64 | 7744 (+4) | 7638 (+19) | 14 (+5) | 92 (-20) >>>> | >>>> | head/i386 | 7742 (+4) | 7628 (+15) | 16 (+5) | 98 (-16) >>>> | >>>> | 12-STABLE/amd64 | 7508 (0) | 7449 (-3) | 1 (+1) | 58 (+2) >>>> | >>>> | 12-STABLE/i386 | 7506 (0) | 7425 (-17) | 2 (+2) | 79 (+15) >>>> | >>>> | 11-STABLE/amd64 | 6882 (0) | 6829 (-6) | 1 (+1) | 52 (+5) >>>> | >>>> | 11-STABLE/i386 | 6880 (0) | 6749 (-82) | 80 (+80) | 51 (+2) >>>> | >>>>=20 >>>> (The statistics from experimental jobs are omitted) >>>>=20 >>>> If any of the issues found by CI are in your area of interest or >>>> expertise >>>> please investigate the PRs listed below. >>>>=20 >>>> The latest web version of this report is available at >>>> https://hackmd.io/@FreeBSD-CI/report-20200412 and archive is >>>> available at >>>> https://hackmd.io/@FreeBSD-CI/ , any help is welcome. >>>>=20 >>>> ## News >>>>=20 >>>> * The test env now loads the required module for firewall tests. >>>>=20 >>>> * New armv7 job is added (to replace armv6 one): >>>> * FreeBSD-head-armv7-testvm >>>> The images are available at https://artifact.ci.freebsd.org >>>> FreeBSD-head-armv7-test is ready but needs test env update. >>>>=20 >>>> ## Failing jobs >>>>=20 >>>> * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ >>>> * See console log for the error details. >>>>=20 >>>> ## Failing tests >>>>=20 >>>> * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ >>>> * = local.kyua.integration.cmd_about_test.topic__authors__installed >>>> * sys.netipsec.tunnel.empty.v4 >>>> * sys.netipsec.tunnel.empty.v6 >>>> * sys.netpfil.common.forward.ipf_v4 >>>> * sys.netpfil.common.forward.ipfw_v4 >>>> * sys.netpfil.common.forward.pf_v4 >>>> * sys.netpfil.common.tos.ipfw_tos >>>> * sys.netpfil.common.tos.pf_tos >>>> * sys.netpfil.pf.forward.v4 >>> I can=E2=80=99t actually reproduce this failure in my test VM, but = with the >>> ci test VM I can reproduce the problem. >>> It=E2=80=99s not related to pf, because the sanity check ping we do = before >>> we set up pf already fails. >>> Or rather pft_ping.py sends an incorrect packet, because `ping` = does >>> get the packet to go where it=E2=80=99s supposed to go. >>>=20 >>> Scapy seems to fail to find the source IP address, so we get this: >>>=20 >>> 12:12:22.152652 IP 0.0.0.0 > 198.51.100.3: ICMP echo = request, id 0, >>> seq 0, length 12 >>>=20 >>> I have a vague recollection that we=E2=80=99ve seem this problem = before, but >>> I can=E2=80=99t remember what we did about it. >>>=20 >>> In all likelihood most of the other netpfil tests fail for exactly = the >>> same reason. >>=20 >> The problem appears to be that >> /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is = misparsing >> the `netstat -rnW` output. > Thanks for the analysis! >=20 > Sorry for breaking the tests. > I should have run tests with userland changes installed. >=20 > I'll revert the netstat output changes shortly to unbreak the tests. > Re longer-term: parsing textual output for the routes does not seem to = be a good habit, especially in these days. > Structural (libxo) approach looks better, however I guess this will = make scapy unusable on the routers with full-view. >=20 > So far light-weight sysctl-route reader looks like the best option. > What do you folks think? >=20 >>=20 >> For reference, this is the output in the test VM: >>=20 >> Routing tables >>=20 >> Internet: >> Destination Gateway Flags Nhop# Mtu Netif >> Expire >> 127.0.0.1 link#2 UH 1 16384 lo0 >> 192.0.2.0/24 link#4 U 2 1500 epair0a >> 192.0.2.1 link#4 UHS 1 16384 lo0 >> 198.51.100.0/24 192.0.2.2 UGS 3 1500 epair0a >>=20 >> Internet6: >> Destination Gateway Flags >> Nhop# Mtu Netif Expire >> ::/96 ::1 UGRS >> 4 16384 lo0 >> ::1 link#2 UH >> 1 16384 lo0 >> ::ffff:0.0.0.0/96 ::1 UGRS >> 4 16384 lo0 >> fe80::/10 ::1 UGRS >> 4 16384 lo0 >> fe80::%lo0/64 link#2 U >> 3 16384 lo0 >> fe80::1%lo0 link#2 UHS >> 2 16384 lo0 >> fe80::%epair0a/64 link#4 U >> 5 1500 epair0a >> fe80::3d:9dff:fe7c:d70a%epair0a link#4 UHS >> 1 16384 lo0 >> fe80::%epair1a/64 link#6 U >> 6 1500 epair1a >> fe80::37:9eff:fe03:250a%epair1a link#6 UHS >> 1 16384 lo0 >> ff02::/16 ::1 UGRS >> 4 16384 lo0 >>=20 >> The parsing code seems to think that the netif for the = 198.51.100.0/24 >> route is 1500 rather than epair0a. >> This may be related to the difference in netstat output, because on = my >> VM it looks like this: >>=20 >> Routing tables >>=20 >> Internet: >> Destination Gateway Flags Use Mtu Netif >> Expire >> default 172.16.2.1 UGS 319 1500 vtnet0 >> 127.0.0.1 link#2 UH 0 16384 lo0 >> 172.16.2.0/24 link#1 U 14 1500 vtnet0 >> 172.16.2.2 link#1 UHS 0 16384 lo0 >>=20 >> Internet6: >> Destination Gateway Flags >> Use Mtu Netif Expire >> ::/96 ::1 UGRS >> 0 16384 lo0 >> ::1 link#2 UH >> 0 16384 lo0 >> ::ffff:0.0.0.0/96 ::1 UGRS >> 0 16384 lo0 >> fe80::/10 ::1 UGRS >> 0 16384 lo0 >> fe80::%vtnet0/64 link#1 U >> 0 1500 vtnet0 >> fe80::5a9c:fcff:fe02:a95e%vtnet0 link#1 UHS >> 0 16384 lo0 >> fe80::%lo0/64 link#2 U >> 0 16384 lo0 >> fe80::1%lo0 link#2 UHS >> 0 16384 lo0 >> ff02::/16 ::1 UGRS >> 0 16384 lo0 >>=20 >> I suspect that this change was introduced in r359823 (Introduce = nexthop >> objects and new routing KPI). >>=20 >> Best regards, >> Kristof >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"