kern/57152: BPF / dhcpcd on mipsn64-be appears to malfunction

[he%NetBSD.org@localhost]

>Number:         57152
>Category:       kern
>Synopsis:       BPF / dhcpcd on mipsn64-be appears to malfunction
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jan 01 21:30:01 +0000 2023
>Originator:     he%NetBSD.org@localhost
>Release:        NetBSD 9.99.106
>Organization:
	I try...
>Environment:
System: NetBSD n64 9.99.106 NetBSD 9.99.106 (MIPSSIM64) #0: Sat Dec 31 12:39:58 CET 2022  he%mt.urc.uninett.no@localhost:/u/build/HEAD/obj/evbmipsn64-eb/sys/arch/evbmips/compile/MIPSSIM64 evbmips
Architecture: mipsn64eb
Machine: evbmips
>Description:
	Running a MIPSSIM64 kernel built with "-m evbmipsn64-eb"
	within qemu with "user" networking, like so:

MEM=2g
CPU=5Kf

qemu-system-mips64 \
        -M mipssim-virtio \
        -m $MEM  \
        -cpu $CPU \
        -kernel netbsd \
        -nographic \
        -device virtio-rng-device \
        -drive id=hda,format=raw,file=disk.img \
        -device virtio-blk-device,drive=hda \
        -netdev user,id=net0,hostfwd=tcp::2228-:22,ipv6=off \
        -device virtio-net-device,netdev=net0,mac=00:11:1e:01:02:08

	I am using qemu 7.0.0nb1 at the moment.

	and having dhcpcd=YES in /etc/rc.conf results in the machine
	not getting an IP address via dhcp, but instead it ends up
	with an "unusable" address on 169.254.0.0/16.

	Doing "tcpdump -x -n -e -i vioif0 -c 2" while dhcpcd is running
	results in

11:31:36.013042 ff:00:11:1e:01:02 > 00:ff:ff:ff:ff:ff, ethertype Unknown (0x0808), length 4294967295:
        0x0000:  0045 0001 482f 2000 0040 114a 8600 0000  .E..H/...@.J....
        0x0010:  00ff ffff ff00 4400 4301 3403 8001 0106  ......D.C.4.....
        0x0020:  00ec d229 c800 bd00 0000 0000 0000 0000  ...)............
	...

	On the wire, the destination address travels first, source
	address thereafter, and then the "type / length" field.

	So ... here it looks like the "snap" of the ethernet header
	has started one byte too early.  Note that the first "0x08" in
	the type field should be part of the source address, and the
	first byte in the source address should be part of the
	destination address instead, and "0x45" should be the first
	byte (IPv4, IHL=5), but it isn't.

>How-To-Repeat:
	Spin up a big-endian 64-bit MIPS kernel in qemu, and try to
	use dhcpcd, and watch it fail miserably.

>Fix:
	Sorry, don't know.