search

gotthardp / lorawan-server

Compact server for private LoRaWAN networks
https://gotthardp.github.io/lorawan-server
MIT License
957 stars 329 forks source link

Multicast FCount mismatch for late joining devices #509

Open amc2505 opened 6 years ago

amc2505 commented 6 years ago

hello,

Because I had strange behavior I have disable Fcnt on my profile for the moment. I have a Multicast which is in the same profile. It seems that the fcount are not deactivated for the multicast. If I deactivate fcount, it must be deactivated for the whole profile isn't it ?

gotthardp commented 6 years ago

Hello. It's uplink FCnt Check that gets disabled, not the counter itself. The multicast is related to downlinks only. What exactly you want to disable?

amc2505 commented 6 years ago

In fact, in my testbed I have 7 modules which are listening in Multicast. i don’t know why, it was not working anymore, and there was nothing in the lorawan-server logs …I restarted the modules and nothing change… I put the multicast Fcount to zero and everything work.

What do you think about that ?

regards.

Le 17 oct. 2018 à 10:56, Petr Gotthard notifications@github.com a écrit :

Hello. It's uplink FCnt Check that gets disabled, not the counter itself. The multicast is related to downlinks only. What exactly you want to disable?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gotthardp/lorawan-server/issues/509#issuecomment-430546552, or mute the thread https://github.com/notifications/unsubscribe-auth/ABa5XvB_1hE8GuBP0yQCSa8PFeB0mHoeks5ulvCtgaJpZM4Xjb64.

gotthardp commented 6 years ago

The Multicast FCount in the server is permanent, but the stored FCount in the device is often not (although the standard says they should be). I suspect the Multicast may have been rejected by the device because the Fcnt had "wrong" value. Could it be a possible reason?

altishchenko commented 6 years ago

It could. Met this a few times. Unless the device does something analogous to 'reset on zero', communication breaks.

ср, 17 окт. 2018 г. в 13:11, Petr Gotthard notifications@github.com:

The Multicast FCount in the server is permanent, but the stored FCount in the device is often not (although the standard says they should be). I suspect the Multicast may have been rejected by the device because the Fcnt had "wrong" value. Could it be a possible reason?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gotthardp/lorawan-server/issues/509#issuecomment-430571235, or mute the thread https://github.com/notifications/unsubscribe-auth/ASj_3wkqcp7hqIK1xUmrmYsTkVQ6BhcLks5ulwIggaJpZM4Xjb64 .

amc2505 commented 6 years ago

the fcount on the server side et device side must be the same or it must simply be bigger at server side ?

Le 17 oct. 2018 à 14:47, Alexander Tishchenko notifications@github.com a écrit :

It could. Met this a few times. Unless the device does something analogous to 'reset on zero', communication breaks.

ср, 17 окт. 2018 г. в 13:11, Petr Gotthard notifications@github.com:

The Multicast FCount in the server is permanent, but the stored FCount in the device is often not (although the standard says they should be). I suspect the Multicast may have been rejected by the device because the Fcnt had "wrong" value. Could it be a possible reason?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gotthardp/lorawan-server/issues/509#issuecomment-430571235, or mute the thread https://github.com/notifications/unsubscribe-auth/ASj_3wkqcp7hqIK1xUmrmYsTkVQ6BhcLks5ulwIggaJpZM4Xjb64 .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gotthardp/lorawan-server/issues/509#issuecomment-430614192, or mute the thread https://github.com/notifications/unsubscribe-auth/ABa5Xjxd8qiqIm7bXbR3B8GFUGKsIxTyks5ulybhgaJpZM4Xjb64.

gotthardp commented 6 years ago

The next FCnt shall always be bigger and the gap between the last and the next must not be too big. I thought the standard says "too big" is more than 16384, which is a lot. To be honest I don't understand why the device rejects uplinks that have just a little higher FCnt.

altishchenko commented 6 years ago

I met devices that rejected the server's answers where FCntDown was way off. This can happen if you test the device on one server and then deploy it on another. The device in question should implement something analogous to "reset on zero" from the server side, otherwise without hard reset to the device you won't be able to connect it back - "security" prevails, thanks to LoRaWAN.

amc2505 commented 6 years ago

The problem is that, when there is a difference of about 16000, for loran multicast fcount and the device fcount this is not working anymore.

So what happens …

I start the multicast system with some device … this is OK fcount increase and reach 16125 this is OK.

I had a new device listening on multicast ..because Lorawan fcount is more than 16000 and my device is 0 because it is new … it doesn’t work on the new device.

I reset the loran-server fcount to



0, and then my new module work … but not the old one because again I have a difference of more than 16000.

So I think I need a system to reinit the fcount on a regular basis…..so I write a small program to re init the multicast fcount, but I got an http 405 error.

help is welcome..

Le 17 oct. 2018 à 16:13, Alexander Tishchenko notifications@github.com a écrit :

I met devices that rejected the server's answers where FCntDown was way off. This can happen if you test the device on one server and then deploy it on another. The device in question should implement something analogous to "reset on zero" from the server side, otherwise without hard reset to the device you won't be able to connect it back - "security" prevails, thanks to LoRaWAN.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gotthardp/lorawan-server/issues/509#issuecomment-430645102, or mute the thread https://github.com/notifications/unsubscribe-auth/ABa5XmQmG7PBfToHxC2zLeWPgUSuW3WFks5ulzsYgaJpZM4Xjb64.

gotthardp commented 6 years ago

This is an interesting problem of the LoRaWAN standard. I am not sure how this should be solved; I will try asking the LoRaWAN Alliance. Let's see what the experts say.

https://semtech.force.com/lora/LC_Answers_Questions#!/feedtype=SINGLE_QUESTION_DETAIL&dc=Theory_LoRaWAN&criteria=OPENQUESTIONS&id=90644000000LawRAAS

amc2505 commented 6 years ago

and what about the fact that my python program is not able to reset multicast fcount, I ‘m able to change when I connect with the web interface.

Le 19 oct. 2018 à 11:46, Petr Gotthard notifications@github.com a écrit :

This is an interesting problem of the LoRaWAN standard. I am not sure how this should be solved; I will try asking the LoRaWAN Alliance. Let's see what the experts say.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gotthardp/lorawan-server/issues/509#issuecomment-431308089, or mute the thread https://github.com/notifications/unsubscribe-auth/ABa5XnyXepTlEtM4lDSgHSPv_v7Gq2Vqks5umZ9sgaJpZM4Xjb64.

gotthardp commented 6 years ago

The manual reset to zero shall be possible. What HTTP request are you sending, what error are you getting and what is written in the log files?

amc2505 commented 6 years ago

I got ..

http_error {405,"/api/multicast_channels/ABBA0080/",{127,0,0,1}},

Le 19 oct. 2018 à 11:46, Petr Gotthard notifications@github.com a écrit :

This is an interesting problem of the LoRaWAN standard. I am not sure how this should be solved; I will try asking the LoRaWAN Alliance. Let's see what the experts say.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gotthardp/lorawan-server/issues/509#issuecomment-431308089, or mute the thread https://github.com/notifications/unsubscribe-auth/ABa5XnyXepTlEtM4lDSgHSPv_v7Gq2Vqks5umZ9sgaJpZM4Xjb64.

amc2505 commented 6 years ago

the address "http://localhost:8080/api/multicast_channels/ABBA0080/«

And I just try to upgrade doing a post 

print(requests.post(addressServer,json=payload,auth=self.auth))

with payload

def set_payload(self): return [{"fcntdown":0}]

Le 19 oct. 2018 à 11:46, Petr Gotthard notifications@github.com a écrit :

This is an interesting problem of the LoRaWAN standard. I am not sure how this should be solved; I will try asking the LoRaWAN Alliance. Let's see what the experts say.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gotthardp/lorawan-server/issues/509#issuecomment-431308089, or mute the thread https://github.com/notifications/unsubscribe-auth/ABa5XnyXepTlEtM4lDSgHSPv_v7Gq2Vqks5umZ9sgaJpZM4Xjb64.

gotthardp commented 6 years ago

1) You must use PUT, (not POST) 2) You must include the entire payload, i.e. do GET, change a value and then PUT everything back

amc2505 commented 6 years ago

ok…

Thanks.

Le 19 oct. 2018 à 15:42, Petr Gotthard notifications@github.com a écrit :

You must use PUT, (not POST) You must include the entire payload, i.e. do GET, change a value and then PUT everything back — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gotthardp/lorawan-server/issues/509#issuecomment-431367198, or mute the thread https://github.com/notifications/unsubscribe-auth/ABa5XodMSwLJECYaEAApPZityaXQ2tlXks5umdasgaJpZM4Xjb64.