09-22-2017 09:00 PM - edited 09-23-2017 09:06 AM
Curious if anyone else has seen where "Block LAN to WLAN Multicast and Broadcast Data" seems to break DHCP for some wireless clients. In my case, it was specifically my Liftmaster 821LM.
My DHCP server (USG) was added as an exception, but didn't matter. Hadn't tried adding the 821LM, but could it be doing DHCP in some odd way (why would it be different)?
Would love some info if others have seen this. I'd really like to leave the feature enabled, but at this point, it's gotta stay off. =(
09-23-2017 09:03 AM - edited 09-23-2017 09:05 AM
So, looking at this a bit further (and I thank waking up in the middle of the night with an epiphany):
It looks like the auto-detect adding of the USG's ethernet MAC is adding eth0, and not eth1 or eth2... meaning they can't respond to DHCP requests.
On my USG, I have (I got these by SSHing into the USG, and doing "show interfaces ethernet eth0" and then eth1, and eth2):
But... if I click "Block LAN to WLAN Multicast and Broadcast Data", I see:
f0:9f:c2:c5:62:63 usg (Auto-Detected)
That... seems wrong. I can manually add eth1 and eth2 (via "Add Batch") and that solves the problem. So it looks like the logic for deciding which MAC to add via auto-detect needs to be adjusted. =/ Or I'm missing something obvious...
11-23-2017 11:11 AM
This hosed me too.
I never added any exceptions, but the verbiage on the tooltip suggested that this was station-to-station broadcast traffic that would be affected.
tcpdump on the AP itself saw the DHCP REQUEST and the OFFER, but no ACK, so I was kind of puzzled.
Reading this (https://help.ubnt.com/hc/en-us/articles/115001529267-UniFi-Managing-Broadcast-Traffic), specifically this part "This is why verifying the blockage via
tcpdump won't work. You will however, be able to observe by listening on their wireless interface, that once this feature is enabled, broadcast traffic will not be received by any computer connected to that AP, even though you would still be able to see that traffic when running
tcpdump -i athX on the AP. " explained it all.
10-11-2018 11:15 AM
10-11-2018 01:06 PM
What I find strange is that after at least well over a year this bug is still (or again?) in the software.
And what I also don't understand is that our iPad's, iPhone's and my Surface are not affected by this problem.
Apparently something is different with the way they request and get an IP from DHCP then the EvoHome.
11-26-2018 11:18 PM - edited 11-26-2018 11:26 PM
I ran across this issue with some Wemo Mini switches. They wouldn't get a connection (orange blinking light) if I had "Block LAN to WLAN Multicast and Broadcast Data" checked. If I connected them with blocking disabled and later enabled the blocking, the switches would eventually lose their connection. Adding the switches to the list of Excepted Devices didn't help.
Doing a tcpdump on the USG and watching the Wemo switch attempt DHCP, then comparing the traffic with another device that can successfully get an IP via DHCP, it looks like the Wemo switch sets the bootp flag to broadcast, whereas the successful device sets the bootp flag to unicast. The successful device gets its DHCP offer via unicast and everything is fine. But the Wemo switch gets its DHCP offer via broadcast (as it requested), which is blocked because the USG's eth1 (LAN1) MAC isn't in the list of Excepted Devices. So it just keeps sending discover packets and never gets a response. As discussed earlier in this thread, the USG eth0 device's MAC is added to the Excepted Devices list by default, but not eth1. Manually adding the eth1 MAC to the list fixes the problem for me, but I'd love to see this fixed in an update.
11-26-2018 11:21 PM - edited 11-26-2018 11:23 PM
@UBNT-MikeD: any input on this issue?
3 weeks ago
Thank you @staze this fixed my issue with a client and an older wifi unit not receiving an IP after connecting to my AC AP PRO.
When I enabled Block LAN to WLAN Multicast and Broadcast Data it added the default mac ending with ...50:c3 but if I SSH to the USG and typed
show interfaces ethernet eth1
the correct mac address is ...50:c4
So when I added this mac to the list and clicked save, all OK.
@UBNT-Brandon is this a bug in unifi?
UniFi AP-AC-Pro 126.96.36.19973
UniFi Security Gateway 3P 188.8.131.5246617
UniFi Switch 8 POE-150W 184.108.40.20673
Maybe I didnt have to downgrade my whole setup because in the end the problem was wrong mac address...
3 weeks ago
But I didn't want to change settings because my setup has been working for so long. My problems started after some weeks after a upgade, and there is only 1 wifi client with this problem. Its a internet radio with a Frontier chipset. All my other newer devices works.
My internet radio connects fine, but does not receive an IP.
So I wanted to do a different approach, and started to ask some questions:
1. Why did this happen now?
2. Why is this only happening to my internet radio?
3. Why is the mac address unifi set, different from the one I found with ssh? And why did this work?
4. Is this mac address thing a bug in unifi?
5. Is the Frontier chipset doing something that unifi dont like?
I did capture some data with wireshark. Broadcast ARP says stuff like
Who has 169.254.243.133? Tell 0.0.0.0
169.254.243.133 is the Frontier device. https://www.frontiersmart.com/
Then there is some EAPOL stuff from Ubiquiti, then SSDP and MDNS
3 weeks ago
Adding the additional MAC addresses as explained by Staze immediately resolved my WeMo issues, which had become so problematic I was planning to remove all of them from my house. Thanks!