[Xastir] 'Server Ports' addressing issue
eric at christensenplace.us
Wed Mar 16 11:55:57 EDT 2016
On 03/16/2016 11:27 AM, Curt Mills wrote:
> 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.
Okay, this makes sense AND it should be noted that when I was reviewing
my configuration I remembered putting WG3K-5 (the client hanging off of
2023 TCP) in my nws-stations.txt file so it would get gated out. In
that respect I believe Xastir is appropriately handling the third-party
> 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.
Again, this makes sense. I wonder, however, how the person at the
master Xastir station (the one everyone is hanging off of) would know
that they need to "adopt" the object since someone else touched it.
Without that information the IC might have one view while those in the
field have a completely different view.
> 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.
I guess I was thinking that a UDP connection would be used to serve
unlicensed users (read that to be read-only) but I could see others
being able to move objects around and them having to be approved by the
master station before they go out. That makes sense from the COP
> 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.
Seeing the back story for the original purpose of this feature I think I
was trying to do something that was not intended to do. Perhaps this
functionality could be added at some point in the future? I'm
envisioning some sort of info box with all the clients attached and
having the master station have the ability to give those clients
transmit access to RF/INET. For clients that just have local access, I
wonder if it would be possible to somehow show to the master station (or
everyone on the local network?) that an object needed to be officially
adopted so that everyone locally and on RF would have the same picture.
More information about the Xastir