Jan Harkes wrote:
> That is strange, the 64-bit client is working fine here. Of course it
> may be that there is some subtle difference between Intel's em64t and
> amd64.
>
> In any case, there are some minor fixes involving truncated integers
> (64-bit values copied or compared to a 32-bit integer). You should be
> able to tell if your tree got this patch because the same patch also
> removed the unused SafeStrCpy and SafeStrCat function from
> coda-src/util/util.c, which probably weren't safe on a 64-bit
> system anyways so it was in a way good they were unused.
>   
I checked my sources, and it seems they are up-to-date.
Just to be sure, I build from those sources again, and I get exactly the 
same behaviour.

I naively tried to checkout where could be the problem :)
I'm no expert in architecture specifics but I my first guess would be 
that rpc2 is truncating somewhere while binding to the server.
in coda-src/auth2/auser.c TryBinding() always gets a 0 at the 
RPC2_Newbinding() call
I checked rpc2/rpc2-src/rpc2a.c for RPC2_Newbinding() but there is no 
return statement (maybe normal?)
I tried to study types and conversion, I didn't see anything wrong but 
there is a lot of code and depedencies.
(hopefully many functions are clearly named & described, thank you !)

> Now I have not tried the 64-bit server, and I'm sure it has similar
> problems. If you have to run a Coda server on a 64-bit machine, the best
> way is probably to compile with the -m32 flag, but I don't know if that
> would also imply that all libraries have to be rebuilt as well, which is
> probably not worth all the hassle.
>
> The client pretty much has to be 64-bit to be able to communicate with
> the 64-bit Coda kernel module. The server doesn't have the kernel
> dependency, so it actually should run fine as a 32-bit binary on a
> 64-bit kernel,
>   
I think it might be worth the try (just to know if it solves the 
problem), but I think it might be a long work.
> ipv6 is not used, but doesn't hurt either. My desktop/laptop and one of
> the Coda servers actually have both ipv4 and ipv6 connectivity. Some
> code already works fine on ipv6, for instance clog and auth2. However
> venus and codasrv are very much tied to being able to use a single ipv4
> address to identify each other. They explicitly bind to a v4 socket and
> only ask for ipv4 addresses.
>   
ok, thank you, I would have wasted time on that :)
> Not being able to test your client against testserver does make it
> difficult. Is there a reason why UDP is completely blocked? Are they as
> strict with tcp connections?
>   
UDP is simply droped in both ways because of the provider which is used 
& for QOS.
it's rather extreme but they don't really care, because in the past some 
students abused (p2p...).

Anyway, I guess I should try to find a 32bit computer to try the coda 
server, just to be sure I didn't messed up somewhere.

-- 
Stephane Cance