Yes, that description of how they get adopted fits my fuzzy recollection of same. Perhaps others who have used that side-effect feature can comment.
It'd be good to add a blurb to the man-page about the possibility, so people don't get confused when things work differently than they expect. On Thu, Jan 20, 2022 at 11:29 AM km5vy Tom Russo <[email protected]> wrote: > > On Thu, Jan 20, 2022 at 11:13:52AM -0800, we recorded a bogon-computron > collision of the <[email protected]> flavor, containing: > > Commented-out lines: Seems to be a common complaint of yours these > > days. > > As someone who's day job involves maintaining an enormous legacy software > package written by some dozen different authors over 20+ years, code > readability and code rot is a major concern, and I'll bring it up often until > I retire from that job *and* start using a pencil instead of a computer in > day to day operation. > > Commented out code in version-controlled software, especially commented out > code that was inserted once 18 years ago and then promptly commented out, > has been the bane of my existence because of its impact on readability. > Worse, code inside those comments is often rotted out so that uncommenting it > would be disastrous. > > My position is that if it was commented out in 2005, the code in there is > no longer helping anyone and just serves to make it that much harder to > read and maintain. > > "git log -p" on a file will show all the changes made to that file since > it was created, and one can always just use the pager's search function to > look for specific old code that was removed. > > > > > Anyway... I was just mentioning the Xastir adoption of packets as a > > side-effect in case you wanted to add a blurb about that to the > > man-page as well. > > I don't have the opportunity to scope out when and how Xastir adopts packets > inserted this way right now, though I believe I have made use of the fact in > my old (no longer functional) DFing code --- inserting OBJECTS via TCP or UDP > into Xastir's ports does seem to let Xastir adopt them if you use the same > call. But it's been so long since I've done that I'm uncomfortable adding it > to the documentation without actually testing it out first. > > I think that's because objects created by xastir get handled by looping them > through the input processing, and then inserted into Xastir's own-object list > when they're recognized, at which point they get transmitted and added to > the "retransmit this periodically" process. Both objects created by Xastir > and those that come in through an interface get treated the same way. But I'd > actually have to revisit all the code to make sure this is true. > > And I'm pretty sure that non-object/item packets don't get the same treatment. > > > On Thu, Jan 20, 2022 at 11:07 AM km5vy Tom Russo <[email protected]> wrote: > > > > > > The code is pretty hard to read and is peppered with blocks of > > > commented-out > > > code that have been that way since 2005. There used to be some attempt to > > > treat the injected stuff as third-party only if its callsign was different > > > from Xastir's, but all that is commented out and stuff injected by > > > xastir_udp_client is *always* treated as third-party. > > > > > > Whether it gets inserted into xastir's "own" packets and adopted for > > > retransmission is another question, but I don't think it does. > > > > > > When I tested this all out by hand, I didn't use the same SSID for the > > > injected packet, so I could tell the difference when I looked at aprs.fi > > > for whether it had been gated properly. Xastir retransmitted it fine, but > > > did not adopt it. > > > > > > Since it's not an object or item, I don't think Xastir would have > > > retransmitted > > > it anyway --- WeeWx's aprs extension creates a "weather station" packet > > > payload, > > > not a "weather object" payload. > > > > > > On Thu, Jan 20, 2022 at 11:00:57AM -0800, we recorded a bogon-computron > > > collision of the <[email protected]> flavor, containing: > > > > It's fuzzy in my memory now, but I believe there may be a side-effect > > > > in Xastir as well (which can be taken advantage of in some cases) > > > > where if the call and SSID are the same as the Xastir instance when > > > > injecting packets in via xastir_udp_client, Xastir can take up > > > > re-transmitting those packets at intervals. Like I said it's a bit > > > > fuzzy now as I haven't messed with that piece for some time. > > > > > > > > Where it can be and advantage is if you're trying to inject > > > > objects/items into Xastir from some other interface, using > > > > xastir_udp_client to do this injection. > > > > > > > > Of course the side-effect is if you don't desire Xastir to pick up the > > > > transmission as it's own and retransmit it. I believe this can be > > > > solved by using a different SSID and/or callsign for the injection. > > > > > > > > On Thu, Jan 20, 2022 at 10:50 AM Tom Russo <[email protected]> wrote: > > > > > > > > > > Resurrecting an ancient thread, because Dj opened an issue on GitHub > > > > > about it > > > > > this week, and I tracked down what is happening here. I'm following > > > > > up to > > > > > the original thread to clear up the misunderstanding and get the > > > > > answer into > > > > > the mailing list archive where it could presumably be found in web > > > > > searches. > > > > > > > > > > Dj had Xastir and WeeWx's APRS extension working, but only by > > > > > modifying > > > > > main.c. > > > > > > > > > > The reason for the suggested mods of main.c in the message I'm > > > > > replying to > > > > > is to work around some mistaken usage of xastir_udp_client, which I > > > > > think > > > > > may have been the result of some incomplete (or perhaps overly vague) > > > > > documentation. > > > > > > > > > > xastir_udp_client does NOT insert the packet header > > > > > "FROMCALL>TOCALL:" into > > > > > the data passed to it on the command line, it does a straight > > > > > insersion of > > > > > the data passed to it directly into Xastir's incoming packet stream. > > > > > And so > > > > > one MUST include "FROMCALL>TOCALL:" at the beginning of the packet > > > > > oneself. > > > > > Some other APRS tools for injecting packets do this for you, but > > > > > xastir_udp_client does not. > > > > > > > > > > Once injected, Xastir creates a third-party packet out of the data. > > > > > Third > > > > > party packets look like > > > > > "xastircall>APX219,PATH1,PATH2...:}tpcall>tocall:..." > > > > > where "xastircall" is the call sign of the Xastir instance and > > > > > "tpcall" is the > > > > > call sign of the third party station (which may be the same as > > > > > Xastir's). > > > > > When properly formatted, these packets show up in APRS clients > > > > > (including web > > > > > based ones like aprs.fi) as being from tpcall. > > > > > > > > > > The main.c changes Dj mentions here basically break the third-party > > > > > insertion > > > > > and mask the fact that he's left out the packet header in what he's > > > > > passed to > > > > > xastir_udp_client. The fact that he was leaving out "tpcall>tocall:" > > > > > was > > > > > why his packets were being flagged as invalid without those > > > > > modifications (the stuff after the "}" was incomplete). > > > > > > > > > > Once that usage error is corrected, Xastir should be able to take > > > > > WeeWx's data > > > > > just fine. So the script to do the insertion would be: > > > > > > > > > > #!/bin/bash > > > > > # > > > > > weatherpacket=`cat /dev/shm/aprs.pkt` > > > > > /usr/local/xastir/bin/xastir_udp_client localhost 2023 YOURCALL XXXX > > > > > -to_rf > > > > > "YOURCALL>APX219:$weatherpacket" > > > > > > > > > > > > > > > with the obvious modification to make it correct for your call sign. > > > > > This > > > > > will work with Xastir unmodified, and is as xastir_udp_client was > > > > > meant > > > > > to be invoked. > > > > > > > > > > I have examined the xastir_udp_client man page and found it to leave > > > > > too much > > > > > to interpretation. I edited it and added more notes about how it > > > > > really works > > > > > so that perhaps it will be easier for others to grok in the future. > > > > > If anyone > > > > > still finds it confusing, I can modify it further. > > > > > > > > > > On Sat, Oct 31, 2020 at 08:30:18PM -0400, we recorded a > > > > > bogon-computron collision of the <[email protected]> flavor, containing: > > > > > > On 10/30/2020 1:07 AM, Steven Morrison wrote: > > > > > > > I can configure the WeeWx program to generate a report and send > > > > > > > it to the > > > > > > xastir Pi, but how can i receive that report and transmit it in > > > > > > xastir? > > > > > > > > > > > > > > > > > > I'm doing it as follows in Linux (Raspberry Pi) with both WeeWx and > > > > > > Xastir > > > > > > running on the same RPi, but you could easily rsync the > > > > > > /dev/shm/aprs.kpt > > > > > > file to a different computer if needed. > > > > > > > > > > > > I have the APRS extension loaded into WeeWx > > > > > > (https://github.com/cavedon/weewx-aprs). > > > > > > > > > > > > In /etc/weewx/weewx.conf I have: > > > > > > > > > > > > # Options for extension 'aprs' > > > > > > [APRS] > > > > > > comment = "RaspberryPi-Xastir-Wx-Topsham,ME" > > > > > > include_position = 1 > > > > > > symbol_code = _ > > > > > > symbol_table = / > > > > > > output_filename = /dev/shm/aprs.pkt > > > > > > > > > > > > > > > > > > Then I have a crontab entry that does: > > > > > > > > > > > > 01,11,21,31,41,51 * * * * /home/xastir/scripts/send-weather-rf.sh > > > > > > > /dev/null > > > > > > > > > > > > > > > > > > and the send-weather-rf.sh script looks like (XXXX is my 4 digit > > > > > > APRS code): > > > > > > > > > > > > #!/bin/bash > > > > > > # > > > > > > weatherpacket=`cat /dev/shm/aprs.pkt` > > > > > > /usr/local/xastir/bin/xastir_udp_client localhost 2023 N1JOV XXXX > > > > > > -to_rf > > > > > > $weatherpacket > > > > > > > > > > > > > > > > > > I am using an older version of Xastar (2.1.1) compiled from source > > > > > > code, and > > > > > > had to make the following change in main.c to make the > > > > > > xastir_udp_client > > > > > > command work for the above. I do not know if this still needs to > > > > > > be done in > > > > > > later versions. > > > > > > > > > > > > main.c is my custom version, main.c.orig is the original. > > > > > > > > > > > > $ diff main.c main.c.orig > > > > > > 12180,12183c12180,12183 > > > > > > < // char path[100+1]; > > > > > > < // char info[100+1]; > > > > > > < // char *path0 = NULL; > > > > > > < // char *info0 = NULL; > > > > > > --- > > > > > > > char path[100+1]; > > > > > > > char info[100+1]; > > > > > > > char *path0 = NULL; > > > > > > > char *info0 = NULL; > > > > > > 12187,12188c12187,12188 > > > > > > < // path0 = strtok(line,":"); // > > > > > > Pointer to > > > > > > start of path > > > > > > < // info0 = strtok(NULL,""); // > > > > > > Pointer to > > > > > > information field > > > > > > --- > > > > > > > path0 = strtok(line,":"); // > > > > > > > Pointer to > > > > > > start of path > > > > > > > info0 = strtok(NULL,""); // > > > > > > > Pointer to > > > > > > information field > > > > > > 12190,12197c12190,12196 > > > > > > < // xastir_snprintf(path, sizeof(path), > > > > > > "%s", > > > > > > path0); > > > > > > < // xastir_snprintf(info, sizeof(info), > > > > > > "%s", > > > > > > info0); > > > > > > < // //fprintf(stderr, "path: %s\n", > > > > > > path); > > > > > > < // //fprintf(stderr, "info: %s\n", > > > > > > info); > > > > > > < // //fprintf(stderr, "line: %s\n", > > > > > > line); > > > > > > < // xastir_snprintf(line, sizeof(line), > > > > > > "%s%s%s", path, ",NOGATE:", info); > > > > > > < // xastir_snprintf(line, sizeof(line), > > > > > > "%s%s%s", path); > > > > > > < // //fprintf(stderr, "line: %s\n", > > > > > > line); > > > > > > --- > > > > > > > xastir_snprintf(path, sizeof(path), > > > > > > > "%s", > > > > > > path0); > > > > > > > xastir_snprintf(info, sizeof(info), > > > > > > > "%s", > > > > > > info0); > > > > > > > //fprintf(stderr, "path: %s\n", path); > > > > > > > //fprintf(stderr, "info: %s\n", info); > > > > > > > //fprintf(stderr, "line: %s\n", line); > > > > > > > xastir_snprintf(line, sizeof(line), > > > > > > > "%s%s%s", > > > > > > path, ",NOGATE:", info); > > > > > > > //fprintf(stderr, "line: %s\n", line); > > > > > > 12239c12238 > > > > > > < // *(line + line_offset - 1) = '}'; > > > > > > --- > > > > > > > *(line + line_offset - 1) = '}'; > > > > > > 12242,12243c12241 > > > > > > < // (char *)(line + line_offset - > > > > > > 1), // > > > > > > Raw data line > > > > > > < (char *)(line + line_offset), // > > > > > > Raw data > > > > > > line > > > > > > --- > > > > > > > (char *)(line + line_offset - 1), > > > > > > > // Raw > > > > > > data line > > > > > > > > > > > > > > > > > > -Dj > > > > > > > > > > > > > > > > > > -- > > > > > > Dj Merrill - N1JOV - EAA Chapter 87 > > > > > > Currently Flying: Glastar > > > > > > Previously: Cessna 150 - Glasair 1 FT - Grumman AA1B > > > > > > > > > > > > _______________________________________________ > > > > > > Xastir mailing list > > > > > > [email protected] > > > > > > http://xastir.org/mailman/listinfo/xastir > > > > > > > > > > -- > > > > > Tom Russo KM5VY > > > > > Tijeras, NM > > > > > > > > > > echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] > > > > > [n-z][a-m] > > > > > > > > > > _______________________________________________ > > > > > Xastir mailing list > > > > > [email protected] > > > > > http://xastir.org/mailman/listinfo/xastir > > > > > > > > > > > > > > > > -- > > > > Curt, WE7U http://xastir.org http://www.sarguydigital.com > > > > > > -- > > > Tom Russo KM5VY > > > Tijeras, NM > > > > > > echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] > > > [n-z][a-m] > > > > > > > > > -- > > Curt, WE7U http://xastir.org http://www.sarguydigital.com > > -- > Tom Russo KM5VY > Tijeras, NM > > echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] > -- Curt, WE7U http://xastir.org http://www.sarguydigital.com _______________________________________________ Xastir mailing list [email protected] http://xastir.org/mailman/listinfo/xastir
