Re: Filters. IS/RF RF/IS on various ports.


Julian
 

Hi Robert,

XML
Tnx for clarifying that.

FILTERS
I'll look into that wikidot docket. Most importantly, it's good we kind of clarified the filters principle in APRSIS32. I have seen few questions on the net regarding this matter.
The -u/TOCALL was only an example. What I was aiming at was the -b/CALL (as per my 1st message in the thread). I run a WIDE1-1 digi and had these stations getting my rig finals red by beaconing every minute via WIDE1-1, WIDEn-N. Only few occasions. Now, don't get me wrong, I would not go out there, cancelling stations out on my digi. I always choose the amiable way, communication via email, APRS message. Communication is actuality compulsory in these situations, because of the mad traffic such behaviour can incur. It's just, sometimes, it takes a bit longer to get a response from the beaconing station. Beaconing every minute also drives many other wider digis nuts.

IS/RF RF/IS tickboxes on the APRSIS port only.
Thought this through a bit. These are probably only there by default (probably reuse of the same window in programming, on every port), but do not actually have any effect on the traffic on the APRSIS port itself. APRSIS is either disabled or enabled. If no RF port present, then, of course, no RF IS IS RF traffic will take place on the APRSIS port anyway. If RF port is present, APRSIS enabled and the IS RF RF IS boxes ticked on the RF port, then yes, traffic to/from Internet would take place. I am still not sure whether I am in a bit of a  logical error here.
Was there someone saying that IS RF traffic doesn't take place anyway, whether or not that box is enabled,  as a security measure to avoid RF flooding, and it has to be enabled somewhere else, or in a developer version of APRSIS32? Can't remember exactly.


Julian, M0IPU YO3FCA.



---In aprsisce@..., <kb8rco@...> wrote :

XML
The XML with a date extension is from the last upgrade.  You should also have an EXE file with a date extension (the same date extensions).    This is for the case where something doesn't work, you can quickly go back to the previous working version by deleting the newer, and removing the date extension.

Filters
I believe you are correct, you cannot filter RF received.  Anything received on RF is handled (DIGI, etc.).  However, you can use the <DigiXform> to ignore or limit hops by changing the response to WIDEn-N requests as shown on the wiki: http://aprsisce.wikidot.com/doc:digipeating

I think the general philosophy is that if it came in on RF it is safe to send on RF.  On the other hand, what you get from the internet, you need to ensure it meets amateur radio regulations.

Are you trying to filter RF data as in prevent your station from DIGI'ing a request just because of a callsign?
  Most TOCALLs are ALTNETs or just an indication of the APRS app in use.  Why would you block certain ones from being DIGI'ed?

Robert Giuliano
KB8RCO





From: "iulianp@... [aprsisce]" <aprsisce@...>
To: aprsisce@...
Sent: Monday, June 25, 2018 4:08 PM
Subject: Re: [aprsisce] Filters. IS/RF RF/IS on various ports.

 
Filters.
I had a bit of a 'revelation' this morning. I came across a couple of similar unanswered questions somewhere else on the net. I believe the filters only apply to the RF IS / IS RF traffic and they do not interfere at all with the RF digipeater function in the APRSIS32 program. In other words, if I used APRSIS32 as a WIDEn-N RF digipeater and wanted to block a certain TOCALL, for example, the filter -u/TOCALL won't have any effect on the digipeated packet. That TOCALL won't go though the RF IS though in my APRSIS32. I am yet to do some experiments on this.

RF IS IS RF vs APRS-IS disabled/enabled.
I also need to experiment with the RF IS tick boxes on the RF port and APRS-IS port (enabled and disabled). See the outcome.

XML
Truly, I haven't seen many xml files in the programs folder! There is one more in my case. It has a date extension added to it. Probably another backup.

"Lynn's implementation of filters"
I have seen something in the manual, pg 38.

Any comments and suggestions on the above from pax who have already mastered APRSIS32, more than welcome.

73, J, YO3FCA M0IPU



Join APRSISCE@groups.io to automatically receive all group messages.