[aprssig] aprsd drops mic-e characters

[Tapio Sokura]

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 
be ASCII.

> 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.

   Tapio

PS. This might be more on topic on the aprsspec-list..