Packetbroker not routing TTI to TTN - enable off?

Gateways
1

Hi everyone,

I have setup other test / demo TTI gateways fine in the past and the Packetbroker goodness has just… worked.

I have one where some of the sensors are within receiving distance of two gateways. A TTN gateway and a TTI gateway. When I look at the application of the sensors, I can read the data and see which gateways the sensor has been received on. Never the TTI gateway.

Odd I thought, so I can see the DevAddr of the device on TTN so I watch the live traffic on the TTI gateway and yes, the same DevAddr appearing there.

After a bit of checking etc - I start to realise that the TTI gateway isn’t relaying the data into Packetbroker - which is odd, as I say, I’ve done a couple of others and they have just… worked!

I have gone to the settings of the TTI gateway, Share Status within Network is ticked. Share Location with network is ticked.

The Packer Broker option is unticked. If you tick it, you actually disable Packetbroker. However, I have ticked it, clicked save and in the live feed of the gateway you see the text

disable_packet_broker_forwarding

So if I go back and untick the box (and therefore, in theory enabling the Packetbroker), the text in the live data feed reads

disable_packet_broker_forwarding

so I suspect the web GUI front end is not configured quite correct. I have installed TTICLI (used it before to add gateways and delete gateways so moderately familiar with it) and I can see the gateway listed there - but does anyone know the specific gateway command for the CLI to

enable_packet_broker_forwarding

I’ve Googled and ChatGPT’d - I get close- but never quite the prize!

Hope the hive knowledge can help - many thanks in advance.

2

The CLI has a

--disable-packet-broker-forwarding

flag for gateway create & set. But no corresponding enable.

Working on LW Relay testing has led to a complete hot mess of setups & configurations with some misleading UI feedback, so you are not alone.

The best I can think of is to delete the gateway and create a new entry - this will mean you will NOT be able to use the original gateway id so you may have to append some extra digit or character to it. The id ≠ the EUI.

We can comment in more detail with what sort of gateway it is, how it is connected PF or BS and its EUI which appears in public logs so isn’t a security issue to share.

3

The Relay stuff has some quirks in similar vein - there’s a CLI option to add a second channel for Relay comms, but no option to remove it. The only way to get rid of it is a similar way to what is suggested by @descartes.
Feels like some of the developers never worked with it themselves? :man_shrugging:

4

Saucer of milk, table 2 much …

… perhaps best not to bite the hand that gives us the free tech ball-pit of swim wear mud wrestling with complementary hot dogs & beer.

Relay is bleeding edge and desperately needs someone to sweat through the creation of end-devices that can utilise the relay functionality - not many of them around.

And the Packet Broker buttons are definitely esoteric.

As Douglas notes:

“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”

No worse or better than figuring out I2C on a Heltec WiFi LoRa 32.

5

Does the API have the option to enable? Even if the docs are incomplete, you can look at the soruce of ttn-lw-cli to find out how it’s disabling and see whether the API has a boolean. Then you can perhaps get someone to hack the go code to let you force an enable. If the API doesn’t have the option to enable, then you’re probably stuck.

6

An admirable idea, let me just check how many 4 leaf clovers & chickens for sacrifice there are in the garden …

< Read Source Code> < Cross-reference abbreviations > PB = Packet Broker || Protocol Buffers < Trace code> From lorawan-stack-3.34/cmd/ttn-lw-cli/commands/gateways.go to lorawan-stack-3.34/pkg/ttnpb/gateway.pb.go to gateway_flags.pb.go, gateway_json.pb.go, gateway.pb.setters.fm.go and some other stuff.

… so, the answer is yay, it is a boolean. However I’m not sufficiently familiar with Go to figure out what I’ve no doubt is a thing of beauty in design & classing & inheritance and some such so I can’t quite see where it might pickup the boolean and set the field in the SQL (which I can read). Lets travel hopeful.

Boooooooo, CLI doesn’t want to accept a false with some BS about invalid EUI.

To be clear, I can write small app servers in Go for querying back databases, but this stuff is in a whole other league, like the modules in RadioLib. And then the frontend is React which, shudder, shouldn’t have left the confines of FaceAche. But I digress.

So a quick scan up & down, I see there’s an --unset option. So you can have a command like:

ttn-lw-cli gateways set your-gateway-id-here --unset disable-packet-broker-forwarding

So if you do:

ttn-lw-cli gateways get your-gateway-id-here --disable-packet-broker-forwarding

It may / should report a true value. And then you use that first command, just have a strong drink to cope with the cognitive dissonance of issuing a set command that then uses --unset, and then repeat the second command to check to see if it has disappeared. It will not return:

“disable_packet_broker_forwarding”: false

because whilst Google invented Go to be accessible to jobbing programmers and clearly failed, the Protocol Buffers team took it to eleven and any zero, null or false value is dropped when a buffer is constructed, so when it marshalled in to JSON, there is no key to include.

Marshall McCloud says just say no - nothing wrong with Fortran on punched cards - but I guess I’ll have to get off my high horse. :wink: