Lora-net / LoRaMac-node

Reference implementation and documentation of a LoRa network node.
Other
1.89k stars 1.09k forks source link

Downlink is not working on Everynet US915 #962

Closed Lozeonjyu closed 3 years ago

Lozeonjyu commented 4 years ago

Hi,

I am currently using the code stack for The Things Network and everything works fine. But recently when I tried to work on Everynet it didn't work properly. The everynet gateway can see the join requests and uplinks, but the node never receives the join ack or downlink. The everynet server also pushes back downlink everytime the node sends abp uplink for some reason.

Below is the downlink payload, it seems to send the same one everytime: "payload": "A0UBAHEDBf8AAQMFAABBBAAFCGjijA==",

Please advise. Many thanks

altishchenko commented 4 years ago

@Lozeonjyu You should probably check the keys on the everynet side, if you don't receive join-accept. Mind you, some cloud providers have reversed byte order in the keys. As for the downlinks - there are expected, they look like ADR control to me, which every network forces upon the end devices upon connect (like channels, txpower, spread factor/data rate, etc).

Lozeonjyu commented 4 years ago

@Lozeonjyu You should probably check the keys on the everynet side, if you don't receive join-accept. Mind you, some cloud providers have reversed byte order in the keys. As for the downlinks - there are expected, they look like ADR control to me, which every network forces upon the end devices upon connect (like channels, txpower, spread factor/data rate, etc).

Thanks @altishchenko That's good info. I will investigate them a little bit more

Lozeonjyu commented 4 years ago

@Lozeonjyu You should probably check the keys on the everynet side, if you don't receive join-accept. Mind you, some cloud providers have reversed byte order in the keys. As for the downlinks - there are expected, they look like ADR control to me, which every network forces upon the end devices upon connect (like channels, txpower, spread factor/data rate, etc).

@altishchenko May I know how to understand the payload? Sorry I am not very good about the specs and data structure.

lucaspeixotot commented 4 years ago

@Lozeonjyu What LoRaMac version are you using?

lucaspeixotot commented 4 years ago

I was having problems to receive downlink claims in class C with the v4.4.4 LoRaMac version. So I saw in everynet documentation that they are using a different version of LoRaMac-Node, more specifically they are using a modification of the v4.4.3 version.

here is the link with the stack used by everynet

altishchenko commented 4 years ago

@altishchenko May I know how to understand the payload? Sorry I am not very good about the specs and data structure.

@Lozeonjyu It all depends upon where you get it. It may be encrypted, may be not. I tried parsing it as a MAC payload and as a frame payload - neither made any sense, What am I saying about the ADR is my best guess, because all networks try to establish ADR parameters on connect (first air) of the device. If your device ignores this payload and doesn't answer (also guessing it, because the same payload is repeated multiple times) it is a sign of the problem with the keys. Like, if your device doesn't support ADR or doesn't accept the network parameters it will reply so. If the device keeps quite, it means it ignores the downlink altogether - that is encryption. Also, be advised, that not all networks support "Reset on zero" ABP behaviour, on the contrary, most networks insist on FCNT consistency with ABP - you can't keep resetting your device and restarting transmissions with FCnt 0/1 - network will ignore that and will reply with its own FCnt different from 0/1, which will be ignored by your device for the same reasons. I suggest you investigate OTAA Join problems - they are much simpler to troubleshoot in development. (With Actility we had to delete and re-create the ABP devices in there system every time we had to reset them).

P.S.: The only major difference between 4.4.4 and 4.4.3 is adherence to LoRa 1.0.4 version of the standard and its regional parameters companion. Modifications made by everynet are mostly for the regional channel plans that were missing or not correct in the 4.4.3, not the LoRaWAN protocol itself. We never had any interoperability problems in this area.

mluis1 commented 4 years ago

Can we close this issue?

mluis1 commented 3 years ago

No feedback we close the issue