[haiku-bugs] Re: [Haiku] #8316: Haiku needs IPv6 link scope Auto Configuration
- From: "Haiku" <trac@xxxxxxxxxxxx>
- To: undisclosed-recipients: ;
- Date: Thu, 24 Dec 2020 08:04:21 -0000
#8316: Haiku needs IPv6 link scope Auto Configuration
--------------------------------------+----------------------------
Reporter: kallisti5 | Owner: nobody
Type: enhancement | Status: assigned
Priority: normal | Milestone: Unscheduled
Component: Network & Internet/IPv6 | Version: R1/Development
Resolution: | Keywords: local scope
Blocked By: | Blocking:
Platform: All |
--------------------------------------+----------------------------
Comment (by jeremyvisser):
Replying to [comment:13 kallisti5]:
Yeah, there is a ::1 address assigned to loopback with a strange prefix
length:
inet6 addr: ::1, Prefix Length: 2147512363
While I didn't experience this with the loopback address, I did experience
this with link local addresses. I had been experimenting locally with
hrev45736 reverted to see how the system performed, and I did observe
strange prefix lengths on the IPv6 link local addresses.
Though there might be more than one instance of this bug, one bug I found
was in net_server's `NetServer::_ConfigureIPv6LinkLocal()`, where it
generates the link local addresses like this:
{{{
BNetworkAddress localLinkAddress(addressRaw, 0);
BNetworkAddress localLinkMask("ffff:ffff:ffff:ffff::"); // 64
BNetworkAddress localLinkBroadcast("fe80::ffff:ffff:ffff:ffff");
// ...
BNetworkInterfaceAddress interfaceAddress;
interfaceAddress.SetAddress(localLinkAddress);
interfaceAddress.SetMask(localLinkMask);
interfaceAddress.SetBroadcast(localLinkMask);
interface.AddAddress(interfaceAddress);
}}}
I was curious whether this was working as expected, so I dumped the hex
contents of the sockaddr of each of the address/mask/broadcast addresses,
and I found that they were not working as expected:
{{{
Address (hex): fe 80 00 00 00 00 00 00 a6 c3 f0 ff fe 67 94 90
Mask (hex): e0 02 73 41 cb 7f 00 00 00 0d 73 41 cb 7f 00 00 <--
random contents each time
Broadcast (hex): 66 65 64 32 3a 35 35 37 19 00 00 00 00 00 00 00 <--
random contents each time
}}}
The random contents suggested uninitialised memory. After further digging
I found that BNetworkAddress tries to resolve the string address by
calling BNetworkAddressResolver, which was in turn failing
(BNetworkAddress::SetTo was returning error, but the constructor ignores
the error).
I observed that BNetworkAddressResolver only failed on a fresh boot. After
a link local address (with invalid, random mask) was added, subsequent
calls to `BNetworkAddress localLinkMask("ffff:ffff:ffff:ffff::");` worked
as expected.
This suggested the resolver library was failing to resolve IPv6 addresses
if no IPv6 addresses are present. Given net_server's job is to add IPv6
addresses in the first place before any exist, this is quite the Catch-22.
I see the following options for solving the problem:
1. Pass the `B_UNCONFIGURED_ADDRESS_FAMILIES` flag to the BNetworkAddress
in NetServer::_ConfigureIPv6LinkLocal. It appears this tells the resolver
to resolve IPv6 addresses regardless of whether it thinks IPv6 is
available on the system (which on first boot, it is not yet).
1. Modify the _ConfigureIPv6LinkLocal function to create the localLinkMask
/ localLinkBroadcast by passing an `in6_addr` structure, not a `const char
*`, avoiding the BNetworkAddressResolver altogether. This means no string
parsing is needed at all, which is more robust.
1. Introduce a mode on the BNetworkAddressResolver or BNetworkAddress
which only uses `inet_pton()` rather than `getaddrinfo()`. While this is
less useful for a generic BNetworkAddress, it is suitable for low-level
network config, which net_server does qualify for.
1. There might be other options I haven't thought of yet.
I'm going to assume Option 1 is preferable (fewest changes required) and
prepare a patch for that, but of course there is a lot more work needed to
get IPv6 usable so I'd need additional feedback as to whether we think we
are ready to uncomment the call to _ConfigureIPv6LinkLocal.
--
Ticket URL: <
https://dev.haiku-os.org/ticket/8316#comment:19>
Haiku <
https://dev.haiku-os.org>
The Haiku operating system.
Other related posts:
