MacOS 10.12 Bridge sends bad chksum

[Meno Abels]

Hello,

i have a special configuration and the shinny new macos 10.12. So It could be that macos is the cause of this error too.

I'm running 5.1.6 on 10.12 macos and installed a own bridge on macos with:

ifconfig bridge0 create
ifconfig bridge0 10.24.1.1/24 up
ifconfig bridge0 inet6 fd00::10:24:1:1/64 up

than I bind my guest to these bridge0 and on ipv4 all is good but on ipv6 ping's are working but any tcp or udp doesn't. The root cause is that the guest host receives packet with a wrong checksum:

1	0.000000	fd00::10:24:1:1	fd00::10:24:1:201	TCP	98	53596→22 [SYN, ECN, CWR] Seq=0 Win=65535 [TCP CHECKSUM INCORRECT] Len=0 MSS=1440 WS=32 TSval=497945749 TSecr=0 SACK_PERM=1

If add another guest to that bridge and try so access my dest from these new ("linux") guest everything is ok. Like:

1	0.000000	fd00::10:24:1:149	fd00::10:24:1:201	TCP	94	45678→22 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=301306 TSecr=0 WS=128

I was not able to check the chksum generation if i plugin a real device to the macos bridge.

And i did not have these ipv6 use case days before where i had run 10.11, so this problem might be new or old from virtualbox or macos ... I decided to report to you out of the fact that you are not manage the bridges on macos like on linux where you add a virtual device to the bridge. This is a kind of odd-:)

Cheers meno

P.S.

$ ifconfig bridge0
bridge0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	options=63<RXCSUM,TXCSUM,TSO4,TSO6>
	ether 7a:31:c1:9c:ed:00
	inet 10.24.1.1 netmask 0xffffff00 broadcast 10.24.1.255
	inet6 fe80::7831:c1ff:fe9c:ed00%bridge0 prefixlen 64 scopeid 0x8
	inet6 fd00::10:24:1:1 prefixlen 64
	Configuration:
		id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
		maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
		root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
		ipfilter disabled flags 0x2
	Address cache:
	nd6 options=201<PERFORMNUD,DAD>
	media: <unknown type>
	status: inactive

[Valery Ushakov]

Are the tcpdump captures both from the fd00::10:24:1:201 guest?

Can you try disabling TSO6 on the bridge and see if that helps?