ABP on AEP

Home Forums Conduit: AEP Model ABP on AEP

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #19771
    Mike Cook
    Participant

    Good morning,

    I am writing in reference to implementing ABP on my AEP-based MT Conduit.

    I have mixed results. It works every time when I ssh into my conduit and use the lora-query utility to set up a ABP-based node.

    But it only works for the length of time that the client node is powered. If I power of my client node, or simply restart its program, the data received by the Conduit can’t be decrypted properly. At this point if I delete the node via the “lora-query -d <network ID>” command and then re-add it using the lora-query -a command, it immediately starts to work again.

    Why does this occur?

    Mike

    #19775
    Jason Reiss
    Keymaster

    the data received by the Conduit can’t be decrypted properly.

    Are received packets being reported?

    Perhaps the device does not maintain the uplink counter over power cycles.

    #19776
    Mike Cook
    Participant

    Yes. Packets are received. But they are no longer decrypted. I can see the activity in Node-Red; they are being published to a topic via MQTT. But the LoRa side is not outputting any information.

    #19786
    Jason Reiss
    Keymaster

    What MQTT topic is reported?

    If the uplink counter on the device is reset to 0 when power cycled, the packets will not be reported to the application until the counter reaches the last value received by network server.

    If this behavior cannot be corrected on the device side then the network server can be configured to allow the device to return to 0. However this does introduce a security risk of allowing counter reuse.

    This strict check can be disabled to allow the device to reset to zero.

    mLinux lora-network-server.conf

    “lora”: {
    “enableStrictCounterValidation”: true, /* ensure packet counter values are not being reused, packets are dropped if not within MAC_FCNT_GAP, default:true */

    }

    AEP
    https://192.168.2.1/api/loraNetwork?method=PUT&data={"lora":{"enableStrictCounterValidation":false}}&apply=now

    https://192.168.2.1/api/command/save?method=POST

    • This reply was modified 6 years, 3 months ago by Jason Reiss.
    #19808
    Mike Cook
    Participant

    Thanks. That was exactly the issue. I’ll look into how to keep the frame count on my device between power cycles.

    Mike

    #19810
    Lawrence Griffiths
    Participant

    Jason, accepting the security risk on uplink counter validation. Could disabling strict work for when AEP is power cycled and end-node keeps transmitting. As assume Netserver counters are lost and end-node keeps tx-ing so counters are out of sync and can’t be validated?

    Reason for asking I have live project where end-node supplier Doesn’t check to see if they are still joined to network. I can’t go and power cycle 200+ sensors which are in different country. So pondering what I can do?

    Lawrence

    #19813
    Jason Reiss
    Keymaster

    The network can handle missed packets without becoming out of sync.

    The counters can increase up to 16384 missed packets, MAX_FCNT_GAP in LoRaWAN, and the network server will accept the packet and the counters will be in sync.

    The issue is only when a counter is decreased or reset to 0.

    #21264
    Sergio Valiente
    Participant

    Hello,
    I had this problem. It was resolved. thanks

    But now, I have similar problem if the conduit power off, and the mdot is on.
    when the conduit power up, I send a packet to the mdot from the conduit but the mdot trace shows:

    [TRACE] Check downlink counter rollover 00020008
    [WARNING] Invalid MIC Addr: 00000001 FCnt: 00000008

    the packets from the mdot to de conduit are received withon problems.
    if I reset the mdot all go well.
    have I to disable some check in the mdot too?
    thanks

    #21991
    Arturo Gasca
    Participant

    How implement the API in AEP? I have this result
    {
    “code” : 400,
    “error” : “Error parsing URL JSON data [* Line 1, Column 2\n Missing ‘}’ or object member name\n]”,
    “status” : “fail”
    }

    #21992
    Jason Reiss
    Keymaster

    You have this result in response to what exactly?

    #22206
    Albert Beukman
    Participant

    I got the same thing as Arturo above submitting.

    https://<IP-address>/api/loraNetwork?method=PUT&data={“lora”:{“enableStrictCounterValidation”:false}}&apply=now

    Also tried editing /var/config/lora-network-server.conf but the changes get reverted every time I start the network server.

    MTCAP-LNA3-915-001A Firmware1.4.4
    LNSv1.0.41

    EDIT
    POST API executes successfully (confirming I’m logged in and API should be OK)
    https://<IP-address>/api/command/save?method=POST

    EDIT
    Correction on Conduit model.

    #22210
    Albert Beukman
    Participant

    Regarding the API not executing.

    Quotes copied from forum was generating the error. Pasting config into a JSON formatting tool found the issue (Google “JSON Formatter”)

    Hoping code block takes out special quote formatting:
    https://<IP-address>/api/loraNetwork?method=PUT&data={"lora":{"enableStrictCounterValidation":false}}&apply=now

    If not, copy the URL into a text editor and replace quotes by typing them. Should do the trick.

    #22212
    Mikael Grah
    Participant

    Hi,

    Just wanted to thank you for this topic, it helped solve an issue for me as well. I was trying to get a mDot to communicate with an AEP Conduit using ABP. I suspected the counter for a long time, but was not able to find a solution/description of how to configure the Conduit (and mDot) properly.

    After reading this discussion, I’m curious about how to assure that the counters are working properly? Especially when having multiple Conduits that may be in range (or when moving between multiple conduits).

    Are there any online resources describing this?

    Best regards, and a happy new year to all of you!
    /M

    #22217
    Jason Reiss
    Keymaster

    You can adjust the counter values in mDot with these commands.
    AT+DLC – Downlink counter
    AT+ULC – Uplink counter

    If you have multiple conduits in range and all have ABP session information for the end-device, any one of them can receive the uplink or author a downlink for the device.
    However there will be issues with keeping the downlink counter in sync between the dot and conduits if it moves around, out-of-range at times, or if two gateways are responding to the same packet.
    If this is an uplink only network this may work OK as long as the counter does not get ahead of the gateway by 16k packets.

    With mDot there is NVM available to store the counter values over a reset.

    AT+SS – save session before reset
    AT+RS – restore session after reset

Viewing 14 posts - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.