search

PhirePhly / aprx

A highly configurable APRS I-gate/Digipeater Daemon
http://thelifeofkenneth.com/aprx/
BSD 3-Clause "New" or "Revised" License
153 stars 68 forks source link

Filters break digipeater behavior #11

Closed PhirePhly closed 8 years ago

PhirePhly commented 9 years ago

Adding filters to a digipeater source block breaks standard WIDEn-N digipeating on that digipeater.

<digipeater>
    transmitter     $mycall
    <source>
        source            $mycall
        filter "-b/CALL*"
    </source>
</digipeater>

Bug reported by Beau bvdgroenendaal@gmail.com https://groups.google.com/forum/#!topic/aprx-software/qwh3UAJ3mAM

oh2mqk commented 9 years ago

Probably another logic error -- if a filter is defined at all, it says what to do. If no filter is defined, then digipeat default rules are applied.

It really should be "apply filters, non-matching result is to pass on to default rules". But for "-" prefix the non-match path is apparently "reject all". Oops.

w8vfr commented 9 years ago

Just curious if this bug is 'targeted' for a fix anytime soon. I have several digIgates on the air, and I do indeed wish to use the filtering feature in the digi section. If I can be of any help in testing a new version, please contact me.

Thanks Curtis W8VFR

PhirePhly commented 9 years ago

I was hoping to start poking at it after this weekend; currently running communications support for a triathlon this weekend. I'd expect to have a patch up within 7 days, life permitting.

w8vfr commented 9 years ago

Fantastic! I am about to re-arrange several digi/igate stations and move into aprx via Raspberry-PI. The "broken" but handy filter feature is ideal for the very busy Cincinnati / Dayton, OH area I am in. Hamvention is comming soon!

Thank You for your efforts!

samwathegreat commented 9 years ago

Just wanted to say thanks to PhirePhly for taking this filter bug on. Looking forward to being able to use the filter feature without losing normal digi operation.

You Rock!

Sean KS9N

w8vfr commented 9 years ago

I now have the 2nd Raspberry Pi2 based aprx unit up and running. Awaiting the patch.

Thanks to all,

73s

W8VFR

samwathegreat commented 9 years ago

Any updates?

PhirePhly commented 9 years ago

What happens if you use a source block such as:

 <source>
     source         $mycall
     filter         -b/W6KWF-5        # always block these
     filter t/*
 </source>

Page 40 of the aprx manual, item 8.1, states that you need to match at least one filter to be digipeated if you use any filters, which seems to be a pretty major assumption in how the filtering is architected. This example would then allow ALL types of packets, except those from W6KWF-5.

I've performed only minimal testing, since I can't currently find any of my VHF antennas.

samwathegreat commented 9 years ago

Thanks for looking into this!!! So perhaps there was no bug at all and our syntax was just incorrect.

When I have a chance, I will test and report back.

KS9N

w8vfr commented 9 years ago

Initial testing shows good results. I will update after it 'soaks' a while. Thank you for looking into this issue.

PhirePhly commented 9 years ago

So perhaps there was no bug at all and our syntax was just incorrect.

I would certainly say there is a bug here, but it's with the defined behavior and/or the documentation and not the implementation. Blacklisting individual problematic stations is likely needed often enough that it should be called out as an explicit example in the manual, and shouldn't stump all of us for two months.

w8vfr commented 9 years ago

Excellent idea, putting an example into the manual. Please advise if i can assist in any way. So far the station has performed 100% since the "filter t/*" addition in the digi section.

73s, Curtis W8VFR

On Sat, Aug 8, 2015 at 11:47 PM, Kenneth Finnegan notifications@github.com wrote:

So perhaps there was no bug at all and our syntax was just incorrect.

I would certainly say there is a bug here, but it's with the defined behavior and/or the documentation and not the implementation. Blacklisting individual problematic stations is likely needed often enough that it should be called out as an explicit example in the manual, and shouldn't stump all of us for two months.

— Reply to this email directly or view it on GitHub https://github.com/PhirePhly/aprx/issues/11#issuecomment-129101761.

So we fix our eyes not on what is seen, but on what is unseen, since what is seen is temporary, but what is unseen is eternal. 2 Corinthians 4:18

Why use 'Windows', since there is a door? -> Linux!

w8vfr commented 9 years ago

I'd like to comment on this again after several stations have 'soaked' a while running with the suggested " filter t/* " appended to the -b/CALL list.

So far, no issues. I would consider this issue resolved, but again would ask for an addition to the manual to detail the 'correct' filter procedure. (Now if we can just figure a way to stop the excess PATH variable abuse most aprs running hams seem to like.... we would be good! )

w8vfr commented 9 years ago

Last comment was 12 days ago. Five sites running this configuration, no issues. Also added radius and area filter to the mix, again no issues.

Solved issues it would seem.