Hi all,
Does someone obsere the same problem like i do?:
Since version 2.5.4 onwards my Tbeam (currently using 2.5.6) cannot send personal messages. I’m getting the strikethroughed line in the cloud quite quickly when writing a personal message to a node, as if the message is denied. When the message passes one hop, i first see the checkmark in the cloud but then the strikethrough afterwards.
Writing to the public channel works and i’m getting feedback, i.e. i can communicate.
Channel 0 is configured as a standard channel.
I already tried a fresh install with ./device-install.sh and also a factory reset. I removed the battery and tried again. No luck! Very strange.
The old admin channel has been deleted…
Does someone observe the same problem or even know a solution?
Regards…
use older firmware, is the solution that is working for now.
Also, it behooves you to start learning VSCode now; after a couple of years of unhelpful replies to suggestions or problems, that’s what you’ll want to do eventually anyway.
2.5.x provides fundamental improvements over 2.4.x.
The new traceroute function is most useful, a milestone. Thus, i need it !!!
One of my Tbeams does not show the described behaviour, the other does. But i can not see a different setting that could explain it.
It is not the first time that i thought there could be a hardware fault. Could it be that the data storage, flash and such stuff, becomes faulty after say 20+ firmware updates or 500 reboots? That would be very bad.
Is there a special erase option? Can you swap the roles and see if the fault follows one of the devices? What happens if both get reverted to 2.4 ? Do they both work then?
(I have given up on the normal T-beam and use the Supreme, so cannot test this too.)
I get a cloud with tick when sending a direct message (DM) from node A to a second node B, which has S&F, that then reverts to a crossed-out cloud (most odd):
S&F has never been active here.
I’m testing between my own nodes and also towards the nodes of others, so i partly know that S&F is not involved.
But now, while writing that answer, i got the idea to write a message to some of the meanwhile rare nodes that didn’t update to 2.5.x (seen by the unlocked channel) yet.
And that works! I got an ACK, even over 3 hops.
That’s one step forward to solve the issue… It is highly likely to me now, that there is no hardware fault and that 2.4.x would work… I should have a look into these debug messages…
BTW i also use Android, 2.5.1 is the latest provided by F-Droid (not using Google play-store here).
We have had in Munich sporadic reports of Ack not working in 2.5 sometimes. The situation is very odd indeed. I would test with LongFast as the only channel in both nodes.
Then see if introducing a private channel with full PSK causes the issue. Then see if making the private channel, that both the nodes have in common, the first (channel 0). I gave up trying to make a mix of 2.4 and 2.5 nodes behave the same.
On 433 we have a mesh using a private channel. But on 868, we run the public / default channel. Since some people, maybe the majority, are somehow update addicted, they will update as soon as an update appears (even alpha stuff). So if you want to participate you have to update too, sooner or later. And then, you are forced to update the app of your phone as well. And then we are forced to update our purely private 433 mesh as well, or we would have to use different phones…
That’s one issue…
Anyway, for me, 2.5.x is very convincing due to the new traceroute function and the secure encrypted communication. In 2.4.x and below, you could theoretically modify the firmware in VSC and read all personal messages you can receive, including the ones between others. The new traceroute function lets you check where the S/N on the route is critical and this will contribute to improve it. Diagnostics…
There was just a short time between 2.3.x and the appearance of 2.5.x. Hopefully, 2.5.x will have a long life-time before 2.6.x appears…
similar situation. the long term solution, which I almost have totally sorted, is nodes that are not used with internet exposed client devices, ever. There’s just no other path to have any kind of reliability.
If the crowd of earnest “I want to use Meshtastic for firefighting/saving whales in the rainforest/critical communications for when the Trumpkins come to throw furries in camps” actually used this for critical public safety grade applications, this last update screwed their networks. No amount of snarky “read the docs” replies are changing that reality.
It’s still a toy, unless you force it into precisely the configuration you need, test the hell out of it, isolate it from foreign nodes, and not push any updates to it until they’ve been thoroughly tested BY YOU on similar devices to the ones you deploy.
ETA: If you’re using custom FW, do not connect an IOS client to any of your nodes. Despite the denials and protestations, I’ve tested this repeatedly over the last 2 years: A network that runs reliably 99% of the time when used ONLY on standalone devices or Android EUDs that are airgapped, will inexplicably develop problems when an iOS client is connected to it. I have neither the expertise nor the time to develop it to determine WHY, but it’s an observable fact.
…adding another detail to the initial problem description:
I noticed that i CAN send personal messages from that TBeam to nodes that i can administer, i.e. nodes that have my public key as an admin key.
Here in Munich people were seeing and reporting that DM can only be sent in firmwear 2.5 if the other node has at least one private channel that the sending node has too. I posted to ask whether this was needed and got no answers. I fear that this effect needs testing by having both nodes only have longfast channel. Then only one have a private channel. Then only one have private channel as primary. Then recipient only a private channel. Also primary and not primary. Then both have private channel as secondary. Then one as primary. Then both as primary… I gave up testing. I only have so many hours in the day. On my Android app (old version) I cannot SET which channel to use to send a DM. But for example a DM from and store and forward node (like the T-beam is capable of), that received the message FS, will come back to the node that sent the message FS, on the private channel the two have in common. One test with S&F showed that any only private channel in common has merely to exist - not be used - for S&F replies to make it through. Very head-scratching. Am very most mightily perplexed but that seems to be normal - else this Meshtastic becomes a full-time job.
Related links:
say make sure the two nodes explicitly have set the same slot
As an amusing, perhaps, related issue: I was testing S&F and it was not working. In fact it was: just the DM came back on a different (private) channel to the one used to send. And that worked only when primary was the private channel (if using 2.4 and 2.5 mix).
Yes, i can imagine that it works if you have a second channel which is private. But it is hard to imagine that this is intended by the developers.
It should be possible to exchange private messages, i.e. between two nodes and not over the public channel. And this actually works between two of my RAK4631s, as expected. But not from that TBeam.
Unfortunately i cannot paste the debug messages from my phone into this message here since i have no email or messangers installed there. But i just run from the CLI:
sr@test:~$ meshtastic --dest ‘!724b4d3a’ --no-time --ack --sendtext “TEST”
Connected to radio
Sending text message TEST to !724b4d3a on channelIndex:0
Waiting for an acknowledgment from remote node (this could take a while)
Received a NAK, error reason: NO_CHANNEL
This is reproducable and the result appears after less than 2 seconds. All running on the default channel, LONG-FAST.
However:
sr@test:~$ meshtastic --traceroute ‘!724b4d3a’
Connected to radio
Sending traceroute request to !724b4d3a on channelIndex:0 (this could take a while)
Route traced:
!1fd17234 → !724b4d3a
Try this. Set one of the T-beams to do store and forward (S&F). Make sure both nodes are set to the same slot. Then send it the message SF. It should reply. If the reply message comes back over the private channel then this will appear as a separate message thread. Example below:
Now that thread exists and is linked to a fully encrypted private channel (S&F_Munich in the abive) you can send a DM in that private thread and see if a tick appears. Then send a DM in the other channel (LongFast in the above) and see if a tick appears (which it may not).
Then play with the channel order and see if the results change.
Sorry if this seems complex but I have no other suggestion to try to find out how DMs works here. I am using the OLD Android app version 2.4.4 which might make the results odd but at least I can a feeling for what is going on in the firmwear. It may be that with the new app all this is different due to the use of keys etc. and all this is archeology. If so, pls ignore this.
It is massively useful and important to delete all messages in all chat / channel threads before a test like this or it gets mega confusing!! So that you have something like this:
You know how Silicon Valley types love to give sort of woodsy, Californicated Burning-Man-esque names to OSs and devices? I hereby yclept version 2.5.x firmware “KickaBaby” because that’s what it makes everyone want to do.
(Oops…I mean ‘KickAnUndifferentiatedMassOfCellsThatIsClearlyIncapableOfSustainingLifeOutsideTheBirthingPerson.’ Better?)
It appears that setting up nodes with 2.6.x is a process much more involved than previous iterations. Each node (and so far this afternoon I’ve flashed two TBeams and two RAK4630s) has to be flashed, then connected to the desktop. You need to decide which of your nodes is going to be the master (Don’t even…) and get ITS public key, and paste it into the permitted admin key field on the web interface on EACH new node as it’s set up. Then, you have to connect to the node via the OTA admin interface to make sure it works. The direct messaging function will not work unless you delete each node from the previous NodeDB, then directly message each new node as you set it up.
After reading the doc concerning the new PK implementation, I do LIKE the additional security - but damn.
As an aside, there was a release note that said support for the ATECC608A crypto chip was added a while back, and all I can see in the code last time I looked is “is the ATECC608A present?”
Further irritants: Just because ROUTER_CLIENT is overused at Burning Man and the DNC, doesn’t mean it’s not needed. Aaargh. opens VSCode again…
I know about setting up the new admin function. This was discussed here in another thread, where i learned how to do it.
Are you sure? Where do you know this from? By testing on your own or is it described somewhere?
After upgrading to 2.5.x, my “old” node-db was gone anyway (which is no problem of course) so i didn’t have to delete it manually.
I used device-install.sh instead of device-update.sh anyway, so the ESP32 on that TBeam was ereased completely, so there is no node-db etc.
Unfortunately no one of the experienced programmers who are deep into the code are commenting (something helpful!!!) on the issue…
as i said above, “I just spent the afternoon flashing devices…”
I flashed the firmware to those devices directly from VSCode using the PlatformIO tool after making mods to suit my network. The observations I made above are not something I read, it’s what i observed myself.
