rnprobe utility usage, how to enable "proofs for received packets"? #289
-
|
Hello, For range testing I would love to use the rnprobe, rather than sending messages to myself! I have setup a Pi computer, with rnsd running, transporting over local wifi with a Rnode strapped to the USB port. Next, a mobile devices running Sideband with only local network configured, and connected to the same network as the Pi. Finally, another machine running rnsd with an Rnode over USB allows me to run rnprobe and other utilities. Rnode interface configs match as needed. My goal is to probe the address of the mobile device, which would path through the wifi transport, over an rnode link, to the terminal I am working with. My main questions are as follows: -Do I use "LMXF address" or "Identity Hash" (as listed in the Sideband app) when probing from my other machine? I have tried both and the rnprobe utility is left hanging on "Path to address requested ". Though this could be caused by my next concern... -As the documentation states, the device you are attempting to probe would need to have "proofs for received packets" enabled. How is this enabled in Sideband(if at all)? If not in Sideband, what .retiuclum/config parameters would allow for that on terminal machine? Any help would be great! Thank you :) |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
As an aside to the main issue, with this same network setup, I can only communicate one direction using text. Sideband(WIFI)-->RaspPi(WIFI Transport/Rnode on USB)-->Laptop(Nomadnet, Rnode on USB) I cannot message from the laptop to the Sideband client all messages fail. Though the Rnodes show activity.What I CAN do, is message from the Sideband client to the laptop. Why is this so? |
Beta Was this translation helpful? Give feedback.
-
|
You would use the LXMF address, not the identity hash. But as you have discovered, for a destination to respond to probe packets, it will have to be set up to automatically send packet-proofs for anything it receives. This is not the default behaviour for LXMF, for very obvious security and privacy reasons. It is not something you can enable globally for destinations running on a system in any way. It is up to each application to decide, and can be controlled for each individual destination that the application creates. The default behaviour is to respond to nothing. If you want to probe a destination, you can set up your own small script or program that will respond to probes, simply by setting the proof-strategy of the destination to |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the direction. I misunderstood the function of the utility. |
Beta Was this translation helpful? Give feedback.
You would use the LXMF address, not the identity hash.
But as you have discovered, for a destination to respond to probe packets, it will have to be set up to automatically send packet-proofs for anything it receives. This is not the default behaviour for LXMF, for very obvious security and privacy reasons.
It is not something you can enable globally for destinations running on a system in any way. It is up to each application to decide, and can be controlled for each individual destination that the application creates. The default behaviour is to respond to nothing.
If you want to probe a destination, you can set up your own small script or program that will respond to probes, simply by …