Full-feed is not actually full? Possible bug?

[Geoffrey Merck]

Hi All,

Last weekend I fiddled around with Trackdirect and installed the complete stack onto a new machine.

As per recommendation I also installed a dedicated APRC server. This trackdirect APRSC was connected to rotate.aprs.net, port 10152 full feed. It all worked flawlessly.

Today I decided to connect the trackdirect to our club official T2 server T2F5KAV. And noticed something really weird.

We run some digipeater-igates (F5ZEE, F5ZSG) but they only beacon over RF, not directly into IS. The reason is that we do not see a need to beacon on APRS-IS  because all RF lands into IS anymay.

These digipeater-igates are also connected to T2F5KAV.

This evenning I went to my trackdirect and noticed the igates were not showing up. As soon as I changed the trackdirect-aprsc uplink back to another server boom the F5ZEE and F1ZSG digipeater igates were showing up again!

Unless I am missing something, the igates connected to a server and only beaconing over RF will not show up in the full feed of that server!

[Lynn W Deffenbaugh (Mr)]

Are you using unique APRS-IS signon callsign-SSIDs across everything?   And especially, the signon callsign-SSID should NOT match any actual RF-only station.   Otherwise, those packets will be dropped as possible looping packets.   At least, that's my understanding of one of the self-protection features of the APRS-IS.

This protection only occurs within a single server, so if you connect to a different APRS-IS server than the one that is receiving the RF packets, they won't be suppressed.

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

--
You received this message because you are subscribed to the Google Groups "aprsc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aprsc+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/aprsc/92c055c8-c3a1-4560-91a3-deb439940143n%40googlegroups.com.

[Geoffrey Merck]

Hy Lynn,

the trackdirect-aprsc connects to the full feed using F4FXL-AP

the digipeater-igates connect using their own callsign F5ZEE and F1ZSG which also connect using the same callsing they use on-air.

I will try to cchange their sign-on callsign to something else and test again.

[Heikki Hannikainen]

Hi,

Right, the APRS-IS servers (javaprssrvr, aprsc) drop packets which have
the source callsign of a validated client of that server, if that packet
comes in from some other socket than the socket of that client. This is a
standard loop prevention mechanisms.

So if OH7LZB-1 is directly connected to T2FINLAND, and packets with the
source callsign of OH7LZB-1 come in from anywhere else than directly from
OH7LZB-1 itself, the server drops them. The server expects OH7LZB-1 to
pass in its own packets directly.

It breaks some use cases, like figuring out which other iGates can hear
the packets sent by an iGate (when that iGate is configured to send out
beacons only on RF), but then again, the APRS-IS is not designed for that
use case at all, and the duplicate packet filtering mostly breaks it
already.

It breaks more if you try to send APRS text messages *only* on RF while
being connected to an APRS-IS server and expect that APRS-IS server to
carry those packets; the workaround is to send the packets to APRS-IS too,
not just RF.

It's one of those features that were in javaprssrvr, that I have not
changed; it'd take some figuring out what kind of packet loop cases might
reappear if this packet dropping would be removed. For example, I am
afraid some iGates might potentially have bugs where they might
accidentally retransmit their own packets to RF if they came in from the
APRS-IS again.

> To view this discussion on the web visit https://groups.google.com/d/msgid/aprsc/9d21c127-1dff-444a-a5cc-7c65f305b00bn%40googlegroups.com.
>
>

- Hessu

[Geoffrey Merck]

Thanks  for the clarification.

"So if OH7LZB-1 is directly connected to T2FINLAND, and packets with the
source callsign of OH7LZB-1 come in from anywhere else than directly from
OH7LZB-1 itself, the server drops them. The server expects OH7LZB-1 to
pass in its own packets directly."

==> This is exactly the behavior I am observing.

"It breaks some use cases, like figuring out which other iGates can hear
the packets sent by an iGate (when that iGate is configured to send out
beacons only on RF), but then again, the APRS-IS is not designed for that
use case at all, and the duplicate packet filtering mostly breaks it
already."

==> This is the use case I had in mind with sending the packets only to RF. Observing the igate receiving my beacons works fine as long as I am observing it from another server.

"It's one of those features that were in javaprssrvr, that I have not
changed; it'd take some figuring out what kind of packet loop cases might
reappear if this packet dropping would be removed. For example, I am
afraid some iGates might potentially have bugs where they might
accidentally retransmit their own packets to RF if they came in from the
APRS-IS again."

==> With changing the sign-on callsign I was able to solve my issue. This means if there is such a buggy igate out there, it only takes changing of the login callsign to defeat this loop protection. Am I seeing this wrong?

73

Geoffrey

[Geoffrey Merck]

I made some further tests.... But the scenatio is a little bit different.

It seems like that any packet injected directly into the server does not show up on the full feed.....

For this scenario the setup is :
F5ZEE is logged in as F5ZEE-IG

It sends a packet into IS as F5ZEE

This packet never shows up on full-feed....

[Geoffrey Merck]

Nevermind my last message, all is fine, packets placed on IS by F5ZE are present on the servers full feed.