Tippis Posted December 18, 2019 Posted December 18, 2019 (edited) Having updated and restarted my dedicated server for the first time in a month or two because the updates to the Hornet, Viper, and Jeff in the last patch, everything seemed to be working just fine with the old setup until I tried to connect from my actual gaming computer. When checking the server list, I was met by this: ...the server being listed roughly a bajillion times. All of them list different IP:s. All the listed IP:s are incorrect. Picking any of the listed servers works and connects me just fine. I have yet to hear anyone else report the same spam -- this is when I view the list from the client I'm running two TP ports away from the server machine. When I asked how it looked form the outside, this was the reported result: So it kind of looks like it's something that happens if both client and server are on the same network. Edited December 18, 2019 by Tippis ❧ ❧ Inside you are two wolves. One cannot land; the other shoots friendlies. You are a Goon. ❧ ❧
ED Team c0ff Posted December 19, 2019 ED Team Posted December 19, 2019 (edited) ...the server being listed roughly a bajillion times. All of them list different IP:s. All the listed IP:s are incorrect. Picking any of the listed servers works and connects me just fine. It means the IP:s are correct. Try pinging them. Also check the output of ipconfig on your server machine. Edited December 19, 2019 by c0ff Dmitry S. Baikov @ Eagle Dynamics LockOn FC2 Soundtrack Remastered out NOW everywhere - https://band.link/LockOnFC2.
Tippis Posted December 19, 2019 Author Posted December 19, 2019 (edited) It means the IP:s are correct. Try pinging them. Also check the output of ipconfig on your server machine. No, the IP:s reported in the server list are not correct. They simply can't be because not a single one of them is anywhere near the range of IP:s it can get assigned to, either internally or externally. Somewhere, the actual IP to connect to is conveyed, but it is not in the one any of the listed server duplicates actually has. For comparison, this is a normal server listing: IP 84.194.21.119 port 10311. Responds to pings. Tracert puts it in Belgium as one might expect. These are the top five listings of my server: IP 178.63.19.113 port 10308 Pings time out. Tracert fails to route beyond hetzner.com IP 74.91.115.179 port 10308 Responds to pings. Tracert puts the server in Chicago. IP 84.33.111.36 port 10308 Responds to pings. Tracert puts the server in Italy. IP 176.61.95.202 port 10308 Responds to pings. Tracert puts the server in Ireland. IP 85.214.159.222 port 10308 Responds to pings. Tracert leads to stratoserver.net. The IP of my server is 10.0.1.204 internally; 213.66.21.79 externally. It is located in Sweden. The only thing that is accurate about the different listed server IP:s is the port. In spite of all that, asking to connect to any of those still lets me connect to the server. It used to be that the server list showed the IPv6 address when I was on the same network, but that is no longer shown. It is entirely possible that this is the address actually used to connect, but there's no indication of that from either client or server that I can see. C:\WINDOWS\system32>ipconfig /all Windows IP Configuration Host Name . . . . . . . . . . . . : Kether-18 Primary Dns Suffix . . . . . . . : Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No Ethernet adapter Ethernet: Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller Physical Address. . . . . . . . . : 14-DD-A9-7C-DD-DF DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::3539:4fa7:9ffb:b6%14(Preferred) IPv4 Address. . . . . . . . . . . : 10.0.1.204(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Lease Obtained. . . . . . . . . . : 18 December 2019 21:53:53 Lease Expires . . . . . . . . . . : 20 December 2019 10:23:36 Default Gateway . . . . . . . . . : 10.0.1.1 DHCP Server . . . . . . . . . . . : 10.0.1.1 DHCPv6 IAID . . . . . . . . . . . : 102030761 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-22-AA-24-EB-14-DD-A9-7C-DD-DF DNS Servers . . . . . . . . . . . : 10.0.1.1 208.67.222.222 NetBIOS over Tcpip. . . . . . . . : Enabled Ethernet adapter vEthernet (Default Switch): Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter Physical Address. . . . . . . . . : 76-15-9F-AB-56-9B DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes Link-local IPv6 Address . . . . . : fe80::b1c6:dfe1:795d:c00d%17(Preferred) IPv4 Address. . . . . . . . . . . : 172.17.16.129(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.240 Default Gateway . . . . . . . . . : DHCPv6 IAID . . . . . . . . . . . : 292951455 DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-22-AA-24-EB-14-DD-A9-7C-DD-DF DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 NetBIOS over Tcpip. . . . . . . . : Enabled …and of course, the question of why on earth this single server instance is repeatedly listed for over a page and a half (in 1440p) remains the real mystery and the actual issue that needs to be figured out. Edited December 19, 2019 by Tippis ❧ ❧ Inside you are two wolves. One cannot land; the other shoots friendlies. You are a Goon. ❧ ❧
Tippis Posted January 6, 2020 Author Posted January 6, 2020 (edited) It even seems to be getting worse over time. Today, the two instances running on my server produced this fine result on the server list… :D I haven't been able to check which one of these is the actual, accurate listing since there are simply too many of them. I can check for the dogfight server entries since that one only spits out a single duplicate. The “real” server can be pretty easily identified since when clicked, it shows the actual, accurate IPv6 address, the same as it always did when client and server were situated on the same local network: This probably in part explains the behaviour explained above, where no matter which false entry I pick, I can still join the server: no matter what the actual IP listed is, it still uses that IPv6 address (which is seemingly accurate) but for some reason, the server communicates some random junk that gets filled into the IP field that makes the server list incorrectly see it as another server. Edited January 12, 2020 by Tippis ❧ ❧ Inside you are two wolves. One cannot land; the other shoots friendlies. You are a Goon. ❧ ❧
Tippis Posted January 11, 2020 Author Posted January 11, 2020 (edited) Breakthrough – potential cause found. Having had issues connecting to a different server all evening, I suddenly got a vague hunch on something that might be causing the interference and did some cfg changes here and there… CAUSE FOUND: A same-network server blocks any clients on that network from seeing other servers using the same port as the local server. Instead, the client sees a false copy of the local server, bearing the blocked server's (IPv4) IP, but with the local server's info and — more importantly — its IPv6 IP, which is used to actually connect to that server. By changing my server away from the common 10308 port to one that no-one else seems to be using, I was able to get rid of all duplicate entries in the server list. These duplicates were instead replaced with actual servers bearing the IP:s that would previously show, except with the accurate server info. The port change was (of course) made in the serverSettings.lua file and in the port-forwarding setup in my firewall. The issue thus does not seem to be with the server, but with the client being utterly confused by having a local server and external servers sharing the same port. It may have to do with how NAT loopbacks are resolved, potentially making it a router config issue: the client asks for info on the provided port and the router stupidly goes “port xyz? well, that's this local machine over here…”. Either way, local server + common server port + [unknown circumstance in client and/or router] = external server listings being replaced by the local server. That said, it is definitely a DCS issue, not something external. It started appearing somewhere during November or December 2019. Before then, this server masking did not occur. The inability to pin down a precise time or build is because the server was not being used and was turned off during roughly that period, and no attempt was made to join any other hosted DCS session. Edited January 14, 2020 by Tippis ❧ ❧ Inside you are two wolves. One cannot land; the other shoots friendlies. You are a Goon. ❧ ❧
ED Team c0ff Posted February 6, 2020 ED Team Posted February 6, 2020 Having had issues connecting to a different server all evening, I suddenly got a vague hunch on something that might be causing the interference and did some cfg changes here and there… CAUSE FOUND: A same-network server blocks any clients on that network from seeing other servers using the same port as the local server. Instead, the client sees a false copy of the local server, bearing the blocked server's (IPv4) IP, but with the local server's info and — more importantly — its IPv6 IP, which is used to actually connect to that server. By changing my server away from the common 10308 port to one that no-one else seems to be using, I was able to get rid of all duplicate entries in the server list. These duplicates were instead replaced with actual servers bearing the IP:s that would previously show, except with the accurate server info. The port change was (of course) made in the serverSettings.lua file and in the port-forwarding setup in my firewall. The issue thus does not seem to be with the server, but with the client being utterly confused by having a local server and external servers sharing the same port. It may have to do with how NAT loopbacks are resolved, potentially making it a router config issue: the client asks for info on the provided port and the router stupidly goes “port xyz? well, that's this local machine over here…”. Either way, local server + common server port + [unknown circumstance in client and/or router] = external server listings being replaced by the local server. That said, it is definitely a DCS issue, not something external. It started appearing somewhere during November or December 2019. Before then, this server masking did not occur. The inability to pin down a precise time or build is because the server was not being used and was turned off during roughly that period, and no attempt was made to join any other hosted DCS session. THANKS for investigation. Will look into this. Dmitry S. Baikov @ Eagle Dynamics LockOn FC2 Soundtrack Remastered out NOW everywhere - https://band.link/LockOnFC2.
Recommended Posts