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