[aprssig] aprsc 2.0.16/2.0.17 bug with m/ filter
hessu at hes.iki.fi
Thu Sep 10 11:22:05 EDT 2015
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
> 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
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
- Hessu, AF5QT
More information about the aprssig