terrillmoore
commented
1 year ago The LMIC sends an ACK to the confirmed downlink message without a port number because there's no application payload. I guess that the Network service is not tested yet for this situation. Check https://github.com/mcci-catena/arduino-lmic/blob/master/doc/LoRaWAN-at-a-glance.pdf which correctly says: "FPort is present if any payload bytes are present" but forgets to say "if and only if". My guess is that the NS code is not anticipating this case, and is instead reading off the end of the buffer (and assuming the MIC starts one byte late).
Best regards, --Terry
mohsenmoqadam
Hello dears
This is my configuration: 1- LMIC Version:
v4.1.12- IDE:Arduino3- Board:UNO4- Region:EU8685- Radio:HopeRF6- Network Provider:My ServerSome about Network Provider: I'm developing a network server, this server works fine with different scenarios, it can do
OTA,unconfirmed uplink, andunconfirmed uplink. At the moment, I working on theconfirmed downlinkand I am facing a weird issue!Some about the issue: UNO does OTA and Network Session Key and Application Session Key generate successfully and same in the Server and UNO, unconfirmed uplink and unconfirmed downlink exchange properly, but when the server sends a confirmed downlink the issue is raised! In this case, UNO gets data properly and then sends an unconfirmed uplink with
FCtrlACK=true, but it usesFPort=255!The first question is: Why does UNO use 255? while the downlink port was 1.
Furthermore, the
MICof the uplink message isn't valid!So the next question: In this scenario (
FCtrlACK=true, and with no frame payload) which Key is used for generatingMICin the LMIC library? I readlmic.cbut everything is okay and cont find any problem, can anyone guide me about this issue and how to fix it?