Are we looking at the same thing?

===> from lib/krb4/cr_tkt.c:

    memcpy(data, session, 8);
    data += 8;
    *data++ = life;
    /* issue time */
    KRB4_PUT32BE(data, time_sec);

    memcpy(data, sname, snamelen);
    data += snamelen;
    memcpy(data, sinstance, sinstlen);
    data += sinstlen;

====> KRB4_PUT32BE is the relevent macro, from include/kerberosIV/prot.h:

   #define KRB4_PUT32BE(p, val)                    \
   do {                                            \
       (p)[0] = ((KRB_UINT32)(val) >> 24) & 0xff;  \
       (p)[1] = ((KRB_UINT32)(val) >> 16) & 0xff;  \
       (p)[2] = ((KRB_UINT32)(val) >> 8)  & 0xff;  \
       (p)[3] =  (KRB_UINT32)(val)        & 0xff;  \
       (p) += 4;                                   \
   } while (0)

This is equivalent to casting an 8byte or 4byte quantities (val) to a 4
byte quantity and memcpy'ing the 4 bytes.

If val is big endian, it writes the (casted) 4 bytes as would a
memcpy of 4 bytes, resulting in network byte order (big endian).

If val is little endian, this again, copies bytes as would a
mempcy, resulting in little endian.

With 1.3.1 krb524d running on linux - with code borrowed from libkrb4
as shown above, start time is:

1060266366 (decimal), or

7E61323F (hex, in host byte order, which on my linux box is little
endian).

Would be 3F32617E (hex, if converted to big endian)

These corresponds to: Thu Aug  7 10:26:06 EDT 2003

However, when 7E61323F is interpreted as big endian (212029907 in
decimal), by AFS server, it corresponds to Tue Mar 10 06:57:51 EDT
2037.

AFS error message:

afs: Tokens for user of AFS id 4843 for cell q.ny.ms.com are discarded (rxkad error=19270407)

(don't have code off hand to convert this error code to string).

In any case, this code did not run correctly on linux. When I applied
patch that was submitted, starttime is correctly issued. Without
patch, starttime was postdated and tokens discarded by AFS fileserver.


>>>>> "Tom" == Tom Yu via <RT" <rt-comment@krbdev.mit.edu>> writes:

>>>>> "Cesar" == Cesar Garcia via RT <rt-comment@krbdev.mit.edu> writes:
Cesar> Hmm, not totally. Would appear the code in libkrb4 assumes big
Cesar> endian. (as explained in original mail - code did not work on
Cesar> little endian platforms - e.g., RedHat AS 2.1 on intel, patch
Cesar> addresses this by determining big or little endian and handling
Cesar> accordingly).

Tom> Not exactly... in krb5-1.3, libkrb4 has been modified to
Tom> unconditionally emit big-endian encodings, regardless of the
Tom> endianness of the machine, but will accept either little-endian
Tom> or big-endian.

Tom> ---Tom