CFList not in the join-accept message

ChirpStack Network Server
1

Hello,

I am programming a node with loramac 1.2.1 with lorawan version 1.0.3.

I want it to communicate with a Tektelic Kona Micro gateway that is listening on US channels 8,9,10,11,12,13,14 and 15. However, when the device performs a join and receives the join accept, it does not any channel mask (CFList) at all. By debugging the loramac module, I can see that its own channel mask is all 64 channels, despite the fact that the gateways in my office can only listen to 0-15.

My loraserver.toml file has the following content for the enabled uplink channels:

# Enable only a given sub-set of channels
#
# Use this when ony a sub-set of the by default enabled channels are being
# used. For example when only using the first 8 channels of the US band.
#
# Example:
# enabled_uplink_channels=[0, 1, 2, 3, 4, 5, 6, 7]
enabled_uplink_channels=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]
#enabled_uplink_channels=[]

My question is: How is the CFList in the join-accept messaged determined by the network server? How is it triggered?

Thanks

2

OK I think I found a potential answer to my problem. By checking in the Lorawan Regional Parameters v1.0.2, It says that the CFList in the join-accept message is not supported for US915 region. However, in the same document for version 1.0.3 it says that the CFList is supported for US915.

Perhaps the loraserver.io project hasn’t done the difference properly yet?

3

I have found a part of the code of the lorawan repository that might be an answer to the question:

In the the GetCFList() function in the band.go file of the lorawan repository, it seems like it doesn’t give CFList in the join accept message at all if the lorawan version is 1.0.x. I think this is a misinterpretation of the protocol, since the 1.0.3 version should contain CFLists in the join-accept message. I will probably create an issue in the github repository for this.

1 Like
4

image

It says when the band does not support extra channels (e.g. US band) and the protocol version is 1.0.x. I believe this is valid as the EU band has supportsExtraChannels=true so this condition would not pass.

For LoRaWAN 1.1 other bands do also implement the CFList, but it would contain a channel-mask instead of a channel-list in some cases.

Edit: Nevermind, you are right. The LoRaWAN 1.1 CFList was backported into the LoRaWAN 1.0.3 regional parameters. This needs to be fixed in the lorawan/band package to make sure that this type of CFList is also returned for LoRaWAN 1.0.3.

1 Like
5

@acourt would be able to test this when I have this change ready? I can provide you a test binary or .deb package which you can install like any normal release. That would be much appreciated :slight_smile:

6

Sure. I will be on vacation next week, so if you send a .deb today or tomorrow, I will be able to test it out. If not, it will go to the week of the 18th.

1 Like
7

@acourt you can find pre-compiled binaries here: https://www.dropbox.com/sh/78iifcxd4zjztar/AAAvgnGWeuRO-JwoiFAUc309a?dl=0

This is a build of https://github.com/brocaar/loraserver/tree/fix_cflist_lw103 and contains this fix:

Looking forward to your feedback :slight_smile:

1 Like
8

After testing with the version you sent me, I can confirm that the CFList is sent during the JoinAccept message. Thanks @brocaar! :grin:

On a side note, do you know if theres an easy way to go back to my previous install of loraserver after doing a dpkg -i *.deb on the .deb file you sent me?

1 Like
9

Great! You can download this previous version from https://artifacts.loraserver.io/downloads/loraserver/ (look for the .deb package for your version) and install that one using dpkg -i :slight_smile:

2 Likes