New: IPV6 forced on in busybox
https://bugs.busybox.net/show_bug.cgi?id=8736
Bug ID: 8736
Summary: IPV6 forced on in busybox
Product: buildroot
Version: 2015.11
Hardware: Other
OS: Linux
Status: NEW
Severity: trivial
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: ksmith at aesaustin.com
CC: buildroot at uclibc.org
Target Milestone: ---
Created attachment 6371
--> https://bugs.busybox.net/attachment.cgi?id=6371&action=edit
Patch to package makefile to remove forcing IPV6
It appears from the commit logs that the IPV6 config option was removed for buildroot, but the remnants of the removal are forcing FEATURE_IPV6 in busybox.
The attached patch would remove setting that feature in busybox.
Without this patch, the ntpd applet in busybox doesn't function properly, attempting to contact IPV6 hosts.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 8736] IPV6 forced on in busybox
https://bugs.busybox.net/show_bug.cgi?id=8736
Peter Korsgaard <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #1 from Peter Korsgaard <[email protected]> --- (In reply to Kenric Smith from comment #0)
That sounds like a bug in busybox that should be fixed instead of worked around then. What exactly goes wrong? Have you reported the bug to the busybox developers?
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 8736] IPV6 forced on in busybox
On 2016-03-03, bugzilla at busybox.net <[email protected]> wrote:
[Regarding restoring the ability to configure buildroot with IPv6 support disabled because some utilities don't work right with IPv6 enabled.]
Quoted 3 lines
That sounds like a bug in busybox that should be fixed instead of worked around then. What exactly goes wrong? Have you reported the bug to the busybox developers?
I agree that IPv6 support (if broken) needs to be fixed. But I think it's also important to restore the ability to disable IPv6 support. I have customers who explicity state that they want no IPv6 support in their products.
Signature · 3 lines
Grant Edwards grant.b.edwards Yow! Here I am in 53
at B.C. and all I want is a
gmail.com dill pickle!![Buildroot] [Bug 8736] IPV6 forced on in busybox
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Grant" == Grant Edwards <[email protected]> writes:
On 2016-03-03, bugzilla at busybox.net <[email protected]> wrote:
[Regarding restoring the ability to configure buildroot with IPv6 support disabled because some utilities don't work right with IPv6 enabled.]
Quoted 8 lines
Quoted 3 lines
That sounds like a bug in busybox that should be fixed instead of worked around then. What exactly goes wrong? Have you reported the bug to the busybox developers?
I agree that IPv6 support (if broken) needs to be fixed. But I think it's also important to restore the ability to disable IPv6 support. I have customers who explicity state that they want no IPv6 support in their products.
Yes, I think we should drop the forced ipv6 (and largefile) config modifications and just enable them in our default busybox config instead.
Signature · 1 line
Bye, Peter Korsgaard
[Buildroot] [Bug 8736] IPV6 forced on in busybox
In reply to Grant EdwardsQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Grant" == Grant Edwards <[email protected]> writes:
Hi,
Quoted 4 lines
I agree that IPv6 support (if broken) needs to be fixed. But I think it's also important to restore the ability to disable IPv6 support. I have customers who explicity state that they want no IPv6 support in their products.
I btw must say that I find such requirements quite sad in 2016 :/
Signature · 1 line
Bye, Peter Korsgaard
[Buildroot] [Bug 8736] IPV6 forced on in busybox
Quoted 10 lines · Peter Korsgaard
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Grant" == Grant Edwards <[email protected]> writes:
Hi,
Quoted 4 lines
I agree that IPv6 support (if broken) needs to be fixed. But I think it's also important to restore the ability to disable IPv6 support. I have customers who explicity state that they want no IPv6 support in their products.
I btw must say that I find such requirements quite sad in 2016 :/
Well, these are products which are often installed on small, air-gapped networks which are never connected to "The Interwebs" and have nothing but a handful of static, non-routable IPv4 addresses. The people who set up and maintain these systems often don't understand even IPv4 network addressing and just blindly follow recipes. IPv6 is new and scary and could make heads explode.
It's still sort of sad, because with a little forethought, switching to IPv6 could make setup and comissioning many of these setups _way_
simpler: everything could just run with auto-discovered link-local addresses. The phrase "plug and play" comes to mind, but historically that phrase is too closely associated with Microsoft to be used in polite company.
OTOH, there are other product lines where IPv6 is absolutely required because of feature checklists handed down from on-high. Still, nobody ever enables IPv6 or uses it. I actually had to add some code to the network stack to allow IPv6 to be completely disabled at boot time based on user-configuration [these products don't run Linux, so that's a moot point for this discussion]. :)
Signature · 3 lines
Grant Edwards grant.b.edwards Yow! Boys, you have ALL
at been selected to LEAVE th'
gmail.com PLANET in 15 minutes!![Buildroot] [Bug 8736] IPV6 forced on in busybox
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=8736
--- Comment #2 from Kenric Smith <[email protected]> ---
Sorry for the confusion. Busybox is acting as it should, the issue is that Buildroot is telling Busybox to enable IPV6 no matter what. For Buildroot systems where IPV6 is not enabled (in the kernel), Buildroot shouldn't enable IPV6 in Busybox.
Previously it appears that IPV6 was a Buildroot configuration option and that option was properly being passed into Busybox. When that option was removed, IPV6 was forced on in Busybox by the Buildroot configuration.
The patch attached just allows Busybox to be configured or not for IPV6, in the menuconfig option of Busybox, instead of forcing it to be enabled in Busybox.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 8736] IPV6 forced on in busybox
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=8736
--- Comment #3 from Peter Korsgaard <[email protected]> --- (In reply to Kenric Smith from comment #0)
Notice: I'm not against us removing the forced IPv6 (and just enable it in the default defconfig instead). We should probably also do it for largefile now that we always have that enabled, but I would like to understand what the problem is you are seeing.
I did a quick test with qemu_arm_versatile_defconfig and the busybox defconfig tweaked to enable the ntpd daemon, and everything seems to work OK here:
# date Thu Jan 1 00:00:50 UTC 1970 # ntpd -d -n -p pool.ntp.org ntpd: sending query to 77.243.43.213 ntpd: reply from 77.243.43.213: offset:+1457039097.162244 delay:0.036664 status:0x24 strat:2 refid:0xf00726c0 rootdelay:0.003418 reach:0x01 ntpd: sending query to 77.243.43.213 ntpd: reply from 77.243.43.213: offset:+1457039097.161038 delay:0.032410 status:0x24 strat:2 refid:0xf00726c0 rootdelay:0.003418 reach:0x03 ntpd: setting time to 2016-03-03 21:06:05.090957 (offset +1457039097.161038s) ntpd: sending query to 77.243.43.213 ntpd: reply from 77.243.43.213: offset:+0.001327 delay:0.033226 status:0x24 strat:2 refid:0xf00726c0 rootdelay:0.003418 reach:0x07
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 8736] IPV6 forced on in busybox
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=8736
--- Comment #4 from Kenric Smith <[email protected]> --- Try ntp.vt.edu.
When I try it, I get:
[root ~]# nslookup ntp.vt.edu
Server: ******** Address 1: ********
Name: ntp.vt.edu Address 1: 2001:468:c80:2101:0:14b:a768:154f ntp-1.ipv6.vt.edu Address 2: 198.82.247.108 ntp-3.vt.edu Address 3: 198.82.247.51 ntp-1.vt.edu Address 4: 198.82.247.131 ntp-4.vt.edu Address 5: 198.82.247.71 ntp-2.vt.edu
[root ~]# ntpd -w -p ntp.vt.edu
ntpd: socket: Address family not supported by protocol
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 8736] IPV6 forced on in busybox
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=8736
--- Comment #5 from Kenric Smith <[email protected]> --- I should have added, with the patch enabled, I get this behavior:
[root ~]# nslookup ntp.vt.edu
Server: ******* Address 1: *******
Name: ntp.vt.edu Address 1: (null) Address 2: 198.82.247.51 ntp-1.vt.edu Address 3: 198.82.247.131 ntp-4.vt.edu Address 4: 198.82.247.108 ntp-3.vt.edu Address 5: 198.82.247.71 ntp-2.vt.edu
[root ~]# ntpd -w -d -p ntp.vt.edu
ntpd: sending query to 198.82.247.131
ntpd: reply from 198.82.247.131: offset:+21623.503688 delay:0.048829 status:0x24 strat:2 refid:0xa4f752c6 rootdelay:0.000381 reach:0x01
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 8736] IPV6 forced on in busybox
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=8736
--- Comment #6 from Peter Korsgaard <[email protected]> --- (In reply to Kenric Smith from comment #4)
So I tried again, this time with IPv6 support disabled in the kernel but enabled in the toolchain (external codesourcery/glibc):
buildroot login: root
# ifconfig
eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1152 (1.1 KiB) TX bytes:684 (684.0 B)lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
# date Thu Jan 1 00:00:13 UTC 1970
# ntpd -w -p ntp.vt.edu ntpd: reply from 198.82.247.51: offset:+1457040206.437536 delay:0.123510 status:0x24 strat:2 refid:0xa4f752c6 rootdelay:0.000351 reach:0x01 ntpd: reply from 198.82.247.51: offset:+1457040206.437670 delay:0.109456 status:0x24 strat:2 refid:0xa4f752c6 rootdelay:0.000351 reach:0x03 ntpd: reply from 198.82.247.51: offset:+1457040206.438839 delay:0.109959 status:0x24 strat:2 refid:0xa4f752c6 rootdelay:0.000351 reach:0x07 ntpd: reply from 198.82.247.51: offset:+1457040206.437485 delay:0.107279 status:0x24 strat:2 refid:0xa4f752c6 rootdelay:0.000351 reach:0x0f random: nonblocking pool is initialized
So that works. If I instead try ntp-1.ipv6.vt.edu (which only has an AAAA record) it indeed fails:
# ntpd -w -p ntp-1.ipv6.vt.edu ntpd: socket: Address family not supported by protocol
Which makes sense as it cannot create an IPv6 socket:socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = -1 EAFNOSUPPORT (Address family not supported by protocol)
write(2, "ntpd: socket: Address family not"..., 55ntpd: socket: Address family not supported by protocol
) = 55
Looking at the ntpd code, it ends up calling xhost2sockaddr() on the peer name, which ends up doing a getnameinfo() with AF_UNSPEC, and using the first result without checking that it can create a socket - So if your C library prefers IPv6 over IPv4 this explains it.
The function does contain a workaround though: If you enable ENABLE_FEATURE_PREFER_IPV4_ADDRESS then it will use the first AF_INET result if available.
What C library do you use?
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 8736] IPV6 forced on in busybox
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=8736
--- Comment #7 from Kenric Smith <[email protected]> --- uClibc-ng and the default config file for it.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 8736] IPV6 forced on in busybox
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=8736
--- Comment #8 from Kenric Smith <[email protected]> --- Confirmed setting ENABLE_FEATURE_PREFER_IPV4_ADDRESS also corrects the behavior.
I personally still think forcing IPV6 in Busybox isn't great, but I also understand if you don't want to change the configuration.
Feel free to close the issue as resolved, if you want to change the forced IPV6 in Busybox is up to you. (it results in a 20% larger executable for me)
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 8736] IPV6 forced on in busybox
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=8736
--- Comment #9 from Kenric Smith <[email protected]> --- Disregard 20% comment. It was incorrect, it is only slightly larger.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.
[Buildroot] [Bug 8736] IPV6 forced on in busybox
In reply to bugzilla at busybox.nethttps://bugs.busybox.net/show_bug.cgi?id=8736
Peter Korsgaard <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED--- Comment #10 from Peter Korsgaard <[email protected]> --- Fixed in git by:
commit 7a5be2a042f3c1d55c5599ad819333a2150955ff
Author: Peter Korsgaard <[email protected]> Date: Fri Mar 4 16:47:38 2016 +0100
busybox: tweak IPv6/largefile handling
Fixes #8736
When IPv6 and largefile options were removed from Buildroot, the code to force these options in busybox were still left in.
There's no strong reason to forcefully enable these options (only to
disable
options if the system cannot support it like we do for nommu), so instead enable the options in our default defconfig, allowing people to override this if they use a custom config.
While we're at it, enable the prefer-ipv4 option so network applets like ntpd doesn't fail when dual stacked hosts are resolved from a system
without
IPv6 support enabled in the kernel.
Signature · 2 lines
You are receiving this mail because: You are on the CC list for the bug.