rns.recipes

Hi, I'm using meshchatx and I'm having trouble messaging, I don't know if the problem is with lxmf or reticulum, anyway I assumed maybe the program version is old and I updated to the latest version of meshchatx with reticulum version 1.5.2 and the problem still persists, problem? I can't send messages! For example, I use two devices over the internet but they can't send me messages, or sometimes it's one-way! For example, device number 1 can send messages and another device can receive them and even its ping is very low, for example below 1000 or 500... but the other device can't connect at all! And it's been like this for hours, I just tried it myself, but a few days ago I was talking to someone and we had the same problem...

But let me tell you that my internet is weak and may be intermittent, and I am in a country that has filtering, but Reticulum works and Nomadnet works too... I thought I would write that maybe the routing is also the problem with my internet and maybe with non-interrupted internet and... this problem is not for others, or I don't know!
Anyway, it occurred to me to write it, maybe you found a solution (:

Hi Boltic, what interfaces do you have on both ends?

Can you run rnstatus or check the MeshChatX interfaces page to see if they are all online?

Thanks for the reply. On both devices, there are 8 automatic connections and a few hundred nodes found in total.
rnstatus:

 Shared Instance[rns/default]
    Status    : Up
    Serving   : 1 program
    Rate      : 1.00 Gbps, MTU 262144
    Traffic   : ↑647.97 KB  0 bps
                ↓825 B      0 bps

 AutoInterface[Default Interface]
    Status    : Up
    Mode      : Gateway
    Rate      : 10.00 Mbps, MTU 1196
    Peers     : 0 reachable
    Traffic   : ↑0 B        0 bps
                ↓0 B        0 bps

 TCPInterface[Mike node/[200:186d:b8ad:799b:1146:2f3e:e58a:7478]:4242]
    Status    : Down
    Mode      : Full
    Rate      : 10.00 Mbps, MTU 16384
    Traffic   : ↑0 B        0 bps
                ↓0 B        0 bps

 BackboneInterface[Discovered BackboneInterface/419e0280abc1.sn.mynetname.net:4242]
    Source    : Auto-connect via <0eb6f156aaa7a7a1fefa5bd0ab6286c5>
    Status    : Up
    Mode      : Full
    Rate      : 5.00 Mbps, MTU 8192
    Traffic   : ↑17.43 KB   0 bps
                ↓506.82 KB  6.28 Kbps

 BackboneInterface[RNS - Derpy Cloud/rns.derps.me:34242]
    Source    : Auto-connect via <708f363d8b320eafd38ba886ab34352a>
    Status    : Up
    Mode      : Full
    Rate      : 5.00 Mbps, MTU 8192
    Traffic   : ↑5.91 KB    0 bps
                ↓210.84 KB  1.88 Kbps

 BackboneInterface[lga.us.thunderhost.net/lga.us.thunderhost.net:4242]
    Source    : Auto-connect via <8c583fdf194d9c733ede1dad51b1a599>
    Status    : Up
    Mode      : Full
    Rate      : 5.00 Mbps, MTU 8192
    Traffic   : ↑4.27 KB    0 bps
                ↓194.75 KB  1.68 Kbps

 BackboneInterface[tpa.us.thunderhost.net/tpa.us.thunderhost.net:4242]
    Source    : Auto-connect via <9e648abbad92e6b291dc72b3adf3cc11>
    Status    : Up
    Mode      : Full
    Rate      : 5.00 Mbps, MTU 8192
    Traffic   : ↑15.47 KB   0 bps
                ↓183.32 KB  0 bps

 BackboneInterface[rns.wcmesh.com/rns.wcmesh.com:4242]
    Source    : Auto-connect via <ef21e0e760a6ddf6418d4f6bde3108f6>
    Status    : Up
    Mode      : Full
    Rate      : 5.00 Mbps, MTU 8192
    Traffic   : ↑7.31 KB    0 bps
                ↓242.79 KB  1.88 Kbps

 BackboneInterface[DjVolSky TCP/rns.djvolsky.ydns.eu:4242]
    Source    : Auto-connect via <4e9229ffa3d768d70da8c6d8d81542fc>
    Status    : Up
    Mode      : Full
    Rate      : 5.00 Mbps, MTU 8192
    Traffic   : ↑16.20 KB   0 bps
                ↓453.33 KB  0 bps

 BackboneInterface[Blinken Space DE-FSN1/rns.fsn1.blinken.space:4242]
    Source    : Auto-connect via <9ef4ffed6c86c348c47f2d93712f7abd>
    Status    : Up
    Mode      : Full
    Rate      : 5.00 Mbps, MTU 8192
    Traffic   : ↑264.07 KB  0 bps
                ↓532.10 KB  5.61 Kbps

 BackboneInterface[bnZ-NODE01 Gothenburg SE Public RNS/91.207.113.250:4242]
    Source    : Auto-connect via <a7105a4f1a7202dfe83f0fe83fae11f2>
    Status    : Up
    Mode      : Full
    Rate      : 5.00 Mbps, MTU 8192
    Traffic   : ↑4.10 KB    0 bps
                ↓210.86 KB  2.42 Kbps

And so nomadnet works on both devices, now it might take a few seconds but it works, but both my devices still can't send me messages! And when I ping it, it gives a 30 second delay error! When it was one-way, I could send messages, and the ping was usually under 1 second... Now both devices are like this
And I apologize if it's not very readable, I'm using a translator..

Boltic wrote:

And so nomadnet works on both devices, now it might take a few seconds but it works, but both my devices still can't send me messages! And when I ping it, it gives a 30 second delay error! When it was one-way, I could send messages, and the ping was usually under 1 second... Now both devices are like this
And I apologize if it's not very readable, I'm using a translator..

What I'd recommend doing is this:

Turn off discovery for now on both ends.

Then add a single backbone interface for both your RNS instance and the instance of the person you are trying to send a message to. Make sure that interface you add is online and reachable.

Then try doing some two-way messaging.

For example, in your rnstatus output lga.us.thunderhost.net was reachable, so in your Reticulum config (or in MeshChatX) add that one. Both you and your recipient should have the same setup

[[lga.us.thunderhost.net]]
type = BackboneInterface
enabled = yes
remote = lga.us.thunderhost.net
target_port = 4242
transport_identity = 04b9ff836e921ff4b85fe766f7ce929e

While it shouldn't be an issue with discovery as most of the public nodes are peered with each other, this may help to isolate the problem.

I'm really embarrassed, does it have to be announced periodically? I thought that routing without notifications would also be done on the network, I had disabled automatic notifications and the notification was for many days ago, and I just announced on two devices and now it's easy to send messages...

I meant those notifications originally as Announce, translator..
And so the problem is solved, it was my mistake that I misunderstood the network's operation, maybe?
Anyway, thank you again for your time.

You can disable automatic announces if you want to fully control when you send an announce an become reachable. That could be preferred if you want to remain more invisible on the network, and for example only download messages from propagation nodes.

In almost all normal use cases, you want your LXMF client to handle announces automatically. If an announce is not send, there is no path to you on the network.

Glad to hear it's working for you now.