Problem with L3 adoption for Unifi gear in 2.3.3 / 2.4 beta?

doktornotor

Errr, guys, dunno what you are doing there really.

Set up a host override for unifi. <search.domain>pointing to the controller's IP
put <search.domain>to "Domain name" and "Domain search list" in DHCP server settings
put the interface IP as DNS server in DHCP server settings

Done. Works.

If it doesn't work for you, perhaps reset your APs/switch/whatever UniFi gear.</search.domain></search.domain>

FreeMinded

I didn't set the domain name (only the the domain search list). With the domain name set as well it works!
Why is the domain name required in this case? Should it really be this way or is this a bug on the Unifi side?

Thanks doktornotor!

@johnpoz doing as you say would need to configure every AP manually. This is not an option if you have many of them.

doktornotor

This is from /etc/udhcpc/udhcpc (FW v3.7.42)


configure_dns()
{
        # do not remove resolv.conf if no dns servers received from dhcp
        if [ ".$dns" = "." ]; then
                return 0
        fi

        echo -n > $RESOLV_CONF
        [ -n "$domain" ] && echo search $domain >> $RESOLV_CONF
        for i in $dns ; do
                echo adding dns $i
                echo nameserver $i >> $RESOLV_CONF
        done
        echo "127.0.0.1 localhost.localdomain   localhost" > $HOSTS_CONF
        [ -n "$unifi_addr" ] && echo adding unifi-server $unifi_addr
        [ -n "$unifi_addr" ] && echo "$unifi_addr       unifi" >> $HOSTS_CONF
}

Busybox needs to be compiled with FEATURE_UDHCP_RFC3397 for Option 119 to work. No idea what's UBNT doing with busybox, looks to me like they are using Option 015 instead. (Then again, MS doesn't support this either, so you really should set up both.)

luckman212

Never before had to set any options in DHCP for search domain etc. Defaults always worked up until 2.3.3 so something has changed, still haven't been able to run those Wireshark captures to figure out what exactly the reason is – but I hope to find time to do that later today. I imagine that dok might not have encountered this (yet) because I believe existing devices that have already been Adopted and have their set-inform URL in place will continue to work, but if the devices are factory reset or brand new out of the box unprovisioned devices will fail to reach the controller.

johnpoz

If you have a lot of them to setup And your controller is on a different network - can you not just use the discovery tool on that local network your AP are on and set them to use the FQDN for the inform.. That is what the discovery util is for is it not.

If your not on site, then I would admin the dhcp to give them the fqdn they should use..

Setting up a host only name to resolve would be my last choice. Devices should always be resolved via fqdn not some host name.. Even if your on the same layer 2 and can broadcast for a name - it is still better practice to always use a fqdn..

Last option would be to set your dns to resolve host only name without a domain.

That is my 2 cents on the matter.

doktornotor

@luckman212:

I imagine that dok might not have encountered this (yet) because I believe existing devices that have already been Adopted and have their set-inform URL in place will continue to work, but if the devices are factory reset or brand new out of the box unprovisioned devices will fail to reach the controller.

Erm… nope. The whole goal of the setup is that you plug in a never configured AP via a cable and it shows up in controller for adoption. So that when some gear dies, you can ship a replacement and all that's required is plugging a cable in to get things working again. Works just perfectly fine with setup as shown above. It works with the controller on LAN, it works with a remote site connected via IPsec, or another connected via site-to-site OpenVPN. It works over WAN as well as long as you forward 8080 to the controller.

(And sorry, I cannot comment on setups that rely on some confusing, badly described/documented behind-the-scenes logic looking for options configured in completely different places of pfSense and picking that up for unrelated stuff when people cannot be bothered to set things up. It takes about 60 seconds to set up things explicitly and avoid any unexpected behaviour or breakage.)

johnpoz

where are you coming up with option 15 or 119.. You only need to setup option 43 for unifi devices to find their L3 controller..

doktornotor

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

luckman212

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.

doktornotor

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

johnpoz

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.

hostnamequery.png_thumb

luckman212

you set 'unifi' in the 'domain'? and left 'hostname' blank? never seen it done that way before.

johnpoz

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

luckman212

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 between 36hudson.lan and hudson36.lan
• also tested all of the above again with PR#3599 installed, with and without enabling the "add unqualified hostname" option

Steps
1. boot Unifi WAP from powered-off state
2. once it's booted, ssh in and run

cat /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

doktornotor

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.

luckman212

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.

doktornotor

The offending code is linked on the UBNT thread.

luckman212

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.

luckman212

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)

jimp

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