[Xastir-dev] interface igate config?

[Curt, WE7U]

On Thu, 11 Feb 2010, Jason KG4WSV wrote:

> Do we need these global controls?  Do they need to be in this form, or
> would a simple "enable gating" button more appropriate, with
> direction-specific gating controls on the individual interfaces?

I guess I've used the global controls mostly as an enable/disable
global option, so perhaps that would be adequate.

Dreaming a little bit:  The nicest (for me) setup would be a
separate "igating" dialog where I could turn on/off global gating,
turn on/off individual directions for each interface, and perhaps do
some cross-wiring between interfaces for those special instances
where you're supporting a public service event or emergency and need
to gate RF->RF.  That last has been asked for and we've never had
the capability.

Combine the above with named interfaces (any string for a name) and
you'd have something easy to read & maintain.


>> Generally for an igate of any type with the APRS-IS as we have it
>> now, RF->INET won't hurt anything.
>
> OK, so there's no need for RF->inet filtering.

I believe that's correct.  For any instance where you are running a
special event and don't wish to gate, you can turn off gating in
that direction entirely.


>> The other direction is pretty much asking for trouble if you allow
>> wildcards.
>
> OK, but what about NWS WX data? that's the specific use case I was
> thinking of.

Sure.  I can think of other things people might want, like quakes,
fires, amber alerts, etc, so there's definitely a case there for
allowing wildcards too.  The problem is RF bandwidth protection if
people use the wildcards too freely.  It's very easy to swamp an RF
channel.


>>  The "normal" method is to automatically gate messages,
>> ACK's, and NAK's through to RF for stations that have been heard on
>> local RF only.
>
> OK, so we need a per-interface heard list.

That would be best.  Just a "heard-on-rf" list would work, but is
not optimum as you'd have to send any message out ALL RF channels
for this to work.

Rather than a separate per-interface heard list one could store the
last-heard interface or short list of last-heard interfaces in the
station record for each station, along with a time.  Implementation
details, but either way would work.


> ACKs and NACKs are messages too, right?

That is probably correct.  Check the spec.


> I'm trying to (maybe wrongly) trying to find
> an easier way than making a user create a config file to get NWS
> warnings, etc gated to RF.  But we don't want an ignorant user
> destroying an RF channel, either.  Put a list of callsigns (or
> callsigns/object names?) on the GUI, but forget about wildcards?
> Aren't there prefixes involved in the NWS data, with unique
> calls/object names for individual storms?

The format changed slightly in the last year or so, but yea I think
there's info to be gleaned from the NWS messages.

Perhaps a quick survey of other APRS apps to see how they handle
these sorts of situations?  I'm all for making it easier to
understand and maintain.  The current method works kind'a, but
doesn't handle some situations.  For instance we can send to RF
based on destination callsign but not based on source callsign,
something like that.  REGEX matches on packets would be very cool
and powerful, but try to get the average user to learn it...  May
not be the best option.


>>> Should anything other than the "allow transmit" button on the "inet
>>> server" control gating?
>>
>> There shouldn't be an allow transmit button on the inet server side,
>> as you're not transmitting there.  It's only on RF where you
>> transmit.  Perhaps I misunderstood.
>
> er, there is an "allow transmit" button on the server interface
> config, and the global "disable transmit:all" also disables
> transmitting data to servers.  (hence the occasional confused user
> trying to use a "filter around my position" filter that doesn't work
> because the posit report doesn't it the server.)

Ok.  I see you've pointed out a glaring problem in the
terminology...  I can see where the confusion comes from!

-- 
Curt, WE7U.                         <http://www.eskimo.com/~archer>
    APRS:  Where it's at!                    <http://www.xastir.org>
   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!"