Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uplink with FPort 255 and invalid MIC! #950

Open
mohsenmoqadam opened this issue Oct 3, 2023 · 2 comments
Open

Uplink with FPort 255 and invalid MIC! #950

mohsenmoqadam opened this issue Oct 3, 2023 · 2 comments
Assignees
Labels

Comments

@mohsenmoqadam
Copy link

Hello dears

  • This is my configuration:
    1- LMIC Version: v4.1.1
    2- IDE: Arduino
    3- Board: UNO
    4- Region: EU868
    5- Radio: HopeRF
    6- Network Provider: My Server

  • Some about Network Provider:
    I'm developing a network server, this server works fine with different scenarios, it can do OTA, unconfirmed uplink, and unconfirmed uplink. At the moment, I working on the confirmed downlink and 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 uses FPort = 255!

The first question is: Why does UNO use 255? while the downlink port was 1.

Furthermore, the MIC of 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 generating MIC in the LMIC library?
I read lmic.c but everything is okay and cont find any problem, can anyone guide me about this issue and how to fix it?

@terrillmoore
Copy link
Member

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
Copy link
Author

Thanks, Terry.
Based on your guidance if FramePayload is empty, then we must calculate MIC with: MHDR|DevAddr|FCtrl|FCnt|FOpts.

Now my problem is solved and all things are okay, again I would like to admire your subtlety and quick response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants