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
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
