MAC command DeviceTimeReq supported?


(Verkehrsrot) #1

With this pull request network time support as specified in LoRaWAN 1.0.3 was integrated in the LMIC stack maintained by MCCI.

I tried this on TTN, but was not yet successful getting a time from the network.

I’m not sure if this is a gateway issue, or a network issue. So my question is:

Has TTN the new MAC commands DeviceTimeReq / DeviceTimeAns implemented?


#2

MAC commands are processed by the back-end, not the gateway

see https://github.com/kersing/packet_forwarder/issues/25


(Verkehrsrot) #3

Tested it. If i send a MAC command 0x0D (DeviceTimeReq), i don’t see an answer to it from the network. So i assume TTN does not support DeviceTimeReq (yet)?


#4

maybe @htdvisser can shed some light on this… will it be implemented in the upcoming V3 ? :roll_eyes:


(Hylke Visser) #5

Yes, it will be in v3


(Verkehrsrot) #6

So that means that it is not implemented in current V2?


Cannot see data in device dashboard, while OTAA works and uplinks show in gateway's traffic
(Hylke Visser) #7

Correct


(Arjan) #8

As an aside: the V2 stack is open source :wink:

https://github.com/TheThingsNetwork/ttn/blob/v2.10.0/core/networkserver/uplink_mac.go shows nothing that relates to this. Of course, it could be hidden elsewhere, but as this uses https://github.com/brocaar/lorawan/blob/master/mac_commands.go, one can peek into that code to reveal the name would be just as expected:

DeviceTimeReq       CID = 0x0D
DeviceTimeAns       CID = 0x0D

Hence, it’s safe to assume that a search for DeviceTimeReq in the ttn repository would return some results, if implemented.

That said, @htdvisser, the V3 stack is still closed, right?


MAC commands on TTN Server
(Arjan) #9

Do you remember if the packet with the unsupported DeviceTimeReq MAC command still make it to the application’s Data page in TTN Console?

(If it did not, then that might explain Cannot see data in device dashboard, while OTAA works and uplinks show in gateway’s traffic. But given the empty default in the code I’d assume that unsupported commands would just be ignored. It should then probably stop processing subsequent commands too though, as for unsupported MAC commands the server would not know if those provided any payload for such command; issue #748.)


(Verkehrsrot) #10

The packet was not displayed in console, what also means that a payload with embedded unsupported MAC command in FOpts field will get lost.


Cannot see data in device dashboard, while OTAA works and uplinks show in gateway's traffic