Folks,
I'm working on a NAS device that uses FreeBSD 11.1 as the host OS. I'm running through the UNH "INTACT" IPv6 conformance test suite and I see a lot of failures. One common theme seems to be that FreeBSD fails to resolve the test node's MAC before responding. The result is that the Ethernet header contains junk, but beyond that the IPv6 and ICMP6 headers make sense. Please see the attached pcap.
The test node sends two packets. Frame 1 is a Router Advertisement. Note that it has no SLL option. So the FreeBSD side can't glean the test node's MAC from any of the packet contents.
In frame 7 the test sends an Echo Request. Note that the test environment configuration contains, among other things, the MAC address of the "device under test". So it doesn't bother to first send a Neighbor Solicitation to resolve FreeBSD's MAC.
Frames 8-11 originate from FreeBSD. The Ethernet headers appear to contain junk. But if the payload beyond that is decoded as IPv6 then it looks reasonable. Frame 8 is an Echo Reply; frames 9-11 are Neighbor Unreachability Detection kicking in. Except, the FreeBSD side cannot know the MAC address of the test node since it never attempted to solicit for it. It should send a NS back to the test node and look for a corresponding NA before any of this.
This test (and a number of other similar tests that start this way) previously passed (e.g. in 10.3).
Thanks!
I'm working on a NAS device that uses FreeBSD 11.1 as the host OS. I'm running through the UNH "INTACT" IPv6 conformance test suite and I see a lot of failures. One common theme seems to be that FreeBSD fails to resolve the test node's MAC before responding. The result is that the Ethernet header contains junk, but beyond that the IPv6 and ICMP6 headers make sense. Please see the attached pcap.
The test node sends two packets. Frame 1 is a Router Advertisement. Note that it has no SLL option. So the FreeBSD side can't glean the test node's MAC from any of the packet contents.
In frame 7 the test sends an Echo Request. Note that the test environment configuration contains, among other things, the MAC address of the "device under test". So it doesn't bother to first send a Neighbor Solicitation to resolve FreeBSD's MAC.
Frames 8-11 originate from FreeBSD. The Ethernet headers appear to contain junk. But if the payload beyond that is decoded as IPv6 then it looks reasonable. Frame 8 is an Echo Reply; frames 9-11 are Neighbor Unreachability Detection kicking in. Except, the FreeBSD side cannot know the MAC address of the test node since it never attempted to solicit for it. It should send a NS back to the test node and look for a corresponding NA before any of this.
This test (and a number of other similar tests that start this way) previously passed (e.g. in 10.3).
Thanks!