The following message apparently hasn't made it to the mailing list, so
I'm reposting it on behalf of an IRC user phadthai.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/

--

I have had a netrek server successfully running and advertizing to the
metaservers (solicit.c) for a few months.  This is primarily a practice
server, with robots maintaining T mode 24/7.

I had fixed my local copy of the server code to not send robot players
along in solicit packets, and this seemed to successfully work for some
time.  However, lately it appears that the nine robots always appeared
again in the metaserver's list.

Using tcpdump(8) I could see that the solicit UDP datagram that is sent
is correct and does not include the robots.  Here is one:

0x0000:  0048 5480 e911 00b0 d083 dcd5 0800 4500            .HT...........E.
0x0010:  0051 68d6 0000 4011 0000 c0a8 010a 41c1            .Qh... at .......A.
0x0020:  11f0 c44c 0dc1 003d f708 620a 6e65 7472            ...L...=..b.netr
0x0030:  656b 2e70 756c 7361 722d 7a6f 6e65 2e6e            ek.pulsar-zone.n
0x0040:  6574 0a42 0a32 3539 320a 3235 3933 0a30            et.B.2592.2593.0
0x0050:  0a31 360a 790a 790a 6e0a 6f70 656e 0a              .16.y.y.n.open.

So I expect that the metaserver connects to the servers and obtain their
players list themselves, rather than relying on the solicit datagram (I
however yet have to read the metaserver code).  Grepping the metaservers
code for strings like "robot" or "localhost" it doesn't seem to perform
any checking to ignore robot players, however.

Considering that the source of a UDP client packet is easily spoofable,
it might make sense.  If this is the main issue, then would anyone mind
if I came up with an update to the Vanilla server code as well as to the
metaservers so that these can be transfered using TCP, and the source IP
address verified to match with the server's hostname resolution address?

If this was implemented, would there remain any other reasons for the
metaserver to connect to the servers, other than to verify their working
status?  Or, could we simply obsolete the current solicit datagram to be
replaced with one which only has the server address, for the metaservers
to continue querying the user list as it currently does, and add some
filtering against robot or localhost strings to hide those users?

Since I noticed that the robots on my server were now being seen as
players again, and that I'm not yet able to fix this easily without
looking closely at the metaservers code, I disabled the robots at around
15h EST today to avoid getting in trouble with the metaservers
administrators for "spamming" robot players.  However, it appears that
from approximately 19h EST and up, both orion.netrek.org and
sage.real-time.com stopped connecting to my server, and the server also
now seems out of the metaservers list (netrek.pulsar-zone.net).

Was the server blacklisted?  And if so, was it because of the
aforementionned "bot" spamming?  Under which case, why was it
blacklisted even after those robots were deactivated?  Moreover, would a
technical solution by server and/or metaserver code change be accepted
by the community?  These changes would not break clients.

If my server was blacklisted, what action can possibly be taken to list
the server again?

Thanks,
Matthew Mondor