[aprssig] aprsd drops mic-e characters
oh2kku at iki.fi
Sat May 7 08:46:33 CDT 2005
Bill Diaz wrote:
> This aprsd problem has been known for at least 5 years and it was supposedly
> fixed a long time ago. This type of data corruption / mangling causes
> excessive copies of the mangled packets and causes stations in some areas to
> have errorneous positions reported by affected clients.
I guess it wasn't fixed then, at least 2.2.5-13 contains it and that is
what I have been observing here. There is no difference in the relevant
part of the code to 2.2.5-15.
> Please define invalid characters. I can understand removing the unneeded
> space at the end of the packet but any other modifications to the payload
> can change the entire meaning of the packet and can defeat attempts at dupe
> suppression. Past practice has been NOT to modify the payload.
The heart of the problem as I see it, is that the APRS specification is
vague on what are and what are not valid characters. It says in many
places that "printable ASCII" is good, but what is printable ASCII?
Usually it means characters of decimal value between 32-126, possibly
including 127. But characters above 127 are not normally considered to
> Not true. Properly written APRS applications can handle 8 bit characters.
> This was also discussed 4 or 5 some time ago on the sig and supposedly aprsd
> was modified to eliminate this mangling of payloads.
Maybe, I wasn't here then. The fact is that aprsd mangles certain
packets, with or without my patch. It is trivial to modify the code or
that patch to pass all bytes that are between 28 and 255. It would be
trivial to pass all bytes between 0 and 255, but I'm also guessing that
many applications won't handle the zero bytes this can insert into the
APRS-IS stream. Not to mention the ambiguity of where a packet starts
and where it ends.
> Please, please do NOT modify the contents of any payload. In the past aprsd
> was responsible for the majority of packet mangling on the APRS-IS. Let's
> not degrade the APRS-IS again.
Ok. Then what do I do to packets that contain cr, lf or any combination
of those anywhere in the packet? If I just blindly pass packets
containing them into the APRS-IS, they will probably be mishandled. What
I need is a clear and unambiguous specification on what
characters/packets to pass and what not to pass. The "pass everything"
just doesn't work in APRS-IS without a clearly defined protocol that
somehow embeds or escapes the "bad" characters. You can always say that
these things appear rarely in practice, but they do occur and that's why
you need a clear spec. Now with the ambiguous spec you see every author
making up their own rules on what to filter or not to filter.
> If you are actually running an aprsd version that is mangling packets, you
> should immediately remove it from service.
No I'm not running aprsd, but there are some in the local network.
PS. This might be more on topic on the aprsspec-list..
More information about the aprssig