Revision history [back]

click to hide/show revision 1
initial version

CRC for Reliable Data Packets over SLAP failing

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.

CRC for Reliable Data Packets over SLAP failing

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 Linux 12.04 PC.

CRC for Reliable Data Packets over SLAP failing

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 Linux 12.04 PC. 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 '\r' is used in old Mac Systems and '\r\n' is used in Windows, and my '\r\n' seem to be getting turned into '\n\n'.

CRC for Reliable Data Packets over SLAP failing

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 Linux 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 '\r' is used in old Mac Systems and '\r\n' is used in Windows, and my '\r\n' seem to be getting turned into '\n\n'.

Maybe it has something to do with how I've done the Serial Port Programming on the TC side. I'll look into it.

CRC for Reliable Data Packets over SLAP failing

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 Linux 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 '\r' is used in old Mac Systems and '\r\n' is used in Windows, and my '\r\n' seem to be getting turned into '\n\n'.

Maybe it has something to do with how I've done the Serial Port Programming on the TC side. I'll look into it.