You are not logged in.

#1 2019-08-17 22:34:33

Delzur
Member
Registered: 2019-07-07
Posts: 7

[Solved] "Redirecting 255.255.255.255 to my local network"

Hi there,

I'm not sure where to put this post, it could be networking and also gaming, but I'm pretty sure that this is very simple so I put it here.

Context

I am trying to play Warcraft III on LAN using playonlinux/wine. It seems that Warcraft III makes uses of some UDP broadcasting to do this, and
according to some sources here, here, here or even here, the way to solve this issue is either to "redirect 255.255.255.255 to the local network or add a default gateway.
I am trying to set this on an archlinux and one ubuntu, to play with a Windows.
My Arch's "ip ro":

default via 192.168.1.1 dev wlp2s0 proto dhcp src 192.168.1.33 metric 303
192.168.1.0/24 dev wlp2s0 proto dhcp scope link src 192.168.1.33 metric 303
Tried

Based on the commands found on these sources, I've tried the following:

ip route add 255.255.255.255/32 dev wlp2s0

Two things happened. First, I could see the game hosted by the Windows machine and play with him, that's the good news!
Second, "ip ro" loops. It continually prints, the same routes over and over, without stopping.

I find this very strange so I removed it from the Arch comp.
I tested the same command on the ubuntu, and the opposite happens: I cannot see the hosted game but "ip ro" works fine.

Questions

Based on my readings of Archwiki's Network Configuration page, wikipedia's Routing table page, ip route's man page, and my close to 0 knowledge of networking, I'm asking myself:

  • Does this rule makes sense? What does it do? I read is as "if you want to send something to 255.255.255.255, send it to wlp2s0" but I'm unsure what this means in reality

  • What could explain the difference of behaviour between arch and ubuntu?

  • What would the "add a default gateway" solution look like? Is it a better solution? Don't I already have one in my routing table above?

Hopefully that's not too much questions, but after an evening of looking up info, I'm completely lost.
I'd also gladly welcome a source that would help me answer my own questions by the way, most of the pages I've checked (including archwiki) are more about how to use the tools than what they do.

Last edited by Delzur (2019-08-18 09:52:55)

Offline

#2 2019-08-17 23:22:43

Zod
Member
From: Hoosiertucky
Registered: 2019-03-10
Posts: 636

Re: [Solved] "Redirecting 255.255.255.255 to my local network"

255.255.255.255 is the broadcast address.

Any packets put on the wire with that address are read by all machines on the lan.

packets sent to that address are not forwarded by routers so they will stay on your lan.

I'm probably missing something but those instructions you've linked make no sense to me.

Offline

#3 2019-08-18 07:04:37

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 76,030

Re: [Solved] "Redirecting 255.255.255.255 to my local network"

You *do* have a default gateway and I'm pretty sure you'll be able to

ping -b 255.255.255.255

w/o any changes to the default setup?

Did you check whether the game feature worked w/o these things?

Offline

#4 2019-08-18 09:52:20

Delzur
Member
Registered: 2019-07-07
Posts: 7

Re: [Solved] "Redirecting 255.255.255.255 to my local network"

Thank you for the answers.

[x@y ~]$ ping -b 255.255.255.255
WARNING: pinging broadcast address
PING 255.255.255.255 (255.255.255.255) 56(84) bytes of data.
^C
--- 255.255.255.255 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 112ms

Should I expect responses from other devices of the LAN?

And... Yeah, It didn't work before. But now it does even after removing that rule...
I'm not sure what happened yesterday, it seems my friend's Windows has a very strange behaviour. Even when it says it's connected to the wifi, it might be a lie.
Anyway, sorry about this.

I'm glad that you both said the rule made no sense, at least I know som of my understanding was correct and there is nothing magical about it.
It still does not work for the ubuntu, but that's not related to arch anymore.

Would you mind explaining why adding that rule make "ip ro" go on an (supposedly) infinite loop?

Offline

#5 2019-08-18 11:58:37

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 76,030

Re: [Solved] "Redirecting 255.255.255.255 to my local network"

Would you mind explaining why adding that rule make "ip ro" go on an (supposedly) infinite loop?

No idea an I'm not sure this is the direct cause.
Can you reproduce it?
Any resulting errors in dmesg?

I could imagine that something goes nots and keeps the NIC under high pressure as a result of that rule. *shrug*

Offline

#6 2019-08-18 20:36:41

Delzur
Member
Registered: 2019-07-07
Posts: 7

Re: [Solved] "Redirecting 255.255.255.255 to my local network"

seth wrote:

Can you reproduce it?
Any resulting errors in dmesg?

Definitely, I can!
dmesg is completely silent about this though.

Offline

#7 2024-02-24 10:53:39

Dark_iaji
Member
Registered: 2024-02-24
Posts: 1

Re: [Solved] "Redirecting 255.255.255.255 to my local network"

I also have some similar doubts. Isn't the broadcast address 255.255.255.255 saying it will connect to all interfaces? But why didn't I ping to the address under vxlan0? Wol is similar. I crawled packets under vxlan0 and didn't find any ping or Wol packets sent to vxlan0. However, it seems that the ping and Wol packets sent to 10.10.10.255 can be caught by network packet scraping tools on the vxlan0 interface.

ping -b 255.255.255.255
WARNING: pinging broadcast address
PING 255.255.255.255 (255.255.255.255) 56(84) bytes of data.
64 bytes from 192.168.1.100: icmp_seq=1 ttl=64 time=0.137 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.330 ms
64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=0.353 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.600 ms
64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=0.321 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.579 ms
64 bytes from 192.168.1.100: icmp_seq=4 ttl=64 time=1.24 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.50 ms
64 bytes from 192.168.1.100: icmp_seq=5 ttl=64 time=0.132 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.214 ms
64 bytes from 192.168.1.100: icmp_seq=6 ttl=64 time=0.203 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=0.457 ms
^C
--- 255.255.255.255 ping statistics ---
6 packets transmitted, 6 received, +6 duplicates, 0% packet loss, time 5076ms
rtt min/avg/max/mdev = 0.132/0.504/1.496/0.415 ms

ip route show
default via 192.168.1.1 dev br0 proto dhcp src 192.168.1.11 metric 1024 
10.0.0.0/24 dev wg0 proto kernel scope link src 10.0.0.5 
10.10.10.0/24 dev vxlan0 proto kernel scope link src 10.10.10.91 
114.114.114.114 via 192.168.1.1 dev br0 proto dhcp src 192.168.1.11 metric 1024 
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.11 metric 1024 
192.168.1.1 dev br0 proto dhcp scope link src 192.168.1.11 metric 1024 
223.5.5.5 via 192.168.1.1 dev br0 proto dhcp src 192.168.1.11 metric 1024 

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:e0:4c:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.11/24 metric 1024 brd 192.168.1.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::7c76:c0ff:fe3e:378e/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
3: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d4:3d:7e:ff:ff:ff brd ff:ff:ff:ff:ff:ff
    inet6 fe80::98f1:b8ff:fe44:8c84/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.0.0.5/24 scope global wg0
       valid_lft forever preferred_lft forever
    inet6 fdc9:281f:4d7:9ee9::5/64 scope global 
       valid_lft forever preferred_lft forever
5: vxlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether b6:4c:7c:78:cd:88 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.91/24 brd 10.10.10.255 scope global vxlan0
       valid_lft forever preferred_lft forever
    inet6 2001:0db8:85a3:0000:0000:8a2e:0370:7334/64 scope global temporary dynamic 
       valid_lft 86361sec preferred_lft 14361sec
    inet6 fe80::216:96ff:feec:3c06/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
6: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 00:e0:4c:00:16:34 brd ff:ff:ff:ff:ff:ff
7: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UP group default qlen 1000
    link/ether d4:3d:7e:df:d4:eb brd ff:ff:ff:ff:ff:ff
8: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br1 state UNKNOWN group default qlen 1000
    link/ether fe:c7:c0:fa:ad:8e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fcc7:c0ff:fefa:ad8e/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

Offline

Board footer

Powered by FluxBB