[Xastir-dev] Broken "ST_DIRECT" flag?

[Tom Russo]

Folks:

After a round of discussion with Dick, KB7ZVA about the APRSD (direct 
stations query) issue brought up by Jason Hitesman on the other list, I tried 
to fix one of the things he complained about and another that I noticed last 
night.

They use APRSD queries out there in Yuma to try to map out how people hear
each other and try to use that data to tailor their infrastructure.  The 
fact that xastir didn't respond when given a lower case ?aprsd prompted them
to think xastir was broken and didn't respond at all.  But it works with
upper case, per the standard, and now they can get that info from xastir 
stations.

One thing he complained about was that xastir reported its own station 
in the list, which seems a simple enough thing to fix and I did that this
afternoon.  It was a one-line hack.

The thing I noticed was that xastir was only returning a single line of
results, even if there were too many direct stations to list on one line.
UI-View sends multiple lines.  I fixed that last night, making xastir
flush its message buffer and start another line, rather than breaking out of 
the loop when it encounters a station that would overflow the buffer the
first time.

But now I'm seeing that if I have my station connected to the internet,
many stations that I know I can't hear directly are getting reported as
being directly heard.  This was true even before I changed to multi-line
query response, but is much more obvious now --- whereas I noticed one 
odd station yesterday that I didn't think I could hear directly (it is
nearly 300 miles away, in Arizona), today I'm seeing two or three lines
worth.

Here's an example for the MELROZ digipeater, cut/paste from station info
dialog.

Packets received: 4     Last Heard: 12/16/2004 17:50:32
Heard via the TNC on device 0, last via Internet on device 1
Data path: APRS,WIDE,qAr,KD5XB-2
Status  12/16 17:14 : W5DIG-12/R KPC 3 Ver 8.2 - Melrose,NM - www.urfmsi.org
Comment 12/16 17:50 : /W5DIG-12 APRS Digi www.urfmsi.org
Current Power Gain: 16W @ 320ft HAAT, 3dB omni, range 14.2mi
Altitude: 4564ft 
Distance from my station: 159.2 miles  Bearing from my station: 100.8°
Last Position: 12/16  17:50   34.50733N  103.55633W  4564ft               DM84fm *

I don't know how I heard this via TNC, it was probably digipeated through
several of the other urfmsi mountaintop digis.  But the RF path is clobbered by 
the internet path, and the ST_DIRECT logic looks at the path as part of
its decision making.  Note that there is no asterisk anywhere in the path.  
In db.c we have:

        // KC2ELS
        // Okay, here are the standards for ST_DIRECT:
        // 1.  The packet must have been received via TNC.
        // 2.  The packet must not have any * flags.
        // 3.  If present, the first WIDEn-N (or TRACEn-N) must have n=N.
        // A station retains the ST_DIRECT setting unless a certain number of 
        // seconds goes by without a direct packet being received.  This value 
        // will eventually make its way to the configuration file, but for now 
        // it's hardcoded to one hour.

        if ((p_station->flag & ST_VIATNC) != 0 &&       // From a TNC interface
                (p_station->flag & ST_3RD_PT) == 0 &&   // Not a 3RD-Party packet
                p_station->node_path_ptr != NULL &&     // Path is not NULL
                strchr(p_station->node_path_ptr,'*') == NULL) { // No asterisk found

[etc.]

Looks like there's something wrong with the logic, but I haven't decoded it
properly to see how to fix it.  I guess since the station was heard
via TNC through a digipeater the ST_VIATNC stays set, even though when
it's heard subsequently the PATH is now a path from an internet server.  
Since the path that's in the station structure isn't the path that was 
there when it was heard via TNC, this is causing false positives.

I know that most paths from internet servers have some sort of Q-construct
to show it's been through an internet server (e.g. qAr in this case).  Is it
always going to be there?  If so then that might be the way to detect this
conflict and fix it.

At this point, any xastir that is connected to both a tnc and internet 
server will report bogus direct stations, and that's a bug.  
Thoughts on how best to fix it?

-- 
Tom Russo    KM5VY     SAR502  DM64ux         http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://www.qsl.net/~km5vy/
 "That which does not kill me is better than that which does."
    --Irving Nietzche, lesser known of the famous Nietzche twins