topic Spurious MDNS with IP 169.254.XX.XX in Access Points - Indoor and Outdoor

Spurious MDNS with IP 169.254.XX.XX

OUSUIXIN — Fri, 30 Aug 2024 05:50:14 GMT

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

Re: Spurious MDNS with IP 169.254.XX.XX

OUSUIXIN — Fri, 30 Aug 2024 05:52:15 GMT

The Access Point I used is R650.

Re: Spurious MDNS with IP 169.254.XX.XX

Squozen — Fri, 30 Aug 2024 14:34:49 GMT

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.

Re: Spurious MDNS with IP 169.254.XX.XX

OUSUIXIN — Fri, 30 Aug 2024 15:38:26 GMT

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!

Re: Spurious MDNS with IP 169.254.XX.XX

OUSUIXIN — Fri, 30 Aug 2024 15:56:31 GMT

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

Re: Spurious MDNS with IP 169.254.XX.XX

Squozen — Fri, 30 Aug 2024 17:56:43 GMT

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?

Re: Spurious MDNS with IP 169.254.XX.XX

OUSUIXIN — Sat, 31 Aug 2024 03:50:54 GMT

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.

Re: Spurious MDNS with IP 169.254.XX.XX

Squozen — Sat, 31 Aug 2024 06:31:05 GMT

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.

Re: Spurious MDNS with IP 169.254.XX.XX

OUSUIXIN — Mon, 02 Sep 2024 10:07:20 GMT

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!

Re: Spurious MDNS with IP 169.254.XX.XX

Squozen — Mon, 02 Sep 2024 20:36:34 GMT

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