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!!!

[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?

[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.

[OUSUIXIN]

I'm sure the spurious packets are created and send by Ruckus, and the attached figures are evidence: I sniff the traffic on the wireless network, and find the device that is sending the MDNS packet with mac f2:ee:8a:f4:13:45 and IP 192.168.10.102 (figure 1). But in figure 2 I also find the spurious packet on the wireless side with MAC RuckusWirele_a7:0c:43 (28:b3:71: ) and IP 169.254.25.191, which means the spurious IP 169.254.XX.XX is not Something failing to obtain a DHCP address and falling back self-assigned IP, it is definitely assigned by Ruckus!

[Squozen]

So, you think the Ruckus is responding to MDNS requests and it suddenly decides not to do it when you turn off the Bonjour gateway, rather than it being a rogue device on your network. Ok! I think you still haven’t grasped how a Bonjour gateway works if you think that the MAC address being the Ruckus is a smoking gun?

Have you tried expanding the MDNS answer fields to see what information the ‘Ruckus’ is sending?

Would I be correct in guessing that the wired side of the network doesn’t have DHCP configured? Have you sniffed the traffic on the wired side yet to see if you can find the 169.254.25.191 device?

Do you know where the Vivo Nex phone is on the network? Is it the 192.168.10.102 device?

From what I can see on your capture, you are seeing Apple Airplay MDNS traffic. Looking through the _raop._tcp.local RRs should reveal some more information.

https://openairplay.github.io/airplay-spec/service_discovery.html