Hello,
I attach a debian bug report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755479):
[quote]
Dear Maintainer,
ipmitool 1.8.14 introduced IPv6 support throughout the suite (upstream
commits f6cabfb and 0b97d32). Despite ipmitool now supporting (and
preferring) IPv6 by default, most BMCs (most notably at least iDRAC 5
and 6) do not support lanplus sessions over IPv6, although they do
support HTTP(s) connections.
When attempting to use a lanplus session with a hostname that has both,
an A and a AAAA record, ipmitool will fail to establish a session
because it will only try the IPv6 address, on which the opposite end
will not respond. Normally ipmitool should detect this and fall back to
the IPv4 address, however the way ipmitool checks for IPv6 connectivity
is broken: it seems to rely on the return status of connect(2) on a
SOCK_DGRAM socket¹, however connect(2) on datagram sockets merely sets
the remote endpoint address and does not actually attempt to establish
any communications; any potential error (e.g. an ICMPv6 port
unreachable) will only appear at send(2) time.
To quickly reproduce the above behaviour, you can try establishing a
lanplus session on localhost:
ipmitool -U root -I lanplus -H localhost sol activate
while watching the loopback traffic with tcpdump.
Added to that, there is no (documented) way to force ipmitool to prefer
IPv4 without specifying the IPv4 address verbatim.
¹ see ipmi_intf_socket_connect() at src/plugins/ipmi_intf.c:341
Regards,
Apollon
[/quote]
Jörg Frings-Fürst
Maintainer of ipmitool on Debian
Hello,
attached is possible patch. I'd be great to test it since I have no means of testing it myself.
Best regards,
Z.
Last edit: Zdenek Styblik 2015-10-18
I'm sorry. The patch implements '-4' and '-6' which should enforce IPv4, resp. IPv6.
Z.
I've tested the patch at least via
-4 -H <IPv6 addr>and-6 -H <IPv4 addr>and it seems to be working.Z.
I've merged in the patch I've posted since there were no comments against it.
Z.