[Buildroot] [Bug 8736] New: IPV6 forced on in busybox

[Buildroot] [Bug 8736] New: IPV6 forced on in busybox

[bugzilla at busybox.net]

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 8736] IPV6 forced on in busybox

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=8736

Peter Korsgaard <jacmet@uclibc.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #1 from Peter Korsgaard <jacmet@uclibc.org> ---
(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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 8736] IPV6 forced on in busybox

[Grant Edwards]

On 2016-03-03, bugzilla at busybox.net <bugzilla@busybox.net> wrote:

[Regarding restoring the ability to configure buildroot with IPv6
support disabled because some utilities don't work right with IPv6
enabled.]

> 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.

-- 
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

[Peter Korsgaard]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

 > On 2016-03-03, bugzilla at busybox.net <bugzilla@busybox.net> wrote:
 > [Regarding restoring the ability to configure buildroot with IPv6
 > support disabled because some utilities don't work right with IPv6
 > enabled.]

 >> 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.

-- 
Bye, Peter Korsgaard

[Buildroot] [Bug 8736] IPV6 forced on in busybox

[Peter Korsgaard]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

Hi,

 > 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 :/

-- 
Bye, Peter Korsgaard

[Buildroot] [Bug 8736] IPV6 forced on in busybox

[Grant Edwards]

On 2016-03-03, Peter Korsgaard <peter@korsgaard.com> wrote:
>>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:
>
> Hi,
>
> > 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]. :)

-- 
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

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=8736

--- Comment #2 from Kenric Smith <ksmith@aesaustin.com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 8736] IPV6 forced on in busybox

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=8736

--- Comment #3 from Peter Korsgaard <jacmet@uclibc.org> ---
(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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 8736] IPV6 forced on in busybox

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=8736

--- Comment #4 from Kenric Smith <ksmith@aesaustin.com> ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 8736] IPV6 forced on in busybox

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=8736

--- Comment #5 from Kenric Smith <ksmith@aesaustin.com> ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 8736] IPV6 forced on in busybox

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=8736

--- Comment #6 from Peter Korsgaard <jacmet@uclibc.org> ---
(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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 8736] IPV6 forced on in busybox

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=8736

--- Comment #7 from Kenric Smith <ksmith@aesaustin.com> ---
uClibc-ng and the default config file for it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 8736] IPV6 forced on in busybox

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=8736

--- Comment #8 from Kenric Smith <ksmith@aesaustin.com> ---
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)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 8736] IPV6 forced on in busybox

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=8736

--- Comment #9 from Kenric Smith <ksmith@aesaustin.com> ---
Disregard 20% comment. It was incorrect, it is only slightly larger.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Buildroot] [Bug 8736] IPV6 forced on in busybox

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=8736

Peter Korsgaard <jacmet@uclibc.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Peter Korsgaard <jacmet@uclibc.org> ---
Fixed in git by:

commit 7a5be2a042f3c1d55c5599ad819333a2150955ff
Author: Peter Korsgaard <peter@korsgaard.com>
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.

    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.