[aprssig] APRS-IS Duplicate Packets

Tapio Sokura oh2kku at iki.fi
Mon May 3 23:04:34 EDT 2010


On 4.5.2010 5:26, Pete Loveall AE5PL Lists wrote:
> "modifying the packets themselves".  I understand that some few
> individuals have improperly programmed their software to strip data
> from the APRS-IS stream.  But that is no reason to reduce all other
> software to the same mistake.

Has any real effort been put into getting the malfunctioning programs 
and devices first a) identified and then b) fixed? In the end, if 
something that is clearly malfunctioning isn't fixed, could it just be 
shut off from the network until fixed? In the APRS-IS it actually might 
be doable in practice.

On the other hand I still remember pretty well the old packet radio BBS 
days. And the sysops that thought they owned the world. If someone 
didn't do as things were supposed to be done in their world, they just 
filtered them out or routed around or whatever. Anything to get their 
point across and to nullify those who don't share the same views.

> way.  It will continue to assume that trimmed packets seen
> immediately -after- packets with trailing whitespace have been
> improperly modified and the improperly modified packets will be

The above evidently holds true to VX-8. I have also seen cases where the 
original packet is the one that doesn't have extra whitespace at the 
end. For example certain versions of aprsd like to replace unprintable 
characters with spaces.

Anyway as long as we in reality don't have an 8-bit clean data 
transport/encoding in use over the TCP stream (like SLIP or KISS), 
talking about not modifying anything that passes through is just 
ignoring the facts. Every igate or APRS-IS server software that is used 
has some limits that it imposes on the data stream it passes through. If 
nothing else, just separating the packets from each other necessarily 
breaks 8-bit transparency. We need unambiguous rules to get consistency 
in treatment here.

   Tapio




More information about the aprssig mailing list