I've come across an issue that seems to be specific to macOS when binding an ndp connection to the LinkLocal address of an interface. Subsequent Writes using WriteTo will fail with a sendmsg: no route to host error. This problem does not occur when binding the connection to either the Global scoped address or Unspecified.

After some digging and reconstructing the process manually I managed to narrow the issue down to the WriteTo providing a default ControlMessage to the ipv6.PacketConn when nil is passed to the WriteTo method. Specifically it seems that explicitly setting the Src field of the ControlMessage is what causes this to fail. Passing nil or using a ControlMessage without the Src field set avoids the problem

None of this is reproducible on Linux where all versions worked as expected.

The original mac address of the sent data packet is the mac address of the network card. Can this mac address be changed to the mac address in the na packet?

Is there any reason *Conn has a SetReadDeadline method but not SetDeadline/SetWriteDeadline methods? The underlying *ipv6.PacketConn provides all three so this seems like it would easy, but I wasn't sure if there was a reason to omit them.

I'd be happy to open a PR creating SetDeadline and SetWriteDeadline methods if you agree that they should be added.

I am trying to use this tool to detect duplicate IPv6 address in the network but in case when the address is unique in the network the tool fails with the error below.

When setting the '-a' option as 'unspecified' I expected that source value in IPv6 packet would be '::' but it is not.

OS:
NAME="Rocky Linux"
VERSION="8.7 (Green Obsidian)"

NDP:
VERSION=v1.0.0

func Dial(ifi *net.Interface, addr Addr) (*Conn, net.IP, error) {...}

As far as I am aware, this module cannot be used on Windows because the ndp.Dial method returns errNotImplemented. This error originates from the following call to (*icmp.PacketConn).SetChecksum:

Now, I don't know that much about ndp, however, during my testing, at least sending router advertisements seemed to work just fine when the call to SetChecksum was removed. Disclaimer: I do not know why this call is necessary and what may break if it is removed. However, if it is indeed optional, I would propose the following solutions:

1. Separate ndp.Dial for Windows

Implement a seperate ndp.Dial function with Windows build tags where the lines above are removed.

2. Allowing users to setup the connection themselves

Almost everything in ndp.Dial can be done by the user itself. However, at the end ndp.newConn is used to construct a *ndp.Conn from an *icmp.PacketConn. As ndp.newConn is not exported and as all properties of ndp.Conn are also private, this currently cannot be done by the user. If ndp.newConn was exported, users could work around this issue themselves. This solution would also work fine alongside ndp.Dial as it grants the user more flexibility to work around future issues.

3. Skipping SetChecksum at runtime on Windows

Another less preferable solution would be to just skip the SetChecksum call on Windows at runtime as follows:

if runtime.GOOS != "windows" {
	// Calculate and place ICMPv6 checksum at correct offset in all
	// messages, is is not implemented by x/net/ipv6 on Windows.
	const chkOff = 2
	if err := pc.SetChecksum(true, chkOff); err != nil {
		return nil, nil, fmt.Errorf("set checksum: %w", err)
	}
}

If you decide on a preferred solution, I could also create a PR if you want.

Add to the README with one or more of

• illustrative examples, as in #7
• build instructions
• usage guidelines
• motivation (why you wrote this, why we should run this)

I've got some WIP code, just need to commit it.

As documented in https://tools.ietf.org/html/rfc4191#section-2.3.

Can you cut binary releases to allow for easier distribution?

Thanks

PR to follow.

Set up Drone Cloud CI, with one or more of the following, as first implemented in Travis CI .travis.yml.

• Set up Drone Cloud for a repo in the branch
• Build ndp
• Test ndp using static tests (golint, staticcheck)
• Test ndp using "go test"
• Test ipv6 status

@stapelberg and I had spoken at GopherCon and I believe he mentioned the need to specify an arbitrary net.PacketConn in this package.

The problem right now is that we effectively force an *ipv6.PacketConn because of multicast groups and control messages. Is this a problem for you, Michael?