[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