[aprssig] aprsc 2.0.16/2.0.17 bug with m/ filter

[Heikki Hannikainen]

On Wed, 9 Sep 2015, Tom via aprssig wrote:

> I run an IGate, it's connected to a APRS IS Server.  Prior to 1 Sep 2015 
> as part of the TCPIP feed from the APRS Server connection - DStar 
> Repeaters, Hotspots and Users were part of the default data fed back to 
> my IGate.  If I didn't exclude it via Server-side filter settings it was 
> there.
>
> On 1 Sep 2015 all that DStar APRS information went dark.  It's no longer 
> part of the default feed from the APRS IS Server network on port 14580. 
> I've tried this across multiple Tier 1/2 servers with the same result. 
> All those DStar Repeaters, Hotspots and Users are still there, connected 
> and sending the same info they were before.  But it's no longer fed by 
> default to those stations connected to the Tier 1/2 servers.

There is a bug in aprsc 2.0.16 and 2.0.17, in the handling of the m/ 
filter. I'll release 2.0.18 later tonight with a fix for that.

The discussion here got a bit weird, since Tom wrote about "default feed", 
which made everyone think he didn't set any filters and was looking at the 
*actual* default feed given by the filter 14580 port, which certainly 
would not include any nearby DStar traffic (by default you don't get much 
anything at all, except for messaging and such things needed for 
transmitting igates).

On the aprsc mailing list Tom posted his client connection log file, which 
shows the filter settings. He's using a m/350 filter, but his client is 
not sending a position packet at all.

aprsc 2.0.16/2.0.17 would not use historic positions for the same callsign 
(received earlier or sent by another APRS-IS client) and instead insisted 
on waiting until the client sends a position packet to learn the position 
used for the m/ filter range calculation.

On the upside, 2.0.16 and later store the position of an unvalidated 
client in the client memory structure (even if the position packet is then 
dropped, since the user did not provide a passcode). That makes the m/ 
filter work for unvalidated clients.

>From 2.0.18 it will, again, use older positions for the username/callsign 
if the client does not send a position and an older position is stored in 
the historydb.

   - Hessu, AF5QT