FreeBSD CI Weekly Report 2019-06-09

Kristof Provost kp at
Sat Jun 15 09:36:02 UTC 2019

On 12 Jun 2019, at 16:49, Li-Wen Hsu wrote:
> *
>     * Same as amd64:
>         * sys.netinet.socket_afinet.socket_afinet_bind_zero
>     * Others:
>         *
>         *
>         *

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
Scapy tries to resolve the MAC address of the gateway (jail, 
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 tell, length 28
	13:19:29.953572 02:be:b4:57:9f:0b > 00:a0:98:b2:48:59, ethertype ARP 
(0x0806), length 42: Reply 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: > 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 mailing list