Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
LoRaWAN: Remedy for issue #7230 #7445
Link for the original issue #7230
For ABP: If everything goes well, LORAWAN_STATUS_OK is returned for first call followed by a
For OTAA: When a JoinRequest is sent, LORAWAN_STATUS_CONNECT_IN_PROGRESS is returned followed
Mbed OS 5.10
Pull request type
referenced this pull request
Jul 9, 2018
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?
Build number : 2591
Build number : 2234
Jul 13, 2018
14 checks passed
@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.
I think the problem is caused by LoRaWAN: Handling re-joining when already Joined where the return value of
The following change meant the join got retried again: