My "Megaglest" does not appear to be in LAN

[thiemo]

Hi all

I wanted to play a LAN game and found my client unable to connect to the providing client that I have been able on previous occasions.

I checked our IP addresses which where were perfectly fine in the 192.168.178.0/255 range.
I hosted myself a LAN game and found Megaglest show me 62.138.239.45 and 62.138.238.45 in the top line where as the top line showed the real ip address of its client.

I tried with removing the personal Megaglest config folder (.megaglest), I re-installed Megaglest and also rebooted - all to no avail.

My partner and I both use OpenSUSE Tumbleweed, however my installation is more uptodate. So, it might be, that this issue arises because of a system update. Hoever, I also debuglogged the network of Megaglest and found some strange things:

Code: [Select]

thiemo @ lenovo-tWeed ~/.megaglest % grep -RnF 62. debug.log                                                                                                                     17-10-22 20:44
395:[2017-10-22 20:27:30] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getLocalIPAddressList Line: 691] myhostaddr = [62.138.239.45]
396:[2017-10-22 20:27:30] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getLocalIPAddressList Line: 691] myhostaddr = [62.138.238.45]
1034:[2017-10-22 20:27:31] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getLocalIPAddressList Line: 691] myhostaddr = [62.138.239.45]
1036:[2017-10-22 20:27:31] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getLocalIPAddressList Line: 691] myhostaddr = [62.138.238.45]
1245:[2017-10-22 20:27:31] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getNetworkInterfaceBroadcastAddress Line: 541] ifaAddrStr [127.0.0.1], maskAddrStr [255.0.0.0], dstAddrStr[127.0.0.1], ipAddress [62.138.239.45], broadCastAddress []
1247:[2017-10-22 20:27:31] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getNetworkInterfaceBroadcastAddress Line: 541] ifaAddrStr [192.168.178.73], maskAddrStr [255.255.255.0], dstAddrStr[192.168.178.255], ipAddress [62.138.239.45], broadCastAddress []
1251:[2017-10-22 20:27:31] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getNetworkInterfaceBroadcastAddress Line: 541] ifaAddrStr [127.0.0.1], maskAddrStr [255.0.0.0], dstAddrStr[127.0.0.1], ipAddress [62.138.238.45], broadCastAddress []
1253:[2017-10-22 20:27:31] In [/home/abuild/rpmbuild/BUILD/megaglest-3.13.0/source/shared_lib/sources/platform/posix/socket.cpp::getNetworkInterfaceBroadcastAddress Line: 541] ifaAddrStr [192.168.178.73], maskAddrStr [255.255.255.0], dstAddrStr[192.168.178.255], ipAddress [62.138.238.45], broadCastAddress []
Line 1247 of the debug.log shows that the real ip address of my system (192.168.178.73) is not entirely unknown to my Megaglest client, making me unsure whether this still is a flaw in Megaglest. Btw, I have not been able to figure out where those public ip addresses come from. Grepping /etc or .megaglest for it showed no result.

I did a standard tumbleweed installation with

Code: [Select]

zypper install megaglestfrom

Code: [Select]

lenovo-tWeed:~ # zypper repos -u -E
Repository priorities are without effect. All enabled repositories share the same priority.

# | Alias                            | Name                            | Enabled | GPG Check | Refresh | URI                                                               
--+----------------------------------+---------------------------------+---------+-----------+---------+--------------------------------------------------------------------
1 | download.opensuse.org-non-oss    | Haupt-Repository (NON-OSS)      | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/tumbleweed/repo/non-oss/             
2 | download.opensuse.org-oss        | Haupt-Repository (OSS)          | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/tumbleweed/repo/oss/                 
3 | download.opensuse.org-tumbleweed | Hauptaktualisierungs-Repository | Yes     | (r ) Yes  | Yes     | http://download.opensuse.org/update/tumbleweed/                   
5 | packman                          | packman                         | Yes     | (r ) Yes  | Yes     | http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/

The system report shows for the OS and Megaglest version the following.

Code: [Select]

***** Operating system *********************************************************

* Distribution: openSUSE
* Release:      20171006
* Codename:     n/a
* Architecture: x86_64
* LSB support:  1

>>> uname -a
Linux lenovo-tWeed.home 4.13.4-1-default #1 SMP PREEMPT Wed Sep 27 14:20:45 UTC 2017 (4dec972) x86_64 x86_64 x86_64 GNU/Linux

>>> cat /etc/issue
Welcome to openSUSE Tumbleweed 20171006 - Kernel \r (\l).

enp3s0: \4{enp3s0} \6{enp3s0}


***** MegaGlest version ********************************************************

>>> INSTALLATION_LOCATION (def2): [/usr/bin/].

>>> ./megaglest --use-language=en --version
megaglest v3.13.0
Compiled using: GNUC: 70201 [64bit] platform: Linux-X64 endianness: little
GIT: [Rev: $5604.3a5d459$] - using STREFLOP [SSE] - [no-denormals]
Is there a work around?

Kind regards

Thiemo

[tomreyn]

I'm not entirely sure what happens there, yet, but your ISP hijacking your DNS queries seems to be part of the problem:

Code: [Select]

# host navigationshilfe.t-online.de
navigationshilfe.t-online.de has address 62.138.239.152
navigationshilfe.t-online.de has address 62.138.238.152

Usually, ISP who will provide such fake DNS responses on their customers' caching resolvers allow customers a way to disable the fake DNS replies. Alternatively, you could use other / open resolvers.

This website lists serveral open resolvers:
 https://www.ungefiltert-surfen.de/nameserver/de.html

[thiemo]

I figure that those public ip addresses are linked to my ISP as a tracepath is really short. However, those are not the DNS my ISP provides me.

Code: [Select]

thiemo @ lenovo-tWeed ~ % tracepath 62.138.239.45                                                                                                                                 17-10-23 0:06
 1?: [LOCALHOST]                      pmtu 1500
 1:  fritz.box                                             4.170ms
 1:  fritz.box                                             1.712ms
 2:  p57A4680D.dip0.t-ipconnect.de                         1.519ms pmtu 0
 2:  send failed
     Resume: pmtu 0
Be it as may, why does Megaglest query such information or maybe why does my tWeed know such information anyway as it uses my fritz.box to send DNS queries?

Code: [Select]

thiemo @ lenovo-tWeed ~ % cat /etc/resolv.conf                                                                                                                                    17-10-23 0:06
nameserver 192.168.178.1

[tomreyn]

I figure that those public ip addresses are linked to my ISP as a tracepath is really short. However, those are not the DNS my ISP provides me.

No, they are the A records your ISP's DNS cache returns erroneously (on purpose) when you ask them for a host which doesn't exist. i.e. if you run

Code: [Select]

host thisdomaindontexist.com
they will return those A records, then they should actualyl return 'NXDOMAIN'.

Be it as may, why does Megaglest query such information or maybe why does my tWeed know such information anyway as it uses my fritz.box to send DNS queries?

Code: [Select]

thiemo @ lenovo-tWeed ~ % cat /etc/resolv.conf                                                                                                                                    17-10-23 0:06
nameserver 192.168.178.1

Your router is just another caching nameserver, it sends requests to your ISPs caching DNS servers (and relays those back to you), which may in turn send them to other caching DNS servers until it hits the authoritative DNS servers for the object you asked for.

The reason these two IP addresses show up on MegaGlest's log will be that MG queried some hostname which does not exist. Why it did this, and which hostname that is, I do not know.

[titi]

If the problem is LAN only ... see this too: https://forum.megaglest.org/index.php?topic=9967.0

( problem was fixed around this commit: https://github.com/MegaGlest/megaglest-source/commit/c898c633891bbae7d1249f4810ef1ac1c25a1664 )

[thiemo]

Thanks to all. I gather, I need to compile a snapshot then and try out.

[tomreyn]

Here's how your ISP's malicious DNS servers can be replaced by proper ones:
https://telekomhilft.telekom.de/t5/Browser/Navigationshilfe-ausschalten/td-p/2466125

[thiemo]

Thx, I shall try this solution first this weekend.

[thiemo]

Here's how your ISP's malicious DNS servers can be replaced by proper ones:
https://telekomhilft.telekom.de/t5/Browser/Navigationshilfe-ausschalten/td-p/2466125

Thanks Tom. This did the trick but funny enough, my clientdoes not show any ip adress in the lan hosted setup screen thingy as described above.