[Support] Linuxserver.io - Unifi


Recommended Posts

19 hours ago, anethema said:

Any chance you guys will make it possible to never upgrade past the 5.6.36 LTS ?

 

5.7x is dropping support for all their APs below the version currently being sold, so for a lot of networks this will mess us up. Not sure if it would be possible to add a "LTS" tag or something to stay on this one?

 

I know I could just not update the docker ever again, but I am just asking due to maybe messing up and clicking the upgrade, or somehow misconfiguring the auto update plugin to do it, etc.

 

Per mention on Reddit by Ubiquiti employees, this isn't entirely accurate.

 

AP Generations:

Gen 1: UAP, UAP-LR, UAP-OD, UAP-OD5, UAP-v2, UAP-LR-v2, UAP-IW, UAP-Pro, UAP-OD+

Gen 2: UAP-AC-Lite/LR/Pro/EDU/M/M-PRO/IW/IW-Pro

Gen 3: UAP-HD/SHD/XG

Very recently added:

MTK Gen 1: UAP-nanoHD

 

The ones EOL and not supported in 5.7 anymore:

BRCM Gen 1: UAP-AC, UAP-ACv2, UAP-AC-Outdoor

 

So basically only 3 of the 9 original Gen1 AP's have reached End of Life with 5.7.x, so its definitely not "dropping support for all their APs below the version currently being sold" since 2/3rds of the original Gen1 and all the other Gen's are still supported for now.  

 

That said, I agree that it would be good practice to have an LTS tag for the container in addition to the Stable and Unstable tags.

 

Per the discussion above, it looks like the Stable tag is the LTS tag since latest on LTS is 5.6.36 and matches the latest update on Stable.

 

Edited by jedimstr
Link to comment

unifi docker it still completely broken for me.

 

Can it be recovered, or am I looking at having to re-install the whole thing?  I posted diags a while back before the huge version discussion.

 

If I have to reconfigure and restore, so be it, but I have no idea how to erase the "my-unifi" template and start from scratch.

 

Thanks.

Link to comment

After updating the UniFI docker to the latest (controller version 5.6.36) one of my UniFI switches became disconnected in the controller.  Everything else is recognized and connected.

 

I am not saying the container update caused the problem, I just first noticed the problem after the update.

 

I reset the switch to factory defaults and told the controller to "forget" it, which it has.  It no longer shows up in the devices list.  However, I can't get it re-adopted either.  it never shows up.  I connected via SSH and ran a set-inform 192.168.1.10:8080/inform which claims to have sent an adoption request to the controller, but, the switch still does not show up.

 

Ubiquiti support has told me to try what I have already tried (forget, reset, adopt - can't do that last bit)  Perhaps they will come back with something different after my latest report.

 

Any ideas what I should try next?  Has anyone here seen this problem?

Edited by Hoopster
Link to comment
2 hours ago, Hoopster said:

After updating the UniFI docker to the latest (controller version 3.6.36) one of my UniFI switches became disconnected in the controller.  Everything else is recognized and connected.

 

I am not saying the container update caused the problem, I just first noticed the problem after the update.

 

I reset the switch to factory defaults and told the controller to "forget" it, which it has.  It no longer shows up in the devices list.  However, I can't get it re-adopted either.  it never shows up.  I connected via SSH and ran a set-inform 192.168.1.10:8080/inform which claims to have sent an adoption request to the controller, but, the switch still does not show up.

 

Ubiquiti support has told me to try what I have already tried (forget, reset, adopt - can't do that last bit)  Perhaps they will come back with something different after my latest report.

 

Any ideas what I should try next?  Has anyone here seen this problem?

 

Try the controller override settings detailed on the previous page of this thread (pg 23).  There are screenshots of the settings you need to change.  Do this in conjunction with another cycle of set-inform (you actually have to do set-inform twice on the device usually, before and after you request adoption on the controller).

Link to comment

The problem was resolved by running the set-inform command several times consecutively in rapid succession.  After about 4-5 times the switch showed up in the controller pending adoption and was able to be re-adopted.  Apparently, just running set-inform once may not really send an adoption request.  Ubiquiti pointed this out to me and 4-5 times running it primed the pump so to speak.

 

Who knew?

Edited by Hoopster
Link to comment

My post is lost in this version mess.

 

Where else can I find the run command syntax to post?  Besides the docker interface in the GUI.  Since its not there.  Anywhere.

 

And still can't re-add the unifi docker.... When I select the template and select 'save' or 'apply', the page goes blank/white/'view source' is blank.  Nothing happens.  Can't re-build the unifi docker at all.

Edited by tucansam
Link to comment
10 minutes ago, tucansam said:

My post is lost in this version mess.

 

Where else can I find the run command syntax to post?  Besides the docker interface in the GUI.  Since its not there.  Anywhere.

 

And still can't re-add the unifi docker.... When I select the template and select 'save' or 'apply', the page goes blank/white/'view source' is blank.  Nothing happens.  Can't re-build the unifi docker at all.

 

the run command is to be found where you have been told it can be

 

if you're having white screens or unresponsive webui problems then that would point to either a browser cache problem or worst case scenario something wrong in the host but i'd be leaning towards the first

Link to comment

http://192.168.0.5/Docker/AddContainer?xmlTemplate=user%3A%2Fboot%2Fconfig%2Fplugins%2FdockerMan%2Ftemplates-user%2Fmy-unifi.xml&rmTemplate=&csrf_token=9910968FDB4C51A5

 

 

That's the URL that shows a blank screen when I try to add the unifi docker back.  Tried three different browsers on three different computers; two of those browsers were just newly installed, specifically to test the cache theory, and had the same issue.

 

Had renamed docker.img prior, and was able to add my other three items (sab, sonarr, plex) without issue.

 

What else can I try?  Worst case, how do I blow the entire unfi setup out of existence completely and start from scratch?

Link to comment
4 minutes ago, tucansam said:

http://192.168.0.5/Docker/AddContainer?xmlTemplate=user%3A%2Fboot%2Fconfig%2Fplugins%2FdockerMan%2Ftemplates-user%2Fmy-unifi.xml&rmTemplate=&csrf_token=9910968FDB4C51A5

 

 

That's the URL that shows a blank screen when I try to add the unifi docker back.  Tried three different browsers on three different computers; two of those browsers were just newly installed, specifically to test the cache theory, and had the same issue.

 

Had renamed docker.img prior, and was able to add my other three items (sab, sonarr, plex) without issue.

 

What else can I try?  Worst case, how do I blow the entire unfi setup out of existence completely and start from scratch?

 

 

that's an address on your lan and as such not gonna work for anyone outside of your lan

and just add a new unifi container from CA as you would any other new container

Link to comment

Yes, I was hoping that something in the URL would jump out at someone and help diagnose the issue.

 

I blew away the /appdata/unifi directory after tar'inig it, and also blasted /boot/config/../../../my-unifi.xml

 

I re-added from CA and untar'd the original /appdata/unifi directory.

 

Now things are moving along, it seems, however everything is stuck at 'adopting'

 

I'll let it sit for a while.

 

Link to comment
7 hours ago, tucansam said:

Nope, stuck at either 'adopting' or 'disconnected' with no resolution.

 

Completely nuked the entire unifi package out of existence, started over.  Fresh install couldn't see any of the hardware.  Nothing to adopt.  

 

Oh well.

Sometimes I wonder if Ubiquiti ever tests their software or if they just let customers do it for them.

 

When I first set up my Ubiquiti gear. I had to put the UniFi docker in host mode to get it to properly see and adopt the USG, switches and APs.  After adopting, I set it back to Bridge mode and all was well for months.  However, one of my switches decided to disconnect a few days ago and nothing I did would allow it to be seen in the controller.  Finally, last night I got it adopted and connected again by doing the following.

 

1 - reset switch to factory defaults

2 - in the Controller, "forget" the disconnected device.

3 - SSH in to the device and run "set-inform [IP address of UniFi controller docker]:8080/inform" 

4 - run the above command 4-5 times in rapid succession (once was not enough)

5 - when device shows again in controller as "adoption pending" go ahead and adopt it

6 - run the set-inform command once more so the inform path is remembered in the adopted device

 

A page back, as pointed out by jedimstr, there are some instructions for using the controller override settings which have worked for some to get out of the adoption/disconnected loop.

 

I hope you resolve your problem.  You can click on the Chat button (the 'talk" bubble) in the lower left of the controller and speak directly with Ubiquiti support.  They pointed out to me that running the set-inform command multiple times is what was needed to get my device to show up again in the controller.  They were helpful.  By now they are probably well versed in all the quirks in the software and how to get around them.

Edited by Hoopster
Link to comment

Is it best to setup this container with using the Host as network to use the IP of the unRAID server itself?

Wouldn't this be the best setup as then you know the IP and can set things up accordingly?

This would also minimize some of these issues people are seeing?

 

Unless im totally wrong here :D

Link to comment
53 minutes ago, apgood said:

I give mine its own static IP address using the docker functionality and then reserve the same IP address in dhcp.

Doing this I have zero issues with device adoption, etc because it is seen on the network on its own IP address.

 

I did that but the result was lots of call traces in the syslog. When I set the docker back to the unRAID host IP, the call traces went away.  This was with unRAID version 6.4.0 and I have not tried it since.  Perhaps this has been resolved although I still see reports of various call traces even in the latest 6.5.1 RC.

Link to comment
16 hours ago, Hoopster said:

Sometimes I wonder if Ubiquiti ever tests their software or if they just let customers do it for them.

 

 

 

I worked for a major DSLAM manufacture for a while, and development teams, in general, aren't nearly as skilled or professional as the general public believe.  Having said that, there are a LOT of smart people working in tech, but between deadlines and completely idiotic product requirements driven by management's general ignorance, and *major* customers' influence, I'm surprised half the products we buy work at all.

 

I finally got it to work.  No idea why or how.  I left it running overnight, and when I work up, all three of my APs were green "connected."  But now Windows tells me I "may have to log in to a web page in order to use this network" on every PC, every time I wake it up from sleep and connect to the network.  Whatever the heck that means.

 

Thanks again for the reply.

Link to comment
16 hours ago, SavellM said:

Is it best to setup this container with using the Host as network to use the IP of the unRAID server itself?

Wouldn't this be the best setup as then you know the IP and can set things up accordingly?

This would also minimize some of these issues people are seeing?

 

Unless im totally wrong here :D

 

 

I completely forgot about this, thanks.  It actually worked, through no fault of my own, and I am presently running in Bridge mode.  I did a few force adopts from the command line of each AP, had virtually zero success, and then hours later, it was all working. 

 

But on my initial install, months ago, before the docker blew up, Host is exactly what I had to use to get it to work.

Link to comment
20 hours ago, Hoopster said:

 

I did that but the result was lots of call traces in the syslog. When I set the docker back to the unRAID host IP, the call traces went away.  This was with unRAID version 6.4.0 and I have not tried it since.  Perhaps this has been resolved although I still see reports of various call traces even in the latest 6.5.1 RC.

 

Can't explain why you have call traces, could be a combination of hardware and linux kernel.

I have set up Unifi on a dedicated interface and dedicated (fixed) IP address, all is working great.

 

Bridge mode can not be used with Unifi because it uses network address translation (NAT) which interferes with the communication between app and clients.

 

Edited by bonienl
Link to comment
8 minutes ago, bonienl said:

 

 

Bridge mode can not be used with Unifi because it uses network address translation (NAT) which interferes with the communication between app and clients.

 

 

That's weird because that's exactly how mine is now, and working.  Plus it had to have been the default, because I blew away any and all traces of unifi and then re-added from the community applications list and reconfigured from scratch.

 

 

Untitled.png

Link to comment
8 minutes ago, tucansam said:

That's weird because that's exactly how mine is now, and working.  Plus it had to have been the default, because I blew away any and all traces of unifi and then re-added from the community applications list and reconfigured from scratch.

Mine too. Just installed a couple of weeks ago. Never used the docker prior to this installation. Seems to be working ok.

Link to comment
2 hours ago, bonienl said:

Dunno, maybe something has changed (for the better). As far as I can recall I had issues with bridge mode, but it has been quite some time ago when I installed Unifi.

 

Same here.  The UniFi docker has been running in Bridge mode since day one (other than when I tried assign it an IP Address and got the call traces).

 

I also installed the 6.5.1 RC2 on the server last night.  Pi-Hole currently has its own IP address and was generating lots of call traces on 6.5.0. So far, the syslog is free of call traces.

Link to comment

I was on unifi controller version 5.7.20 on another PC. I installed the unifi docker for unraid and tried to use the backup file, but stated that the file was for a newer version of unifi and wouldnt be able to use it. What version of the controller is the docker app at? hoping to downgrade the previous controller and re download the backup file.

Link to comment
14 minutes ago, chronicvader said:

I was on unifi controller version 5.7.20 on another PC. I installed the unifi docker for unraid and tried to use the backup file, but stated that the file was for a newer version of unifi and wouldnt be able to use it. What version of the controller is the docker app at? hoping to downgrade the previous controller and re download the backup file.

5.6.36

Link to comment
  • trurl locked this topic
Guest
This topic is now closed to further replies.