You are not logged in.
Hello everyone,
# Problem
I was on a LAN party recently and with my up to date arch I was unable to find (list) any server of any game that was hosted by two Windows 11 machines.
# Additional information
The location had no internet.
(Native games and wine games were affected - Company of heroes, Xonotic and TrackmaniaNation for example)
Games I hosted could be found and joined by the Windows machines.
I was able to join a server of one game (only one game had this possibility in-game) by entering the servers IP.
We used a single switch with static IPs, no dhcp. All machines were in the same class C network. (I guess it was just a layer 2 switch)
I did not configure a gateway or DNS server.
I turned firewalld off, by changing to the trusted zone. (Not really relevant I think)
The two windows machines found their servers without problems.
Back at home in a network with a router I added back the DNS server and the gateway (My router is configured as gateway and DNS server).
Here finding games on windows 10 machines is no problem.
Removing the gateway entry again (and do a disconnect and reconnect cycle of the wired connection) also makes game servers undiscoverable. So a missing gateway entry triggers the issue also in my home network. (The LAN party configuration also didn't had a gateway configured)
I cannot test if configuring a gateway would have solved that problem in that LAN party network right now. Even if I could I don't know what to configure since there was no gateway.
I asked a friend who uses arch on LAN parties. He said that finding servers without setting a gateway works for him.
That made me remember that I was on another LAN party also with a switch and without internet, but a running DHCP server. That was half a year ago and there the server discovery on windows machines was no problem. So perhaps it is a problem of a recent update. (I will provide additional info regarding the dhcp gateway configurations)
Update: The dhcp server ob that LAN didn't configure a gateway.
So it somehow worked there.
I am also unable to find a solution online.
Why is this happening?
The gateway configuration cannot have something directly to do with the problem I think.
For discovering game servers I think a broadcast is used.
Last edited by topasiss (2023-05-27 05:37:00)
Offline
Tested to disable firewalld completely in systemd - without success.
Offline
Offline
Thanks for helping me.
Yes, avahi is installed as a dependency:
tobiasb@tobias-pc ~]$ pacman --query --info avahi
Name : avahi
Version : 0.8+22+gfd482a7-3
Description : Service Discovery for Linux using mDNS/DNS-SD -- compatible with Bonjour
Architecture : x86_64
URL : https://github.com/lathiat/avahi
Licenses : LGPL
Groups : None
Provides : libavahi-client.so=3-64 libavahi-common.so=3-64 libavahi-core.so=7-64 libavahi-glib.so=1-64
libavahi-gobject.so=0-64 libavahi-libevent.so=1-64 libavahi-qt5.so=1-64 libavahi-ui-gtk3.so=0-64
libdns_sd.so=1-64
Depends On : expat libdaemon glib2 libcap gdbm dbus libdbus-1.so=3-64
Optional Deps : gtk3: avahi-discover, avahi-discover-standalone, bshell, bssh, bvnc [installed]
qt5-base: qt5 bindings [installed]
libevent: libevent bindings [installed]
nss-mdns: NSS support for mDNS [installed]
python-twisted: avahi-bookmarks
python-gobject: avahi-bookmarks, avahi-discover [installed]
python-dbus: avahi-bookmarks, avahi-discover [installed]
Required By : geoclue guitarix gvfs libcups libdmapsharing mod_dnssd mpd mumble murmur nss-mdns ola ostree
sane shairplay vino
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 1895.88 KiB
Packager : Evangelos Foutras <foutrelis@archlinux.org>
Build Date : Wed 01 Dec 2021 21:38:00 CET
Install Date : Tue 26 Jul 2022 13:50:24 CEST
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : Signature
edit: I did not actively configured it yet. I'll look into the configuration options.
Last edited by topasiss (2023-01-08 20:54:39)
Offline
I have configured Hostname Resolution and therefor installed
nss-mdns
as mentioned in that section.
I don't remember why I needed this.
My
nsswitch.conf
looks like this:
[tobiasb@tobias-pc ~]$ cat /etc/nsswitch.conf
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.
passwd: files systemd
group: files [SUCCESS=merge] systemd
shadow: files systemd
gshadow: files systemd
publickey: files
hosts: mymachines mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] files myhostname dns
networks: files
protocols: files
services: files
ethers: files
rpc: files
netgroup: files
I can make a snapshot and reinstall Avahi and its config files.
Offline
Looked into the routing table and tested a workaround that came into my mind:
Routing table with gateway set :
[tobiasb@tobias-pc ~]$ route --numeric
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.178.1 0.0.0.0 UG 100 0 0 enp5s0
192.168.178.0 0.0.0.0 255.255.255.0 U 100 0 0 enp5s0
Nothing special. Finding servers in games works.
Routing table with no gateway set:
[tobiasb@tobias-pc ~]$ route --numeric
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.178.0 0.0.0.0 255.255.255.0 U 100 0 0 enp5s0
I cannot find something wrong, but finding servers in games doesn't work.
Routing table with gateway set to 192.168.178.99 (not a valid host):
[tobiasb@tobias-pc ~]$ route --numeric
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.178.99 0.0.0.0 UG 20100 0 0 enp5s0
192.168.178.0 0.0.0.0 255.255.255.0 U 100 0 0 enp5s0
Priorities changed, default route has low priority - okay - BUT finding servers in games works!.
The routing tables don't tell me that there is something wrong even without a gateway configured - it looks good.
Adding some kind of gateway could also be a workaround for the LAN sessions I'll have to test. (For others to walk by)
But still the question is why does this work?
Where else can I ask for help?
Offline
Maybe udp broadcast does not work when the gateway is not set:
https://unix.stackexchange.com/question … g-in-linux
https://www.ridgesolutions.ie/index.php … -on-linux/
Last edited by progandy (2023-01-10 05:37:30)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Yeah, It looks like the game uses a broadcast and it is missing when no gateway is set. Thanks fire investigating.
This is a filtered packet trace taken on the machine that searches for servers at the time, the game searches for servers:
With an existing gateway set:
Without a gateway set:
Just no packets matching the filter
With an non existing gateway set:
(192.168.178.98 in this case)
What's the reason or what part of linux does this or where should I ask for a reason?
Last edited by topasiss (2023-01-11 07:40:58)
Offline
It would be nice to know if this happens only on my machine.
So if someone finds the time to test this on another arch and report here I would appreciate that.
Offline
I tested this on a live arch cd to find out if this only happens on my installation or also on new installs.
I assume that an installed arch behaves like an arch live disc at least regarding this issue.
I used a qemu virtual machine for the test and replaced the real games with
nping
to generate the UDP broadcast and wireshark with
tcpdump
to trace packets. (Used two different tty in parallel)
I tested the new tools on the machine that produced the issue initially again to make sure the tool replacements work. Issue can be seen with the new tools, too (No gateway set - no UDP broadcast going out). So the tools can reproduce the issue.
The test outputs that the live arch has the same behavior as my current installation. When no gateway or default route is set, then the UDP broadcast is not sent.
I have a screenshot of the test.
Screenshot comments:
The initial test before touching the routing table for testing is not shown, since it went or of the screen (Sending UDP broadcasts worked there)
Though the broadcast is sent without error when the default route is present,
nping
reports lost packets. I don't exactly know what that means, but there were no issues sending the packets and
tcpdump
saw them going out.
For now I consider this solved. I'll test this in future real LAN sessions and if these assumptions are wrong i'll report back.
Thanks to everyone who helped.
Offline
It would be nice to know if this happens only on my machine.
So if someone finds the time to test this on another arch and report here I would appreciate that.
This is normal linux behavior. Here is a bit more background:
https://stackoverflow.com/questions/683 … interfaces
nping reports lost packets. I don't exactly know what that means, but there were no issues sending the packets and
nping sends a packet and then waits for the receiver to acknowledge the receipt. In this case there is nothing that will answer.
Last edited by progandy (2023-01-13 16:26:05)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
This is normal linux behavior. Here is a bit more background:
https://stackoverflow.com/questions/683 … interfaces
Thanks.
To summarise:
- broadcasts (255.255.255.255) are meant for immediate neighbors (computers in the same network)
- broadcasts should not be forwarded at gateways for security reasons
I don't understand why linux delivers those broadcasts only on interfaces where a gateway is set.
The only reason I see is that that the authors thought that this broadcast should be delivered to all networks. Since linux is most likely not connected to all networks at once, this delivery can be done best by a gateway.
But that conflicts with the idea to stop such broadcasts at gateways.
Well... maybe it doesn't conflict with that. The gateway could deliver it to all attached networks and stop it from passing a NAT border. That makes sense to me.
Another thing is if there is no interface with a gateway configured, this broadcast stays undelivered, tough it could be delivered to the immediate neighbors by linux on the network linux is connected to. So it doesn't get lost. That doesn't happen and I don't know a reason for that.
I searched for an answer to this in the kernel mailing lists and found only slightly related discussions about this and not a real answer.
Offline
Linux can only send a packet to a single interface. As a result it always uses the routing tables to choose that if you do not manually set the interface for the socket (only root is allowed to do that). If the routing table does not provide an interface, it is not delivered.
Instead of a gateway you should be able to create a special route for the broadcast ip to choose one interface.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline