Post by email@example.com
Looks like MP chat and transponder codes are broken in fgms-0.13.2 &
2017.2.1. Tested clients on Windows and Mac OSX, servers are 0.13.2.
Transponders set to a code show up remotely as 0000 until reset to
The MP protocol has changed. What are the tested clients' versions?
I have recently been testing this on those servers and it worked as
(newly) expected. If you connect a new (>=2017.2) client without
selecting the compat option, and read from an old client, such
behaviour is normal.
I have to adjust my statements.
Two clients are Win7-32, one client is Mac OSX. All three are 2017.2.1.
The server versions all match to 0.13.2; 0.12.a1 has been retired for
One thing I noticed is that the rxport had to be changed on the two
clients sharing a host so the firewall/NAT/router can keep them
separated, and it works better to put each client on a different server
(since they are coming from the same IP address).
Another complication crept in with the communications radius. With one
client set to 400 nm, the other client -- still set for 100 nm --
appeared with transponder code 0000 (despite the default being 1200, or
overridden with other settings at start). Changing the transponder code
corrected the transponder from 0000 to what I set it to. Changing the
code again updated the transponder code seen by the remote client set to
400 nm (invisible to the first client set to 100 nm).
It seems like this should be something that can be set by the user and
retained over sessions until we actually have the code in the model
computing radio path availability.
The protocol could make use of compression; I've captured a few packets
and noticed a lot of null bytes.
-- Dr. R0ckso, Ph.D.