nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Spurious MDNS with IP 169.254.XX.XX

OUSUIXIN

Hello everyone! In my company's network, there are some Ruckus APs as well as some Cisco APs and Cisco Switches. We found a device on the management page of our Cisco Switch that doesn't exist in the topology. Its IP address is 169.254.xx.xx. After packet capture with Wireshark, we found there are some MDNS packet sent by Ruckus APs with ip 169.254.xx.xx. Maybe that is related to Bonjour Service (Once I disable the Bonjour Gateway, the phenomena above disappears)

I wan to know why Ruckus APs would construct and send such an MDNS packet? That makes me confused and brings some trouble to our control and management of device accessing in the network.

Can anyone help me with the above question？ Many thanks!!!

Find more posts tagged with

Accepted answers

All comments

OUSUIXIN

The Access Point I used is R650.

Squozen

Are you sure it’s not a device with a self-assigned IP on the network that is doing a multicast? The Bonjour gateway would just be relaying that broadcast to the other VLAN, it wouldn’t be coming from the Ruckus AP itself. You should see the same broadcast if you capture wifi traffic with a device on the SSID which the device/s are connected to.

OUSUIXIN

Yes, I'm sure the packet with source IP 169.254.XX.XX is created by Ruckus R650, since the source mac address of that packet has a prefix registered by Ruckus (And Wireshark parses the source mac address to RuckusWi_XX:XX:XX).

Note that I configured a Bonjour Service Rule with SrvVlan 200 and CliVlan 800.

Besides the spurious MDNS packet with Vlan 800, there are also another MDNS packet with VLAN 200 according to the packet captured on the wired side. They have the similar/same MDNS payload but the spurious one has source address RuckusWi_XX:XX:XX and source IP 169.254.XX.XX, while the other packet has source 92:2c:09:29:ee:64 and source IP 172.160.200.59.

Thank you for your kindly reply!

OUSUIXIN

Yes, I'm sure the packet with source IP 169.254.XX.XX is created by Ruckus, Since its source mac address has a prefix registered by Ruckus (And Wireshark parses it as RuckusWi_XX:XX:XX)

Note that I configured a Bonjour Service Rule with SrvVlan 200 and CliVlan 800.

Besides the spurious MDNS packets with VLAN 800, there are some other MDNS packets with VLAN 200 according to the packets captured from the wired side. They have similar MDNS payload but differ from mac address, source IP address and VLAN. The spurious packets have source mac address RuckusWi_XX:XX:XX, source IP 169.254.XX.XX and VLAN 800. while the normal packets have source mac address like Chongqin_06:db:e9 and source IP like 172.160.200.59

Squozen

That is what will happen with a relay to another VLAN. The original MAC address wouldn’t pass between VLANs so the Ruckus uses its own MAC address as the ‘source’. Sniff the traffic on the wireless network and you should see a Bonjour broadcast from the actual culprit.

I've attached a packet capture from my network where my Palo Alto firewall is relaying an MDNS packet from my phone on the guest wifi - see how the source MAC address says it's a Palo Alto device, and not the iPhone that actually has the source IP of 192.168.249.17?

Screenshot 2024-08-30 at 18.47.44.png

OUSUIXIN

It's so kind of you to reply so quick.

You means the MDNS packet with MAC address 92:2c:09:29:ee:64 and VLAN 200 can not be passed to VLAN 800 where some MDNS queriers exist?

So why don't Ruckus relay that MDNS packet with only VLAN changed? I mean Ruckus R650 can relay a MDNS packet with VLAN 800 while keeping the source MAC (92:2c:09:29:ee:64 ) and source IP (172.160.200.59) of the actual culprit, instead of relaying a MDNS packet with VLAN 800 and source MAC RuckusWi_XX:XX:XX and IP (169.254.XX.XX), which is fake/spurious information.

Why is it necessary to replace the source MAC address? Is it for privacy protection? If so, why can I still capture the original MDNS packet with actual MAC on the wired side of Ruckus R650? Or do you mean actual MAC address is bind to specific VLAN so only change VLAN of the original MDNS packet is not enough, the MDNS packet may still be dropped?

And below is another doubt：according to my observation, fake/spurious IP like 169.254.XX.XX can be seen not only when Ruckus R650 receives the MDNS response packet from device connected to some SSID of Ruckus, but also when Ruckus receive the MDNS query packet from its wired side. If there is already relaying behavior for Ruckus, why does Ruckus still answer MDNS query on behalf? I mean it is not necessary to answer/reply MDNS query, just relaying the MDNS packet with VLAN changed is enough.

Squozen

The source MAC is changed because multicasts cannot route between networks by default. This is why the Bonjour gateway feature exists in the first place. Using a single MAC instead of passing on the real source MAC address reduces resource use on the destination VLAN.

I’ll repeat what I said earlier - run Wireshark on the source VLAN, not the destination VLAN, and you’ll find the MAC address of the device that is sending the multicast packets. Something is failing to obtain a DHCP address and falling back to a self-assigned IP.