Why device activation record not generated after an OTTA device's join request has been accepted?

ax003d · January 8, 2019, 3:35pm

Hello,

One of my OTTA device’s join request has been accepted by LoRa app server, but it hasn’t sent any uplink data yet.
In this case, there is no device activation record generated in loraserver_as database, and when I try to send downlink data to the device, it will be in the queue, and not sent by the network server.

I wonder why it designed like this.
Doesn’t it mean an OTTA device is activated after the join request accepted?
And since there is at least one gateway has accepted the join request from the OTTA device, so the network server should know which gateway to use to send downlink data to the device, but why the downlink data is kept in the queue instead of being sent?

Thank you very much!

brocaar · January 8, 2019, 4:46pm

This is by design. On the first received uplink, LoRa Server will inform the application-server (LoRa App Server) that the security context of the device has changed. In other words, on the first received uplink frame, it will send the (encrypted when using a KEK) AppSKey to LoRa App Server.

ax003d · January 9, 2019, 1:41am

I see. Then there is a problem.

Say I have one OTTA device joined the network, and has sent at least one package of uplink data.
So the lora-app-server has one device activation record.

Now the device restarted, and joined the network, but has not sent uplink data yet.
I call the downlink data API, and the data will be encrypt with the appskey from the last activation record, and push into the device downlink queue.

The device sends a package of uplink data now, and a new device activation record include a new appskey is created.
Since there is downlink data in the device queue, the loraserver will send it to the device. But the data has been encrypted with the old appskey, so the device cannot decrypt it correctly.

So maybe we should flush the device downlink queue when the first uplink data is received after an OTTA device join the network?

brocaar · January 9, 2019, 8:40am

I think you mean flush the downlink queue after LoRa Server has received the first uplink frame after an OTAA and is about to inform LoRa App Server about the new security context?

You might be right that there is currently a short time-window where LoRa App Server is able to enqueue downlink items with an old invalid AppSKey. The context signaling happens here:

github.com

brocaar/chirpstack-network-server/blob/master/internal/uplink/data/data.go#L431


      
          		}
          
          		// Re-create device-queue items.
          		// Note that the CreateDeviceQueueItem function will take care of setting
          		// the Class-B ping-slot timing.
          		if err := storage.Transaction(func(tx sqlx.Ext) error {
          			items, err := storage.GetDeviceQueueItemsForDevEUI(ctx.ctx, tx, ctx.DeviceSession.DevEUI)
          			if err != nil {
          				return errors.Wrap(err, "get device-queue items error")
          			}
          
          			if err := storage.FlushDeviceQueueForDevEUI(ctx.ctx, tx, ctx.DeviceSession.DevEUI); err != nil {
          				return errors.Wrap(err, "flush device-queue for deveui error")
          			}
          
          			for _, item := range items {
          				if err := storage.CreateDeviceQueueItem(ctx.ctx, tx, &item, ctx.DeviceProfile, ctx.DeviceSession); err != nil {
          					return errors.Wrap(err, "create device-queue item error")
          				}
          			}

I think an extra step might be required that before sending the uplink to the AS, it will check if the ctx.DeviceSession.AppSKeyEvelope is present, it flushes the downlink queue. I believe we should do this before calling the AS, as when calling asClient.HandleUplinkData, the AS might directly send a downlink (depending the AS implementation).

That would still leave a small window for scheduling downlinks using an invalid AppSKey, but I don’t think you can avoid this.

ax003d · January 9, 2019, 2:16pm

Yes, you got it.

The time-window is depended on the OTAA device implementation, if it sends uplink data in a several hours interval, then this time-window would be several hours.

This window is very small, I think it is acceptable.