Opened 7 years ago

Last modified 3 years ago

#2841 new defect

deal with inet_pton that doesn't recognize AF_INET6

Reported by: jinmei Owned by: UnAssigned
Priority: medium Milestone: Outstanding Tasks
Component: build system Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: Medium
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 3 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description (last modified by tomek)

I've received a feedback from a user who tried to build and used BIND 10.
The OS is CentOS6 (reportedly), disables IPv6 in the kernel, and
apparently its inet_pton doesn't recognize AF_INET6 (not sure it's
related to the kernel support of IPv6; API-wise it should be
independent).

This caused at least two known issues:

  • some test data (generated by src/lib/util/python/gen_wiredata.py) can't be generated because the genetator script fails to create AAAA rdata.
  • b10-resolver (and I suspect b10-auth also) failed to start up because its default config has ::1/53 for listen_on, which is considered a syntax error.

I'm not sure whether we want to help such environment; it seems to me
inet_pton that doesn't recognize AF_INET6 is so broken and wouldn't
be worth introducing another layer of complexity in our code. But if
such a deployment is actually not so uncommon, we may have to do
something in our side.

Based on discussions at the Mar12 2013 team call, specific suggestion
is:

  • Do #2842 (this will "hide" the first problem for most ordinary users)
  • Document the second issue with workaround somewhere

Regarding the second (the main task of this ticket), my suggestion is
to update the description of SRVCOMM_EXCEPTION_ALLOC log message which
currently reads:

The process tried to allocate a socket using the socket creator, but an error
occurred. But it is not one of the errors we are sure are "safe". In this case
it is unclear if the unsuccessful communication left the process and the bind10
process in inconsistent state, so the process is going to abort to prevent
further problems in that area.

This is probably a bug in the code, but it could be caused by other unusual
conditions (like insufficient memory, deleted socket file used for
communication).

so it will mention the issue. As a workaround we should be able to
avoid it by editting the installed resolver/auth.spec excluding IPv6
addresses from listen_on. We document it there, too. And provide
some text in ChangeLog?.

Subtickets

Change History (9)

comment:1 Changed 7 years ago by jinmei

  • Description modified (diff)

comment:2 Changed 7 years ago by jwright

  • Defect Severity changed from N/A to Medium
  • Milestone changed from New Tasks to Next-Sprint-Proposed

comment:3 Changed 7 years ago by jreed

Also see #2628 (duplicate?)

comment:4 Changed 7 years ago by jinmei

  • Description modified (diff)

comment:5 Changed 7 years ago by jinmei

  • Description modified (diff)

comment:6 Changed 5 years ago by tomek

  • Milestone set to Remaining BIND10 tickets

comment:7 Changed 4 years ago by tomek

  • Milestone changed from Remaining BIND10 tickets to DHCP Outstanding Tasks

As part of bug scrubbing during Kea 1.0, we decided to move a number of tickets to DHCP Outstanding.

comment:8 Changed 4 years ago by tomek

  • Milestone changed from DHCP Outstanding Tasks to Outstanding Tasks

Milestone renamed

comment:9 Changed 3 years ago by tomek

  • Description modified (diff)

Hi, it's 2016. We should actually check the opposite - if Kea can build and run on IPv6-only system :)

Note: See TracTickets for help on using tickets.