On Thu, Apr 03, 2008 at 03:46:06PM +0200, wrote:
> Hi!
Hi again!
> globus_libc_addr_to_contact_string (addr=0xbff69090, opts_mask=11,
> contact_string=0xbff6908c)
> at globus_libc.c:3552
> 3552 result = globus_error_put(
>
>
> Afterwards, the error string is constructed. The segfault occurs in
> strlen, the backtrace is already shown above.
>
> I wonder why I see family=2, which is AF_INET. The corresponding address
> is even worse:
>
> (gdb) p ((struct sockaddr_in*) addr).sin_addr
> $18 = {s_addr = 33}
I've digged a little more into the code. The trouble is caused by
globus_i_gfs_data.c, line 2551.
The comment in line 2539 says:
/* XXX This needs to be smarter.
And then in 2551:
if((globus_l_gfs_data_is_remote_node && !handle->use_interface)||
(ipv6_addr && !handle->info.ipv6))
The problem is handle->info.ipv6. Right now, I don't know where it is
set and why it is zero. I guess it represents the remote end's
capabilities.
When I override info.ipv6 in the debugger and force it to 1,
globusrun-ws fails:
Setting destination anne-vz102.inf-ra.uni-jena.de to striped passive
failed [Caused by: Server refused performing the request. Custom
message: (error code 1) [Nested exception message: Custom message:
Unexpected reply: 522 Network protocol not supported.]]
So that's maybe the problem: while "globus-url-copy -ipv6" sets
the right client attributes, "globusrun-ws -ipv6" does not. (or the WS
stack or whoever is initiating the GridFTP connection)
It seems that globusrun-ws is stuck to IPv4, and as I don't have any
IPv4 addresses on the machine (except 127.0.0.1), it fails.
Surely, the segfault should not happen, but that's another question.
What's wrong? Is (data_)info.ipv6 defined by the client's capabilities?
I feel there's some logic missing in the WS stack. Something like "if
the remote end is IPv6, use IPv6. If we don't have IPv4, don't even ask
for it" and so on.
Cheerio
--
mail: [EMAIL PROTECTED] http://adi.thur.de PGP/GPG: key via
keyserver
Was Vacuum ist? - Ich habs im Kopf, aber ich kriegs nicht raus...
