[aprssig] aprsd drops mic-e characters

[Tapio Sokura]

Bill Diaz wrote:
>>>>I guess it wasn't fixed then, at least 2.2.5-13 contains it 
>>>It was fixed at one point, in some distributions.  Some of the older
>>I meant the aprsd at sourceforge, just to be clear.

> Just because something is posted at sourceforge does not guarantee it is
> correct.  Obviously, the version you are modifying contains code that may

Of course it doesn't. After doing some googling it looks like wa4dsy 
offers one version of aprsd, the original I guess? It doesn't seem to 
support the linux kernel ax.25 stack so at least it doesn't have the 
exact same problem. The distribution also has files in it that are dated 
to February 2004, the sourceforge version is dated September 2003 so it 
looks like the wa4dsy one is more recent.

>>Yes, but they are not ASCII. For example, a direct quote from 
>>APRS 1.0.1 
>>specification says "An Object Report has a fixed 9-character Object 
>>name, which may consist of any printable ASCII characters." And the 
>>glossary at the end describes ASCII as being a 7-bit code. And 
>>so do the 
>>documents that actually specify ASCII, I believe.

> You are only quoting a reference to object names and yes they are expected
> to constructed of ASCII characters.  There is no such reference to data in
> all payloads.

I quoted only one part of the spec as an example. For example regarding 
comments on packets (page 20) the spec says "The comment may contain any 
printable ASCII characters". On APRS messages the spec says on page 71 
"The message text may be up to 67 characters long, and may contain any 
printable ASCII characters" (plus notes on both cases about not using 
two TNC stream switch characters). The term "printable ASCII" is used 
throughout the document for describing text strings, I'm not going to 
quote all of those places here.

> Your intereptation is flawed.  You are unilaterally deciding what characters
> are valid and what is not.  I suggest you spend some time reviewing the
> APRSSig and APRSSpec archives.  Then you may be in a better position to
> judge what is generally considered to be proper behavior both on RF and on
> the APRS-IS. 

I'm not deciding anything, I'm just trying to follow the specification 
the way it is written. I'm used to following specifications like that, 
not make my own rules about what is right and what is wrong. If the true 
spec is only spread out in mailing list archives, it's no wonder there 
are numerous interpretations on how to implement the APRS "specification".

> Obviously you are not interested in determining how a packet is delimited or
> constructed, you would rather tell everyone how it SHOULD, in your opinion
> be constructed.  FYI, the FromCall can be up to 9 printable ASCII

I'm just saying how the specification says the packet is constructed. If 
I can't trust the specification to be the authoritative source, I don't 
know who to trust.

> How many APRS applications can you name that cannot correctly handle a nul
> char?  

At least one, because it is the only one whose source code I have read 
through and am familiar with. But I guess it doesn't do that correctly 
either, because it dumps the zero byte (it is not used in other than 
user defined APRS packets) and reads on until it sees the end of the 
packet. After rereading some parts of the spec, I guess zero bytes can 
be valid bytes in APRS user defined formats, because they are not 
disallowed there. Discouraged yes, but not forbidden. And I guess this 
is the loophole in the spec that also officially allows full 8 bit 
character usage at least in the user defined packets and therefore 8 bit 
characters can be gated, in user-defined packets, to APRS-IS.

>>I think APRS(-IS) has been "improved" to the point it currently stands 
>>very well even without my input. And this is not a compliment.

> FWIW, you need to understand how APRS packets are constructed before you
> attempt to criticize what has evolved over the years.  We have a workable
> system that was developed by many talented, dedicated individuals who worked
> for years to bring us to where we are today.  There were many disagreements
> and arguments that were resolved after much debate.  

Without looking further into the archives, I'd guess many of those 
debates have been sparked by having an ambiguous specification to begin 
with. I'm not saying the efforts of these individuals have been in vain, 
on the contrary many things in APRS are better now than they were 5 
years ago. But they could be a lot better too.

> If you are not happy with what is presently available, you are free to
> design your own "improved" system, but please do not pollute the existing

Are you saying here that APRS the way it is now is written in stone and 
it can't be improved anymore and that's why I should start designing a 
better system?

>>when it makes it to the APRS-IS. It doesn't matter what software is 
>>doing the igating, it will break those packets because APRS-IS 
>>is not an 
>>8-bit (or should I say, 7-bit) clean packet transfer medium.

> It is not clean because of defective software (such as your "improvements"
> to aprsd) or improperly setup TNC's.  Please don't make it worse with ill
> considered "improvements".

The APRS-IS stream can never be 8-bit (or 7-bit) clean the way it is 
specified now. This is why KISS and many similar things (like SLIP and 
PPP encapsulation) were developed a long time ago, to reliably pass 
8-bit packets of data in a serial stream. There's nothing wrong with not 
being 7/8 bit clean in APRS-IS, but in that case there should be a clear 
procedures for dealing with those packets that really use those 
bytestrings that cause the "cr or cr/lf delimits packets" rule to break.

If you actually read the patch I provided, you could easily see that the 
patch actually _increases_ the chances of a valid (according to the 
spec!) aprs ax.25 packet being passed into aprs-is without being mangled.

   Tapio

PS. I'm not going to return to this matter anymore. This is by now well 
off topic on this list and I want to spare other list members from the QRM.