[aprssig] aprsd drops mic-e characters

[Bill Diaz]

Tapio,
  See below:

>-----Original Message-----
>From: aprssig-bounces at lists.tapr.org 
>[mailto:aprssig-bounces at lists.tapr.org] On Behalf Of Tapio Sokura
>Sent: Saturday, May 07, 2005 07:17
>To: TAPR APRS Mailing List
>Subject: [aprssig] aprsd drops mic-e characters


>Hi,

>I have been debugging a local packet corruption problem and it turned 
>out to be aprsd doing the mangling. When using the kernel ax.25 
>interface, aprsd does some of its own filtering on packets before 
>passing them on to further processing. This extra filtering is too 
>restrictive for mic-e packets as it replaces bytes 28-31 and 
>127 with a 
>space.

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've put a small patch against aprsd 2.2.5-15 to 
>http://www.oh2kku.ham.fi/aprs/aprsd-mic-e-pass.patch that modifies the 
>checking to be mic-e compatible. In some earlier versions of aprsd the 
>file is named sockets.cpp. At the same time the filtering is 
>modified so 
>that invalid characters are stripped out of the packets, not replaced 
>with spaces. This method of filtering should reduce the number of 
>packets containing extra spaces at the end, if the original 
>AX.25 packet 
>contained a cr, lf or a combination of them in the end.

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. 

>This also means that many national characters that are over 
>ASCII value 
>127 are dropped, but it should be no surprise to anyone that APRS 
>doesn't handle 8-bit characters. 

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.

> Many APRS programs allow the use of 
>8-bit characters so other software have to make a decision on 
>what to do 
>with those packets: pass without touching the contents, strip 
>or replace 
>offending characters fully or just the 8th bit or discard the whole 
>packet. All of these methods are seen in the APRS-IS, which makes 
>duplicate filtering so much easier..NOT. I guess someone could blaim 
>this on the spec that doesn't explicitly say what to do with packets 
>containing invalid characters. Ok, enough ranting.

Duplicate filtering works well, provided ill conceived applications do NOT
mangle payloads by stripping the high order bit, replacing "invalid"
characters with a space, deleting "invalid" characters etc. 

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.

If you are actually running an aprsd version that is mangling packets, you
should immediately remove it from service.  

Bill KC9XG

>I filed a bug report on this at sourceforge, but as the latest aprsd 
>release seems to be over 1,5 years old, I'm not expecting it 
>to make it 
>to the official distribution anytime soon. So I'm sending this small 
>note here so those running aprsd with kernel AX.25 can be 
>notified about 
>it. aprsd running with a command mode TNC without using kernel 
>AX.25 is 
>not affected by this.
>
>   Tapio
>
>_______________________________________________
>aprssig mailing list
>aprssig at lists.tapr.org
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>