[Xastir] 'Server Ports' addressing issue

Curt Mills curt.we7u at gmail.com
Wed Mar 16 11:27:24 EDT 2016


Note: Port 2023 UDP operation is well defined, as there are flags in
xastir_udp_client to determine whether a packet should be sent out INET or
RF (assuming everything is coded correctly). However for the discussion
here I'm talking about TCP connections to Port 2023, which aren't as well
defined in how they operate.

A few memories are coming back about this. Port 2023 was implemented with
this scenario in mind: Command-post / DEM / public service event. One
Xastir hooked to internet and/or RF. Other APRS clients hung off Xastir's
port 2023 getting the feeds. Anyone in the room with an APRS client can
update objects, plot area, etc, but those will only appear locally on
everyone's displays. Anything that should go "public" must be done on that
one INET/RF-connected box. There's separation of what's private and what's
public, plus not everyone in the room needs to be a ham to make use of the
system. Think of the "connected" Xastir instance as being a firewall,
keeping the private info in the room from going public.

I'm a bit unclear whether anyone in the room would be able to update the
main Xastir box's screen and objects via port 2023. Can't remember if it
was implemented that way or not. Then again, they'd probably have to adopt
an object to change it, then that object wouldn't make it out of the
command center to the INET or RF unless it was re-adopted by someone
controlling the "connected" Xastir instance.

So... Port 2023 was implemented with a specific purpose in mind. Whether or
not the 3rd-party stuff is appropriate is another question. I would hope
that if igating was turned off, those packets wouldn't get sent to INET/RF
from port 2023.

Things get a bit twisted when we have igating toggles in the GUI for RF and
INET, but not for the 2023 localport stuff. Doesn't exactly fit. I welcome
ideas about how things _should_ work, and how toggles to enable/disable
such operation might be implemented in the GUI.

Off-topic: Back to UDP (xastir_udp_client): I may have broken the
"-to_inet" stuff lately. Looks like "NOGATE" gets added to the path in all
instances now for UDP packets inside Xastir.


On Wed, Mar 16, 2016 at 6:34 AM, Eric Christensen <eric at christensenplace.us>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Much like you describe I want multiple clients to be connected
> together with a single box connected to RF and IS.  Right now Xastir
> supports this functionality (well, at least with one client, I've not
> tried it with multiple clients).  The problem is that the RF/IS
> connected box sends out these client-connected packets as third-party
> packets.
>
> WG3K>APX204,K3CAL-1,WIDE2-1:}WG3K-5>APDR13,TCPIP,WG3K*:=3841.15N/07632.0
> 7W$307/001/A=-00034
> CALV ARES EC WLNK-1
>
> Because the packets are transmitted in this fashion they will never
> make it to the IS.  While there is technically nothing wrong with the
> way these packets are transmitted, I'd prefer that Xastir handle them
> by just sending them out as if the client were actually attached to
> the radio or Internet.  I'm imagining the packet now being transmitted
> like this:
>
> WG3K-5>APDR13,WG3K*,K3CAL-1,WIDE2-1:=3841.15N/07632.07W$307/001/A=-00034
> CALV ARES EC WLNK-1
>
> - --Eric
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJW6WD6AAoJED4nr8JXHVrFGcwH/jtUxLRFp0882xgocLpk7sor
> 24AHJCW1Zt+LlXI8Gex/x1jKIdRbLPknpIvVdW5bfnH02UjArhgIye7vV45V6nMm
> 0l/FFfbgJL+IvjagUrl6Jy6yXYvorSfX58k2knAwXRYjTdSxT+mS4XAQtw3sFmpI
> S096lY87drXVjzDungBnsllB5fVW3KrdbCk/VXKXGdBb6C0pxTuaDjizMaGyU8kR
> uU7dS1YSYCvSSmISEcOLeSI4I7+henvpdoJSZP6w4iIyl3V5JATreCJe8px2NOyE
> VHghwdT5JITdW2UCjovYazTmTqgpMLpeepg5asWM3hJ5GusfYIrutrYWANvLrkA=
> =pK8R
> -----END PGP SIGNATURE-----
> _______________________________________________
> Xastir mailing list
> Xastir at lists.xastir.org
> http://xastir.org/mailman/listinfo/xastir
>



-- 
Curt, WE7U
http://wetnet.net/~we7u
http://www.sarguydigital.com


More information about the Xastir mailing list