[aprssig] Jim's Improper APRS Software

[Jim Alles]

Vague, because I don't know what software Scott is using. Negative, because
he might want to look into this.

That most recent reply you noticed, is actually an old post, that I only
became aware of after reading comments in the source code for Dire Wolf.

There is a much more extensive description, and my test-bench setup in
previous posts, where it belongs - in that forum. although TL;DR.

and that 'filter' that you mis-quoted is a client side thing that allows
messages from the APRS-IS to be transmitted, while blocking anything *else*
from the server that has TCPIP in the path. Which is ALL of the packets
sent to try to decide if we heard an IGate. More from some servers, than
others.

The mash-up in the packets is because Dire Wolf choked on the lower case
letter in the q construct, on the way to RF. Yes, I know, it isn't supposed
to try that.

There is no doubt in my mind it is broken. Because I RTFM. And tested it.
And asked questions here (remember my seeming confusion)? And found a way
to search through all this. And read the source code. All to troubleshoot
what I observed as bad behavior, before going on air.

The needed temporary fix, as I see it, with no blessing (just yet) from the
author, is "FILTER IG 0 t/m | ( ! d/TCPIP/TCPXX )". This is specific only
to Dire Wolf, and has nothing to do with a server-side subscription.

I know it does work, and settles PTT down nicely, because I tested it.

I was trying to be discrete, throughout this tortuous month.

Peace, and goodnight.

Jim Alles
BAS Controls Technician
Penn State University
Penn State Amateur Radio Club (K3CR)




On Wed, Nov 30, 2016 at 10:06 PM, Kenneth Finnegan <
kennethfinnegan2007 at gmail.com> wrote:

> On Wed, Nov 30, 2016 at 3:33 PM, Lynn W. Deffenbaugh (Mr) <
> ldeffenb at homeside.to> wrote:
>
>> On 11/30/2016 6:06 PM, Jim Alles wrote:
>>
>> ​
>>  However, there is at this time an APRS software package that appears to
>> be not working properly. And provides the use of other, blocking-type
>> filters (client-side).
>>
>> Maybe I missed something, but to what is this referring?
>>
>
> My guess would be Jim is talking about Direwolf where someone posted
> saying that it seems like Direwolf is merging packets together, which
> didn't make much sense since they all looked like third-party packets with
> a liberal RF-gate filter configured to me.
>
> Jim came back with an RF-gate filter of "t/m | ( ! d/TCPIP/TCPXX )" to
> work around the issue until it was sorted out, which as best as I can tell
> RF-gates all message packets seen or not directly connected stations, which
> doesn't seem to change anything except trade one set of surplus gated
> packets for another. The thread lacked any clear identification of what the
> issue was or any exploration of root cause or a reproduction of the fault.
>
> In any case, not really escalated yet to "make vague negative comments
> about it on the SIG".
>
> --
> Kenneth Finnegan
> http://blog.thelifeofkenneth.com/
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20161130/8dad898d/attachment.html>