[aprssig] UI-VIEW tcp/ip only question

[Keith VE7GDH]

Tim N8DEU wrote...

> We had a local user connected to Internet only this past week trying
> to send messages and ACK's from UI-View32 to RF stations. The data
> would not pass from Internet to RF or it certainly would not ACK any
> RF station sending a message to it. When they changed the TCPIP entry
> in their path to APRS, it allowed their messages to be sent as well as
> acknowledge those sent to it from the Internet to RF. It seems
> something blocked the TCPIP path but passed the APRS path. They did
> not try a blank entry in this case as the APRS TOCALL in the path
> worked the first time when changed from the TCPIP entry.

For a TCPIP user to send a message, the APRS validation number must be
entered.

To get it out to someone on RF, there must be an IGate that considers
the RF station to be local. It's up to the IGate operator to know how to
set the IGate up... i.e. must the RF station be heard direct, or via one
hop, via two hops etc. The success rate goes down drastically if it goes
out over more than one or two hops. For the TCPIP station to get an ACK,
the RF station must send the ACK and it must make it to an IGate.

The TCPIP station using UI-View should leave "APRS" in the unproto
setting. UI-View users will know from reading the help that this is the
destination (translated to APU25N before it goes out if they are using
UI-View32 ver 2.03) but the "APRS" must be left in there. They don't
need to enter any path after the APRS.

> Messages sent from this user from Internet to Internet stations worked
> fine with the TCPIP entry in the path, but it would not make the
> journey when they sent messages to an RF station until TCPIP was
> changed to APRS.

They should NOT be entering TCPIP in their path. That will automatically
be added by UI-View before their message is sent. It will to out with a
destination of APU25N (if they are using ver 2.03) and will already have
a "path" showing it went out via TCPIP.

> IGate designs are supposed to block RF sending stations that have
> TCPIP, TCPXX, NOGATE, or RFONLY in the header (last 2 are optional).
> On the other hand, it is my understanding that IGates are suppose to
> block stations from Internet to RF if they contain TCPXX, NOGATE, or
> RFONLY in the header. I am referencing Pete, AE5PL's, APRS IGate
> Details on Gating Criteria and Paths.

Users on RF should most definitely not be fiddling with the path to add
TCPIP or (heaven forbid) TCPXX to the path. As you mentioned, they can
use NOGATE or RFONLY if they don't want their beacons gated. A station
with a TCPIP connection but without having entered the APRS validation
number will show as TCPXX. The "fix" is to enter their APRS validation
number.

> The local user and the local IGate are both UI-View32 in this case. It
> seems that UI-View should have passed the TCPIP path entry from the
> end user. The data did not pass to RF until the user changed the path
> entry to APRS.

It's right in the help. The UI-View station should leave "APRS" as the
destination unless they want to be on their own "ALTNET". Unless they
are doing something like that, they should leave APRS in the "unproto"
setting in UI-View. Again, the help explains this and has an example
showing how the path IF they are on RF) goes after that, separated by a
comma.

All the TCPIP station can do is make sure their own settings are
correct. To have success via an IGate to an RF station, the IGate must
be configured properly. The RF station must be within range of that
IGate or (usually) no more than one or two hoops away from it. There
will be exceptions... e.g. where the IGate are few and far between and
where the APRS frequency is very quiet, and the IGate is set to consider
stations further away even if they are a few digi hops away. There are
far too many so called "one way IGates" around that are a dis-service to
users on RF.

73 es cul - Keith VE7GDH
--
"I may be lost, but I know exactly where I am!"