Digipeated packet with empty path

[PhirePhly]

@W8VFR reports Aprx digipeating a packet with an empty path:

2016-11-16 01:04:19.662 W8VFR-8 R W8VFR-3>APRX28:/010418h3938.06NI08421.26W#33KM digigate
2016-11-16 01:04:19.665 W8VFR-8 T W8VFR-3>APRX28:/010418h3938.06NI08421.26W#33KM digigate

Please add any insight as to the frequency of these errors, and attach your complete config file for Aprx.

[w8vfr]

Still happening. I will attempt to verify this is really transmitting out to RF in the next few days. My config is also posted for reference below.

2016-11-17 00:18:54.758 W8VFR-8 R N8VKX-10>APRX28:/001851h3951.44NI08432.96W#33KM digigate 2016-11-17 00:18:54.761 W8VFR-8 T N8VKX-10>APRX28:/001851h3951.44NI08432.96W#33KM digigate

File name for this install: aprx_2.8.2-12-g820690e_raspi.deb (I simply don't remember where I got this from.) Running direwolf sound card decoder, connected with 127.0.0.1:8001 (see config)

myloc lat 3955.22N lon 08437.51W
mycall W8VFR-8

<aprsis>
#server    finland.aprs2.net
server    third.aprs.net
passcode 8348
filter m/25
</aprsis>

<logging>
pidfile /var/run/aprx.pid
rflog /var/log/aprx/aprx-rf.log
aprxlog /var/log/aprx/aprx.log
</logging>

#DIREWOLF #################### 
<interface>
tcp-device 127.0.0.1 8001 KISS
callsign $mycall
tx-ok true 
</interface>
##############################
<beacon>
beaconmode radio
cycle-size 10m
beacon symbol "I#" type "!" timefix file /root/posPacket
</beacon>

<beacon>
beaconmode radio
cycle-size 21m
beacon symbol "I#" type "!" timefix file /root/posPacket via VFR2-2
</beacon>

<beacon>
beaconmode aprsis
cycle-size 15m
beacon symbol "I#" type "/" timefix file /root/posPacket1
</beacon>

<digipeater>
        transmitter  $mycall
<source>
        source     $mycall
                relay-type  third-party  #third-party=W2 directonly=W1
                        viscous-delay  0

#### Buddy List #####
filter b/KS9N*
filter b/KD8LXB-12
filter b/W8VFR
filter b/KD8QFM*
filter b/KD8FQQ*

#Aircraft > WIDE1-1 ########
filter -b/N486JT
filter -b/N531EM
filter -b/N486JT
filter -b/N553KM
filter a/40.3533/-84.8529/39.8172/-084.4217
filter t/mn

<wide>
maxreq 2 
maxdone 2 
keys WIDE,VFR
</wide>

</source>
        <source>
                        source        APRSIS
                        relay-type    third-party  # Must define this for APRSIS source!
                        viscous-delay  0    # Recommendation: 5 seconds delay to give # RF delivery time make itself known.
                        ratelimit      60 120      # default: average 60 packets/minute,
        </source>                          #          burst max 120 packets/minute
</digipeater>

[PhirePhly]

You have your W8VFR-8 source defined as a third-party type: relay-type third-party This is meant to be used for APRS-IS sources to encapsulate packets in APRS third party frames. Apparently doing this on a standard APRS interface other than APRS-IS causes Aprx to unconditionally digipeat packets.

What happens if you change the source to being digipeated?:

<source>
  source     $mycall
  relay-type  digipeated
  viscous-delay  0
  [...etc...]

Your comment #third-party=W2 directonly=W1 seems to imply that you think third-party will handle WIDE2 paths, which is incorrect.

Other comments on your config: If you'd like to use proportional pathing for your RF beacon, the recommended method is to list all the iterations of paths in one beacon block so they're deliberately spread across the period instead of defining independent cycles for each path. I.e.:

<beacon>
beaconmode radio
cycle-size 20m
beacon symbol "I#" type "!" timefix file /root/posPacket
beacon symbol "I#" type "!" timefix file /root/posPacket via VFR2-2
</beacon>

This will cause the one beacon to alternate between direct and VFR2-2 at 10 minutes between any beacon instead of sometimes putting out a direct beacon very close in time to an identical "via VFR2-2" beacon.

You are also defining WIDE as an untraced alias, but by default it is defined as a traced alias, so I don't think that <wide> block is doing what you want. I'd also encourage you to change it to a <trace> block so Aprx performs callsign substitution. This would cause paths to change from "WIDE2-2" to "W8VFR-8*,WIDE2-1" instead of only decrementing the alias to "WIDE2-1". This is preferred since it shows which digipeater handled the packet.

[w8vfr]

Thanks very much for the feedback! I changed the beacon and 'wide' to 'trace'. I will check this soon, but in the past 'third-party' vs 'directonly' entry only seemed to respond (digi) packets on second hop with it set to 'third-party' thus the comment in the config to remind me. I have also set this to 'directonly' and will see if it responds to 2nd hop requests, ie W2 digi via grep results from an adjacent station and report back.

[PhirePhly]

directonly will only respond to packets which have not be digipeated already. If you want to provide second-hop service, you want the relay-type to be digipeated

[w8vfr]

I have changed it to digipeated. (Sorry about that, I had RTM, but it has been a good while back....). Yes, I do wish to provide 2nd hop service but only in the LSA (Limited Service Area) of filter a/40.3530/-84.8600/39.8000/-084.4200, and that seems to work well. Any comment on the placement of filters as they are parsed in the list? Is it better to place the buddy list first before are filter or does it matter? I want the buddy list to always digi, no matter if outside the area filter.

[PhirePhly]

I can't remember exactly what the behavior is for the filter handling, but I'd guess it jumps out at the first positive match, so I'd keep it in the order you have shown; positive buddies, negative buddies, service area, messages/NWS. It's how I'd write the config too.

[PhirePhly]

Can I get confirmation that digipeated has solved your problem so we can close this ticket?

[w8vfr]

Please close it Sir. The digipeated parameter did the trick. I simply don't know why I didn't see that to begin with.

Thanks

(PS, are you a professional tower climber? I work in the wireless industry, and around them frequently.)