LoRaWAN: Remedy for issue #7230 #7445

hasnainvirk · 2018-07-09T10:06:41Z

Description

Link for the original issue #7230
Unfortunately, a refactor in the past slightly changed the behaviour of re-connection and we stopped using LORAWAN_CONNECT_IN_PROGRESS return code. This was added in the first place to help the application know that the stack is waiting for a JoinAccept from the network server. There was a confusion created because of this mistake regarding re-connection. We have now devised clear rules about what can be done and how its done. Here are the rules which are now added to the API documentation:

For ABP: If everything goes well, LORAWAN_STATUS_OK is returned for first call followed by a
'CONNECTED' event. Otherwise a negative error code. Any subsequent call will return
LORAWAN_STATUS_ALREADY_CONNECTED and no event follows.

For OTAA: When a JoinRequest is sent, LORAWAN_STATUS_CONNECT_IN_PROGRESS is returned followed
by a 'CONNECTED' event when the JoinAccept is received. Otherwise a negative error code is
returned. Any subsequent call will return LORAWAN_STATUS_ALREADY_CONNECTED and no
event follows.

TARGET release

Mbed OS 5.10

Pull request type

[ ] Fix
[X] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change

This is a remedy for the issue ARMmbed#7230. While the device is joining, LORAWAN_STATUS_CONNECT_IN_PROGRESS is returned. However, if the device is already joined, we will return LORAWAN_STATUS_ALREADY_CONNECTED.

API documentation is updated to clear how the connection related return codes will work from now on.

hasnainvirk · 2018-07-09T10:07:41Z

@kivaisan @kjbracey-arm Please review.

kjbracey · 2018-07-09T10:53:26Z

For OTAA: When a JoinRequest is sent, LORAWAN_STATUS_CONNECT_IN_PROGRESS is returned followed
by a 'CONNECTED' event when the JoinAccept is received. Otherwise a negative error code is
returned.

Otherwise? Does that mean if it doesn't send a JoinRequest? I guess so, but the phrasing is a bit convoluted here - "When this..., followed by X when... Otherwise..."

I may have raised this before - POSIX has an extra error code, which distinguish the two cases of "this connect request is now in progress" (EINPROGRESS) and "there was a connect already in progress, so I'm ignoring this call" (EALREADY). (And both are distinct from "this is connected, so I'm ignoring you" (EISCONN)".

Is it worth distinguishing that - what code do you currently get if this is called between JoinRequest and JoinAccept event?

For ABP: First call to connect() or connect(params) will return LORAWAN_STATUS_OK and a CONNECTED event will be sent. Any subsequent call will return LORAWAN_STATUS_ALREADY_CONNECTED (posix EISCONN) and no event is generated. FOR OTAA: First call to connect() or connect(params) will return LORAWAN_STATUS_CONNECT_IN_PROGRESS and a CONNECTED event will be sent whenever the JoinAccept is received. If the application calls connect again before receiving the CONNECTED event, LORAWAN_STATUS_BUSY will be returned. After the CONNECTED event is dispatched, any subsequent call to connect() or connect(params) API will be returned with LORWAN_STATUS_ALREADY_CONNECTED. No new parameters are accepted after the first call. The application must disconnect before making a connect() call with new parameters.

hasnainvirk · 2018-07-10T10:42:41Z

@kjbracey-arm Please review again.

hasnainvirk · 2018-07-11T14:04:02Z

@kjbracey-arm @cmonr @0xc0170 Please review.

hasnainvirk · 2018-07-12T08:59:29Z

@0xc0170 Needs CI here.

cmonr · 2018-07-12T15:44:25Z

/morph build

mbed-ci · 2018-07-12T19:09:29Z

Build : SUCCESS

Build number : 2591
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7445/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

mbed-ci · 2018-07-12T21:14:21Z

Exporter Build : SUCCESS

Build number : 2234
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/7445/

mbed-ci · 2018-07-13T14:09:32Z

Test : SUCCESS

Build number : 2344
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/7445/2344

mattbrown015 · 2018-07-16T11:31:35Z

@hasnainvirk When there is something wrong with the LoRaWAN session parameters the 'JOIN_FAILURE' event occurs after the first join request transmission. This surprised me, I expected the 'JOIN_FAILURE' after 12 join attempts.

Immediately after the 'JOIN_FAILURE' I see another transmission but then that's it. In other words, I can't see the 12 join attempts that I would expect.

I thought I'd seen a discussion about the expected behaviour of 'JOIN_FAILURE' somewhere but I can't find it now.

I'm using 38744b9.

mattbrown015 · 2018-07-16T13:12:28Z

I think the problem is caused by LoRaWAN: Handling re-joining when already Joined where the return value of LoRaMac::send_join_request() changes from LORAWAN_STATUS_OK to LORAWAN_STATUS_CONNECT_IN_PROGRESS.

The following change meant the join got retried again:

diff --git a/features/lorawan/lorastack/mac/LoRaMac.cpp b/features/lorawan/lorastack/mac/LoRaMac.cpp
index 2a925744d..6d7ed946b 100644
--- a/features/lorawan/lorastack/mac/LoRaMac.cpp
+++ b/features/lorawan/lorastack/mac/LoRaMac.cpp
@@ -772,7 +772,7 @@ bool LoRaMac::continue_joining_process()
     }

     // Schedule a retry
-    if (handle_retransmission() != LORAWAN_STATUS_OK) {
+    if (handle_retransmission() != LORAWAN_STATUS_CONNECT_IN_PROGRESS) {
         return false;
     }

hasnainvirk · 2018-07-16T13:27:02Z

@mattbrown015 You are right. My local branch had the code correctly as you have shown. For some reason my PR still had a check for OK status.

mattbrown015 · 2018-07-16T13:35:35Z

@hasnainvirk Great! Relatively easy to sort out then. :-)

hasnainvirk · 2018-07-16T13:40:04Z

@mattbrown015 I have opened a PR for the fix. handle_retransmission() is shared between both Join and Data paths that's why the confusion happened. #7520

0xc0170 · 2018-07-17T13:39:24Z

@mattbrown015 thanks for bringing this up

LoRaWAN: Remedy for issue ARMmbed#7230

Hasnain Virk added 2 commits July 9, 2018 12:59

LoRaWAN: Handling re-joining when already Joined

51f92b0

This is a remedy for the issue ARMmbed#7230. While the device is joining, LORAWAN_STATUS_CONNECT_IN_PROGRESS is returned. However, if the device is already joined, we will return LORAWAN_STATUS_ALREADY_CONNECTED.

Updating docs

24db1c8

API documentation is updated to clear how the connection related return codes will work from now on.

hasnainvirk mentioned this pull request Jul 9, 2018

lorawan interface connect method should return LORAWAN_CONNECT_IN_PROCESS when connnecting #7230

Closed

0xc0170 requested review from kjbracey and a team July 9, 2018 10:12

0xc0170 added the needs: review label Jul 9, 2018

kivaisan approved these changes Jul 9, 2018

View reviewed changes

cmonr requested review from cmonr and 0xc0170 July 11, 2018 15:21

kjbracey approved these changes Jul 12, 2018

View reviewed changes

hasnainvirk force-pushed the issue_7230 branch from 1ceeb41 to f0844b4 Compare July 12, 2018 09:22

cmonr added needs: CI and removed needs: review labels Jul 12, 2018

cmonr added the release-version: 5.9.3 label Jul 13, 2018

cmonr merged commit c5ba97f into ARMmbed:master Jul 13, 2018

0xc0170 removed the needs: CI label Jul 13, 2018

pan- pushed a commit to pan-/mbed that referenced this pull request Aug 22, 2018

Merge pull request ARMmbed#7445 from hasnainvirk/issue_7230

2e820e1

LoRaWAN: Remedy for issue ARMmbed#7230

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

LoRaWAN: Remedy for issue #7230 #7445

LoRaWAN: Remedy for issue #7230 #7445

Uh oh!

hasnainvirk commented Jul 9, 2018 •

edited

Loading

Uh oh!

hasnainvirk commented Jul 9, 2018

Uh oh!

kjbracey commented Jul 9, 2018

Uh oh!

hasnainvirk commented Jul 10, 2018

Uh oh!

hasnainvirk commented Jul 11, 2018

Uh oh!

hasnainvirk commented Jul 12, 2018

Uh oh!

cmonr commented Jul 12, 2018

Uh oh!

mbed-ci commented Jul 12, 2018

Uh oh!

mbed-ci commented Jul 12, 2018

Uh oh!

mbed-ci commented Jul 13, 2018

Uh oh!

mattbrown015 commented Jul 16, 2018

Uh oh!

mattbrown015 commented Jul 16, 2018

Uh oh!

hasnainvirk commented Jul 16, 2018

Uh oh!

mattbrown015 commented Jul 16, 2018

Uh oh!

hasnainvirk commented Jul 16, 2018

Uh oh!

0xc0170 commented Jul 17, 2018

Uh oh!

Uh oh!

LoRaWAN: Remedy for issue #7230 #7445

LoRaWAN: Remedy for issue #7230 #7445

Uh oh!

Conversation

hasnainvirk commented Jul 9, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

TARGET release

Pull request type

Uh oh!

hasnainvirk commented Jul 9, 2018

Uh oh!

kjbracey commented Jul 9, 2018

Uh oh!

hasnainvirk commented Jul 10, 2018

Uh oh!

hasnainvirk commented Jul 11, 2018

Uh oh!

hasnainvirk commented Jul 12, 2018

Uh oh!

cmonr commented Jul 12, 2018

Uh oh!

mbed-ci commented Jul 12, 2018

Build : SUCCESS

Triggering tests

Uh oh!

mbed-ci commented Jul 12, 2018

Exporter Build : SUCCESS

Uh oh!

mbed-ci commented Jul 13, 2018

Test : SUCCESS

Uh oh!

mattbrown015 commented Jul 16, 2018

Uh oh!

mattbrown015 commented Jul 16, 2018

Uh oh!

hasnainvirk commented Jul 16, 2018

Uh oh!

mattbrown015 commented Jul 16, 2018

Uh oh!

hasnainvirk commented Jul 16, 2018

Uh oh!

0xc0170 commented Jul 17, 2018

Uh oh!

Uh oh!

hasnainvirk commented Jul 9, 2018 •

edited

Loading