mirror of
https://github.com/jkingsman/Remote-Terminal-for-MeshCore.git
synced 2026-11-03 08:02:19 +01:00
Bug with parser/visualizer with trace packets #17
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/Remote-Terminal-for-MeshCore#17
Reference in new issue
Block a user
I observed strange behavior of the visualizer when processing trace packets (possibly path packets also). When such packets pass through, nodes appear that do not actually exist.
No problem here:
And here is a screenshot after tracing one of the nearest repeaters (there are no nodes with prefixes 27 and 33 in the area):
If these erroneous prefixes interfere with real ones, then this distorts the network graph - impossible direct links with my companion appear.
RemoteTerm for MeshCore
v2.7.9
9fbdbaaOh interesting; yeah the SNR values are being read as node IDs. That's definitely a parsing bug. Thanks for the report! I'll get that fixed when I dive back into dev work later this week.
Thank you very much!
It seems to me that I have seen a similar problem with other types of packets, with DM traffic (with ACK or PATH packets). But I'm not sure. I'll let you know later if I will reproduce it.
Okay, I'll reopen :) Let me know if you can find a repro packet. Thank you!
I updated to 3.0 release, and I don't see any problems with DM, ACK, or PATH. Thank you!
It looks like I found packets with incorrect visualisation. Unfortunately, I can’t take a legible screenshot due to the abundance of other traffic. The problem is that after some of these packets, false direct connections are created between the sender and my companion (and possibly with the repeaters closest to me). Perhaps I'm wrong about something. Do you have a way to check whether these packets are processed correctly?
I tried to view these packets using mehscoredecoder, and everything seemed to be fine with them, that is, they traveled a certain path, but the visualization showed direct connections from this sender to my companion.
[aleksey@mini2x14 ~]$ meshcore-decode decode 0905A15405D5F6203E4D9B2802D4A7DA43E9B1B6818DEEE4324C084E60D2BAE6C999921D2DA313905490E7887C05C8A16022028A211BE6042C58805A583DE52D24C966EDAE5212903C76A87BBABF7660851AA32FF87B9DA52BC5D1309765F36597EDE55E2F49967DD77D2A82F73F648533275D4D13C6B5B9845321281D208DD4C88B06971729D1AC60B035DF9FD36698850EC1486E8E04FE37BB81
=== MeshCore Packet Analysis ===
✅ Valid Packet
Message Hash: 7003782B
Route Type: Flood
Payload Type: TextMessage
Total Bytes: 155
Path Length: 5 byte(s)
Path: A1 → 54 → 05 → D5 → F6
=== Payload Details ===
Payload Type: TextMessage
Payload Version: 0
Valid: ✅
Destination Hash: 20 (0x20)
Source Hash: 3E (0x3E)
Cipher MAC: 4D9B
Ciphertext Length: 144 bytes
🔒 Encrypted (ECDH keys required)
Ciphertext: 2802D4A7DA43E9B1B6818DEEE4324C084E60D2BAE6C999921D2DA313905490E7...
What is your pub key prefix? I'm wondering if there's an ambiguous repeater node causing things to look more collapsed than they should be in reality.
Hmm. My companion pubkey prefix is DC.
Uh... I made a screenshot... With ambiguous repeaters disabled. There is no connections between my companion and zerohop repeaters NEV-LatStrel-S (7D), KRG-Kazanskaya-SE(D5),NEV-KOLLONT-FOX (F6), through which I receive all packets, but messages recipient derzhenot (B0) is impossibly connected with them and with my companion... The sender is Klmn @spklmn ✈️ (3E).
Here is the packets:
F
🔒
Encrypted
DM from 3E to B0 via B3-BC-F6
19:31:36
SNR: -1.3 dB | RSSI: -97 dBm
0903B3BCF6B03E06754419409640F10AA47AD7877E9830856D0CE76F51771830D010EC9BD48F9A25F07A52A67FBF09920A6DA84CCA80BF5F058E8EF8BE66E0567F281349E206FAF53A369FEFCB51AE96135C850738AB4502E07B3AAD236EE7D782D556DDC9D055C297E401CC604722A1F03F52498C6AFD2DDFDA4B94F5D8EC543D02D690F833EBB0445B1219DE79E855002402DDFE0D877EBC
F
🔒
Encrypted
DM from 3E to B0 via B3-BC-80-7D
19:31:38
SNR: 14.0 dB | RSSI: -43 dBm
0904B3BC807DB03E06754419409640F10AA47AD7877E9830856D0CE76F51771830D010EC9BD48F9A25F07A52A67FBF09920A6DA84CCA80BF5F058E8EF8BE66E0567F281349E206FAF53A369FEFCB51AE96135C850738AB4502E07B3AAD236EE7D782D556DDC9D055C297E401CC604722A1F03F52498C6AFD2DDFDA4B94F5D8EC543D02D690F833EBB0445B1219DE79E855002402DDFE0D877EBC
F
🔒
Encrypted
DM from 3E to B0 via B3-BC-F6-D5
19:31:43
SNR: -7.5 dB | RSSI: -103 dBm
0904B3BCF6D5B03E06754419409640F10AA47AD7877E9830856D0CE76F51771830D010EC9BD48F9A25F07A52A67FBF09920A6DA84CCA80BF5F058E8EF8BE66E0567F281349E206FAF53A369FEFCB51AE96135C850738AB4502E07B3AAD236EE7D782D556DDC9D055C297E401CC604722A1F03F52498C6AFD2DDFDA4B94F5D8EC543D02D690F833EBB0445B1219DE79E855002402DDFE0D877EBC
F
🔒
Encrypted
DM from 3E to B0 via A1-54-7D
19:32:08
SNR: 12.0 dB | RSSI: -42 dBm
0903A1547DB03EDD1FDE0E247C06FAA7DC791640B86CCEC8860CE76F51771830D010EC9BD48F9A25F07A52A67FBF09920A6DA84CCA80BF5F058E8EF8BE66E0567F281349E206FAF53A369FEFCB51AE96135C850738AB4502E07B3AAD236EE7D782D556DDC9D055C297E401CC604722A1F03F52498C6AFD2DDFDA4B94F5D8EC543D02D690F833EBB0445B1219DE79E855002402DDFE0D877EBC
F
🔒
Encrypted
DM from 3E to B0 via A1-54-3F-B4-D5
19:32:31
SNR: -9.5 dB | RSSI: -104 dBm
0905A1543FB4D5B03E61C32713D793614F71199EF8ACBD3742D4A075BDE29B71AB3BA6B481FA0754D45FD16E5ECBF771C69315716DB7846CA0FDF6EF6336B0FFC3791A7EC0152826F811D9D0E3703FA13F6DEEAFD21F3FBA5CD4FB689209A475EA01575E7CE9068D6E2D92
It seems to me that the recipient in this case should not be placed to the visualization at all, since we do not know where he actually is, and it is a flood messages. We only know the path of the packet from the sender to our companion.
I updated last screenshot with prefixes for visibility
Thanks for the detailed information! I'll dig into this meaningfully this evening.
DM's send ACKs, but I think from my test just now I think this is an issue with non-ambiguous-repeaters, which collapses the chain down and will show direct connections (i.e. graphs where all intermediate repeaters are ambiguous) when it should in fact not show a connection from that node since it only arrived via ambiguous repeaters. I'll research though.
Okay I've pushed up a minor UI change. Essentially, what you're seeing is "expected" but not super clear. When no ambiguous repeaters are shown (which can include repeaters that would otherwise show a name, which are still ambiguous but that we have a reasonably solid guess at the identity of ("likely" in the hover/click panel)), the graph nodes collapse to show the only certain segments -- they sent it, you got it.
I've updated the UI to instead show that as a dashed line, implying "this was not a direct path, but you have chosen not to show a representation of the hops it took because we either don't know or can guess but are not certain of". Otherwise, we'll just end up with floating nodes which is not a representation I'm a fan of. So, it doesn't really "fix" your issue but it's because there's not a fix I can think of that isn't more confusing, so I've opted to make it clearer via symbolism.
Sorry, I guess I don't really understand what you mean :)
I apologize for being annoying, but I don't see the connection with ambiguous nodes. As far as I can see, the problem is present regardless of the state of "Show ambiguous repeaters/senders/recipients" options. Perhaps I wasn't very clear, or it's a translation problem )
I see the essence of the problem is that when a flood DM packet is received, its recipient appears on the visualization (and its connections will probably change if it is already present on the network graph).
All of these packets from the example above do not contain information about the path to the recipient, they are flood route type, and there is only the actual path from the sender to me. However, the visualization shows a recipient node with direct connections to my companion and the last repeaters from the received packets path. At the same time, my companion did not have connections with the last repeaters from the path, and the F6 repeater did not appear in the visualization at all.
My opinion is that in this case (the case of flood DM), the recipient should not appear on the visualization at all, and if he is already present in the current network graph, then his connections should not change, since the received packets do not contain information about them.
All of the prefixes presented in this case are known at the time of receiving these packets, and are present in the contact list. They do not have matches with the prefixes of other nodes.
This is how I see the correct visualization for this case:
Ah, okay, we were talking about different things then, or at least I read your latest message as a different issue from your prior message.
Yes, you have found a bug (yay thank you!) where we preemptively add a recipient node before we have actually had anything to establish its place in the network, which is Bad. Basically, the rule needs to be "we only create new nodes when they originate traffic or we become aware of them by citation within path data", and our DM recipient handling broke that rule. I'll audit the codebase and eliminate that and any other places we're overeager.
And, I suspect F6 is not showing up because it is an ambiguous repeater and you may have ambiguous repeater visualization turned off. If that's not the case, and you have ambiguous repeaters showing, then I would be very puzzled by that.
Yeah, you're right about F6 - I tried to play with the ambiguous option now, and this repeater disappears.
Gotcha; that would confirm that F6 is a repeater you have not yet heard an advert for. I have revised some of the logic, and fixed some bugs around how ambiguous senders showed up through the day today, but I think I can pretty confidently say we have a fairly reliable data model layer for the visualization now. To be clear, I really want to hear about any bugs spotted, for sure, but I've done a bunch of passes on this since your bug report and I think we've got a much clearer, resilient architecture now 🙂 lemme know how it goes for you.
So... I built the docker image from the main branch, and with it I don’t see any problems with DM processing for now.
I could swear, however, that I saw some other impossible connection with my companion, but it was a short moment, and I have no evidence 🤷♂️🤣
Thanks again for your work, love watching this visualization 👍
P.S. In current main branch build my companion's green ball twitches annoyingly when packets arrive, this did not happen in 3.2.0 )
Eyyy glad to hear it's mostly behaving. Twitching annoyingly is no good; you mean that just your ball wobbles around or they all do? I assume this doesn't change with "Let 'em drift" turned off?
Yeah, my green ball fastly wobbles with every packet no matter the settings )
I tried to upload the video to some hosting https://jumpshare.com/s/5NVTimDC6Q2rJZiEkFfw
Interesting; yeah I definitely see what you're talking about. Will see if I can repro
Okay fixed that.