v2.5 Problems #5111
Replies: 4 comments 3 replies
-
Is this Android App v2.5.1? if so this is fixed in 2.5.2 Android App. (was a known issue) I have three mountain top 2.5.5 Nodes, 1 is a router, 2 in Client mode on different mountains, they happily are passing messages/traceroutes etc across the mountains between two disparate side of the meshes.
If they pass one way, this shows the firmware is passing messages/rebroadcasting... the firmware doesnt keep track of who is on opposite sides of a node, its job is to rebroadcast a packet it hasnt seen before. Is there per chance a router node on the side having trouble sending back? if that is repeating a message faster then your 2.5.5 node, then your 2.5.5 node will mark it as a duplicate and not rebroadcast that packet. |
Beta Was this translation helpful? Give feedback.
-
|
Talie5in Thank you for your reply. At home I am using RAK 4631 v2.3.15 on EU_868 with Hop Limit 7 set as a Client. Dealing firstly with the "Hops Away: always show "Unknown" - yes my Android App is now 2.5.2 and most Nodes are now showing a Hop Number except for a few where the Show Details say UNSET - UNRECOGNISED see photo |
Beta Was this translation helpful? Give feedback.
-
|
The two Nodes that I have put out at 261m (Silverton) and 157m ASL (Isca) are also RAK 4631 v2.3.15 on EU_868 with Hop Limit 7 set as Clients. They are both One Hop Away from my home Node. I cannot do Traceroutes to either of them, as the Hop in between us has a Green Padlock which suggests that it is running v2.5. When I do a trace route to that Node, this is the picture of the result: Hopefully you will see there is no arrows coming back to me. This is the case for all the Nodes nearby to me that are also running v2.5. However if I do a Traceroute to a Yellow Padlock Node I do get a report of the route back to me, see photo On the way back it went through both TUBS and CHUB who are running v2.5 (see first photo) this is very strange. |
Beta Was this translation helpful? Give feedback.
-
|
As far as we can make out there is no Nodes set up as Repeaters or Routers, they all appear as Clients or Client_Mute. Posting LongFast from my home Node show Cloud with Tick so some Nodes are receiving them (possible direct Nodes i.e. No Hops). Some Direct messages are being shown with Man and tick others with Cloud with Tick. When using other forms of communication to the owners of other Nodes more than 1 Hop away, they are usually saying that no messages are being received and the same is for the messages they have sent out. I still stand by what I said above, if somewhere on route Packets/Messages hit a 2.5 Node it all stops. |
Beta Was this translation helpful? Give feedback.
-
|
I think we have solved the source of the problem when using v2.5 Firmware…. When Meshtastic v2.5 Firmware was released, it introduced Encryption where both Public and Private Keys are used in the transmission and reception of messages between Nodes. For some people this caused problems whereas v2.5 messages being sent out never arrived at certain Nodes, yet they did to other Nodes, and vice versa, replies failed to be sent out, yet other Nodes could. Using the default Channel 0 LongFast (where the Public Keys are used), messages flowed back and forwards between all Nodes no matter what version of Firmware was on each Node, however when certain v2.5 Nodes sent out Direct Messages (where the Private Keys are used) their messages didn’t leave their Nodes, it all stopped, i.e. clouds with a line through them. After a lot of head scratching, testing, and searching the Internet for other users experiences when using v2.5, it came clear that the Developers had prevented Licenced Radio Amateurs from being able to send out any Encrypted Direct Messages – the ones that used the Private Keys. We believe that the Developers reasons for doing this are, that normally Licenced Radio Amateurs are not allowed to send/receive Encrypted Messages on the Licenced Radio Frequencies they are allowed to use, HOWEVER in saying that Meshtastic EU_868 is freely available to be used by Everyone i.e. both Non-Licenced and Licensed users – so we don’t understand the Developers reasoning for restricting an Unlicenced Frequency for certain users in such a manner. Perhaps they could re-consider this point? So….. if you are a Licenced Radio Amateur, and you wish to use the v2.5 Firmware, then in Radio Configuration/User, turn off the Licensed Amateur Radio slider – and you should then see your Direct Messages flow to all other Nodes if they are Online and In Range. |
Beta Was this translation helpful? Give feedback.
-
|
This is correct PKC encryption is not available in ham mode. |
Beta Was this translation helpful? Give feedback.
-
|
It has taken several weeks to discover that fact - surely the Developers could link their Encryption Prevention to the Region selected - thereby getting over this problem. |
Beta Was this translation helpful? Give feedback.
-
I don’t know if this is the correct place to post this: I have tried v2.5.5 on two Router Nodes (one @ 261m ASL and the other @ 157m ASL) here in the Southwest of England UK and started to see some problems, Nodes that were running older Firmware could send messages out on LongFast via one of the v2.5 Router Nodes (261meters ASL) and they could be seen by others on the other side. However, when people replied, their messages did not arrive back at the originating Node. Also Traceroutes that go through a v2.5 Node always fail, also the Node Hops Away: always show “Unknown”. In the first instance, I changed the Device setting from a Router back to Client, but that did not make any difference. My conclusion is that Nodes that are running v2.5 Firmware are preventing the transfer of Packets/Messages that go through them. I then reverted the two Nodes back to v2.3.15 and found Packets/Messages started to flow through them properly, however if somewhere on route the Packets/Messages hit a 2.5 Node it all stops. Has anyone else seen this with v2.5 Firmware?
Beta Was this translation helpful? Give feedback.
All reactions