TTN Mapper with T-Beam V1.2

End Devices (Nodes) Hardware
,
21 
/home/user/.arduino15/packages/esp32/tools/esp-x32/2302/bin/../lib/gcc/xtensa-esp32-elf/12.2.0/../../../../xtensa-esp32-elf/bin/ld: /home/user/.arduino15/packages/esp32/tools/esp32-arduino-libs/idf-release_v5.1-632e0c2a/esp32/lib/libpp.a(hal_mac.o): in function `hal_init':
(.text.hal_init+0x40): multiple definition of `hal_init'; /home/user/.cache/arduino/sketches/E368F9F09813AEAD7DF6AA9E4EE4B471/libraries/arduino-lmic-4.1.0/hal/hal.cpp.o:/home/maxi/Arduino/libraries/arduino-lmic-4.1.0/src/hal/hal.cpp:416: first defined here
collect2: error: ld returned 1 exit status

exit status 1

Compilation error: exit status 1

This is a problem with conflicting names., issue ESP32 is failing regression tests ¡ Issue #966 ¡ mcci-catena/arduino-lmic ¡ GitHub. It was fixed in V5. Try using v5.0.1, which is current, and which I know people are using on ESP32.

1 Like
22

Has it been changed to cope with all zeros - a convenient solution to TTS v3 that now asks for a Join EUI up front?

Will endeavour to get myself up to date on v5 over the break.

PS, we had a brief chat at the TTN conference - always feels good to have colleagues around the globe!

23

Has it been changed to cope with all zeros?

If “it” refers to the LMIC, it turns out it wasn’t broken. The Semtech-protocol packet fowarder for the MultiTech was dropping JoinRequests with AppEUI == 0, and by sheer bad luck, the reporter and we at MCCI were all using MultiTech. So I mistakenly thought that the LMIC was broken. Changing the MultiTech gateway to use basic station solves the problem.

Embarassingly, the gateways run by TTN New York are all MultiTechs and the most are still on packet forwarder. But this won’t affect users in Europe!

Yes, I remember we met, hope all is well & best wishes for Yuletide & 2025!

24

Updating to the release of packet forwarder released two years ago will fix it as well. And that will be the better option for MultiTech gateways with old concentrator cards as you need new hardware for basics station. Or consider replacing the gateways as my two MultiTech gateways from 2015 both died over the last year. (Flash worn out)

25

Given that the gateway shows valid data that seems unlikely.

Which packet forwarder are you using on the gateway?

26

Updating to the release of packet forwarder released two years ago will fix it as well.

Yes, I’d forgotten that, but that’s true. Thanks!

27

Hi!

I have established a secure uplink connection on my MikroTik with the following configurations:

  • Address: eu1.cloud.thethings.network
  • Protocol: LNS
  • Port 8887
  • API Key: yes
  • SSL: yes
28

Small update

I have tested the project TTGO T-Beam Tracker for The Things Network again.
The display seems to work, only the display for the battery does not work.
Apparently a new library has to be implemented.

But GPS reception is there, the time has been determined and a location is available after a few minutes.
grafik

The display shows the current position data quite quickly every 20 seconds.
These values can then be recognized:

Latitude: 48.XXXXXXXX
Longitude: 8.XXXXXXXX
Error: 1.00m
Message queued

I think “error” means as much as accuracy.
1.00m varies from 0.9m to 1.9m

But well, joining the LoRa network still doesn’t work.

29

Just for fun, I created a device that starts with FF FF FF FF FF as JoinEUI and DevEUI.
I left the AppKey the same.
I always get this as live data from the TTN console:

{
  "name": "ns.up.join.cluster.fail",
  "time": "2024-12-24T14:54:35.988300079Z",
  "identifiers": [
    {
      "device_ids": {
        "device_id": "t-beam-ffff",
        "application_ids": {
          "application_id": "t-beam-ttn-mapper-1337"
        },
        "dev_eui": "FFFFFFFFD006D09E",
        "join_eui": "FFFFFFFFB0FA710D"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
    "namespace": "pkg/joinserver",
    "name": "mic_mismatch",
    "message_format": "MIC mismatch",
    "correlation_id": "e4be615ef13b4844afae02203544c0a6",
    "code": 3
  },
  "correlation_ids": [
    "gs:uplink:01JFWJK8YAE98MRDHYZ2WNNRK2"
  ],
  "origin": "ip-10-100-7-169.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_APPLICATION_TRAFFIC_READ"
    ]
  },
  "unique_id": "01JFWJK8YMN6NATR733YCRZ3VY"
}

The live data console of the device with the correct data remains completely empty.

30

Can you try with the non secure packet forwarder on the MikroTik.

Don’t delete the gateway! Just change the settings on TTN that require authentication and on the MikroTik change the settings so it uses the non secure version (with UDP port 1700).

1 Like
31

Hi!
I unchecked the “Require authenticated connection” and changed the server to eu1 UDP port 1700.
Aaaaaaaand CONNECTED!

In fact, the T-Beam has now managed to register with the network.
Apparently something is totally messed up with the encryption.

1 Like
32

Probably not as much the encryption but more like the way the data structures are populated.

Anyway, glad you made progress.

2 Likes
33

I just went for a little walk and switched the gateway back to LNS beforehand.
The T-Beam was able to connect properly again and delivered the correct data to TTN.

So let’s make a note:

  • T-Beam V1.2 can only join the network unencrypted
  • After successful joining, the uplink of the gateway can be encrypted again
  • The T-Team with the project TTGO T-Beam Tracker for The Things Network only sends data if a GPS signal is available
  • The battery info doesn’t work, but that’s not bad for now

Thanks to everyone for your tips so that the little project / I can now walk over Christmas.

First of all, Merry Christmas to all :christmas_tree:

34

Given that this forum feature high up in Google results, for clarity:

This is for all devices everywhere, it is not specific to the T-Beam.

And it’s not the device that chooses this, but the firmware.

And it’s NOT even LMIC that can only join the network unencrypted, it’s all LW firmware on all devices.

And it is ONLY the Join Request that is unencrypted, the Join Accept IS encrypted.

It HAS to be this way because if the join request was encrypted the key used to encrypt the message would have to be public and would have to be the same for every device in the world which rather defeats the point.

Once the LNS has looked up the details of the device using the Join EUI & Device EUI, it then knows the AppKey setup for that device which it can use to encrypt the Join Accept. So only the device can decrypt the response. The JA provides information to generate a new set of keys specific to the session which are used for encryption of further up & downlinks.

This is a summary, the Join EUI can do more that just match and with LW 1.1 there are actually two keys.

For those thinking of trying to brute-force crack a Join Accept that is AES-128 encrypted, in 2023 I asked a university dept if it could use its cluster to have a go. They said they could but it was pointless as it would take them days to run on their hardware and if I tried to setup a rig with lots of high end graphics cards to do it, I’d be looking at months and a huge electricity bill.

35

I don’t think we’re talking encryption on the node but rather the MikroTik gateway to TTN.

36

No, neither do I, but the Google indexer doesn’t do context and ChatGPT is mostly wrong.