On Sat, Feb 17, 2007 at 05:27:14PM +0100, S. Cance wrote:
> 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.
>
> 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 just tried to run the 64-bit auth2 and see the same problem.

> 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?)

Yes, rpc2_Quit, which is called at the end of the function is defined as
return (long)rc;

> 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 !)

You are on the right path, I noticed in the auth2 logfile that the
user-id was -1, but it should be 1000. This is logged after a new
connection is bound.

It looks like cIdent.SeqLen is correct, but cIdent.SeqBody is offset by
4 bytes, there are 4 null-bytes added in front of the correct username.
However cIdent was correct when the user's password was checked earlier
on in the GetKeys callback function.

So there is something wrong with incoming connections on 64-bit. This
didn't affect the callback connection for the client because that is
bound anonymously.

I'm assuming something is going wrong in rpc2-src/rpc2a.c:MakeFake where
the first packet on an incoming connection is constructed. Don't see an
obvious place where it goes wrong, but I'm sure single-stepping through
the rpc2 functions will uncover the problem.

Jan