RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 996995 - adcli does not fall back to IPv4 when IPv6 is not responding
Summary: adcli does not fall back to IPv4 when IPv6 is not responding
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: realmd
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Stef Walter
QA Contact: Patrik Kis
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-14 12:49 UTC by Patrik Kis
Modified: 2014-06-13 10:29 UTC (History)
2 users (show)

Fixed In Version: realmd-0.14.5-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 10:29:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
packets captured by wireshark (6.67 KB, application/octet-stream)
2013-08-14 12:49 UTC, Patrik Kis
no flags Details


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 68110 0 None None None Never
FreeDesktop.org 68111 0 None None None Never

Description Patrik Kis 2013-08-14 12:49:27 UTC
Created attachment 786528 [details]
packets captured by wireshark

Description of problem:
When an AD has booth IPv4 and IPv6 addresses configured but IPv6 is not reachable on the network adcli join does not work. It tries to connect to ldap on IPv6 address but does not fall back to IPv4 (refer to the attached network capture).
It should work as for example realmd discover does, i.e. it tries all addresses received from DNS and uses the one that responds (in this case IPv4).

Version-Release number of selected component (if applicable):
adcli-0.7.2-1.el7

How reproducible:
alwaya

Steps to Reproduce:
1. Install a Microsoft AD with booth IPv4 and IPv6
2. Block the IPv6 traffic in the way between the AD and the client
3. Try to join via adcli

Comment 1 Stef Walter 2013-08-14 12:51:19 UTC
Interesting. Could you attach --verbose output of the command? As well as the exact adcli command you ran as well?

Comment 6 Stef Walter 2013-08-14 14:30:36 UTC
Looks like this should be fixed both by:

 1) adcli discovery should try all the addresses
 2) realmd should pass the address it discovers to adcli explicitly

Comment 8 Stef Walter 2013-08-14 15:06:20 UTC
realmd patch upstream: https://bugs.freedesktop.org/show_bug.cgi?id=68111

Comment 10 Stef Walter 2013-08-14 15:10:13 UTC
Since we're now passing the server address between processes on the command line in a --domain-controller agrument, this means that IPv6 testing is relevant here.

Comment 11 Stef Walter 2013-08-15 15:15:55 UTC
I've chosen to fix this in realmd by passing the server address to adcli explicitly when calling through. There is also an upstream bug for the adcli discovery fix. However fixing adcli will be more invasive, and therefore for RHEL 7.0, I think the realmd fix is appropriate.

Comment 12 Patrik Kis 2013-08-16 13:55:20 UTC
(In reply to Stef Walter from comment #11)
> I've chosen to fix this in realmd by passing the server address to adcli
> explicitly when calling through.

Which address is passed to adcli when there are more addresses available (typically IPv4 and IPv6)? All is tried until succeeded?

Comment 13 Stef Walter 2013-08-16 13:58:07 UTC
(In reply to Patrik Kis from comment #12)
> Which address is passed to adcli when there are more addresses available
> (typically IPv4 and IPv6)? All is tried until succeeded?

During discovery we might contact mutliple servers, the first to reply with the necessary data and meet join criteria is chosen as the preferred server. This preferred server is passed to adcli.

Comment 15 Ludek Smid 2014-06-13 10:29:22 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


Note You need to log in before you can comment on or make changes to this bug.