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
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 :)
Also see #2628 (duplicate?)