Bug 1817869
| Summary: | realmd operations hang with inaccessible IPv6 | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Martin Pitt <mpitt> | |
| Component: | realmd | Assignee: | Sumit Bose <sbose> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 34 | CC: | jhrozek, sbose, stefw | |
| Target Milestone: | --- | Keywords: | Triaged | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | realmd-0.17.0-8.fc36 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 2037864 (view as bug list) | Environment: | ||
| Last Closed: | 2021-12-15 07:29:52 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 2037864 | |||
|
Description
Martin Pitt
2020-03-27 07:20:56 UTC
Confirmed on Fedora 32 with realmd-0.16.3-22.fc32.x86_64 I tested this against FreeIPA, and the bug does not happen with that. Hi, thanks for the detailed report. About your test with FreeIPA, were there multiple different lines * Performing LDAP DSE lookup on: [IPv6] * Performing LDAP DSE lookup on: [Ipv4] e.g. with IPv6 and IPv4 addresses as well or was there only a single line? Is the AD DC reachable via IPv6 in your environment or only with IPv4? bye, Sumit (In reply to Sumit Bose from comment #3) > About your test with FreeIPA, were there multiple different lines > > * Performing LDAP DSE lookup on: [IPv6] > * Performing LDAP DSE lookup on: [Ipv4] > > e.g. with IPv6 and IPv4 addresses as well or was there only a single line? My test VM only has IPv4 configured, so there is only a single line: # realm -v discover * Resolving: _ldap._tcp.cockpit.lan * Performing LDAP DSE lookup on: 10.111.112.100 * Successfully discovered: cockpit.lan cockpit.lan type: kerberos realm-name: COCKPIT.LAN domain-name: cockpit.lan configured: no server-software: ipa client-software: sssd required-package: freeipa-client required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd However, this is quite different network-wise: The FreeIPA server lives in a VM right next to my test VM (a single hop through the libvirt bridge), while Stephen's AD server goes through the Red Hat VPN to his machine. That could very well be related. > Is the AD DC reachable via IPv6 in your environment or only with IPv4? Only IPv4 is configured, IPv6 just has the fe80:: link-local addresses. Indeed the discovery shows me an IPv6 address as well ("Performing LDAP DSE lookup on: 26XX.."), and ping6'ing that address hangs. Could that be the reason for discover sometimes hanging even at the first attempt, when it's waiting for a reply from IPv6, even when it already got one on IPv4? I had a default route: default via fe80::2 dev eth0 proto ra metric 1024 expires 1413sec hoplimit 64 pref medium which NM apparently sets up. When I drop this with "ip -6 route del default", then the hang is gone \o/, and I can run "discover" multiple times. It now says * Performing LDAP DSE lookup on: 26xx:[..addresss] ! Can't contact LDAP server So maybe this is a NetworkManager bug after all (setting a default route for an IPv6LL address), but I suppose it shouldn't cause realmd to completely lock up? Thanks, great hint about IPv6! (In reply to Martin Pitt from comment #4) ... > > So maybe this is a NetworkManager bug after all (setting a default route for > an IPv6LL address), but I suppose it shouldn't cause realmd to completely > lock up? > Hi, yes, I think I now have all details to reproduce it and I'll try to fix realmd. Thanks. bye, Sumit This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34. Hi, to reproduce this issue IPv6 is not needed, it is sufficient to drop all packet to one of the addresses returned by DNS even an IPv4 address. bye, Sumit FEDORA-2021-c32332b9a4 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c32332b9a4 FEDORA-2021-c32332b9a4 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. |