search

njh / mqtt-sn-tools

Command line tools written in C for the MQTT-SN (MQTT for Sensor Networks) protocol
MIT License
195 stars 84 forks source link

ClientID default missing for remote #33

Closed nottledim closed 4 years ago

nottledim commented 5 years ago

mqtt-sn-pub works OK with localhost; gives a default ClientID as in the README. However if I direct to remote host it fails to connect. If I supply a -i 'xxx' argument then it works. If I supply -i '' then it fails to connect again. To me that suggests a default ClientID is not provided for remote hosts.

njh commented 4 years ago

Sorry, for not responding.

Did you make any progress with this? What error message were you seeing when it failed to connect? Was there any error message on the server?

It might be useful to try and do a Wireshark packet capture to see what is going on.

Re-looking at the code, I cannot see why the client ID code would behave different for localhost to a remote host.

However if you have multiple devices, running identical setups, then the process ID is likely to be the same for each device. It is desirable to customise the ClientID for each a setup - for example using the MAC address. I don't do this by default because it could unintentionally leak information.

nottledim commented 4 years ago

No, I was baffled. I was using it to test paho.mqtt-sn.embedded-c gateway. I did what I wanted to do by giving an argument.
I can't remember any error messages but if I remember it looked like there was no client ID in the packet being sent. paho gives a hex dump of messages in its log and there it wasn't! Completely missing from the packet i.e. not null or empty; just a short packet.

To me it seemed like a coding error possibly with parsing the options. But that's just a guess.

I got paho to work and so lost interest. It'd be nice if you could have a look sometime.

njh commented 4 years ago

I have tried using mosquitto + paho.mqtt-sn.embedded-c gateway running on a Debian machine and mqtt-sn-tools running on a Raspberry Pi but I have been unable to re-produce this problem.

The only thing I can imagine is that the packet is getting corrupted in some way.

If you regain interest or have more details, I can have another look.