# rmap.world duplicates discoverable interfaces _Help · started by grlx on Thu, Oct 1, 2026 5:05 PM_ --- ## Original post **grlx** · Thu, Oct 1, 2026 5:05 PM I see that https://rmap.world duplicates some `discoverable` interfaces when a node is not set as a transport one. For example there is the same interface with `a04992347d383745e6c1d3bb520f4e3d` and `52d60dfe51b448a84f2ecd20880ad13b` transport ids. I can imagine it makes sense to note transport ids which propagated the interface, but meanwhile it looks like a bug. Do you know any settings apart from enabling transport to prevent the duplicating? Probably the creator of rmap is here? Tried to send them an LXMF message, but didn't get any comments. ![Screenshot 2026-10-01 at 20.50.56.png](/storage/forum/LKwbmXmZE0cnWejDYmHO5q7mymxq16ZegCE7veDo.png) ![Screenshot 2026-10-01 at 20.51.07.png](/storage/forum/oILYPEI58hNQ0tfHCTVPm75joqlAHMIN9nkPX0iD.png) --- ## Reply 1 **welo** · Thu, Oct 1, 2026 8:20 PM I'm gonna piggyback off of this with a similarish issue. Whenever a transport node has two Rnodes attached to one identity with different settings (bandwidth, frequency, whatever), the information about one Rnode will constantly override the other, leading to only one Rnode showing up on the map. To properly advertise my Lora gateways I've had to run two RNS instances with different identities and connect them together with a localhost Backbone interface, which is obviously inefficient. This doesn't seem to apply to backbone interfaces for some reason, having two running on different ports allows both of them to show up on the map. --- ## Reply 2 **NONGKHAEM_BKK_TH** · Fri, Oct 2, 2026 1:53 AM Ah yes I noticed that too. So basically for me my node is duplicated 17 times (just check bangkok, Thailand on the map). And that's the result of how rmap.world functions: they list what they discover that claims to be at position X (since location is something you can manually specify). It doesn't even have to be 'real'. The way they handle this is by disapearing the nodes that didn't announce for 7 days, but it's not a good solution IMHO. It doesn't require you to be operating a propagation or transport node: they just discover everything that's discoverable and has a location, then print it. As @welo says, if ANYTHING changes, it will add another marker for that exact location. They need to update this for 2 reasons: a) if my IP changes, which it does because my node isn't fixed, and i'm not using a dyn DNS, a new instance spawns. That's regardless of the "reachable_on=", which i left fixed but has no correlation to reality anymore. I find that weird but yeah everytime i move networks, a new dot spawn. b) needless to say anyone with a python script could paint the map in about 5 minute flat by spooling up fake instance. My config if you are curious: [[My Node]] type = TCPServerInterface enabled = yes listen_ip = 0.0.0.0 listen_port = 4242 discoverable = yes discovery_name = TEST_NONGKHAEM_BKK_TH latitude = 13.683419053492303 longitude = 100.35779615497232 mode = gateway discovery_lxmf_address = e23e9a470d42f05d8e5f94c222caf723 discovery_stamp_value = 22 reachable_on = 27.130.2.74 --- ## Reply 3 **K8** · Fri, Oct 2, 2026 3:35 AM This looks to be caused by the new-ish ephemeral transport identity feature, which generates a new transport ID on every startup. This is disabled for `enable_transport = yes` nodes, but you can still announce discoverable interfaces on non-transport nodes, and so by default you’d be announcing with a new transport ID after every restart. RMAP is probably using only the transport ID to distinguish nodes (as it should). You can disable ephemeral transport IDs by setting `static_transport_identity = yes` in your config. Out of curiosity, why are you advertising a discoverable interface without also enabling transport? There’s a reason to do that for radio interfaces where you just want to make sure others can get the correct parameters, but I’m not sure what use there is in a non-transport discoverable TCP interface. --- ## Reply 4 **Anon** · Fri, Oct 2, 2026 7:30 AM It seems that rmap listens for discovery announces and dedup nodes by hash address, so if you change and announce 17 times a different hash address for the same place or node, you appear 17 times! Maybe the problem is in your settings and not on rmap, i dont't see any bug here, i only see your 17 different hash addresses for the TEST_*_BKK_NH node and of course the map will show all of them on announce, considering them different one from another due to different addresses! Also rmap is not a testnet, so generally speaking, use your own server for experiments and tests before connecting and spamming/flooding things to public servers! --- ## Reply 5 **Anonymous** · Fri, Oct 2, 2026 9:03 AM Why would you publish your non-transport node? I know thats not your question, but I think its a bad idea in the first place, and apparently would solve your issue. --- ## Reply 6 **Anonymous** · Fri, Oct 2, 2026 9:14 AM **welo** wrote: > I'm gonna piggyback off of this with a similarish issue. > > Whenever a transport node has two Rnodes attached to one identity with different settings (bandwidth, frequency, whatever), the information about one Rnode will constantly override the other, leading to only one Rnode showing up on the map. To properly advertise my Lora gateways I've had to run two RNS instances with different identities and connect them together with a localhost Backbone interface, which is obviously inefficient. > > This doesn't seem to apply to backbone interfaces for some reason, having two running on different ports allows both of them to show up on the map. thats really strange. Do you notice that behaviour in sideband or meshchatx as well? --- ## Reply 7 **grlx** · Fri, Oct 2, 2026 9:41 AM **K8** wrote: > You can disable ephemeral transport IDs by setting static_transport_identity = yes in your config brilliant, thanks! it worked. **K8** wrote: > Out of curiosity, why are you advertising a discoverable interface without also enabling transport? Just testing an RTNode along with a regular discoverable RNode and wanting them to be decoupled. --- ## Reply 8 **Mark** · Fri, Oct 2, 2026 9:43 AM The duplicated announces are really a configuration parsing problem. Non-transport instances have ephemeral transport IDs by default, but this will make de-duplicating the interfaces impossible, since the identity changes on each startup. The correct solution is to ensure that a static transport ID is used when discovered interfaces are published, even though transport is disabled. I've added the fix in the config parser, and will have a maintenance release out shortly. The source is on Aleph already. Regarding the weird situation of not being able to announce two different RNode interfaces, I'd like to know why that occurs, but you should probably not piggyback and instead start a separate thread on it ;) --- ## Reply 9 **Mark** · Fri, Oct 2, 2026 9:47 AM But that being said, the only way I can see multiple RNode interfaces overwriting each other would be if you gave them the same name in the discovery config. RNS de-duplicates received discovered interfaces based on transport ID and announced name, so if you announce the name of "RNode" for both of them, the latest one will always overwrite any earlier. --- ## Reply 10 **anon** · Fri, Oct 2, 2026 10:37 AM **grlx** wrote: > **K8** wrote: > > You can disable ephemeral transport IDs by setting static_transport_identity = yes in your config > > brilliant, thanks! it worked. > > **K8** wrote: > > Out of curiosity, why are you advertising a discoverable interface without also enabling transport? > > Just testing an RTNode along with a regular discoverable RNode and wanting them to be decoupled. > > rtnode is based on microreticulum and is not updated to the latest rns version, so the ephemeral thing is not the problem here, i think. are you creating a new identity everytime you restart the node? this could be the duplicate explanation. also BKK is announcing as tcpinterface, i cannot see lora rnodes from you on rmap... --- ## Reply 11 **Mark** · Fri, Oct 2, 2026 10:46 AM BKK is running RNS, as I said before, it's a config parsing problem. It's now fixed and released in 1.5.6. Regarding the RNode interface publishing, please create a separate thread with details on how to reproduce it. Keep things on-topic, otherwise it's impossible to diagnose and find for others later. ---