FreeBSD CI Weekly Report 2019-06-09
kp at FreeBSD.org
Sat Jun 15 09:36:02 UTC 2019
On 12 Jun 2019, at 16:49, Li-Wen Hsu wrote:
> * https://ci.freebsd.org/job/FreeBSD-head-i386-test/
> * Same as amd64:
> * sys.netinet.socket_afinet.socket_afinet_bind_zero
> * Others:
> * sys.netpfil.pf.forward.v6
> * sys.netpfil.pf.forward.v4
> * sys.netpfil.pf.set_tos.v4
I’ve finally gotten around to taking a look at this, and it appears to
not be a pf problem. forward:v4 already fails at its sanity check,
before it configures pf.
It creates a vnet jail, telling it to route traffic through, and then we
run a sanity check with pft_ping.py.
Scapy tries to resolve the MAC address of the gateway (jail, 192.0.2.1).
The jail replies, but scapy never picks up the reply, so the traffic
looks like this:
13:19:29.953468 02:be:b4:57:9f:0a > ff:ff:ff:ff:ff:ff, ethertype ARP
(0x0806), length 42: Request who-has 192.0.2.2 tell 192.0.2.1, length 28
13:19:29.953572 02:be:b4:57:9f:0b > 00:a0:98:b2:48:59, ethertype ARP
(0x0806), length 42: Reply 192.0.2.2 is-at 02:be:b4:57:9f:0b, length 28
13:19:32.082843 02:be:b4:57:9f:0a > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 52: 192.0.2.1 > 198.51.100.3: ICMP echo request, id 0,
seq 0, length 18
The jail doesn’t forward the broadcast ICMP echo request and the test
My current guess is that it’s related to bpf. It’s interesting to
note that it fails on i386, but succeeds on amd64.
More information about the freebsd-testing