LwMeshTestamonial

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not to sound like too much of a homer, but in my opinion, LwMesh is great.

I designed a board around the ATMEGA128RFA1, using the data sheet as a reference. I downloaded LwMesh, made a few tweaks to IDs in the Peer2Peer project (i.e., APP_ADDR and appDataReq.dstAddr), and flashed it to my board. And it worked. The first time. There is something particularly satisfying in observing wireless transmission for the first time in a personal project.

The demo applications included in the LwMesh package make it easy to get up and running with the stack with my own application specific software.

I'm sure I'll be here, hat in hand, asking for help with a stack problem at some point in the not to distant future. However, at this point, everything seems to be working great.

To anyone else in the AVR world new to wireless applications and trying to get their feet wet, I recommend using the LwMesh stack.

Alexru: thanks a lot for steering me towards the ATMEGA128RFA1 when I was here asking about the TI CC2530 a few months ago...

Science is not consensus. Science is numbers.

Last Edited: Fri. Oct 16, 2015 - 02:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Speaking of questions... I have witnessed some unexpected behavior:

Situation: two nodes talking to each other directly (no mesh). Application very similar to Peer2Peer.

Test Case 1: Neither side has encryption enabled -- full expected functionality

Test Case 2: Both sides have encryption enabled -- full expected functionality

Test Case 3: One side has encryption enabled, the other does not -- The unencrypted can send any number of messages, which get received and processed properly by the other node (with encryption enabled). However, as soon as the node with encryption enabled transmits a message to the other [non-encrypted] node, the non-encrypted node stops working. The MCU doesn't die (i.e., the program is still running), but it can no longer transmit [unencrypted] messages. Why would receiving an encrypted message cause the radio to stop working?

Science is not consensus. Science is numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Technically you are not supposed to mix nodes with different configurations. But if this happens, then this is a bug, since no external frame should be able to kill the node. I just don't see how this might happen, this check should just stop processing of the frame:

 
static void nwkRxHandleReceivedFrame(NwkFrame_t *frame)
{
  NwkFrameHeader_t *header = &frame->data.header;

  frame->state = NWK_RX_STATE_FINISH;
...
#ifndef NWK_ENABLE_SECURITY
  if (header->nwkFcf.securityEnabled)
    return;
#endif
...

So nodes without security should just ignore frames with security bit set.

I'm currently working on the next release and I'll check this behavior.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alex,

Thanks for the response. I realize that encrypted/unencrypted should not be mixed. I am trying to test what would happen if my customers messed up the settings (which I would LIKE to make available to them).

After your post, I modified the code as follows:

static void nwkRxHandleReceivedFrame(NwkFrame_t *frame)
{
  NwkFrameHeader_t *header = &frame->data.header;

  frame->state = NWK_RX_STATE_FINISH;

  if ((0xffff == header->nwkDstAddr && header->nwkFcf.ackRequest) ||
      (nwkIb.addr == header->nwkSrcAddr))
    return;

fprintf(&comExt_str, "hi1\n");
#ifndef NWK_ENABLE_SECURITY
fprintf(&comExt_str, "hi2\n");
  if (header->nwkFcf.securityEnabled) {
fprintf(&comExt_str, "hi3\n");
    return;
	}
#endif

Where comExt_str is sent out to a PC. The attached picture is a screen shot of the two terminal programs monitoring the two boards. In the screen shot, "TXW" is just a keyword for my application to tell it the following data should be transmitted. The terminal on the left (in the picture) is monitoring the board without encryption. The terminal on the right is monitoring hte board with encryption. Note, the encrypted side chops the last four bytes (including a null my application tags on the end of the string) to take the [non-existent, in this case] MIC into account. The screen shot shows me transmit two unencrypted messages which get received. I then transmit an encrypted message. All three "hiN" messages print out, telling me the function you called out is operating as designed. However, the last transmission from the unencrypted board does not go through...

Thoughts?

Edit: also, for what it's worth, when I enabled encryption for the first time, I got a boatload of warnings regarding a function not being a prototype in phy.h -->

#ifdef PHY_ENABLE_AES_MODULE
void PHY_EncryptReq(uint8_t *text, uint8_t *key);
void PHY_EncryptConf();
#endif

When I changed it to:

#ifdef PHY_ENABLE_AES_MODULE
void PHY_EncryptReq(uint8_t *text, uint8_t *key);
void PHY_EncryptConf(void);
#endif

All the warnings went away. Note, the warnings appeared when I compiled with WinAVR-20100110 (AVR Studio 4.18). When I compile the project (without changing phy.h) in AVR Studio 6 (AVR Toolchain), there are no warnings.

Attachment(s): 

Science is not consensus. Science is numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since you have a nice debugging interface, can you also put debug messages on the receiving side before and after this place in the same function:

  if (nwkRxRejectDuplicate(header))
    return;

It is possible that message is received, but being rejected as a duplicate.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Noted about PHY_EncryptConf(). So newer compiler became dumber :). I always check for warnings with IAR and GCC, but only with "current" versions.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alex,

I sprinkled some more debug messages throughout the function.

static void nwkRxHandleReceivedFrame(NwkFrame_t *frame)
{
  NwkFrameHeader_t *header = &frame->data.header;

  frame->state = NWK_RX_STATE_FINISH;

fprintf(&comExt_str, "top of function\n");

  if ((0xffff == header->nwkDstAddr && header->nwkFcf.ackRequest) ||
      (nwkIb.addr == header->nwkSrcAddr))
    return;

fprintf(&comExt_str, "hi1\n");
#ifndef NWK_ENABLE_SECURITY
fprintf(&comExt_str, "hi2\n");
  if (header->nwkFcf.securityEnabled) {
fprintf(&comExt_str, "hi3\n");
    return;
	}
#endif

#ifdef NWK_ENABLE_ROUTING
  nwkRouteFrameReceived(frame);
#endif

fprintf(&comExt_str, "before rejectDuplicate.\n");
  if (nwkRxRejectDuplicate(header)) {
fprintf(&comExt_str, "duplicate header!\n");
    return;
	}

  if (0xffff == header->macDstAddr && nwkIb.addr != header->nwkDstAddr &&
      0xffff != header->macDstPanId && 0 == header->nwkFcf.linkLocal)
    nwkTxBroadcastFrame(frame);

fprintf(&comExt_str, "debug Msg middle\n");

  if (nwkIb.addr == header->nwkDstAddr || 0xffff == header->nwkDstAddr)
  {
fprintf(&comExt_str, "debug Msg inside If\n");
#ifdef NWK_ENABLE_SECURITY
    if (header->nwkFcf.securityEnabled) {
      frame->state = NWK_RX_STATE_DECRYPT;
fprintf(&comExt_str, "last debug msg\n");	 
	}
    else
#endif
      frame->state = NWK_RX_STATE_INDICATE;
  }
#ifdef NWK_ENABLE_ROUTING
  else if (nwkIb.addr == header->macDstAddr && 0xffff != header->macDstPanId)
  {
    frame->state = NWK_RX_STATE_ROUTE;
  }
#endif
}

See the attached image for the output. There are a few interesting things.

1. The unencrypted messages sent BEFORE the encrypted node sends a message fall through to the "else" at the end of the function. The unencrypted message sent AFTER the encrypted node sends a message stops at the "if" --> note the circled message on the terminal on the right.

2. Look at the received bufCount for a very short message from the unencrypted node. I sent 0x68 0x69 0x00 (hi), but the buf count is 255.

Edit: I think the problem is on the [unencrypted] transmitting side.

Scenario:
1. Send unencrypted msg (1 to 2) - received
2. Send unencrypted msg (1 to 2) - received
3. Send encrypted msg (2 to 1) - discarded (hi1, hi2, hi3)
4. Send unencrypted msg (1 to 2) - not received
5. Reset unencrypted MCU (toggle reset pin)
6. Send unencrypted msg (1 to 2) - received

In this scenario, I do NOT reset the encrypted node.

Attachment(s): 

Science is not consensus. Science is numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is BR_BufCnt?

In case if problems on the sending side I'd start from logging NWK_DataReq() and corresponding appDataConf() calls.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alexru wrote:
Noted about PHY_EncryptConf(). So newer compiler became dumber :). I always check for warnings with IAR and GCC, but only with "current" versions.

WinAVR might be 3 years old, but it still works for me... I hardly ever compile with AVR Toolchain. That said, the GUI of AVR Studio 6.0 is much nicer than 4.18, if only for the Windows Explorer-like file tree that the project navigator displays in 6.0 (rather than just a big list of files, as in 4.18 ).

Science is not consensus. Science is numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BR_BufCnt is a count of bytes received:

bool meshDataInd(NWK_DataInd_t *ind) {
	uint8_t i;
	
	if(BR_getRxFlag()) {
		fprintf_P(&comExt_str, PSTR("Warning - meshDataInd(): New wireless message overwriting previous message.\n"));
	}

	BR_BufCnt = 0;
	for(i = 0; i < ind->size; i++) {
		BR_RxBuf[i] = ind->data[i];
		BR_BufCnt++;
	}
	
	//There is a bug in LwMesh -- the MIC does not get stripped before
	//passing the received data on to the application layer.
	//Until the bug is fixed, manually strip the last four bytes	

	#if defined(NWK_ENABLE_SECURITY)
		BR_BufCnt = BR_BufCnt - 4;
	#endif

	BR_setRxFlag(1);

	return(true);
}

BR_RxBuf[] is where I dump the data when a packet comes in. Other functions "handle" the data (i.e., print it to the terminal, in this case). RxFlag is a global that denotes a new received packet. The handler function clears it when it handles the message.

Science is not consensus. Science is numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do something like:

bool meshDataInd(NWK_DataInd_t *ind)
{ 
  if (ind->options & NWK_IND_OPT_SECURED)
    ind->size -= 4;

  ... the rest of the function as if bug is not there ...

}

so you don't strip data from the unencrypted frames.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the tip -- much better. Interestingly, it also fixed the problem observed for short messages. However, I am still observing the issue where the unencrypted node cannot successfully send packets after it has received an encrypted packet.

Science is not consensus. Science is numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In your example "last debug msg" is printed for the last frame. Which means that header->nwkFcf.securityEnabled got set for the frame that is not encrypted. To fix this change in nwkDataReqSendFrame():

#ifdef NWK_ENABLE_SECURITY
  frame->data.header.nwkFcf.securityEnabled = req->options & NWK_OPT_ENABLE_SECURITY ? 1 : 0;
#endif

to

#ifdef NWK_ENABLE_SECURITY
  frame->data.header.nwkFcf.securityEnabled = req->options & NWK_OPT_ENABLE_SECURITY ? 1 : 0;
#else
  frame->data.header.nwkFcf.securityEnabled = 0;
#endif

Sorry for this.

nwkFrameAlloc() should set memory to all zeros, but somehow it does not. This was already fixed in the upcoming release.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ha! Absolutely no apologies necessary. This stack is great. Just because I was trying to break it (i.e., one encrypted, one not encrypted) doesn't mean the stack is wrong.

In any case, I have made the modification you suggested, and it "works" as expected (i.e., I can send messages from the unencrypted node to the encrypted node both before and after the encrypted node has sent messages to the unencrypted node) -- see attached (all debug messages removed).

I'd rather not think about how long this would have taken me to figure out on my own...

Do you have an eta for the upcoming release? I'm not looking for a date -- just an order of magnitude - days, weeks, months, or years.

Attachment(s): 

Science is not consensus. Science is numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That depends on my other work load. I'd say it will be done in a month or so if all goes right, but then there is documentation, testing and internal release process. All of this sometimes takes unpredictable amount of time since it involves other people and they are busy too.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course. Thanks again for your support.

Science is not consensus. Science is numbers.