[Xastir] corrupt packets

[Tom Russo]

On Wed, Oct 19, 2011 at 08:02:33AM -0700, we recorded a bogon-computron collision of the <aa9vi at yahoo.com> flavor, containing:
> The last couple of days I have been reading about corrupt packets getting transmitted over the air.? This sounds similar to what I had mentioned a month ago.? There was no obvious solution then.? I use a KPC3 and Xastir 2.0.0.? I could find no solution until I set permissions on the objects.log and objects-temp.log file to 555.? So, there is some over the air feedback mechanism causing bad packets to be heard over the air and then get fed back into Xastir and then overwrite the default settings. Wouldn't a simple solution be to not have that feedback algorithm?? 

The "feedback algorithm" is in fact how Xastir is intended to work, so 
removing that requires a complete rewrite of how Xastir handles its own
objects.

When Xastir generates an object, it does so by producing the text for a packet
and running it through its normal data parsing routines via a "loopback" 
interface.  Those routines enter the data into the internal database of heard 
information, and if the "FROM" callsign is its own callsign/ssid, then Xastir 
considers the object/item its own and schedules beaconing for it.

This is how we are able to use the server port to inject objects from 
external programs.  If the external program sends the object to Xastir
using a FROM callsign that is the same callsign/ssid that Xastir is using,
then as far as Xastir is concerned, it produced the object, and it begins
beaconing it.  

BUT, if some local digi is corrupting packets and digipeating them, then when
Xastir hears the packet it still claims it is FROM your own station (its from 
callsign was not corrupted), but it doesn't match an existing record (as it 
would if it were not corrupted).  So it enters the "new" data into its 
database, and because the callsign is its own, takes ownership and begins 
beaconing it just as if it had produced the data itself.  Making it not do 
this would require that the object processing mechanism be completely 
revamped, and would break the intended use of server ports to inject data.  

This is different from what Lynn just described:  if someone ELSE beacons
an object with the same name as one we are beaconing already, it will have a 
DIFFERENT "FROM" callsign than Xastir does;  Xastir will NOT adopt it, the 
object will be changed in its internal database as now being owned by some 
other station.  Since the object is no longer its own, it will stop beaconing 
that object.  

Now, the idea that your station is producing garbled objects because it is
receiving them garbled from a digipeater is just a theory, but it seems
at least plausible.  Since you say you were able to stop it from working  by
changing permissions on the objects.log files, then it is almost certain that 
the real issue is that some station other than your own is digipeating garbled 
copies of your own packets --- Xastir refuses to accept them now, because you 
have broken its ability to record its own objects in objects.log.

Your best bet for figuring out where these corrupted packets are coming from
is to start clean  --- remove (or move) objects.log, and start xastir over
with now objects beaconed.  Beacon one object and log your TNC data.
Watch the log until a garbled version of your packet shows up.  Look for the
very first instance of the garbled packet, and scan its digi path.  One of
the stations in that path is broken --- and probably because it's got PASSALL
on in its TNC.  PASSALL off prevents a TNC from sending to the attached 
computer any packets whose data do not have the same computed checksum as 
their transmitted checksums, thus ignoring corrupted packets.  With PASSALL
ON, all packets, irrespective of checksum match, are passed to the attached
machine.  PASSALL is a debugging tool, and should never be on in a TNC used
for a digipeater or IGate.

Come to think of it, it is ALSO possible that your packets are being injected
into APRS-IS by a bad IGate, and picked up again by your station through
APRS-IS rather than your own TNC.  Either way, if the from callsign is not
mangled by the broken station, Xastir will think the packet is its own and
adopt it.  Eliminate *this* possibility by turning off any internet server 
interface you have while looking for the problem on the RF side.  If you
stop receiving garbled packets, but they still show up on, say FINDU or 
aprs.fi, then your job will be to track down which IGate is first injecting 
the garbled packets.

Good luck with that.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
 "One man alone can be pretty dumb sometimes, but for real bona fide
 stupidity, there ain't nothin' can beat teamwork." - Edward Abbey