Help me block these packets from being TX-Gated please

[theisa...@gmail.com]

Hello. I'm trying to limit the amount of unnecessary digipeating in my area, and I've got my transmissions down quite a bit, but am still working on fine tuning my setup. I have one packet in particular for this post, but I have some questions pertaining to other types as well, and best practices. 

First - here's my log entry for what was sent out:

2013-09-18 16:36:20.014 KC9UOQ-2  T KC9UOQ-2>APRS,WIDE1-1:}WF5X-12>APWW10,TCPIP,KC9UOQ-2*:>181636zNo op present, try WF5X instead

That station is over 150 miles away, but I don't believe that packet has any location data, so I can't block by that. Here's my debug captured during that packet:

.. igate from aprsis

interface_receive_3rdparty() aif=0x31884, aif->digicount=1

pbuf_alloc(55,54) -> 0xb6ef48d4

.. parse_aprs() rc=OK  type=0x8100 srcif=APRSIS tnc2addr='WF5X-12>APWW10:>181636zNo op present, try WF5X instead'  info_start='>181636zNo op present, try WF5X instead'

pbuf_free(0xb6ef48d4)

## produce 3rd-party frame for transmit:

ax25hdr 82 a0 a4 a6 40 40 60 96|86 72 aa 9e a2 64 ae 92|88 8a 62 40 03  = APRS  0K|C9UOQ2WI|DE1 .

 tnc2addr = KC9UOQ-2>APRX27,WIDE1-1

pbuf_alloc(94,95) -> 0xb6ef48d4

.. parse_aprs() rc=OK  type=0x100 srcif=APRSIS tnc2addr='KC9UOQ-2>APRX27,WIDE1-1:}WF5X-12>APWW10,TCPIP,KC9UOQ-2*:>181636zNo op present, try WF5X instead'  info_start='}WF5X-12>APWW10,TCPIP,KC9UOQ-2*:>181636zNo op present, try WF5X instead'

## process source filter

 .. other not interested

historydb_insert_heard(APRSIS) v=(nil)

filter_process_one() type=r  '-r/41.04/-85.13/-50'

filter_process_one() type=t  't/poimsnw'

filter says: 1 (accept)

filters say: send!

historydb_lookup(WF5X-12) -> i=50 .. no match

 .. other not interested

historydb_insert_heard(APRSIS) v=(nil)

Send to digipeater

digipeater_receive() from APRSIS, is_aprs=1 viscous_delay=5

1379522175 ENTER VISCOUS QUEUE: len=1 pbuf=0xb6ef48d4

So, it passes both of my filters (1 for range, and 1 for type), and gets digipeated. But, its 150 miles away, and is irrelevant to HAMs in my area. So, given this packet data, how do I block this packet (and packets like it) from being gated out of my station? I don't want to blindly put in rules for W1*, W2*, W3*, etc for calling stations that aren't normally in my area, because that's a disservice to them when they are passing through. 

Here's my relevant source blocks:

<aprsis>

   server   noam.aprs2.net

   filter  "-r/41.04/-85.13/-50"

   filter  "-t/t"

</aprsis>

<digipeater>

   transmitter       $mycall

   ratelimit         60 120

   srcratelimit      4 8

   <trace>

      maxreq         3

      maxdone        3

      keys           TRACE,WIDE

   </trace>

   <wide>

      maxreq         3

      maxdone        3

      keys           TRACE,WIDE

   </wide>

   <source>

      source              $mycall

      relay-type          digipeated

      regex-filter data   "W8FY-"

      regex-filter data   "N9WNH-3"

      regex-filter via    "N9WNH-3"

      regex-filter source "N9WNH-3"

      filter              "-t/tow"

      filter              "-r/41.04/-85.13/-50"

      filter              "t/pimqsun"

   </source>

   <source>

      source              APRSIS

      via-path            WIDE1-1

      msg-path            WIDE1-1

      relay-type          third-party

      viscous-delay       5

      regex-filter data   "W8FY-"

      regex-filter data   "N9WNH"

      filter              "-r/41.04/-85.13/-50"

      filter              "t/poimsnw"

   </source>

</digipeater>

The other problem I'm having, is that my regex-filters aren't working. I still digipeat packets from N9WNH that are heard via RF. There are servera other digis that are "misbehaving" in my area, and I'd like to not digipeat them as well.

Thanks for any help,

TI

[Geoffrey F4FXL]

Hi,

First of all remove any server side filters (the ones in APRSIS section), let the server decide which packets it is going to send you.
Use filters in the corresponding source section instead.

The packet you want to ignore is a status packet. adding
filter -t/s
to the APRSIS source will prevent status packets to get from APRSIS to RF.

Hope this helps,
Geoffrey F4FXL

[theisa...@gmail.com]

Geoffrey,

Help me understand your first paragraph. Why would I not want to limit traffic coming from the internet to my iGate? Am I missing packets that I should normally be seeing? If I eliminate all rules in that section, what are the default rules to limit? I know if I put in a statement such as:

 filter m/1000

I'll see a bunch of packets head my way. So, if there are no rules there, what does the server default to?

Also, what types of packets should I NOT digipeat or Gate? I've searched around, and the only thing I see is a rule that says "t/p", and that's it. I know that my area has used NWS objects during severe weather, so I know that I want to gate "t/n" as well. But besides "-t/s", what else should I exclude and why?

Thanks for helping me understand,

TI

[Heikki Hannikainen]

On Sun, Oct 6, 2013 at 5:57 PM, <theisa...@gmail.com> wrote:
> Help me understand your first paragraph. Why would I not want to limit
> traffic coming from the internet to my iGate? Am I missing packets that I
> should normally be seeing? If I eliminate all rules in that section, what
> are the default rules to limit? I know if I put in a statement such as:
> filter m/1000
> I'll see a bunch of packets head my way. So, if there are no rules there,
> what does the server default to?

I wrote that bit of the server code in the aprsc server application.
In a normal igate setup you should not need to set any filters for the
APRS-IS server. The IS server will, by default, only send you the
necessary packets to enable two-way APRS messaging for any stations
within your igate's service area.

The server's filtered/igate port (14580) has special functions to
enable two-way messaging for your igate, even with the default of
empty filter string. The server keeps track of stations which your
igate has heard from the RF side within the past 3 hours, and forwards
any messages destined to those users to your igate. You can see the
number of stations in the "heard" list as the MsgRcpts counter on an
aprsc server's status page: http://finland.aprs2.net:14501/

After a message, the server will also give your igate a "courtesy
position" packet (the last position packet of the originator of that
message) which your igate should automagically igate (without any
special configuration).

javaprssrvr does the same thing, aprsc mimics it.

Additional filters are only needed if you really need to pass
something else than messages from the APRS-IS to RF. That should be
done very, very carefully, if at all. Some people accidentally forward
a huge amount of traffic from IS to RF, causing duplicate & delayed
packets and quadrupling RF channel traffic.

- Hessu, OH7LZB

[theisa...@gmail.com]

Heikki,

So the server doesn't know the area I'm covering, it only knows what packets I've heard, so it sends me relevant packets back? If that is true, then it would never know to send me national weather service (NWS, t/n) packets, nor would it know to send me objects for repeaters or events in my area either, correct? If I want to gate those items in my area locally, I need to add filters to my APRSIS section, correct? Or is there some magic that it does to learn my area of coverage based on packets heard, and sends me them anyway?

Thanks,

TI

BTW: Thanks for contributing the code. Ham radio lives on because of volunteers. 

[Geoffrey F4FXL]

Heikki explained it quite well, here is an example to expand on this.

A basic Igate should only TXGate messages an an associated position packet.

Let's consider the following scenario :
Station A is near IGate Gate1, A position packets make it to the internet using Gate1
Station B is near IGate Gate2. B position packets make it to the internet using Gate2
A and B cannot ear each other over RF.

A sends a message to B. Thanks to the position packets the APRSIS servers know which IGate to use to reach B.
So the following will happen
A sends the message to B
Gate1 receives the message
The server to which Gate2 is connected sends the message to Gate2 and the last position packet of A
Gate2 sends the message and the position packet to RF.

When no rules are configured at the IGate this is the default behavior of most servers.

You are right, to gate the weather objects you have to add filters to your APRSIS section. To make sure you only gate the objects relevant to your area you can additional reject filters in the source section.

Unfortunately there is no magic to learn which area your igate is covering and gate only what is inside this area.

73
Geoffrey F4FXL

[Lynn Deffenbaugh]

To gate NWS messages to your local RF area, don't use a t/n as that will get you EVERY NWS messages for the entire planet.

Refer to http://www.aprs-is.net/wx/ for a good description and use the lists provided to determine which NWS offices (CWA) that support your area.  Then use a p/ (prefix) filter to bring in just those NWS messages (like p/MLB for my area here near Melbourne, Florida).

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

[Erik Schott]

Dear All,
I don't understand why aprx (2.08 - svn555 on a Raspberry - connecte to T2 Iceland) and APRSIS server is not behaving as described above.
step one: I removed the filters from the aprsis section.
step two: I have the following digipeater section

<digipeater>
    transmitter         $mycall
    <source>
        source              $mycall
       relay-type          directonly
        ratelimit            60 120
        filter                  a/52.53083/06.34767/52.12633/07.226667
        filter                 -b/pa1ww*
        filter                 -b/pd7mtp*
        filter                 -b/pd7mtp-s
    </source>
    <source>
        source              APRSIS
        relay-type         third-party
        viscous-delay   5
        ratelimit            60 120
         filter                 a/52.53083/06.34767/52.12633/07.226667
         filter                 -b/pa1ww*
         filter                 -b/pd7mtp*
         filter                 -b/pd7mtp-s
      </source>
</digipeater>

Test:
The logfile shows the following stations being sent to my igate from APRSIS, although they are almost all outside the service areabox and are not heard by the igate on RF. They are not digipeated though, except when in the area box. So the filters in the digipeater section seem to work.
But I understood that the server would solve what to sent to me and what not. So why is the server that many data to me. ?

Erik

2013-10-30 23:33:01.230 APRSIS R DO7VLR-5>APSAAR,TCPIP*,qAS,DO7VLR:@302333z4923.07N/00712.39E_270/000g000t030r000p000P000b09900h38/fWD, Hangard / Ostertal, 280m ASL, HUGER WM918 {UIV32}
2013-10-30 23:33:01.230 APRSIS R F1ZDW-S>APDG01,TCPIP*,qAC,F1ZDW-GS:;F1ZDW B *302332z4842.52ND00252.01EaRNG0031 440 Voice 439.75000MHz -7.6000MHz
2013-10-30 23:33:01.158 APRSIS R DB0WHV-B>APDG02,TCPIP*,qAC,DB0WHV-BS:!5330.95ND00808.72E&RNG0025 440 Voice 439.49375MHz -7.6000MHz
2013-10-30 23:33:00.572 APRSIS R PA3FRI-9>U2TSQ3,WIDE1-1,qAR,PI1FRI-3:`zJbp"j>/`"3u}438.875MHz T088 -760 Martin with Yaesu FTM350_"
2013-10-30 23:33:00.438 APRSIS R PI1RWD-9>APD225,TCPIP*,qAC,FIRST:!5319.45NI00559.15E&I aprsd Linux APRS Server van PI8RWD
2013-10-30 23:33:00.366 APRSIS R DO7VLR>APSAAR,TCPIP*,qAC,DO0YA-IS:=4923.07N/00712.39E-Lukas aus Neunkirchen/Saar <OV-Q13> {UIV32}
2013-10-30 23:33:00.029 APRSIS R DB0GV-2>APU25N,DB0GV,DB0KT,qAr,DB0GV-2:<IGATE,MSG_CNT=0,LOC_CNT=80
2013-10-30 23:32:59.956 APRSIS R F1ZZF-2>APFD57,qAR,LX1CU-3:;430.100+T*111111z4922.53N/00607.88ErtOff +160 R30k F5ZDH (57)
2013-10-30 23:32:59.838 APRSIS R PA3WZ-C>APDG02,TCPIP*,qAC,PA3WZ-CS:!5247.90ND00643.86E&RNG0016 2m Voice 144,03750MHz +0,0000MHz
2013-10-30 23:32:59.750 APRSIS R PI1KMP>APTT4,WIDE1-1,WIDE2-1,qAS,PI1ZWL-11:!5233.29N/00555.18EQ
2013-10-30 23:32:59.617 APRSIS R DB0OI>APNU19,NULL,qAR,DO0ABB:!5216.37N/01031.55E#PHG3400 TU Braunschweig
2013-10-30 23:32:59.544 APRSIS R DB0DY>APNU19,WIDE2-2,qAR,DK6BA-15:!5210.06NS00754.24E#PHG2240 APRS+PR+Funkruf Lengerich JO32WE
2013-10-30 23:32:59.134 PA0ESH-11 T PA0ESH-11>APRS:}DJ2NL-10>AP4R10,TCPIP,PA0ESH-11*:;145.775-B*010001z5218.13N/00710.01Er 145.775MHz Toff -060 R30k Bad Bentheim DB0VQ
2013-10-30 23:32:59.133 APRSIS R F6KID-3>ID,qAR,F4DVK:>DIGI_NED: F6KID-3 Radio-Club RCN-EG
2013-10-30 23:32:58.928 APRSIS R G7JVN-7>U0URV6,WIDE1-1,qAS,G7JVN:`v<@l!][/`"4T}Dan Greywolf_#

[Lynn W Deffenbaugh (Mr)]

What APRS-IS server and port are you using? Some servers have ports
that provide a default filter which would then start delivering edata to
you.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

> --
> You received this message because you are subscribed to the Google
> Groups "Aprx software" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to aprx-softwar...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Erik Schott]

Hello Lynn

This is the server setting:

<aprsis>
    server        euro.aprs2.net
    passcode XXXXX   (korrekt code for my call)
    heartbeat-timeout 1m    
</aprsis>

At the time of recordig data, i was connected to tier2 in Iceland.

Erik

2013/10/31 Lynn W Deffenbaugh (Mr) <ldef...@gmail.com>

To unsubscribe from this group and stop receiving emails from it, send an email to aprx-software+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google Groups "Aprx software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/aprx-software/N8z_-n7tQMY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to aprx-software+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Erik
www.pa0esh.nl

[Lynn W Deffenbaugh (Mr)]

What is your callsign-SSID for the station in question?  I'd like to track down the server you're connected to currently and see what Filter it's :14501 status page shows for you.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

To unsubscribe from this group and stop receiving emails from it, send an email to aprx-softwar...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google Groups "Aprx software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/aprx-software/N8z_-n7tQMY/unsubscribe.

To unsubscribe from this group and all its topics, send an email to aprx-softwar...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Erik
www.pa0esh.nl

--
You received this message because you are subscribed to the Google Groups "Aprx software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aprx-softwar...@googlegroups.com.

[Erik Schott]

Lyn
Currently I am connected to T2MAZURY using port 14580

see below.....
2013-10-31 22:24:23.467 >> euro.aprs2.net:14580 >> # aprsc 2.0.7-g1091278 31 Oct 2013 22:24:23 GMT T2MAZURY 89.228.59.72:14580
Erik


Op woensdag 18 september 2013 19:03:52 UTC+2 schreef theisa...@gmail.com:

[Lynn W Deffenbaugh (Mr)]

Well, if I'm correct in guessing that your arpx instance's call is KC9UOQ-2 (by looking at the 3rd party packet, which is why it's a guess), you're no longer connected to http://mazury.aprs2.net:14501/

You can check this yourself by browsing to port :14501 on the server that you're actively connected to and then searching for your callsign.  The right-most column should show the filter your client is using which may answer why you are receiving the unexpected packets.

It is actually not good IGate software design to simply trust that anything coming from the upstream APRS-IS server should be gated to RF.  You will receive more packets from the server than you really expect to receive as it will forward to your IGate packets from every station that you've recently gated a packet from.  The IGate should make it's own decisions on what APRS-IS-received packets should go to RF based on message gating rules, "courtesy" posit rules, and any additional packets the operator might want to gate.  The APRS-IS server may send you more than that.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

--

[Erik Schott]

Lyn

Sorry, the digi's callsign  is PA0ESH-11 I know i shouldn't use 11 but for the moment i won't change...)

You can see what the APRS and RF log looks like using http://aprx-test.tk.

Note that the Raspberry is prone to stopping due to the i2ckiss protocol not being very robust.
I am testing it for our local area wideN-N digipeater, PI2TWE-2 as well as PI1SGM-2
They run with identical config files, especially regarding the area coverage.
I have just given the igate a fully restart, deleted all the logs and at the moment it seems to be behaving....

Erik




Op woensdag 18 september 2013 19:03:52 UTC+2 schreef theisa...@gmail.com:

Hello. I'm trying to limit the amount of unnecessary digipeating in my area, and I've got my transmissions down quite a bit, but am still working on fine tuning my setup. I have one packet in particular for this post, but I have some questions pertaining to other types as well, and best practices. 

[Lynn W Deffenbaugh (Mr)]

It shows a blank filter which is what it should be, so I think we can mark that one off as the source of the mystery outbound packets.

Port	Callsign	Address	Verified	Up	Last in	Software	Packets Tx	Packets Rx	Bytes Tx	Bytes Rx	Tx/Rx bytes/s	OutQ	MsgRcpts	Filter
14579	SP4XYI-10	44.165.69.254:38464	Yes	6s	6s	UI-View32 V2.02	0	2/0/0	71	211		0	1
14580	CT7ADH	195.23.175.126:2047	Yes	11m	6m	APRSIS32 2012/08/30-09:19	21	2/0/0	4572	232	6.9 / 0	0	1	m/80 r/39.25172/-8.57832/80 r/39.25160/-8.57814/80
14580	SP7YDD-4	44.165.69.250:7022	Yes	41m	11m	NOSaprs 2.0g	503	5/0/4	55548	425	52 / 0	0	1	m/200
14580	ON7KO-G	78.23.223.89:62229	Yes	51m	10m	DVRPTR-GPRS	0	5/0/0	11806	506	6.9 / 0	0	1
14580	PA0ESH-11	82.75.227.250:36274	Yes	1h42m	2m	aprx 2.07	29	29/11/0	26532	3071	0 / 0	0	4

I'm not an aprsc expert enough to interpret all of the other numbers though.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

--

[Erik Schott]

Lynn
It seems that until now, the iGate is behaving as explained before, while connected to T2MAZURY. So it may have to do with one of the other european tier 2 servers ?
Can't remember to whom i was connected that time.
The log now shows only those stations coming from APRSIS, which are being heard by my iGate.
I am now going to modify the config file from our WideN-N digipeater and see if that behaviour is replicated.
Thanks for the help so far.
Erik

[Lynn W Deffenbaugh (Mr)]

You're welcome, for whatever it was I did.  The main key is that if it seems to be happening again, get to the connected server's :14501 status port and see what filter aprx is using.  You can also telnet to the :14580 port on that server, simulate a logon and see if any data comes out.  As long as no filter has been specified and no packets have been gated, the :14580 port should not give back anything but the periodic heartbeat comment.

telnet <serverNameOrIP> 14580
user TEST pass -1

And wait to see what comes out.  To see what it looks like with packets, just change the 14580 to 10152, the full feed port.  To stop the flow, just exit your telnet client.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  The Tier2 servers have a standard that should be followed.  Any server operator is welcome to offer pre-filtered ports, but they're not supposed to do that on a standard port number.

[kg4pid]

Everyone using the program I2ckiss on the Raspberry Pi should consider updating to the lastest version. It doesn't fix all the problems but it doesn't stop anymore. We have been talking about this over on the "Raspberry Pi for Hams" Yahoo group.

 

http://groups.yahoo.com/neo/groups/Raspberry_Pi_4-Ham_RADIO/conversations/messages/2281

 

For those who don't have access here is a direct link to the new version of I2ckiss.

 

https://dl.dropboxusercontent.com/u/31910649/i2ckiss

 

Instead of crashing, I2ckiss now logs errors in SYSLOG and continues running.

 

Max