[SOLVED] IGMP and getting Minecraft LAN to work

I want my children to be able to play Minecraft LAN games. Yes, I can set up a server, but sometimes if one of them is playing in a world, he will want to just turn on LAN and serve his game to his brother... so that should be able to work.

As it is, it works fine if they are both on the same physical segment of the network. The network looks like this:

Router ---- > Smart Switch 1 ----> Smart switch 2 ----> LEDE AP ---- wifi WDS ---- Another LEDE AP --> dumb switch --- two computers Segment 1
                                         |-----> More computers  Segment 2

so, the two computers connected to the same dumb switch In Segment 1 play just fine with each other, but if one computer is in Segment 1 and one is in Segment 2 they don't see each other.

On the hardware smart switches, I have IGMP snooping enabled, and I have the Smart Switch 1 set up as an IGMP querier.

So, somehow the LEDE/WDS link is not correctly snooping the IGMP and routing the UDP multicast announcements from Segment 2 back to Segment 1 or vice versa.

Eventually I'll eliminate that WDS segment with a wire, but for the moment, is there a way to make the two LEDE boxes with WDS do correct IGMP snooping. I'd rather not just turn off snooping and blast all the multicast packets around, because in part I want to figure out how snooping should work, and be able to configure it correctly.

Also note, I can't wait until programmers are assuming ipv6 is the main way things work. My understanding is that under ipv6 this would "just work" because multicast is hardwired in the ipv6 protocol.

EDIT: Minecraft advertises itself by sending multicast UDP messages to 224.0.2.60 saying essentially "here I am, connect to my IP on this port" so I need to get these announcements to show up across the two segments.

Both lede APs dont do any firewalling/nat?
Is guess you bridged all interfaces to one bridge together.
did you set option igmp_snooping '0' for the bridge interfaces?
You also have to adjust the ttl of the multicast packets. (default is 1 on most systems)
Either on the clients or through a iptable rule(s) on the lede ap(s).

That's right, the APs are just straight up LAN bridges. I did not set igmp_snooping to 0 as that would disable snooping, and it seems to me the point of snooping is to send the multicast packets only to the right place isn't it? So it seems like what we want here is to set up snooping correctly rather than disable it (though I recognize it could maybe start working if I disabled snooping... so I'll see what happens if I test that).

The TTL point is worth looking into also, I'll do some packet sniffing.

it seems to me the point of snooping is to send the multicast packets only to the right place isn’t it?

Yes. But since there is no way to configure igmp snooping per interface basis, atleast i dont know of any way :>,
you have to disable igmp snooping on the bridge, to make the bridge forward multicast traffic.

I dont own a manageable switch or have worked with one.
But on your smart switches, when you enable igmp snooping, you can enable it on each port/vlan you want it (and set the multicast adresses) or?

So, in the end after wiresharking, I could see that the multicast packets actually WERE being forwarded from the Segment1 network to Segment2 but the machine that was on Segment 2 had firewall rules that were dropping multicast packets.

Once i adjusted the firewall on the machine in segment 2 the multicast packets got where they needed to go.

1 Like

Im glad you got this sorted out =)