[Bug]: Network based approach to identify "Meshtastic" service, not following established RFCs. #4992
Replies: 6 comments
-
|
Beta Was this translation helpful? Give feedback.
-
|
+1 for user configurable mDNS hostnames. I've a very busy network and being able to edit the hostname would be very useful. Thanks |
Beta Was this translation helpful? Give feedback.
-
|
relates to #3230 where the network hostname (correct or not) is not used when reporting the hostname to syslog, rather the BLE identifier with an underscore which breaks parsing the logs per DNS naming in RFC 1035 / RFC 1123. |
Beta Was this translation helpful? Give feedback.
-
|
About 1: About 2: About 3: I still think a user changeable hostname makes more sense. Not only in case you want to setup a device where the display is not there (or visible) but also not everyone has an DHCPd or the knowledge to set fixed IPs. |
Beta Was this translation helpful? Give feedback.
-
|
+1 for configurable mDNS names |
Beta Was this translation helpful? Give feedback.
-
|
Landed here while looking for a config item to set the hostname. Currently multiple devices broadcast mDNS with an incrementing number, but the self signed TLS cert doesn't take that into account. It forces every devices cert to I think the fall-through network naming order should be
Domain:
|
Beta Was this translation helpful? Give feedback.
-
Category
WiFi
Hardware
Not Applicable
Firmware Version
2.2.23
Description
Currently Meshtastic devices uses DNS-Based Service Discovery to announce their presence within an IP based network with a generic hostname.
However there are several problems with this in the form of security conciderations, hostname collisions and misleading interpretations of RFC 6763 (https://www.rfc-editor.org/rfc/rfc6763.html).
The currentway of how a Meshtastic device is identified within an network is my looking at either its IP address or by using the announced meshtastic.local hostname.
There are three problems here.
Having a static hostname is a known "Current Hostname Practice Considered Harmful" (https://www.rfc-editor.org/rfc/rfc8117.html).
Further information of why are outlined in this RFC.
This RFC also informs in the introduction (https://www.rfc-editor.org/rfc/rfc8117.html#section-1):
"Hostnames have to be unique within the domain in which they are
created and used. They do not have to be globally unique
identifiers, ..."
Hostname conflicts
As it is not possible to change "meshtastic.local" to a different hostname, we run into what is outlined in Section 9 of RFC 6762 (https://www.rfc-editor.org/rfc/rfc6762#section-9)
"A common example of a resource record type that is intended to be
unique, not shared between hosts, is the address record that maps a
host's name to its IP address. Should a host witness another host
announce an address record with the same name but a different IP
address, then that is considered inconsistent, and that address
record is considered to be in conflict."
Actually the Meshtastic nodes do not even attemp to renagociate the given hostname as they do not listen first for exsisting broadcasts. Which could classify an Meshtastic device as an harmful device within a network.
Expecting that the hostname matches the service that is offered.
Meshtastic devices only announced themself as an _http._tcp and _https._tcp service. Wich identifies the hosts as devices that provide a web page serviice.
This infromation should inform webbrowsers and other similar applications can reach a host that offers an HTTP(S) service inside the network with the via the hostname "meshtastic.local". This should ease the way how users can reach their devices.
However the wrong expectation is that every device that is called "meshtastic.local" is also a meshtastic device.
As any form of devices can use this as a hostname.
Conclusion:
As every Meshtastic devices is claiming this hostname, we now have the situation that we have an none unique hostname in the network and the wrong expectation that every host named meshtastic.local is offering a meshtastic node service.
On top we do have an inconvinience for users that, due to the hostname conflict, the hostname can no longer be used to address a device.
Which leaves the function to announce the hostnames sole purpose to be an confirmation of the type of service offered.
Solution:
Looking at RFC 6763 and RFC 2782 provide well established guidelines on how to differeniate between services offered and how to identify an individual host.
RFC 2782 (https://datatracker.ietf.org/doc/html/rfc2782) "A DNS RR for specifying the location of services (DNS SRV)" gives further information on how services should be announced within a network. The RFC uses her a simple example of offering a LDAP server within an network.
Based on above a more appropriate way to identify that a specific device as an Meshtastic compatible device would be to announce itself for example as "_meshtastic._tcp.".
While also announcing that there are _http._tcp and _https._tcp services offered by this device.
This would not only allow any of the applications who are developed as part of the overall Meshtastic Project, to more reliable know that this is a compatible device, but also allow third party tools to have an idea what kind of service this webservice is actually offering.
Not only that decuple of the service discovery from a general device discovery would means that it can be possible to give each Meshtastic node inside a network an unique hostname.
By having a dedicated service announcement (again e.g. "_meshtastic._tcp.") additional information can be published without the need to actually connect to the service. For example the firmware version, used frequencies, channel names could be announced or API versions.
This would make it even easier for applications to provide users with those information, as most modern operating system would cache this locally.
Relevant log output
No response
Beta Was this translation helpful? Give feedback.
All reactions