APRX digipeating unexpected RF->Igate data

[David Ranch]

Hello Everyone,

I'm using APRX to inject my 1200baud non-APRS packet node into APRS as an object and that works well - http://aprs.fi/#!call=a%2FKI6ZHD&timerange=3600&tail=3600 . I'm also using APRX to act as a simple digipeater for any traffic that has "KI6ZHD-5" or "SCLARA" in the UNPROTO path. Unfortunately, it seems it's also digipeating other unproto packets that do NOT have call in the packet's path:

http://aprs.fi/?c=raw&call=ND6C-6
--
2013-06-09 20:54:17 PDT: ND6C-6>MATT,KLPRC,KPAC,qAR,KI6ZHD:I can't hear kpac so dunno if that worked [Unsupported packet format]
2013-06-09 20:56:05 PDT: ND6C-6>MATT,KLPRC,KPAC,qAR,KI6ZHD:he may have gone QRT [Unsupported packet format]
2013-06-09 20:57:24 PDT: ND6C-6>MATT,KLPRC,KPAC,qAR,KI6ZHD:unproto doesn't work? [Unsupported packet format]
2013-06-09 20:57:34 PDT: ND6C-6>MATT,KLPRC*,KPAC,qAR,KI6ZHD:odd it connects right up [Unsupported packet format]
2013-06-09 20:57:44 PDT: ND6C-6>MATT,KLPRC*,KPAC,qAR,KI6ZHD:awesome [Unsupported packet format]
2013-06-09 20:57:55 PDT: ND6C-6>MATT,KLPRC,KPAC,qAR,KI6ZHD:I closed the loop on the south bay :) [Unsupported packet format]
2013-06-09 20:59:39 PDT: ND6C-6>MATT,KLPRC,KPAC,qAR,KI6ZHD:oh that is neat! [Unsupported packet format]
2013-06-09 20:59:49 PDT: ND6C-6>MATT,KLPRC,KPAC,qAR,KI6ZHD:yeah KLPRC -> KPAC is flakey [Unsupported packet format]
--

http://aprs.fi/?c=raw&call=KG6SJT&limit=50&view=normal
--

2013-06-04 11:18:37 PDT: KG6SJT>ID,KBERR*,qAR,KI6ZHD:KG6SJT/R KG6SJT-1/B
2013-06-04 12:09:10 PDT: KG6SJT>ID,KBERR*,qAR,KI6ZHD:KG6SJT/R KG6SJT-1/B
2013-06-09 07:35:44 PDT: KG6SJT>ID,KBERR*,qAR,KI6ZHD:KG6SJT/R KG6SJT-1/B
2013-06-09 08:00:29 PDT: KG6SJT>ID,KBERR*,qAR,KI6ZHD:KG6SJT/R KG6SJT-1/B
--

Many other examples exist for any remote packet systems that my machine can hear either directly or via other digipeated paths.  You can find my config here:   http://www.trinityos.com/HAM/CentosDigitalModes/etc/aprx.conf


Any ideas of why this is occurring and how to stop this incorrect digipeating?  I only see "rejected" lines in the /var/log/aprx/aprx.log and "R" received lines in the aprx-rf.log.  Is there any way to log what data is sent to APRS-IS much like what the aprx-rf.log is supposed to show on the RF side of things?

Thanks for the help
--David
KI6ZHD

[David Ranch]

I should have mentioned that I'm running aprx-2.06.svn514-1.el6.x86_64 compiled to Centos 6.4

--David

[IZ3GME Marco]

Hi David!
As workaround I would try to add a filter to digipeater source config.

your $0.02 are back ;)

73 de IZ3GME Marco

On 11/06/2013 02:57, David Ranch wrote:
>
> Hello Everyone,
>
> I'm using APRX to inject my 1200baud non-APRS packet node into APRS as
> an object and that works well -
> http://aprs.fi/#!call=a%2FKI6ZHD&timerange=3600&tail=3600 . I'm also
> using APRX to act as a simple digipeater for any traffic that has
> "KI6ZHD-5" or "SCLARA" in the UNPROTO path. Unfortunately, it seems it's
> also digipeating other unproto packets that do NOT have call in the
> packet's path:
>
> http://aprs.fi/?c=raw&call=ND6C-6
> --

> 2013-06-09 20:54:17 PDT: *ND6C-6
> <http://aprs.fi/?c=raw&limit=&call=ND6C-6>*>MATT,KLPRC,KPAC,qAR,KI6ZHD
> <http://aprs.fi/?c=raw&limit=&call=KI6ZHD>:I can't hear kpac so dunno if that worked
> *[Unsupported packet format]*
> 2013-06-09 20:56:05 PDT: *ND6C-6
> <http://aprs.fi/?c=raw&limit=&call=ND6C-6>*>MATT,KLPRC,KPAC,qAR,KI6ZHD
> <http://aprs.fi/?c=raw&limit=&call=KI6ZHD>:he may have gone QRT
> *[Unsupported packet format]*
> 2013-06-09 20:57:24 PDT: *ND6C-6
> <http://aprs.fi/?c=raw&limit=&call=ND6C-6>*>MATT,KLPRC,KPAC,qAR,KI6ZHD
> <http://aprs.fi/?c=raw&limit=&call=KI6ZHD>:unproto doesn't work?
> *[Unsupported packet format]*
> 2013-06-09 20:57:34 PDT: *ND6C-6
> <http://aprs.fi/?c=raw&limit=&call=ND6C-6>*>MATT,KLPRC*,KPAC,qAR,KI6ZHD
> <http://aprs.fi/?c=raw&limit=&call=KI6ZHD>:odd it connects right up
> *[Unsupported packet format]*
> 2013-06-09 20:57:44 PDT: *ND6C-6
> <http://aprs.fi/?c=raw&limit=&call=ND6C-6>*>MATT,KLPRC*,KPAC,qAR,KI6ZHD
> <http://aprs.fi/?c=raw&limit=&call=KI6ZHD>:awesome *[Unsupported packet
> format]*
> 2013-06-09 20:57:55 PDT: *ND6C-6
> <http://aprs.fi/?c=raw&limit=&call=ND6C-6>*>MATT,KLPRC,KPAC,qAR,KI6ZHD
> <http://aprs.fi/?c=raw&limit=&call=KI6ZHD>:I closed the loop on the south bay :)
> *[Unsupported packet format]*
> 2013-06-09 20:59:39 PDT: *ND6C-6
> <http://aprs.fi/?c=raw&limit=&call=ND6C-6>*>MATT,KLPRC,KPAC,qAR,KI6ZHD
> <http://aprs.fi/?c=raw&limit=&call=KI6ZHD>:oh that is neat!
> *[Unsupported packet format]*
> 2013-06-09 20:59:49 PDT: *ND6C-6
> <http://aprs.fi/?c=raw&limit=&call=ND6C-6>*>MATT,KLPRC,KPAC,qAR,KI6ZHD
> <http://aprs.fi/?c=raw&limit=&call=KI6ZHD>:yeah KLPRC -> KPAC is flakey
> *[Unsupported packet format]
> --
> *
> http://aprs.fi/?c=raw&call=KG6SJT&limit=50&view=normal*
> --
> *
> 2013-06-04 11:18:37 PDT: *KG6SJT
> <http://aprs.fi/?c=raw&limit=&call=KG6SJT>*>ID,KBERR*,qAR,KI6ZHD
> <http://aprs.fi/?c=raw&limit=&call=KI6ZHD>:KG6SJT/R KG6SJT-1/B
> 2013-06-04 12:09:10 PDT: *KG6SJT
> <http://aprs.fi/?c=raw&limit=&call=KG6SJT>*>ID,KBERR*,qAR,KI6ZHD
> <http://aprs.fi/?c=raw&limit=&call=KI6ZHD>:KG6SJT/R KG6SJT-1/B
> 2013-06-09 07:35:44 PDT: *KG6SJT
> <http://aprs.fi/?c=raw&limit=&call=KG6SJT>*>ID,KBERR*,qAR,KI6ZHD
> <http://aprs.fi/?c=raw&limit=&call=KI6ZHD>:KG6SJT/R KG6SJT-1/B
> 2013-06-09 08:00:29 PDT: *KG6SJT
> <http://aprs.fi/?c=raw&limit=&call=KG6SJT>*>ID,KBERR*,qAR,KI6ZHD
> <http://aprs.fi/?c=raw&limit=&call=KI6ZHD>:KG6SJT/R KG6SJT-1/B

> --
>
> Many other examples exist for any remote packet systems that my machine
> can hear either directly or via other digipeated paths. You can find my
> config here: http://www.trinityos.com/HAM/CentosDigitalModes/etc/aprx.conf
>
>
> Any ideas of why this is occurring and how to stop this incorrect
> digipeating? I only see "rejected" lines in the /var/log/aprx/aprx.log
> and "R" received lines in the aprx-rf.log. Is there any way to log what
> data is sent to APRS-IS much like what the aprx-rf.log is supposed to
> show on the RF side of things?
>
> Thanks for the help
> --David
> KI6ZHD
>

> --
> 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.
>
>

[Heikki Hannikainen]

On Tue, Jun 11, 2013 at 3:57 AM, David Ranch <dra...@gmail.com> wrote:
> I'm using APRX to inject my 1200baud non-APRS packet node into APRS as an
> object and that works well -
> http://aprs.fi/#!call=a%2FKI6ZHD&timerange=3600&tail=3600 . I'm also using
> APRX to act as a simple digipeater for any traffic that has "KI6ZHD-5" or
> "SCLARA" in the UNPROTO path. Unfortunately, it seems it's also digipeating
> other unproto packets that do NOT have call in the packet's path:
>
> http://aprs.fi/?c=raw&call=ND6C-6
> --
> 2013-06-09 20:54:17 PDT: ND6C-6>MATT,KLPRC,KPAC,qAR,KI6ZHD:I can't hear kpac
> so dunno if that worked [Unsupported packet format]
> 2013-06-09 20:56:05 PDT: ND6C-6>MATT,KLPRC,KPAC,qAR,KI6ZHD:he may have gone

I don't see anything in those packets that would indicate that your
node (KI6ZHD) is digipeating (i.e. retransmitting those packets on
RF).

It's just doing what an igate is supposed to do, and passing all
received packets to the APRS-IS (igating).

> http://aprs.fi/?c=raw&call=KG6SJT&limit=50&view=normal
> --
>
> 2013-06-04 11:18:37 PDT: KG6SJT>ID,KBERR*,qAR,KI6ZHD:KG6SJT/R KG6SJT-1/B

Same here, the packet has been digipeated by KBERR. KI6ZHD, after the
Q construct is the igate, not a digipeater in this path. If you see T
(Transmit) lines in your aprx-rf.log, then you're transmitting /
digipeating those packets.

Packets digipeated by your node are very unlikely to show up in
aprs.fi raw packets display, since your digipeater is also an igate,
and the later duplicate copies will be filtered in the APRS-IS.

- Hessu, OH7LZB

[David Ranch]

Hello Hessu,

Thanks for the reply!

 

I don't see anything in those packets that would indicate that your
node (KI6ZHD) is digipeating (i.e. retransmitting those packets on
RF).

Correct.. it's not sending this traffic out on RF but it IS putting it out the Igate which I don't expect nor want.

 

It's just doing what an igate is supposed to do, and passing all
received packets to the APRS-IS (igating).

On classic packet, unless my specific callsign is put into the digi path, my station should NOT digipeat any traffic.  For APRS traffic, I understand that the digi path would need to include either WIDE1 or WIDE2 and unless it's present, the APRS packet should NOT be repeated.  This specific classic packet traffic in question does NOT have WIDE1/WIDE2 in their packet headers.  If I'm correct in my understanding, that means that APRX is incorrectly IGATEing (digi'ing to the Internet) aka.. a bug.  No?

 

Same here, the packet has been digipeated by KBERR. KI6ZHD, after the
Q construct is the igate, not a digipeater in this path. If you see T
(Transmit) lines in your aprx-rf.log, then you're transmitting /
digipeating those packets.

I'm not quite following you here but are you saying that if lines in the aprs-rf.log have the field populated with a "Q", that means those packets are being sent to the APRS-IS?   If I'm not following you correctly, is there a way to log packets that do get IGATEd so I can track this issue down?  Seems like a needed feature.

 

Packets digipeated by your node are very unlikely to show up in
aprs.fi raw packets display, since your digipeater is also an igate,
and the later duplicate copies will be filtered in the APRS-IS.

I'm seeing that the majority of packets that I transmit from my station (using the Linux kernel's AX.25 stack) is going out to the APRSIS.   Not good.

Is there an APRX configuration to DISABLE digipeating to APRS-IS while still being able to send APRS Objects into APRS-IS?   If no, it was also recommended to try configuring an APRS filter to prevent this behavior.  I'm not familiar with APRX's filtering syntax so I was curious if someone could either give me a proposed filter or point me to some documentation of how to filter out this unwanted traffic?

--David
KI6ZHD

[Heikki Hannikainen]

David,

On Sat, Jun 15, 2013 at 9:55 PM, David Ranch <dra...@gmail.com> wrote:
>> I don't see anything in those packets that would indicate that your
>> node (KI6ZHD) is digipeating (i.e. retransmitting those packets on
>> RF).
>
> Correct.. it's not sending this traffic out on RF but it IS putting it out
> the Igate which I don't expect nor want.

Ok. So it is not actually digipeating - it's igating, which is what an
igate is supposed to do. It might not be what you expect or what you
want, but that's what all igates are designed to do - they listen on
an APRS channel and transmit whatever they hear to the APRS-IS.

>> It's just doing what an igate is supposed to do, and passing all
>> received packets to the APRS-IS (igating).
>
> On classic packet, unless my specific callsign is put into the digi path, my
> station should NOT digipeat any traffic. For APRS traffic, I understand
> that the digi path would need to include either WIDE1 or WIDE2 and unless
> it's present, the APRS packet should NOT be repeated. This specific classic
> packet traffic in question does NOT have WIDE1/WIDE2 in their packet
> headers. If I'm correct in my understanding, that means that APRX is
> incorrectly IGATEing (digi'ing to the Internet) aka.. a bug. No?

Nope. Its gating the packets to the internet. "Digipeating" means
"retransmitting on RF" in APRS terminology.

And igates are supposed to igate *all* traffic that they hear, so that
RF APRS stations do not need to know which igates there are in an
area. The WIDE aliases request digipeating from any digipeaters that
might be in an area. There's no such method to request igating to the
Internet, since the default action by all igates is to gate all
packets they hear to the Internet.

In fact, there is an opposite method to request igates to *not* gate
packets, by appending "NOGATE" or "RFONLY" in the packet path
(WIDE1-1,WIDE2-1,NOGATE for example). Unfortunately not all igates
honour it, though. aprx does.

> I'm seeing that the majority of packets that I transmit from my station
> (using the Linux kernel's AX.25 stack) is going out to the APRSIS. Not
> good.

It's working fine, then. It's doing what all igates are supposed to do.

> Is there an APRX configuration to DISABLE digipeating to APRS-IS while still
> being able to send APRS Objects into APRS-IS?

It's not digipeating, it's gating to internet. And no, I don't think
there is, since igates are supposed to, well, igate.

> If no, it was also
> recommended to try configuring an APRS filter to prevent this behavior.

I don't think you can set up such a filter in aprx (or any other igate
software, actually). There are filter settings to limit which packets
are digipeated (retransmitted on RF), but you're actually talking
about igated packets, and calling it "digipeating" probably confused
someone to suggest setting up a filter.

> I'm
> not familiar with APRX's filtering syntax so I was curious if someone could
> either give me a proposed filter or point me to some documentation of how to
> filter out this unwanted traffic?

Why is it unwanted, if you're transmitting it yourself? I don't understand.

Are you perhaps running APRX on a regular packet radio channel with
non-APRS traffic for some reason?

- Hessu

[David Ranch]

Hello Heikki,

Thanks for the relpy.

>    Ok. So it is not actually digipeating - it's igating, which is what an
>    igate is supposed to do.

Ok.. thanks for correcting me on the terminology.

>    And igates are supposed to igate *all* traffic that they hear, so that
>    RF APRS stations do not need to know which igates there are in an
>    area. The WIDE aliases request digipeating from any digipeaters that
>    might be in an area. There's no such method to request igating to the
>    Internet, since the default action by all igates is to gate all
>    packets they hear to the Internet.

Interesting.. that's not what I would have expected.  So even if a remote APRS station has not configured ANY path like WIDE1 or WIDE2, an IGATE will forward those packets into the APRS-IS system?  Very surprising!

>    In fact, there is an opposite method to request igates to *not* gate
>    packets, by appending "NOGATE" or "RFONLY" in the packet path
>    (WIDE1-1,WIDE2-1,NOGATE for example). Unfortunately not all igates
>    honour it, though. aprx does.

I guess I'm looking for an APRX feature to do this ALL the time for all packets.  Possible?

>    Why is it unwanted, if you're transmitting it yourself? I don't understand.
>
>    Are you perhaps running APRX on a regular packet radio channel with
>    non-APRS traffic for some reason?

That's exactly what I'm doing.  I'm using APRX on 145.050 for two reasons:

1) I want to advertise my packet station (object) on the APRS-IS maps just as a FYI thing

2) I want my station to act like a basic digipeater on RF 145.050 like a classic TNC can.  Linux's AX.25 kernel stack nor it's AX.25 utilities can do this.  APRX does seem to work well for the RF digipeater functionality but it's also Igating that traffic which I *don't* want to do.


So, hopefully understand my goals here.  APRX seem like it does everything I want except I want to disable the RF to APRS-IS igating feature.   Maybe I need to ask for a feature enhancement to do what I want?  I suppose I could just hack the source to disable the igating functionality but the proper way would be to have this a configurable option to control the igating function w/o disabling the beacon into the APRS-IS ability.  I'm thinking something like:

     <interface>
        ax-25 $my-call
        tx-ok true
        igate disable  <-----------------  new
     </interface>

Possible?   If not, does anyone know of any software that might be able to do what I'm looking for?

--David
KI6ZHD

[Heikki Hannikainen]

On Sun, Jun 16, 2013 at 9:09 PM, David Ranch <dra...@gmail.com> wrote:
>> And igates are supposed to igate *all* traffic that they hear, so that
>> RF APRS stations do not need to know which igates there are in an
>> area. The WIDE aliases request digipeating from any digipeaters that
>> might be in an area. There's no such method to request igating to the
>> Internet, since the default action by all igates is to gate all
>> packets they hear to the Internet.
>
> Interesting.. that's not what I would have expected. So even if a remote
> APRS station has not configured ANY path like WIDE1 or WIDE2, an IGATE will
> forward those packets into the APRS-IS system? Very surprising!

Yes indeed, that's how all igates work.

A lot of stations transmit with WIDE* elements in the path at all
(i.e. they do not request any digipeating), for example flying things
like airplanes and high-altitude balloons which will be heard all
around the country. They'd hit all the digipeaters and all igates hear
them directly too, so there's no need to make all the digis in the
country to retransmit - that'd create a lot of useless extra traffic
on the network.

But they still wish to get igated.

>> Why is it unwanted, if you're transmitting it yourself? I don't
>> understand.
>>
>> Are you perhaps running APRX on a regular packet radio channel with
>> non-APRS traffic for some reason?
>
>
> That's exactly what I'm doing. I'm using APRX on 145.050 for two reasons:
>
> 1) I want to advertise my packet station (object) on the APRS-IS maps just
> as a FYI thing

Ok, you could either:

1) run a little script on the side to push the object on the APRS-IS
without running aprx
2) run aprx without any radio interfaces configured, just pushing the
beacon (I've done that myself)

> 2) I want my station to act like a basic digipeater on RF 145.050 like a
> classic TNC can. Linux's AX.25 kernel stack nor it's AX.25 utilities can do
> this. APRX does seem to work well for the RF digipeater functionality but
> it's also Igating that traffic which I *don't* want to do.

Instead of running aprx and having it do two different things which it
can do (digipeating, and object beaconing), but not igating (which is
its *main* feature), you could run two copies of aprx each doing one
thing. Or some other software altogether.

1) aprx without radio interfaces, configured to beacon the objects to aprs-is
2) another aprx for digipeating (with no aprs-is server configured)

*or*

2) axdigi, a standalone digipeater program for AX.25 (non-APRS)
digipeating, with no igate features

- Hessu

[Heikki Hannikainen]

On Mon, Jun 17, 2013 at 8:02 AM, Heikki Hannikainen <he...@hes.iki.fi> wrote:
> A lot of stations transmit with WIDE* elements in the path at all
> (i.e. they do not request any digipeating), for example flying things

That should, of course, read "with no WIDE* elements in the path at all".

> like airplanes and high-altitude balloons which will be heard all
> around the country. They'd hit all the digipeaters and all igates hear
> them directly too, so there's no need to make all the digis in the
> country to retransmit - that'd create a lot of useless extra traffic
> on the network.
>
> But they still wish to get igated.

> 2) axdigi, a standalone digipeater program for AX.25 (non-APRS)
> digipeating, with no igate features

axdigi doesn't appear to be in the ax25-apps/tools packages (apt-cache
search does not find it), but googling reveals that the source code
can be found on a number of FTP sites. Might need a few hacks to get
it running on modern Linux systems. And it's on Facebook too. :)

- Hessu