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
