Problem with L3 adoption for Unifi gear in 2.3.3 / 2.4 beta?
-
Talking about the DNS method. (Option 43 is something I'd avoid since it causes inexplicable issues, such as broken PXE boot with non-UBNT gear.)
-
DHCP Opt 43 will only accept an IP address. Pretty bad way to do it if you ask me, since IP's can change and if you have 100 sites… man what a nightmare to update it. DNS method that has always worked for me (again stating this) is much more flexible since you can use an FQDN.
Dok I was not trying to challenge your knowledge or imply anything I am merely stating facts. No need for aggression. Not sure what you mean about "badly described/documented behind-the-scenes logic looking for options configured in completely different places of pfSense and picking that up for unrelated stuff" but nothing I've posted is particularly esoteric. In any case, I don't think I'm the only one experiencing this, and I will get to the bottom of it shortly when I can sit down with some gear and do some deeper testing w/ packet captures.
-
I mean the logic of "$foo config option setup in that place will be used for $bar option in another place if $baz in yet another place is unchecked or $zomg is not configured". I cannot see how this helps anyone.
Other than that, I don't know what still doesn't work for you. Configure the ""Domain name" in DHCP server configuration. The busybox DHCP client doesn't take option 119. Most things don't, as noted above.
https://forum.pfsense.org/index.php?topic=126354.msg698200#msg698200
-
Ok I just tested this - who says you can set an override for single label ie host name to resolve? I just created this entry and it seems to resolve just fine with just using unifi in a dns query.
-
you set 'unifi' in the 'domain'? and left 'hostname' blank? never seen it done that way before.
-
its single label… that is how you would do it ;) You need to understand what the different entries in a fqdn are.. A single label or host would end up actually just being the tld (top level domain). Like com or net or org, etc. When you talk about it as a fqdn.. Which is what the gui is asking for..
This seems pretty simple to do vs just doing the same thing in the options box..
-
Ok guys, long update here. I have been doing lots of testing.
TL;DR — there is a bug in the version of busybox udhcpc (1.19.4) compiled into Unifi hardware that causes this. When the search domain begins with a numeric character, udhcpc barfs on it and sets the search domain to "bad" in /etc/resolv.conf (screenshot below). This causes the device to fail to register with the controller. The bug was fixed a year-and-a-half ago so I don't know why we are stuck with such an ancient version, but I opened a post over on the UBNT forums and am awaiting a response. For now the only simple fix that works in all test cases below is to use workaround #2 or #3 below. If you care, you can read more…
There are 3 known workarounds:
1. Don't use a system domain that starts with a number (may or may not be an option for you)
2. Use my patch (for 2.4b use this commit, for 2.3.3 use this commit) and tick the "add unqualified (short) hostname" checkbox on your unifi.whatever host override PR#3599
3. In Custom Options of DNS Resolver, add a line e.g.local-data: "unifi A 4.5.6.7"I built up a mini lab with a fresh install of 2.3.3 on APU2 hardware. Bog-standard out of the box config, I was focusing solely on isolating this issue and reproducing it. I believe I have uncovered something strange.
The ingredients for the test were:
• unprovisioned Unifi Access Point - running latest stable firmware which at the time was 3.7.40.6115*
• pfSense CE 2.3.3 on APU2 hardware - clean install
• 2 interfaces configured - WAN/LAN
• Unifi WAP plugged directly into LAN interface (POE injector)
• DNS handled by Unbound - default config options [Transparent/DNSSEC enabled]
• Single Host Override defined "unifi.system-domain" pointing to imaginary controller 1.2.3.4
• system-domain was alternated between36hudson.lanandhudson36.lan
• also tested all of the above again with PR#3599 installed, with and without enabling the "add unqualified hostname" optionSteps
1. boot Unifi WAP from powered-off state
2. once it's booted, ssh in and runcat /etc/resolv.conf ping unifi (if that fails, ping unifi.fqdn) nslookup unifi (if fail, nslookup unifi.fqdn)The test results are below. While it's not a pfSense-specific issue, I believe that my patch handles this problem cleanly, and due to the popularity of Unifi + pfSense, it would be helpful to have it in there. It does fix the issue for me and until Ubiquiti resolves the matter, at least we have an easy & consistent way to patch any affected systems. I do have some .pcap packet captures if anyone needs those, but honestly once I found the issue it was pretty easy to reproduce and after inspecting them in Wireshark, I don't think this bug is a result of any malformed requests or responses on the wire.
*also tested with 2 older firmwares [3.4.14.3413, 3.7.39.6089] – same results
-
Linking the UBNT thread here, such bugs obviously need to fixed by Ubiquiti.
https://community.ubnt.com/t5/UniFi-Wireless/Unifi-DHCP-opt-15-search-domain-starts-with-a-number-BARF/m-p/1854593#M214919
EDIT: That is an outdated busybox version bug.
-
I had already linked to it in my above post…
While the bug is Ubiquiti's, since the culprit lies in the out of date udhcpc, other gear will likely exhibit the problem (eg Linksys etc).
Aside from providing a viable workaround, the PR I submitted adds a couple of useful features as well as fixes one bug on recent 2.4 snaps with editing / saving existing overrides. So I still believe it merits being merged.
-
The offending code is linked on the UBNT thread.
-
cmb announced that the bug was fixed by Ubiquiti today. Not sure what specific build of the firmware contains the fix, but it should be out very soon.
-
Ubnt released a version of their firmware today that contains the busybox fix for this issue. Release post here (it's ver 3.7.49.6201)
-
FYI- If you have an AP that won't update and appears stuck on an older firmware, like mine, set its WLAN config to 'off' and then run the update, then set it back to 'Default' or whatever WLAN group it was a member of.
Why is that necessary? Who knows… But given everything else about them that's happened in the last day, I'm not surprised. :-X
