[aprssig] IGATE message routing bug?

Pete Loveall AE5PL Lists hamlists at ametx.com
Sat Nov 19 23:17:07 CST 2016


Lynn is correct, the server is not the regulator of messaging.  Yes, the last heard table a server keeps -for each client- on filtered ports does regulate if a message is sent to the connected IGate to be gated to a recently heard station but the decision to gate to RF is left up to the IGate.  Remember, however, that if even one packet of -any- type is gated to APRS-IS by the client (IGate), that originating station makes it on the server's last heard list for that client and messages for the gated station will be sent to the client (IGate) to decide to gate to RF.  Where this breaks down is if you are running a RX-only IGate, it will NEVER gate to RF and therefore, it will NEVER support messaging on RF.  When you have a plethora of RX-only IGates and people running short paths to be a good citizen to cut down on RF congestion (each digipeat of a packet increases frequency utilization by at least times 2 and usually higher due to the multiple digipeaters possibly hearing the packet), it is very likely that -only- a RX-only IGate will see that station.  Unfortunately, the station operator is clueless that the only IGate gating them to APRS-IS is RX-only and any other IGate that might be gating them doesn't consider them local so they never get messages from APRS-IS (including acks which are simple message packets).  It has nothing to do with the server since the server would be sending those message packets to all IGates that have recently heard that station (and all clients on either a full feed or message filtered feed) but -NONE- of those IGates gate to the RF station because they are either RX-only (always broken regarding messaging) or they consider that station to not be in their local coverage.

To clarify the above statements: the server "last heard list" is kept on all IGate capable restricted client ports (such as 14580 on APRS-IS) and there is an independent "last heard list" for -every- connected client.  These lists are completely independent and have no awareness of any other client's list.  Therefore if 2 IGates connected to restricted ports (may be the same server and port or different servers and/or ports) gate to APRS-IS the same station heard on RF, that station will make it on to each server-side "last heard list" for each IGate.

We have been down this path before.  We were in agreement that RX-only IGates are great for SatGates or for any instance where you only want to track stations and not support communications (messaging) but that is not the majority of amateur radio operations.  The idea that a non-messaging-capable IGate somehow improves -communications- in an area only gives a false sense of coverage since only tracking is provided with no communication (communication implies bidirectional, not broadcast) capability.

Hope this helps.

73,

Pete Loveall AE5PL
pete at ae5pl dot net



> -----Original Message-----
> From: Lynn W. Deffenbaugh (Mr)
> Sent: Saturday, November 19, 2016 10:32 PM
> Subject: Re: [aprssig] IGATE message routing bug?
> 
> Taking the discussion back to the public list so others don't ask the same
> questions later...
> 
> On 11/19/2016 10:42 PM, Jim Alles wrote:
> 
> 
> 	"Changing the port to which received packets are delivered has
> absolutely no effect on "fixing" anything."
> 
> 
> 
> 	I believe you are wrong - the packets inserted into the unidirectional
> port are not inserted into the heard hash table.
> 
> 
> 	The APRS-IS is smart enough to not try to send messages back to you to
> transmit them - you aren't there.
> 
> 
> But I don't understand just what you think that "fixes"?
> 
> Remote operators are still showing up on the APRS-IS and there's still no
> indication that they came through a non-transmitting IGate.
> 
> Not being in the heard table doesn't do anything as far as I can tell, except
> prevent your UDP-injecting IGate from receiving messages that it wouldn't
> likely have done anything with anyway?
> 
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


More information about the aprssig mailing list