Tektelic gateway does not handle txpk with custom brd + ant fields (set by LoRa Gateway Bridge)

Hi brocaar!

I have strange behavior of TEKTELIC gateway in combination with microchip rn2483 and your lora-gateway-bridge,lora-app-server.
I have setup from ubuntu repo provided by you.

When I’m using loriot network server and app-server then my gateway transmits response of otaa-join. And after that I can send regular data with my device.

But when I’m using loraserver setup otaa-join fails and I can’t send regular packets with my device.
Is it a bug at gateway or something else?
Please help to figure out.

Tektelic gateway is MyGlobalIp, ports 9999/9999
loraserver setup 192.168.5.5

I’m using udp proxy with nginx.

Here the dump from loriot:
request/response:

19:03:21.748673 IP 192.168.5.199.49154 > MyGlobalIp.9999: UDP, length 243 E.........S.....^.<...'....z....d.....@.{"rxpk":[{"time":"2018-01-16T19:03:21.000000Z","tmst":2487806091,"chan":0,"rfch":1,"freq":868.100000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.5,"rssi":-47,"size":23,"data":"AF0KANB+1bNwAFgcAAyjBABBLlXsLow="}]}
19:03:21.966903 IP MyGlobalIp.9999 > 192.168.5.199.49154: UDP, length 4 E.. 0.@.@..Y^.<.....'.....a..... 19:03:22.178436 IP MyGlobalIp.9999 > 192.168.5.199.49155: UDP, length 198 E...1.@.@...^.<.....'.....bX....{"txpk":{"tmst":2492806091,"freq":868.1,"rfch":0,"powe":14,"modu":"LORA","ipol":true,"datr":"SF7BW125","size":33,"data":"IIWrLvxFecRwgd7EoXbUpXPgzqeOHkPfdISP6SGe1Kcs","imme":false,"codr":"4/5"}}

send of regular data:
19:04:30.742756 IP 192.168.5.199.49154 > MyGlobalIp.9999: UDP, length 235 E.........S.....^.<...'...$@....d.....@.{"rxpk":[{"time":"2018-01-16T19:04:30.000000Z","tmst":2556808707,"chan":1,"rfch":1,"freq":868.300000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":9.0,"rssi":-46,"size":17,"data":"QLdNEUgAAQAte+Ce73CcS2E="}]}

pretty print of otaa-join loriot request/response:

{
“rxpk”: [
{
“time”: “2018-01-16T19:03:21.000000Z”,
“tmst”: 2487806091,
“chan”: 0,
“rfch”: 1,
“freq”: 868.1,
“stat”: 1,
“modu”: “LORA”,
“datr”: “SF7BW125”,
“codr”: “4/5”,
“lsnr”: 9.5,
“rssi”: -47,
“size”: 23,
“data”: “AF0KANB+1bNwAFgcAAyjBABBLlXsLow=”
}
]
}

{
“txpk”: {
“tmst”: 2492806091,
“freq”: 868.1,
“rfch”: 0,
“powe”: 14,
“modu”: “LORA”,
“ipol”: true,
“datr”: “SF7BW125”,
“size”: 33,
“data”: “IIWrLvxFecRwgd7EoXbUpXPgzqeOHkPfdISP6SGe1Kcs”,
“imme”: false,
“codr”: “4/5”
}
}

And here with loraserver setup:

19:05:53.240180 IP 192.168.5.199.49154 > MyGlobalIp.9999: UDP, length 243 E.........S.....^.<...'...#W..0.d.....@.{"rxpk":[{"time":"2018-01-16T19:05:52.000000Z","tmst":2639304043,"chan":2,"rfch":1,"freq":868.500000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":7.0,"rssi":-43,"size":23,"data":"AF0KANB+1bNwAFgcAAyjBAC4MOWL6ow="}]}
19:05:53.242404 IP MyGlobalIp.9999 > 192.168.5.199.49154: UDP, length 4 E.. x{@.@.'.^.<.....'.....a...0.
19:05:53.615516 IP MyGlobalIp.9999 > 192.168.5.199.49155: UDP, length 194 E...x.@.@._.^.<.....'.....bT....{"txpk":{"imme":false,"tmst":2644304043,"freq":868.5,"rfch":0,"powe":14,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":true,"size":17,"data":"IOGbxyNJucfqHxjNJ4H0Qr0=","brd":0,"ant":0}}

{
“rxpk”: [
{
“time”: “2018-01-16T19:05:52.000000Z”,
“tmst”: 2639304043,
“chan”: 2,
“rfch”: 1,
“freq”: 868.5,
“stat”: 1,
“modu”: “LORA”,
“datr”: “SF7BW125”,
“codr”: “4/5”,
“lsnr”: 7,
“rssi”: -43,
“size”: 23,
“data”: “AF0KANB+1bNwAFgcAAyjBAC4MOWL6ow=”
}
]
}

{
“txpk”: {
“imme”: false,
“tmst”: 2644304043,
“freq”: 868.5,
“rfch”: 0,
“powe”: 14,
“modu”: “LORA”,
“datr”: “SF7BW125”,
“codr”: “4/5”,
“ipol”: true,
“size”: 17,
“data”: “IOGbxyNJucfqHxjNJ4H0Qr0=”,
“brd”: 0,
“ant”: 0
}
}

Logs of lora-app-server:
Jan 16 19:05:53 lorawan lora-app-server[1386]: time="2018-01-16T19:05:53Z" level=info msg="js: request received" message_type=JoinReq receiver_id=70b3d57ed0000a5d sender_id=010203 transaction_id=62012072 Jan 16 19:05:53 lorawan lora-app-server[1386]: time="2018-01-16T19:05:53Z" level=info msg="device-keys updated" dev_eui=MyNodeId Jan 16 19:05:53 lorawan lora-app-server[1386]: time="2018-01-16T19:05:53Z" level=info msg="device-activation created" dev_eui=MyNodeId id=121 Jan 16 19:05:53 lorawan lora-app-server[1386]: time="2018-01-16T19:05:53Z" level=info msg="handler/mqtt: publishing join notification" topic="application/1/node/MyNodeId/join" Jan 16 19:05:53 lorawan lora-app-server[1386]: time="2018-01-16T19:05:53Z" level=info msg="js: sending response" message_type=JoinAns receiver_id=010203 result_code=Success sender_id=70b3d57ed0000a5d transaction_id=62012072
Logs of lora-gateway-bridge:

Jan 16 19:05:53 lorawan lora-gateway-bridge[1375]: time="2018-01-16T19:05:53Z" level=info msg="backend: publishing packet" topic="gateway/REMOVED/rx" Jan 16 19:05:53 lorawan lora-gateway-bridge[1375]: time="2018-01-16T19:05:53Z" level=info msg="gateway: sending udp packet to gateway" addr=192.168.5.1:39267 protocol_version=1 type=PushACK Jan 16 19:05:53 lorawan lora-gateway-bridge[1375]: time="2018-01-16T19:05:53Z" level=info msg="backend: packet received" topic="gateway/REMOVED/tx" Jan 16 19:05:53 lorawan lora-gateway-bridge[1375]: time="2018-01-16T19:05:53Z" level=info msg="gateway: sending udp packet to gateway" addr=192.168.5.1:45405 protocol_version=1 type=PullResp Jan 16 19:05:54 lorawan lora-gateway-bridge[1375]: time="2018-01-16T19:05:54Z" level=info msg="gateway: received udp packet from gateway" addr=192.168.5.1:53889 protocol_version=1 type=PullData

1 Like

From the first view, the rxpk and txpk looks fine. The downlink happens on the same frequency and data-rate as the uplink and the tmst is incremented by 5 seconds.

Are you sure this is not a networking issue? You wouldn’t be the first having issues with the UDP protocol. E.g. when using DigitalOcean, it doesn’t work with an Floating IP (https://blog.digitalocean.com/floating-ips-start-architecting-your-applications-for-high-availability/), but it does work when using the direct IP of the machine.

Best would be to debug from the side of your gateway, to confirm if the downlink TX is actually received by the gateway. For more info about debuggin: https://docs.loraserver.io/lora-gateway-bridge/install/debug/.

I’m sure that gateway receives packet. I’ve tested that without udp proxy. And udp proxy works fine with loriot.
Tcpdump that provided is from the same subnet as a tectelik gateway.

Was a little name lookup issue with view in deleted message.
Local network only. without proxy.

root@lorawan:/home/user# tcpdump -AUqn -i eth0 port 1700
20:44:41.465623 IP 192.168.5.199.49154 > 192.168.5.5.1700: UDP, length 242
E…,…&.d…@.{“rxpk”:[{“time”:“2018-01-16T20:44:41.000000Z”,“tmst”:193867467,“chan”:0,“rfch”:1,“freq”:868.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:9.5,“rssi”:-46,“size”:23,“data”:“AF0KANB+1bNwAFgcAAyjBABfLXd6GnM=”}]}
20:44:41.467215 IP 192.168.5.5.1700 > 192.168.5.199.49154: UDP, length 4
E… J.@.@.c…:…&.
20:44:41.815206 IP 192.168.5.5.1700 > 192.168.5.199.49155: UDP, length 193
E…J.@.@.c…{“txpk”:{“imme”:false,“tmst”:198867467,“freq”:868.1,“rfch”:0,“powe”:14,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“ipol”:true,“size”:17,“data”:“ICHcbG6KZi1Hy4yQwSwKiys=”,“brd”:0,“ant”:0}}
20:44:45.435817 IP 192.168.5.199.49155 > 192.168.5.5.1700: UDP, length 12
E…(.-…/{…?..d…@…
20:44:45.436415 IP 192.168.5.5.1700 > 192.168.5.199.49155: UDP, length 4
E… L.@.@.b…:…

Jan 16 20:44:41 lorawan lora-app-server[1386]: time=“2018-01-16T20:44:41Z” level=info msg=“js: request received” message_type=JoinReq receiver_id=70b3d57ed0000a5d sender_id=010203 transaction_id=3359770217
Jan 16 20:44:41 lorawan lora-app-server[1386]: time=“2018-01-16T20:44:41Z” level=info msg=“device-keys updated” dev_eui=REMOVED
Jan 16 20:44:41 lorawan lora-app-server[1386]: time=“2018-01-16T20:44:41Z” level=info msg=“device-activation created” dev_eui=REMOVED id=126
Jan 16 20:44:41 lorawan lora-app-server[1386]: time=“2018-01-16T20:44:41Z” level=info msg=“handler/mqtt: publishing join notification” topic=“application/1/node/REMOVED/join”
Jan 16 20:44:41 lorawan lora-app-server[1386]: time=“2018-01-16T20:44:41Z” level=info msg=“js: sending response” message_type=JoinAns receiver_id=010203 result_code=Success sender_id=70b3d57ed0000a5d transaction_id=3359770217

Jan 16 20:44:41 lorawan lora-gateway-bridge[1375]: time=“2018-01-16T20:44:41Z” level=info msg=“gateway: received udp packet from gateway” addr=192.168.5.199:49154 protocol_version=1 type=PushData
Jan 16 20:44:41 lorawan lora-gateway-bridge[1375]: time=“2018-01-16T20:44:41Z” level=info msg=“gateway: rxpk packet received” addr=192.168.5.199:49154 data=“AF0KANB+1bNwAFgcAAyjBABfLXd6GnM=” mac=REMOVED
Jan 16 20:44:41 lorawan lora-gateway-bridge[1375]: time=“2018-01-16T20:44:41Z” level=info msg=“backend: publishing packet” topic=“gateway/REMOVED/rx”
Jan 16 20:44:41 lorawan lora-gateway-bridge[1375]: time=“2018-01-16T20:44:41Z” level=info msg=“gateway: sending udp packet to gateway” addr=192.168.5.199:49154 protocol_version=1 type=PushACK
Jan 16 20:44:41 lorawan lora-gateway-bridge[1375]: time=“2018-01-16T20:44:41Z” level=info msg=“backend: packet received” topic=“gateway/REMOVED/tx”
Jan 16 20:44:41 lorawan lora-gateway-bridge[1375]: time=“2018-01-16T20:44:41Z” level=info msg=“gateway: sending udp packet to gateway” addr=192.168.5.199:49155 protocol_version=1 type=PullResp
Jan 16 20:44:45 lorawan lora-gateway-bridge[1375]: time=“2018-01-16T20:44:45Z” level=info msg=“gateway: received udp packet from gateway” addr=192.168.5.199:49155 protocol_version=1 type=PullData
Jan 16 20:44:45 lorawan lora-gateway-bridge[1375]: time=“2018-01-16T20:44:45Z” level=info msg=“gateway: sending udp packet to gateway” addr=192.168.5.199:49155 protocol_version=1 type=PullACK
Jan 16 20:44:50 lorawan lora-gateway-bridge[1375]: time=“2018-01-16T20:44:50Z” level=info msg=“gateway: received udp packet from gateway” addr=192.168.5.199:49155 protocol_version=1 type=PullData
Jan 16 20:44:50 lorawan lora-gateway-bridge[1375]: time=“2018-01-16T20:44:50Z” level=info msg=“gateway: sending udp packet to gateway” addr=192.168.5.199:49155 protocol_version=1 type=PullACK

After that I can’t send regular packets…

Do you know which packet-forwarder version is installed on the gateway (and is it running the latest firmware)? When the packet-forwarder implements v2 of the PROTOCOL.txt the packet-forwarder will give an ACK or nACK (with an error description).

I don’t have experience with the Tektelic gateway, but it would be helpful to either see the ACK / nACK (I suppose this information is not available as else you probably would already have found this feedback) or to see the gateway / packet-forwarder logs.

Lets assume the UDP frame arrives at the gateway, it could be that it doesn’t implement the PROTOCOL.txt completely (maybe it is expecting some additional fields and Loriot knows how to deal with it?) or a scheduling error occurs for whatever reason we don’t know.

I would first confirm that the gateway is actually transmitting the requested frame.

Seems like no radio transmission from gateway. (Was checking with dvbt2-based spectrum analyzer.) Difficult to intercept such small transmissions with the antenna…
And I have no additional info about gateway. Will try to ask a local distributor for a new firmware.

With your realization only difference I’ve found is additional fields:
“brd”: 0,
“ant”: 0

Bytheway I can’t find such fields at PROTOCOL.txt

BUG: confirmed, that with disabled “brd” and “ant” system works.
So Tektelic pico gateway doesn’t like non-standard fields. I think it should be configurable.
Regards,
Volodymyr.
P.S. Thank you for your software.

I also face strange behaviour with a Libelium node (RN2483 chip) and loraserver. Everything is ok when I use the loriot server so I am trying to understand what is going on. I will take a look at the vms’s suggestion.

Well, the issues that I face are different than the inability to have gateway transmissions like vms’.
The most important issue is the change at the join procedure that the node follows.

  1. If it has used the loriot server previously and you perform a reset at a distance from the gateway, it then gradually lowers the data rate (SF7 all the way to SF12) in order to join successfully.
  2. If it has used the loraserver previously and you perform a reset at a distance from the gateway, the data rate gets stuck (SF7 and then SF9 forever) and it never reaches the gateway.

Do you have any idea about what could cause this erroneous behaviour ? Thank you…
(Notice that I have no access to the node’s code, consider this as a RN2483 black box with ADR: true.)

@thanospetr lets not mix issues in one topic :slight_smile: This is totally different than the issue mentioned @vms

FIXED.
Tectelik in new firmware has fixed that bug. Now all works as expected!
Thank you, brocaar!

1 Like

Hi @vms @brocaar we have the latest firmware updated in our tektelic gateway but we are still getting “None” error in txpk gateway. I request you to let me know how we can solve it?

Please share what exact version you mean with latest :slight_smile: