0

CRC for Reliable Data Packets over SLAP failing

asked 2015-05-14 01:47:19 -0800

TheHindenburg gravatar image

updated 2015-05-19 21:19:37 -0800

I've been working to get an Alljoyn TC and a Router talking over SLAP recently and I got to the point where the first exchanges of reliable data packets happen for the SASL authentication.

So the exchange goes like this:

  1. The Thin Client sends to packets, the first being a null byte and the second a string "AUTH ANONYMOUS\n"
  2. The Router reads these and replies with the string "OK (GUID)"

Now, both these things happen as they should but when the Thin Client gets the "OK (GUID)" packet it keeps showing that the CRC check for the packet failed. So, I tried and printed the CRC check info for all the previous packets, the SLAP control packets, and as it turns out those worked without a hitch.

After a while I tried turning the CRC checks off if the Packet was a Data Packet and as it happens the two apps I ran were able to establish a session and exchange messages without any problems.

So my question is this, are the CRC checks used in Serial Communication(SLAP) supposed to be employed for SLAP control packets only or data packets as well and are there any working samples for serial communication over Alljoyn that are made available?

The setup I used was an Alljoyn 15.04 Router with SLAP enabled and the thin client code from the btle-transport branch with some serial port programming done by me.

EDIT: I think I've figured out what the problem is, though I have little idea how to fix it so...help!

So as I was trying to find where I was getting a CRC check failure it turns I started printing out every value I got during the CRC check in aj_serial_rx.c CompletePacket(). I also printed the entire Byte Array I was receiving over the UART interface.

On the Router end I printed the entire Byte Array when the CRC bytes are computed in SLAPPacket::PrependHeader().

What I found was that every time there was a byte with the value 13 (which corresponds to '\r' in ASCII) in the Byte Array on the Router end(I printed the Byte Array in SLAPPacket::PrependHeader()), that same byte always showed up with the value 10 (which corresponds to '\n' in ASCII) on the Thin Client side.

And as such when CRC16_Compute(...) is called on the TC side it gives a very different value for crc then on the Router side.

Any ideas where or why this might be happening? I am running this on a Ubuntu 12.04 PC.

EDIT 2: I printed the Byte Array in UARTStreamLinux::PushBytes(...) as well and the '\r' characters had in no way been changed. This is weird because now I'm printing the data immediately before I write it to a serial port and print it again immediately after receiving it on the other end and the two are not the same.

Maybe it's a Linux problem, from what I've read ... (more)

edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted
1

answered 2015-05-19 23:27:11 -0800

TheHindenburg gravatar image

updated 2015-05-19 23:56:18 -0800

It seems the problem was with the Serial Port Programming that was done by me. Making changes to that fixed the '\r' to '\n' conversion issues. No issues with the Alljoyn code.

Also, if anyone's thinking of doing any Serial Port Programming for AJTCL on linux take you cue from ajscl/common/os/posix/UARTStreamLinux.cc

edit flag offensive delete publish link more
1

answered 2015-05-14 14:27:07 -0800

cpezzee gravatar image

The CRC is computed on all received packets, then they are dealt with (control packets modifying state and data packets being queued). The code for this is in src\aj_serial_rx.c, CompletePacket().

edit flag offensive delete publish link more

Comments

I don't know how far behind the btle-transport branch is

ry.jones ( 2015-05-14 16:50:51 -0800 )edit

So, are there any samples where I can see this working for myself and maybe compare it to my setup?

TheHindenburg ( 2015-05-14 21:08:10 -0800 )edit
Login/Signup to Answer

Question Tools

Follow
1 follower

Stats

Asked: 2015-05-14 01:47:19 -0800

Seen: 57 times

Last updated: May 19 '15