Join issues

[DrEdHepler]

We are using an InsightSIP module that contains an SX126x device on a sensor board.
The sensors connect to MachineQ (Comcast) (will refer to this as MQ) and provide periodic data. We are having a couple of issues:

1. MQ does not send a CFList with a JoinAccept, so they require that the first uplink message after a JoinAccept be sent on the same channel that the JoinRequest was made on (which happens to always be the same channel as the JoinAccept is received on). I made a modification (hack) to LoRaMac.c to accomplish this, but wonder if there is already a means to do this that I missed.
2. From issue 1, the first message after the JoinAccept, I send as a Confirmed message and most of the time a CFList is returned with the message containing the AckBit. But sometimes the returning message doesn't include a CFList. When this happens, messages are sometime lost, since they are sent on channels that aren't assigned/approved. I tried increasing NbTrans to allow retransmissions and that seems to help, but interacts badly with my "hack" solution with issue 3 (below). Is there a way to request that a CFList be sent?
3. Each time the sensor sends a Join request, the DevNonce is incremented. MQ keeps track of this, and if the sensor attempts to join again, the JoinRequests are ignored until the DevNonce "catches up" with what MQ expects (even though I believe the DevNonce is stored in NVM by LoRaMac.c). Each JoinRequest also uses a different channel, and it appears that the channel is "disqualified/removed from the list" each time the JoinRequest fails. We see the situation where number of attempts gets to point where the Duty-Cycle-Restricted limit is reached. After the "appropriate delay", the JoinRequests should start again, but what I'm seeing is that the Mac re-enters Duty-Cycle-Restricted mode, due to no channels being available. The gateway being used is an 8-channel gateway, and I think the actual "legal" channels were tried previously, but since the DevNonce hadn't "matched / exceeded", they were removed from the list. I again "hacked" a solution that "restores" the channel list when the Duty-Cycle-Restricted mode delay has expired so the channels can be re-examined, and forced JoinRequests to be able to use TxDelay mode, so they could be restarted. This fixed this problem (as a temporary solution), but appears to have other bad side-effects. Is there a better solution to this (that doesn't include hacking the code)?

Thanks for your assistance/comments!

[mluis1]

From your description some valuable information is missing.
Could you please provide the following?

• What region is being used?
• What LoRaWAN and Regional Parameters specifications are being targeted (end-device and MQ server)?
• What version of this project is being used?

The answer will depend on used versions and region.

From your description it looks like that there are some misunderstanding of the LoRaWAN specifications.

For instance a CFList is only sent with the JoinAccept downlink. If no CFList on the JoinAccept is sent the network server should depending on the region send NewChannelReq or LinkAdrReq mac commands once the end-device does normal uplinks.

In your first point you say: "so they require that the first uplink message after a JoinAccept be sent on the same channel that the JoinRequest was made on". For instance in case of US915 region this is forbidden by the FCC as one needs to use randomly all available frequencies prior to use them again. In EU868 the frequencies are selected randomly and the same frequency can be used more than once in a row.

What we can say is that the code provided here is pre-certified by the LoRa Alliance certification process which means it complies with LoRaWAN specifications.
This stands true if no modifications are done to the files under src/mac directory.
It has to be noted as well that interoperability tests with different network servers have been done successfully.