Agent device data item id prefix is non-sensical

[robot-ranger]

What is the prefix on the dataitems of the agent device? and how is it generated?

It looks like MQTT adapter uses a sensible prefix: mqtt client id:

Can we give the SHDR adapters a more sensible prefix? maybe the device uuid or name they are associated with?

[wsobel]

It looks like there was a mistake in some of the code. The prefix is based on the identity of the adapter, which should be one of two versions based on SuppressIPAddress configuration variable:

1. "_" + server + "_" + port example: _localhost_7878
2. "_" + sha1digest("_" + server + "_" + port)[0..10]

The other option is to specify it directly using AdapterIdentity.

The reason was a security concern raised by some companies that didn't want the IP addresses of the adapter exposed. It was supposed to be optional and have effect all the way down. I'll add a fix in version 2.2.0.15 with the MQTT source changes.

[robot-ranger]

Awesome.
I actually remember seeing that issue and the resolution about security, but i guess my keyword searching wasnt strong enough today.
AdapterIdentity is fine for me, just didnt know it existed.

ETA: i said i was going to close this, but ill keep it open and add more to the readme in my PR. these issues can close when the PR goes.

[robot-ranger]

It looks like there was a mistake in some of the code. The prefix is based on the identity of the adapter, which should be one of two versions based on SuppressIPAddress configuration variable:

1. `"_" + server + "_" + port` example: `_localhost_7878`

2. `"_" + sha1digest("_" + server + "_" + port)[0..10]`

The other option is to specify it directly using AdapterIdentity.

The reason was a security concern raised by some companies that didn't want the IP addresses of the adapter exposed. It was supposed to be optional and have effect all the way down. I'll add a fix in version 2.2.0.15 with the MQTT source changes.

Added to my PR : #367

[robot-ranger]

Maybe AdapterIdentity can be used to generate MqttClientId?

[wsobel]

I still have a task to verify if a random client id is being generated if not specified. If it is not generated, why not. And what mqtt_cpp is using as its generator. I thought it used the machine ip and port (unique). I’ll get back once I investigate the code a bit more.

…

On Nov 20, 2023, at 15:37, robot-ranger ***@***.***> wrote: Maybe AdapterIdentity can be used to generate MqttClientId? — Reply to this email directly, view it on GitHub <#368 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ6BCLM5UJ46SRO3RV62MTYFPSTTAVCNFSM6AAAAAA7TTSU3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJZHE3TOMBYGE>. You are receiving this because you commented.

[robot-ranger]

I still have a task to verify if a random client id is being generated if not specified. If it is not generated, why not. And what mqtt_cpp is using as its generator. I thought it used the machine ip and port (unique). I’ll get back once I investigate the code a bit more.

...oh? turns out, host:port for both my sink and source are the same (localhost:1883) !, so they are the same client id? go figure.

I suppose a remote broker is the same issue - host:port is the same for both sink and adapter

[wsobel]

It is the same address we’re connecting to. I thought it was using the local port (client port number) which is assigned randomly and will not repeat. It turns out we are creating it ourselves with a non-unique address. You can automate it by setting it after the initial connection. The code is in the redboltz mqtt_cpp endpoint module. I need to see if we are doing something unnecessary. Otherwise, I can create a sha of the time and machine for uniqueness, Other ideas?

[rajwork9]

AdapterIdentity: in Mqtt it creates like serverIp:MqttPort or serverIp:1883.

MqttClientId: you can declare in config file or Generates unique id.

[wsobel]

We need a better way of creating the ID. Unless we have one client per process (which we could do) we need to make each instance unique.