<div dir="ltr">Yes, I agree. Before we shove arbitrary data into packets, we need to step back and ask what problem are we trying to solve and are there already facilities in the protocol to do what we want?<div><br></div><div>It sounds like what is desired here is to understand network propagation more thoroughly by gathering more information about the physical transport layer. So, to draw a comparison to the "regular" internet, it sounds like what you want to know is some statistics on what kind of network an IP packet travels on. Or in other words, you want to know how many packets travel via Wi-Fi vs Ethernet vs fiber optic, etc, but in this case, it would be VHF vs UHF vs Lora?</div><div><br></div><div>Consider for a moment what this proposal would look like in TCP land? For every TCP packet you would want to stuff some data about the Layer 2 Data Link layer into the Layer 7 Application Layer? What happens when a packet traverses several different kinds of data links, i.e it originates on Lora and then is digipeated via VHF? Does the packet accumulate this "metadata" all along the way?</div><div><br></div><div>We already have a (limited) version of this metadata, in the form of the VIA path. Each hop is recorded in the packet.</div><div><br></div><div>I think Jason is on to something with the reference to ICMP and traceroute tool. AX.25 packets already know what stations the packet traversed; if you want to know what kind of link those stations represent, it could simply be an APRS query to the IGate/digipeater. In this way, if you are doing network propagation analysis, you only have to query the station once to find out details, rather than adding bloat to every packet traversing the network.</div><div><br></div><div>- Wes W8WJB</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 20, 2023 at 11:10 AM Jason KG4WSV <<a href="mailto:kg4wsv@gmail.com">kg4wsv@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I understand the reasoning behind wanting the data, but I’ve gotta say this sounds like the mirror image of shoving application data down into layers 2/3 which resulted in a bit of a nightmare for APRS implementers. I’m not saying your proposal would be as problematic, but I will say I’m not sure it is the correct way to solve the problem. <br>
<br>
I think one place to supply this kind of data would be status text supplied by gateway devices themselves. Anyone interested in storing said data can pull it from the APRS-IS feed. <br>
<br>
What comes to my mind is the ICMP protocol that rides alongside IP to give use some basic data about the lower layers of the network stack (connectivity, latencies etc) that makes up our Internet infrastructure, usually via queries (using tools like ping or traceroute). My first thought is to put that work onto the LoRaGate by crafting queries using the APRS messaging protocol that the gateway would respond to, perhaps in addition to regular status text by the gateway. <br>
<br>
This approach doesn’t require infrastructure modification except on the components you want to keep track of. <br>
<br>
Just some thoughts that I admit aren’t thoroughly thought out. :)<br>
<br>
-Jason<br>
kg4wsv<br>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote></div>