G'day,
Using BusyBox for few years, I've noticed that BusyBox is nowhere near
IPv6 ready out of the box.
To give you guys some context, here's what I've found so far.
ifupdown applet only implements these methods(ifupdown.c:535):
static const struct method_t methods6[] ALIGN_PTR = {
# if ENABLE_FEATURE_IFUPDOWN_IP
{ "v4tunnel" , v4tunnel_up , v4tunnel_down , },
# endif
{ "static" , static_up6 , static_down6 , },
{ "manual" , manual_up_down6 , manual_up_down6 , },
{ "loopback" , loopback_up6 , loopback_down6 , },
};
Currently, there's not much can be done for IPv6 using
/etc/network/interfaces.
At first, I tried to use udhcpc6 since udhcpc is the default
implementation BusyBox uses. I've found that there's been some progress,
but I doubt there's anyone actually using this. The default script
shipped with Buildroot has a bug where it deletes IPv4 default routes
when executed for IPv6 leases. The following shell function seems to
have been written for interop with an external NDP implementation that's
only responsible for setting IPv6 default routes.
wait_for_ipv6_default_route() {
printf "Waiting for IPv6 default route to appear"
while [ $IF_WAIT_DELAY -gt 0 ]; do
if [ -z "$(ip -6 route list | grep default)" ]; then
printf "\n"
return
fi
sleep 1
printf "."
: $((IF_WAIT_DELAY -= 1))
done
printf " timeout!\n"
}
This function does not make sense at all when only udhcpc6 is used - the
script will always wait because there's no one from BusyBox family that
sets default IPv6 routes! If anything, RA is not handled by BusyBox at
all. I think involving more than one implementation to configure IPv6 is
a bad idea anyways. I wonder what the other program was(that the
functions awaits).
And there's this rant of a frustrated dev:
https://git.busybox.net/busybox/tree/docs/ifupdown_design.txt
So, my questions being: how do people usually enable IPv6 on their
embedded systems? Do they just go on using packages like dhclient and
odhcp6c? Is there a motion to make BusyBox's own DHCPv6 and RA
implementation? It seems like handling network stack is too much for
BusyBox.
References(some of these are ancient):
http://lists.busybox.net/pipermail/buildroot/2019-May/553084.html
http://lists.busybox.net/pipermail/buildroot/2021-February/302702.html
https://udhcp.busybox.net/README.udhcpc
https://udhcp.busybox.net/
https://github.com/openwrt/odhcp6c
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
