10-20-2018 10:53 PM
Ok i will try to search for a refund or RMA but do you know if I return the switches to the firmware 3. 9. 6 can I find stability because that's what I need now I'm in a really hurry because it's a big deployment and I needed stable ASAP thank you very much
10-21-2018 06:23 AM - edited 10-21-2018 06:29 AM
Thanks!! Sorry to bother do I have to worry about dhcp snooping after downgrading? Just to understand better, if id stsy at latest firmware and disabled dhcp snooping the problem would continue nevertheless?
The AP’s can stay at latest or do I have to revert them also (more than 110 on this site)
10-21-2018 08:46 AM
Does this problem has to do with multicast or dhcp snooping? I have more than 100 appletvs so that when users arrive the network gets down before users get in everything is great
11-01-2018 10:16 AM
Why is this still an issue and why are Ubiquiti not doing anything about it? Someone from ubnt emailed me asking them to help with debugging the issue but because this destroys my network and I don't have any spare switches just lying around I couldn't help without UUBNT sending me a switch - I'm not ploughing more money into UBNT if they aren't going to even try and fix something after many people have reported it as broken.
11-01-2018 10:19 AM
11-13-2018 07:26 AM
11-13-2018 06:36 PM
What is strange is Firmware 220.127.116.1113 isnt even on the unifi firmware download page. Was it never an official release? Was there an official release that does not have this issue?
I tried like hell today to get 2 48 ports to update to 18.104.22.16813 and they failed every time. I tried custom firmware link with https and http as well as winscp upload of the file and manual putty upgrade and still failed.... has something happened?
11-13-2018 06:52 PM
a month ago
Sorry for taking too long to provide a solution.
Finally I have a patched dev. firmware and the DHCP issue seems to be fixed in some users' environment.
Because this patch is still in the release process, and it would not be available until tag 4.0.7 is released.
If guys would like to try it first, just PM me.
4 weeks ago
The firmware mentioned by @ubnt-tim has been merged into a tagged release. The potential fix can be found by upgrading to any firmware after 4.0.7. The 4.0.8 firmware is still in beta testing but can be found by enabling early access on your account.
4 weeks ago
I think there are a lot of us who would like to understand why this took so long to resolve.
- Why did this issue seem to be ignored when initially reported in the forum
- Why did the issue seem to be ignored when reported in support tickets
- How did identification of the issue by Ubnt take so long after the forum members had worked out what the root cause was?
- Why was there no engagement from Ubnt in the forum?
2 weeks ago
I tried both the firmware from @ubnt-tim and 22.214.171.12418 buth DHCP problem still exists. I can't get my WDS up and running again. Is there any way to check if unifi is blocking my DHCP requests or any other thing I can do to get this fixed.
2 weeks ago
In both firmware, there is a debug command to dump DHCP snooping log to syslog:
# telnet 127.0.0.1
(UBNT) #debug dhcpsnooping packet
Back to shell, an example output like this:
# tail -f /var/log/message | grep DHCP_SNP
Nov 13 11:03:41 US16P-150W daemon.info switch: DHCP_SNP: DHCP_REQUEST port:5 vlan:100 - client MAC:00:E0:9C:10:0F:29 requested IP:192.168.1.117 Nov 13 11:03:41 US16P-150W daemon.info switch: DHCP_SNP: DHCP_NACK port:1 vlan:100 - server IP:192.168.100.1, client MAC:00:E0:9C:10:0F:29 Nov 13 11:03:41 US16P-150W daemon.info switch: DHCP_SNP: DHCP_DISCOVER port:5 vlan:100 - client MAC:00:E0:9C:10:0F:29 Nov 13 11:03:42 US16P-150W daemon.info switch: DHCP_SNP: DHCP_OFFER port:1 vlan:100 - server IP:192.168.100.1, client MAC:00:E0:9C:10:0F:29 IP:192.168.100.11 Nov 13 11:03:42 US16P-150W daemon.info switch: DHCP_SNP: DHCP_REQUEST port:5 vlan:100 - client MAC:00:E0:9C:10:0F:29 requested IP:192.168.100.11 Nov 13 11:03:42 US16P-150W daemon.info switch: DHCP_SNP: DHCP_ACK port:1 vlan:100 - server IP:192.168.100.1, client MAC:00:E0:9C:10:0F:29 IP:192.168.100.11
Another method is, if you are using USG as DHCP server, a command can enable DHCP log as folloing:
(login to USG) admin@ubnt:~$ configure  admin@ubnt# set system syslog global facility daemon level debug admin@ubnt# commit [ system syslog ] Stopping enhanced syslogd: rsyslogd. Starting enhanced syslogd: rsyslogd.  admin@ubnt# sudo su root@ubnt:/home/admin# root@ubnt:/home/admin# grep dhcpd /var/log/messages*
Those logs will help to clearfy the root cause.
2 weeks ago
@ubnt-tim I think I'm doing something wrong because I'm not seeing anything DHCP related in the logs.
This is what I'm doing:
- Logging in to the unifi controller
- Starting a debug terminal using the tools tab
- Issueing these commands in this order:
debug dhcpsnooping packet
tail -f /var/log/messages | grep DHCP_SNP
After that I'm not seeing anything in the log related to DHCP. Where do I go wrong?
2 weeks ago
If it is a wired device, try to un-plug/plug ethernet port.
If it is a cellphone, try to re-enable the wireless, make sure the Access Point is also under that switch.
a week ago
@ubnt-tim I did retrigger the DHCP events, both on wired and wireless devices. But nothing is logged. I looked at the logs of the switch where the devices are connected and on our core switch (the one where our DHCP-server is).