FreeBSD CI Weekly Report 2020-04-12
Kristof Provost
kp at FreeBSD.org
Wed Apr 15 14:09:57 UTC 2020
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.
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
More information about the freebsd-current
mailing list