Open nerijus opened 9 years ago
I set up network namespaces so that Steam does not see WAN interface:
ip netns add steam ip link add veth0 type veth peer name veth1 brctl addif br1 veth1 ip link set veth0 netns steam ip netns exec steam ip link set dev veth0 up ip link set dev veth1 up ip netns exec steam ip link set lo up ip netns exec steam ip addr add 192.168.1.11/24 broadcast 192.168.1.255 dev veth0 ip netns exec steam ip route add default via 192.168.1.10
I then launch Steam by ip netns exec steam su user -c steam
Before using namespaces Steam sent broadcast packets via WAN interface: 23596 73.037108 5.20.215.xx -> 5.20.215.255 UDP 135 Source port: 27036 Destination port: 27036
Now it sends via LAN, but to the wrong broadcast address: 252 3.250078 192.168.1.11 -> 5.20.215.255 UDP 136 Source port: 27036 Destination port: 27036
It should send broadcasts to 192.168.1.255 and not 5.20.215.255. I don't know how steam knows my WAN broadcast address if I use namespaces.
Issue still open? My Linux workstation uses the wrong interface for in home streaming broadcasting. After some digging around, it seems always to be the first non-loopback interface with a default route. Why not using all interfaces for service discovery or a configurable? It is really annoying, since it seems to work on Windows.
On my system, steam's sending those broadcast packets to my ppp0 interface because that's the default gateway (this machine runs pppoe to my ISP using a dumb bridged ADSL modem)
What's weird is that steam is not even using my LAN's broadcast address (x.x.x.255). It's sending to 255.255.255.255.
Fortunately, that makes it fairly easy to work around. Just add a route for 255.255.255.255 to go via your LAN interface.
e.g. this fixed the problem on my system:
ip route add 255.255.255.255 dev br0
You probably haven't set up a bridge your NIC, so you'll want to use eth0
or eth1
or enp2s0
instead of br0
. e.g.
ip route add 255.255.255.255 dev enp2s0
Now steam on linux can see steam on my win7 gaming "console" (steam is the only thing I use windows for, so it's a console not a real computer :-) when it first starts up or when it restarts to install an upgrade. Before I added this route, whenever I started/restarted steam on linux, I had to go to the windows steam box and restart steam there too. Steam on Win7 had to be restarted AFTER Steam on Linux.
This, of course, is just an ugly kludge. The right fix is for steam to not send broadcast packets intended for hosts on the LAN out the WAN interface to the internet. That's pointlessly useless and broken.
If that's too difficult to figure out due to the weird variety of network configurations out there (some far more unusual than mine) then steam should allow the user to override whatever it thinks is the right broadcast interface/address with an environment variable. e.g. STEAMBROADCAST=eth0
. If it's set, get the broadcast address from the interface and use it. If not, make a guess and try not to send the bc packets to the internet.
Please fix this. This is very annoying.
A quick workaround suggested by @craig-sanders would also work(STEAMBROADCAST=eth0).
Still broken. Notably breaks streaming over ZeroTier or other VPN mechanism that doesn't redirect the default gateway.
Please add an advanced option to pick the discovery interface, or just run discovery on all interfaces. Open-source the Steam client and I'll send you the PR myself :)
Still broken. In my case, Steam broadcast to a network with only printer on it. I can see steam sending packets to 10.26.230.255. Even thow I added ip route add 10.26.230.255 dev ens192, packets still go to my obscure interface...
I have br1 interface with IP 192.168.1.10 (LAN) and enp2s0 interface with IP 5.20.x.x (WAN). Steam client sends In-Home Streaming broadcasts on interface enp2s0, not br1 as it should.
I checked with a sniffer: tshark -i br1 -Y "tcp.port == 27036 or udp.port == 27036" does not show any output
tshark -i enp2s0 -Y "tcp.port == 27036 or udp.port == 27036" Capturing on 'enp2s0' 8949 25.963819 5.20.x.x -> 5.20.x.255 UDP 83 Source port: 27036 Destination port: 27036
As we see, broadcasts are sent via my WAN interface.