packet_forwarder
packet_forwarder copied to clipboard
Join packets with JoinEUI of 00-00-00-00-00-00-00-00
Should this be here or on the multitech-installer repo?
In order to ease the transition to TTN v3, we've updated endpoint software to use a JoinEUI of all zeros.
This works fine on Basic Station (RAK7258, Multitech Conduit, Multitech Conduit A/P.
However this does not work on a Multitech Conduit with mp-packet-forwarder_3.0.25-r2_arm926ejste.ipk installed. The join packets are silently discarded. Nothing received on the TTN end and nothing in the local log file.
Thanks.
Jeff
I also ran into this. These all-zero AppEUI joins are received by the concentrator according to the debug output, but never forwarded to the network.
I am using a self-compiled version about two years old. Git master of this repo has not moved since, but maybe some of the subrepos have. I was using these versions:
root@mjs-gateway-5:/opt/ttn-gateway/dev# for i in *; do (cd $i; echo -n "$i: "; git describe --tags --always); done
lora_gateway: 4d8f57f
packet_forwarder: e84e9a3
paho.mqtt.embedded-c: v1.0.0-64-ge4e0402
protobuf: v3.11.4-214-ged5c874de
protobuf-c: v1.2.1-1-g63c78ee
ttn-gateway-connector: 10bfae4
Can you please disable the 'if' at ttn_transport.c line 510 and try again?
That looks like a likely culprit indeed: https://github.com/kersing/packet_forwarder/blob/e84e9a38d3c5deeaf6792b1e77449cf119cd542b/mp_pkt_fwd/src/ttn_transport.c#L510
I don't have a dev setup at hand right now, but I'll try to find a bit of time soon to try that change.
My dev setup has an USB concentrator that requires this check in order not to flood TTN with garbage data. :-(
Hey, I finally gotten around to testing your fix, I see you've already committed it to master. For me, this solves the problem and so far the one gateway I tested this on (Lorank-8/Larank-8) seems to be running fine (for a few hours now).
Thanks!
I've tested extensively and the USB concentrators are running fine as well with the low level library I'm using so this one is fixed.
Thanks!