The Minecraft client (when you enter "multiplayer" mode) says "Scanning LAN for Local Servers..."

What is it doing?

Here's my problem: if computer A and computer B are connected together through Switch1, then computer A can run the minecraft client and find a minecraft server on computer B. But if computer C is connected through Switch2, C cannot see the server running on B. However, C can ping B, and C can connect to the server at if this IP/port are directly entered.

So the mechanism by which clients locate servers is somehow blocked by Switch2. Is this UPnP? Or something similar?

It's a huge pain to keep track of the shifting IP addresses and shifting port numbers each time you start a minecraft server.

  • If switch1 and switch2 are on the same layer 2 network (ie, not routed) then it will work, so I guess you are routing between these two networks. Do you need these two be separate? – Paul Aug 26 '16 at 3:26
  • @Paul Both are on the same LAN (yes, layer 2), but Switch2 is somehow filtering a critical service. I'm trying to figure out what. Perhaps HTTPMU isn't working (which is the basis for UPnP). But I'm hoping someone here can tell me how Minecraft searches for its servers. – Fixee Aug 26 '16 at 4:02
  • Interesting - if switch one and switch two are connected at layer 2, then there shouldn't be any filtering - that type of inspection normally happens at routing, At a switching level we are only interested in mac addresses, whereas upnp/ssdp operates at a multicast level sending to a multicast mac. So anything in your switch blocking multicast traffic? – Paul Aug 26 '16 at 4:34
  • @Paul The switch is a wi-fi router (where all computers are on the same LAN within the router's DHCP domain). It may be doing some kind of filtering, but I am unable to figure it out. There is no explicit setting that I can find for UDP broadcast filtering. – Fixee Aug 26 '16 at 4:56
up vote 3 down vote accepted

I did a bit of packet capturing on Wireshark and to the best of what I can tell, it uses an IGMPv2 packet sent to a lesser used multicast address (, asking for anyone running a Minecraft server to report back. It uses a "Membership report" to do this.

For the nerds, here is the complete packet dump info:

Frame 10: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) on interface 0
    Interface id: 0 (\Device\NPF_{F0A28F43-6094-447F-A150-434AFC4BB19B})
    Encapsulation type: Ethernet (1)
    Arrival Time: Aug 25, 2016 22:25:55.171363000 US Mountain Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1472189155.171363000 seconds
    [Time delta from previous captured frame: 0.235431000 seconds]
    [Time delta from previous displayed frame: 0.235431000 seconds]
    [Time since reference or first frame: 1.234950000 seconds]
    Frame Number: 10
    Frame Length: 46 bytes (368 bits)
    Capture Length: 46 bytes (368 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:igmp:igmp]
    [Coloring Rule Name: Routing]
    [Coloring Rule String: hsrp || eigrp || ospf || bgp || cdp || vrrp || carp || gvrp || igmp || ismp]
Ethernet II, Src: Giga-Byt_91:9c:dc (fc:aa:14:91:9c:dc), Dst: IPv4mcast_02:3c (01:00:5e:00:02:3c)
    Destination: IPv4mcast_02:3c (01:00:5e:00:02:3c)
        Address: IPv4mcast_02:3c (01:00:5e:00:02:3c)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: Giga-Byt_91:9c:dc (fc:aa:14:91:9c:dc)
        Address: Giga-Byt_91:9c:dc (fc:aa:14:91:9c:dc)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src:, Dst:
    0100 .... = Version: 4
    .... 0110 = Header Length: 24 bytes
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 32
    Identification: 0x4347 (17223)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 1
    Protocol: IGMP (2)
    Header checksum: 0x0000 [validation disabled]
        [Good: False]
        [Bad: False]
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
    Options: (4 bytes), Router Alert
        Router Alert (4 bytes): Router shall examine packet (0)
            Type: 148
                1... .... = Copy on fragmentation: Yes
                .00. .... = Class: Control (0)
                ...1 0100 = Number: Router Alert (20)
            Length: 4
            Router Alert: Router shall examine packet (0)
Internet Group Management Protocol
    [IGMP Version: 2]
    Type: Membership Report (0x16)
    Max Resp Time: 0.0 sec (0x00)
    Header checksum: 0x07c3 [correct]
    Multicast Address:

Here is the raw packet dump:

0000   01 00 5e 00 02 3c fc aa 14 91 9c dc 08 00 46 00  ..^..<........F.
0010   00 20 43 47 00 00 01 02 00 00 c0 a8 01 2e e0 00  . CG............
0020   02 3c 94 04 00 00 16 00 07 c3 e0 00 02 3c        .<...........<

So to answer your problem, you might have multicasts turned off on your router, or IGMP is disabled. I'm not completely familiar with the flags, but it looks like it there might be something in the Options/Router Alert field... Probably telling the router to not forward the multicast outside of the subnet, but that's just a guess.

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.