Token problem???

Harald Barth haba at stacken.kth.se
Thu Aug 10 00:27:22 CEST 2000



I think the rx communication was some kind of disturbed when you traced
the first time. Still, I think the error occurs in rxkad_cksum_header
around line 219 which is about the only place where I can find that
this error could be created.

219       if (rx_GetPacketCksum(pkt)
220           != rxkad_cksum_header(pkt, k->keysched, e->header_iv))
221         return RXKADSEALEDINCON;


Step into rx_cksum_header and execute 

108       h.call_number = htonl(packet->header.callNumber);

After that you should get

(gdb) p h.call_number 
$3 = 16777216
(gdb) p packet->header.callNumber
$4 = 1

on the i386. If not, htonl() is broken.

Then look at the return values of rx_cksum_header() compared
to rx_GetPacketCksum(pkt) which is a macro for (packet)->header.spare

(gdb) fin 
Run till exit from #0  rxkad_cksum_header (packet=0x80c23f0, sched=0x8380bf0, 
    iv=0x8380d00) at ../../arla/rxkad/rxk_locl.c:108
0x8094c18 in rxkad_check_packet (pkt=0x80c23f0, con=0x8380c88, level=1, 
    k=0x8380bf0, e=0x8380d00) at ../../arla/rxkad/rxk_locl.c:219
219       if (rx_GetPacketCksum(pkt)
Value returned is $8 = 31364

(gdb) p (packet)->header.spare
$9 = 31364

Harald.





More information about the Arla-drinkers mailing list