IPv6 flag does not have an affect with xrootd as protocol

[thdesy]

Hi,

it seems that with gfal-copy version [1] the IP version switch does not have an affect.

We are currently debugging a routing problem and have noticed, that even with explicitly requirering IPv4 the IPv6 route is used
E.g.,

> gfal-copy -f -4 -vv root://dcache-door-cms20.desy.de:1094/store/foo/baz  /tmp/hartmath.1 

resolving the A/AAAA records explicitly takes the expected protocol, i.e.,

> gfal-copy -f  -vv root://131.169.191.216:1094/store/foo/baz  /tmp/hartmath.1
> gfal-copy -f  -vv root://[2001:638:700:10bf::1:d8]::1094/store/foo/baz  /tmp/hartmath.1

the problem appears to be similar with the xrd-tools (v4.11.3), e.g.,
> xrdcp --debug 3 root://[2001:638:700:10bf::1:d8]:1094///store/foo/baz /tmp/hartmath.1
(where xrd-tools seem to have no IP version switch)

Cheers,
Thomas

[1]

gfal-copy --version
gfal2-util version 1.5.3 (gfal2 2.17.2)
dcap-2.17.2
file-2.17.2
gridftp-2.17.2
http-2.17.2
lfc-2.17.2
rfio-2.17.2
sftp-2.17.2
srm-2.17.2
xrootd-2.17.2
from /cvmfs/grid.cern.ch/centos7-umd4-ui-4_200423/usr/bin/gfal-copy

[thdesy]

addendum: I just noticed, that the behaviour is inconsistent between the transfer protocols and the using explicitly IPv4/IPv6 addresses. For WebDAV and gsiFTP apparently the handshake fails with the host cert DN, i.e., the FQDN, does not match the given address, i.e., the IP

> gfal-copy -f -vv davs://[2001:638:700:10bf::1:d8]:2880/pnfs/foo/baz  /tmp/hartmath.1
 INFO     Davix: Impossible to Recover with Metalink: (Neon): Server certificate verification failed: certificate issued for a different hostname
gfal-copy error: 112 (Host is down) - Could not stat the source: Result (Neon): Server certificate verification failed: certificate issued for a different hostname after 1 attempts


> gfal-copy -f  -vv root://[2001:638:700:10bf::1:d8]::1094/store/foo/baz  /tmp/hartmath.1
 INFO     Event triggered: BOTH xroot TRANSFER:ENTER root://[2001:638:700:10bf::1:d8]:1094///store/foo/baz?xrd.gsiusrpxy=/tmp/x509up_u26551 => file://localhost///tmp/hartmath.1?xrd.gsiusrpxy=/tmp/x509up_u26551
event: [1603460504727] BOTH   xroot	TRANSFER:TYPE	streamed
INFO     Event triggered: BOTH xroot TRANSFER:TYPE streamed

I guess, it is probably related to the xrootd security model?

[andrea-manzi]

Hi Thomas,
if i remember correctly this is a known issue and the flags work only with srm and gsiftp protocol, maybe @mpatrascoiu can have a look a the Jira for the related open issue.
As a workaround for Xrootd you can specify the XRD_NETWORKSTACK var,

XRD_NETWORKSTACK=ipv4 gfal-copy -f -vv root://dcache-door-cms20.desy.de:1094/store/foo/baz /tmp/hartmath.1

cheers
Andrea

[mpatrascoiu]

Hello Thomas,

The discussion on IPv4/6 is picking up within DOMA.

Right now, only the GridFTP plugin offers support for changing the IP stack.
I'm working on making Gfal2 offer better support for the XRootD and HTTP plugins as well.

Cheers,
Mihai

[mpatrascoiu]

Hello Thomas,

For Gfal2 XRootd plugin, I have opened this issue:
xrootd/xrootd#1472

Cheers,
Mihai