search

LacunaSpace / basicmac

BasicMAC LoRaWAN stack that supports (but is not limited to) Arduino
Other
76 stars 18 forks source link

Possible incompatibility of example code with TTN v3 stack with all-zero app EUI #30

Closed bertrik closed 3 years ago

bertrik commented 3 years ago

This week I spent several hours trying to figure out why I could not make this stack work with a Cubecell HTCC-AB01. At first suspecting hardware issues (swapping cables/antennas), then configuration issues (incorrect pinmap perhaps). It turned to be an issue with the app EUI / device EUI in the Arduino example code.

I used the Arduino OTAA example code, which has an all-zero app EUI, a simple dev EUI (1) and a random app key. According to the TTNv3 console the AppEUI can indeed be all-zero: the console shows "The AppEUI uniquely identifies the owner of the end device. If no AppEUI is provided by the device manufacturer (usually for development), it can be filled with zeros."

With the provided arduino OTAA example, no data at all is seen in the gateway console. Only when both the device EUI and application EUI are non-zero, do any packets become visible.

I'm not 100% completely sure yet if this is a problem in the device stack (refusing to actually send a message) or in the TTNv3 backend stack (receiving the data but not displaying it). People playing with stack and TTN v3 stack might be interested to know about the behaviour.

matthijskooijman commented 3 years ago

Did you try enabling verbose debug output? That should give you a reasonable idea about whether any TX happened at the radio driver level.

bertrik commented 3 years ago

With APP eui and device EUI both set to zero, verbose mode shows this:

Copyright @ 2019 Heltec Automation.All rights reserved.

Starting

8438: EV_JOINING
00:00:00.135: engineUpdate[opmode=0x4]
00:00:00.139: Uplink join pending
00:00:00.142: Airtime available at 00:00:01.136 (previously determined)
00:00:00.148: Uplink delayed until 00:00:01.136
00:00:01.134: engineUpdate[opmode=0x4]
00:00:01.137: Uplink join pending
00:00:01.140: Airtime available at 00:00:01.136 (previously determined)
00:00:01.146: Ready for uplink
00:00:01.150: Updating info for TX at 00:00:01.139, airtime will be 00:00:00.061, frequency 868.10. Setting available time for band 2 to 8
72641: EV_TXSTART
00:00:01.163: engineUpdate[opmode=0x884]
00:00:01.167: TX[mod=LoRa,sf=7,bw=125,cr=4/5,nocrc=0,ih=0,fcnt=0,freq=868.1,pow=16,len=23]: 0000000000000000000000000000000000998B2C153FAC
78161: EV_TXDONE
00:00:01.251: engineUpdate[opmode=0x884]
00:00:06.245: RX_MODE[mod=LoRa,sf=7,bw=125,cr=4/5,nocrc=1,ih=0,freq=868.1,rxtime=390658]
00:00:06.255: WARNING: rxtime is 284 ticks in the past! (ramp-up time 2 ms / 155 ticks)
00:00:06.268: RX: TIMEOUT
00:00:07.261: RX_MODE[mod=LoRa,sf=12,bw=125,cr=4/5,nocrc=1,ih=0,freq=869.5,rxtime=454150]
00:00:07.271: WARNING: rxtime is 290 ticks in the past! (ramp-up time 2 ms / 156 ticks)
00:00:07.472: RX: TIMEOUT
00:00:07.474: Scheduling next join at 00:00:09.578
00:00:09.582: engineUpdate[opmode=0x4]
00:00:09.585: Uplink join pending
00:00:09.588: Airtime available at 00:00:09.582 (previously determined)
00:00:09.594: Ready for uplink
00:00:09.598: Updating info for TX at 00:00:09.586, airtime will be 00:00:00.061, frequency 868.30. Setting available time for band 2 to 16
600638: EV_TXSTART
00:00:09.611: engineUpdate[opmode=0x884]
00:00:09.615: TX[mod=LoRa,sf=7,bw=125,cr=4/5,nocrc=0,ih=0,fcnt=0,freq=868.3,pow=16,len=23]: 000000000000000000000000000000000098B23A67B694
606164: EV_TXDONE
00:00:09.699: engineUpdate[opmode=0x884]
00:00:14.693: RX_MODE[mod=LoRa,sf=7,bw=125,cr=4/5,nocrc=1,ih=0,freq=868.3,rxtime=918662]
00:00:14.703: WARNING: rxtime is 284 ticks in the past! (ramp-up time 2 ms / 155 ticks)
00:00:14.716: RX: TIMEOUT
00:00:15.709: RX_MODE[mod=LoRa,sf=12,bw=125,cr=4/5,nocrc=1,ih=0,freq=869.5,rxtime=982154]
00:00:15.719: WARNING: rxtime is 290 ticks in the past! (ramp-up time 2 ms / 155 ticks)
00:00:15.920: RX: TIMEOUT
00:00:15.922: Scheduling next join at 00:00:30.552

So it looks like the TX is happening, I see no warnings or error messages. I don't know if the TX actually happens, I have not checked with an SDR or anything like that.

matthijskooijman commented 3 years ago

I would expect it does, IIRC it's the radio driver that prints:

00:00:09.615: TX[mod=LoRa,sf=7,bw=125,cr=4/5,nocrc=0,ih=0,fcnt=0,freq=868.3,pow=16,len=23]: 000000000000000000000000000000000098B23A67B694

And that just pushes the printed bytes into the radio, without really knowing anything about what those bytes mean. So unless a large run of zeroes is somehow problematic, I would think that this should just transmit as normal.

Any chance of checking on your gateway for incoming traffic?

bertrik commented 3 years ago

No, I have no way of checking this. The gateway is a TTIG still connected on "v2". The TTN v2 console view is known to be buggy (grrr).

mkuyper commented 3 years ago

The LMiC stack does not place any restrictions on the EUIs used. As can be seen in the join-request that is being transmitted above, it is perfectly happy to use an all-zero DevEUI and JoinEUI -- the long run of zeroes are the MHdr which is 0x00 for JREQ, followed by the 2 all-zero EUIs:

>>> loramsg.unpack_jreq(bytes.fromhex('000000000000000000000000000000000098B23A67B694'))
{'msgtype': 'jreq', 'MHdr': 0, 'JoinEUI': <Eui: 00-00-00-00-00-00-00-00>, 'DevEUI': <Eui: 00-00-00-00-00-00-00-00>, 'DevNonce': 45720, 'MIC': -1799985350}

However, it should be noted that an all-zero EUI is a reserved value. IEEE states in the RA Guidelines for the use of EUIs:

The all-zeros EUI-48 value (00-00-00-00-00-00) and EUI-64 value (00-00-00-00-00-00-00-00), though assigned to an organization, have not been and will not be used by that assignee as an EUI. (They can be considered as assigned to the IEEE Registration Authority.) The all-ones 48-bit value (FF-FF-FF-FF-FF-FF) and 64-bit value (FF-FF-FF-FF-FF-FF-FF-FF) are IEEE 802 multicast (group) MAC addresses indicating all stations on a network. These all-ones values are not valid EUIs.

Some back-end systems may use these reserved values to have special meaning, such as not set or unknown. For this reason, I would not recommend using these values as either DevEUI or JoinEUI as a general rule.

bertrik commented 3 years ago

I understand, thank you for the explanation.

In the end, it's a rather unfortunate set of circumstances:

This issue was opened partly out of frustration having spent so much time on essentially a misunderstanding. It can be closed now.