FreeBSD CI Weekly Report 2020-04-12
Muhammad Moinur Rahman
bofh at freebsd.org
Wed Apr 15 20:27:45 UTC 2020
Hi Alexandar,
I have changed net/scapy to apply a simple patch as a workaround for the time being. ports at 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 <melifaro at ipfw.ru> wrote:
>
>
>
> 15.04.2020, 15:10, "Kristof Provost" <kp at freebsd.org>:
>> 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.)
>>>>
>>>> FreeBSD CI Weekly Report 2020-04-12
>>>> ===================================
>>>>
>>>> Here is a summary of the FreeBSD Continuous Integration results for
>>>> the period
>>>> from 2020-04-06 to 2020-04-12.
>>>>
>>>> During this period, we have:
>>>>
>>>> * 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)
>>>>
>>>> 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)
>>>> |
>>>>
>>>> (The statistics from experimental jobs are omitted)
>>>>
>>>> If any of the issues found by CI are in your area of interest or
>>>> expertise
>>>> please investigate the PRs listed below.
>>>>
>>>> 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.
>>>>
>>>> ## News
>>>>
>>>> * The test env now loads the required module for firewall tests.
>>>>
>>>> * 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.
>>>>
>>>> ## Failing jobs
>>>>
>>>> * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/
>>>> * See console log for the error details.
>>>>
>>>> ## Failing tests
>>>>
>>>> * 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’t actually reproduce this failure in my test VM, but with the
>>> ci test VM I can reproduce the problem.
>>> It’s 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’s supposed to go.
>>>
>>> Scapy seems to fail to find the source IP address, so we get this:
>>>
>>> 12:12:22.152652 IP 0.0.0.0 > 198.51.100.3: ICMP echo request, id 0,
>>> seq 0, length 12
>>>
>>> I have a vague recollection that we’ve seem this problem before, but
>>> I can’t remember what we did about it.
>>>
>>> In all likelihood most of the other netpfil tests fail for exactly the
>>> same reason.
>>
>> 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!
>
> Sorry for breaking the tests.
> I should have run tests with userland changes installed.
>
> 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.
>
> So far light-weight sysctl-route reader looks like the best option.
> What do you folks think?
>
>>
>> For reference, this is the output in the test VM:
>>
>> Routing tables
>>
>> 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
>>
>> 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
>>
>> 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:
>>
>> Routing tables
>>
>> 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
>>
>> 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
>>
>> I suspect that this change was introduced in r359823 (Introduce nexthop
>> objects and new routing KPI).
>>
>> Best regards,
>> Kristof
>> _______________________________________________
>> freebsd-current at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-testing
mailing list