Not receiving mqtt msgs for ABP device

ChirpStack Network Server
#1

First off, thx a lot for having created a project like this.

I have an OTAA enabled device configured in the portal, and I’m receiving the Frame Logs in the portal, as well as the following mqtt messages :

application/2/node/0018b2000000185f/rx {"applicationID":"2","applicationName":"app2","nodeName":"adeunis-tester","devEUI":"xxxxx","rxInfo":[{"mac":"xxxxx","time":"2017-09-26T10:58:20.994563Z","rssi":-23,"loRaSNR":9.5,"name":"ixor-gateway","latitude":0,"longitude":0,"altitude":0}],"txInfo":{"frequency":868100000,"dataRate":{"modulation":"LORA","bandwidth":125,"spreadFactor":7},"adr":false,"codeRate":"4/5"},"fCnt":6,"fPort":1,"data":"xxxxxxxxxxxxxxx="}
Client mosqsub/34189-MacBook-P received PUBLISH (d0, q0, r0, m0, 'gateway/xxxxxx/tx', ... (240 bytes))

I also have an ABP device configured in the portal, and I’m receiving the Frame Logs there (so I guess it is properly setup with the correct DevAddr / App and Network key), yet I’m not receiving MQTT payloads for that one. The uplink / downlink counters also remain 0 (despite the fact that I see msgs coming in the frame logs)

The ABP device is configured in a seperate app, and the Device Addr / App / Session Keys are setup correctly (I think). If I chang the app / session keys I’m not seing msgs coming into the Frame Logs tab.

I’ve picked some random values for App EUI / Device EUI (I was under the impression that these aren’t needed for ABP).

Any idea why it is working for OTAA but not for ABP ? What should I do with the App EUI / Device EUI in an ABP scenario ?

#2

Do you see any errors in your logs? E.g.

ERRO[0341] processing rx packet error: get node-session error: node-session does not exist or invalid fcnt or mic  data_base64="..."

If so, that could mean your node is not correctly configured. Please note that the byte-order might be different for some devices. So you need to enter 01020304 as 04030201. What I usually do to find out the correct order is make sure it is reversible, e.g. 01010101. This might apply to the DevAddr, NwkSKey and AppSKey.

Also make sure that the frame-counters are in sync, else they will get rejected by LoRa Server.

#3

ok … will check … It’s a sensor I have no control over.

I only have the DevAddr, NwkSKey and AppSKey. (If I understand correctly this is all you need for ABP)

2 follow up questions :

What should I provide for App EUI / Device EUI in an ABP scenario (they are required fields). Can I just pick something unique ?
What do you mean with frame-counters in sync ? How can I control that ?

#4

Your device should have a DevEUI too, but as far as I know, you could pick one. LoRa Server will map the DevAddr to the DevEUI.

For the AppEUI you could pick anything you want. This field is going away for ABP in one of the next versions of LoRa (App) Server.

Frame-counters must always increment. So when you activate your node in LoRa (App) Server with a value higher than the actual counter on the node, these frames get rejected. Usually 0 should work. If not, you could also enable the relax frame-counter mode for debugging.

#5

Thx for clearing that up …

Here’s what I found in the logs :

time=“2017-09-26T14:23:37Z” level=info msg=“backend/gateway: rx packet received”
time=“2017-09-26T14:23:37Z” level=info msg=“packet(s) collected” dev_eui=00e80669ddcad236 gw_count=1 gw_macs=b827ebfffecbe31f mtype=UnconfirmedDataUp
2017/09/26 14:23:37 warning: unmarshal mac-command error (skipping remaining mac-command bytes): lorawan: invalid CID 1
time=“2017-09-26T14:23:37Z” level=info msg=“rx info sent to network-controller” dev_eui=00e80669ddcad236
time=“2017-09-26T14:23:37Z” level=error msg=“processing rx packet error: expected mac commands, but FRMPayload is empty (FPort=0)” data_base64=“QPsPAAAAEgAAWf7R5zJQxMZ4/KSabwIJ4S/u”

Sensor is a black-box so don’t know how it is sending out the payloads.

Will try to find out more about this error but most likely you already know what the issue is.

#6

image
image.jpg803×144 78.3 KB

I haven’t looked into the actual content of the frame (data_base64), but the error hints that the FRMPayload is empty where mac-commands are expected.

2017/09/26 14:23:37 warning: unmarshal mac-command error (skipping remaining mac-command bytes): lorawan: invalid CID 1

That seems like an other issue, there is no such mac-command with CID=:

image
image.png395×663 84.2 KB

#7

Was also reading that spec sheet… not that familiar with low-level lora.

Just hooked up a Seeeduino LoRaWAN and configured it with ABD and it worked fine, so it is the sensor.

I would imagine that the lora radio on the sensor would be responsible for transmitting valid Lora packets ?
Does a sensor developer interact with lora on this level ?

Are there different versions of the Lora spec that I should take into account? Or packet forwarder settings I can configure on the gateway ?

#8

Hi,

I ran another test, using a NodeJS library (https://www.npmjs.com/package/lora-packet) where I decode the Lora packet and decrypt the payload :

Here’s the output :

packet.toString()=
Message Type = Data
  PHYPayload = 40FB0F0000000200008D32FA2F0B3DCCAF83D250E553E4287979C9

( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
        MHDR = 40
  MACPayload = FB0F0000000200008D32FA2F0B3DCCAF83D250E553E4
         MIC = 287979C9

( MACPayload = FHDR | FPort | FRMPayload )
        FHDR = FB0F0000000200
       FPort = 00
  FRMPayload = 8D32FA2F0B3DCCAF83D250E553E4

      ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
     DevAddr = 00000FFB (Big Endian)
       FCtrl = 00
        FCnt = 0002 (Big Endian)
       FOpts = 

Message Type = Unconfirmed Data Up
   Direction = up
        FCnt = 2
   FCtrl.ACK = false
   FCtrl.ADR = false

packet MIC=287979c9
FRMPayload=8d32fa2f0b3dccaf83d250e553e4
MIC check=OK
calculated MIC=287979c9
Decrypted='xxxxxxxx'

As far as I can see the decrypted value seems correct. (I have a uart connection to the sensor and the sensors logs the un-encrypted payload and it seems to match.

Server throws this error… I’m not familiar with the Go programming language, but the MACPayload does seem to contain a FRMPayload in my case. So not sure why it is throwing an error.

 	if ctx.MACPayload.FPort != nil && *ctx.MACPayload.FPort == 0 {
 		if len(ctx.MACPayload.FRMPayload) == 0 {
 			return errors.New("expected mac commands, but FRMPayload is empty (FPort=0)")
 		}
#9

Am I correct in saying that the Lora packet shown here (FPort 0) is supposed to contain MAC commands only (with “valid” CIDs), and that these MAC commands should not be made visible or considered app data ?

Any idea why this sensor would “wrap” its application payload in such a message ? (with an invalid CID = 1)

#10

Yes, when using FPort: 0, the FRMPayload contains mac-commands only (encrypted using the NwkSKey). It is also correct that mac-commands are not exposed to the application layer.

Maybe it is a an implementation error in their firmware? Best would be to contact the device vendor :slight_smile:

#11

Asked the vendor but doubt I’ll get a response soon.

I did notice 3 different behaviours with 3 different LoRaWAN servers:

  • Your LoraServer receives the Lora packet, links it to the device (via device frame logs), but doesn’t forward them upstream to MQTT
  • Things Network receives the Lora packet, links it to the device (device data), forwards it upstream with empty payload
  • MultiTech Conduit Network server receives the Lora packet, links it to the device, and forwards it upstream with the payload

(By the way : I just got a MultiTech conduit gateway today … would be happy to write down my experiences with it on hooking it up to LoraServer, using Lora Gateway Config,… and providing some docs. If you need something specific let me know).

Just for my understanding : Where exactly should I see this FPort 0 MAC message communication ?

  • Is this something that your LoraServer could implement (or already implements) to check device status for example ? (or some actions that could be triggered via the UI)
  • Is it something that a sensor developer comes in contact with ? For example can the sensor developer decide to actively send out periodic LinkCheckReq / DevStatusAns mgs, or is this done at a lower level ?
#12

You could see FPort: 0 frames when manually scheduling mac-commands for example. I also believe that in the current implementation, when the mac-commands don’t fit in the FOpts field (max 15 bytes), it will use FPort: 0 and put these mac-commands in the FRMPayload.

MAC-commands are currently emitted for channel-reconfiguration (e.g. for the US band) and for ADR. In the future you will also be able to configure device-status related mac-commands (so that LoRa Server will request periodically the device status and report these results to LoRa App Server).

#13

Got a response from the sensor supplier where they state that they are not using LoRaWAN put plain Lora to preserve battery (?). Found this rather strange as they have a typical LoRaWAN star based topology with multiple sensors connecting to 1 or more gateways that forwards these messages to the cloud.

Unfortunately Lora / LoraWAN terms are often used synonymously, but am I correct in saying that :

  • The lora sensor just sends RF packets via its radio. These can either be valid LoraWAN messages, or “plain lora” messages,

  • The packet forwarder running on the Lora gateway simply forwards RF packets, regardless if they are Lora or LoRaWAN.

  • The fact that my PHYPayload can be decoded to a structure containing a PHYPayload / MACPayload / FPort / … does that mean the packet was a LoRaWAN packet, or is that just the lorawan server trying to interpret the packet as a lorawan packet.

  • When a LoraWAN server receives packets (forwarded by a packet forwarder), it will interpret them as LoRaWAN messages. It will / can discard them if they are not LoRaWAN compliant ?

  • If a sensor uses ABP (AppsKey / NwkSKey). Is that type of authentication part of the LoRaWAN spec or is that “plain Lora”. If it uses ABP, does it mean it should send LoRaWAN packets instead of plain Lora packets.

#14

Interesting!

LoRa Server has no way to know if a frame is LoRaWAN or not. The input is just a slice of bytes. It will try to decode it (using https://github.com/brocaar/lorawan) and fail as soon as it is unable to interpret the data (as might be happening in your case). In that case the frame is discarded at the network-server.

If they don’t use the LoRaWAN protocol, they still might have taken parts from it. Therefore it is hard to say if ABP means the node implements the full protocol or that they just borrowed that part for encryption.