FreeBSD CI Weekly Report 2019-06-09

[Kristof Provost]

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 
fails.

My current guess is that it’s related to bpf. It’s interesting to 
note that it fails on i386, but succeeds on amd64.

-- 
Kristof