[Xastir-dev] Broken "ST_DIRECT" flag?

[Curt Mills]

On Thu, 16 Dec 2004, Tom Russo wrote:

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

As I recall that ST_VIATNC flag is set if you EVER hear a station
direct.  Perhaps we need to add a timestamp in there and clear the
ST_DIRECT flag if we haven't heard a station for the last hour and
we're touching that station record again for any reason.


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

Yea, I see the problem.  We've overwritten the direct path with the
internet path by then, so the logic is messed up.  We either need to
save the direct path as well, or clear the ST_DIRECT/ST_VIATNC flags
when we receive a packet on the internet.  I don't like the latter
solution as station on both TNC and INET would not show any stations
direct, or very few.


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

Or just change the record when we get something from an INET
interface.  Easier.  There are both the Q-constructs and the
injection ID methods, and I think one other.


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

Either keep separate data on INET and TNC paths, including
timestamps for TNC, or reset some things upon INET reception of a
packet.

-- 
Curt, WE7U.				archer at eskimo dot com
http://www.eskimo.com/~archer
  Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"