Bug 996995 - adcli does not fall back to IPv4 when IPv6 is not responding
adcli does not fall back to IPv4 when IPv6 is not responding
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: realmd (Show other bugs)
7.0
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Stef Walter
Patrik Kis
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-14 08:49 EDT by Patrik Kis
Modified: 2014-06-13 06:29 EDT (History)
2 users (show)

See Also:
Fixed In Version: realmd-0.14.5-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 06:29:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 68110 None None None Never
FreeDesktop.org 68111 None None None Never

  None (edit)
Description Patrik Kis 2013-08-14 08:49:27 EDT
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 08:51:19 EDT
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 10:30:36 EDT
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 11:06:20 EDT
realmd patch upstream: https://bugs.freedesktop.org/show_bug.cgi?id=68111
Comment 10 Stef Walter 2013-08-14 11:10:13 EDT
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 11:15:55 EDT
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 09:55:20 EDT
(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 09:58:07 EDT
(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 06:29:22 EDT
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.