Identifying the Preferred Ipv6 Source Address for an Adapter

Identifying the preferred IPv6 source address for an adapter

I'm not sure this is in the direction you're seeking, but...

Poking around in the iproute bundle's ip code (ip/ipaddress.c) under linux shows that the ip command digs up interface flags like primary and secondary from a struct ifaddrmsg, member ifa_flags. The ifaddmsg seems to be acquired through a struct nlmsghdr which is documented in man 7 netlink, and used via sendmsg and recvmsg interaction with the kernel, which overall sounds like a royal pain but it's at least programmatic. Whether primary and secondary would be enough to be useful is a separate question.

bind() works for ipv6 wireless adapter interface but not for ipv6 ethernet (error 10049)

Attempt3

Bind() will fail to enter the ip address into the internal table if ipRow.DadState is not set to IpDadStatePreferred after the call to InitializeUnicastIpAddressEntry and before the call to CreateUnicastIpAddressEntry:

ipRow.DadState = IpDadStatePreferred; // RT:191204: beginning with windows 10, this results in 'preferred' instead of 'tentative'

This results in a binding to a preferred socket upon which Listen() can be successfully called.

Here are the incorrect doc snippets in CreateUnicastIpAddressEntry:

If the value of the DadState member returns with some value other than
IpDadStatePreferred or IpDadStateTentative, duplicate address
detection has failed and the IP address is not usable.

If the returned DadState is IpDadStateTentative, the address is not useable either.

Also, there is this:

The DadState, ScopeId, and CreationTimeStamp members of the
MIB_UNICASTIPADDRESS_ROW structure that the Row parameter points to
are ignored when the CreateUnicastIpAddressEntry function is called.

DadState is not ignored, and as stated before will result in a non-preferred, non-useable address if not set to preferred.

Binding an ipv6 slaac address to windows IP Stack error 10049

In the process of resolving the Unable to GetUnicastIpAddressEntry after CreateUnicastIpAddressEntry posting, it was verified that bind() and listen() can indeed be made to work for RFC7217 IPv6 SLAAC generated addresses. See its Answer.

Obtaining MTD IPv6 address

The simplest way -I think- is to send a broadcast request message (using a multicast address e.g. ff03::2), on which every device has to reply.

As soon as you get the response message from a device, you should be able to get the IPv6 address of the sender as well. The sender address info is located in the otMessageInfo.

See example on cli_udp_example.cpp on git.

void UdpExample::HandleUdpReceive(otMessage *aMessage, const otMessageInfo *aMessageInfo)

---

Related Topics