Hi,
I had nothing better to do this morning, so I decided to test. HLDS's
behavior differs slightly from SRCDS's behavior. It appears to me that
"Class C" is used merely for lack of a more appropriate term coming to
the developer's mind - network classes do not exist any more, and even
though most people use "class c" to refer to a /24, that is not the
behavior the servers exhibit. My network configuration on a FreeBSD 7
machine:
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255
inet 5.16.90.1 netmask 0xffff0000 broadcast 5.16.255.255
I tested by changing the IP addresses of several windows machines and
connecting to hlds with half-life and srcds with counter strike source.
Neither server has their IP set, they bind to all available interfaces.
On HLDS, it appears to only allow RFC1918 addresses to connect with
sv_lan 1 (cruft snipped from logs, server is bound to all addresses
shown above):
version : 48/1.1.2.1/Stdio 4383 insecure (70)
tcp/ip : 192.168.1.2:27015
# 1 "moo`fwaggle" 1 STEAM_ID_LAN 0 00:08 11 48 10.0.3.3:27005
Connecting from 5.16.89.3 returns the error message "Server restricted
to Class C" on Half-life. Note that below, this same scenario works on
Source DS.
It appears to me as though srcds will check the IP and netmask of all
interfaces it binds to, and allow any client that falls in the same
network as these to connect:
Network: IP 10.0.0.1, mode MP, dedicated Yes, ports 27015 SV / 27005 CL
"sv_lan" = "1" ( def. "0" )
- Server is a lan server ( no heartbeat, no authentication, no
non-class C addresses )
Client "moo`fwaggle" connected (10.0.0.2:27005).
Client "moo`fwaggle" connected (10.0.1.2:27005).
Client "moo`sabriena" connected (192.168.1.3:27005).
Client "moo`fwaggle" connected (5.16.90.3:27005).
What's interesting to note is that I spliced all these log entries
together for brevity - but when the connection occurred from
192.168.1.3, that machine was attempting to connect 10.0.0.1, though it
was not in the 10.* subnet - the FreeBSD machine was performing NAT and
translated the connection, but because the server has a host in the
192.168.1.* network it appears to have allowed the connection, despite
the fact the connection was from a different network (192.168.1.3 ->
10.0.0.1). I hope that makes sense. :(
The conclusion that I draw is that only Source will work over Hamachi
with sv_lan 1, Goldsource doesn't appear to (limiting you to only
RFC1918 addresses from my observation).
Of course, windows servers could behave entirely different.
Hope that helps some.
--
fwaggle
Tony Paloma wrote:
> Hamachi operates on 5.0.0.0/8 and I'm pretty sure it works just fine on
> sv_lan 1.
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Morgan Humes
> Sent: Monday, February 02, 2009 11:01 PM
> To: [email protected]
> Subject: [hlds_linux] sv_lan - Class C Space?
>
> So I was having a conversation with a friend on how hlds claims that sv_lan
> only works with Class C Address space. This is an epic fail if it is indeed
> true. RFC 1918 does define private address space in Classes A, B, and C.
> Thus a LAN Party could easily use any of the following private address
> spaces:
>
> 10.0.0.0 - 10.255.255.255 (10/8 prefix)
> 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
> 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
>
> (Note, taken from RFC 1918 section 3 - http://tools.ietf.org/html/rfc1918)
>
> For those who are not well versed in networking, the above 10/8 is a Class A
> range, 172.16/12 is Class B, and 192.168/16 is Class C.
>
> Thoughts?
>
> Morgan
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
