[Support] Linuxserver.io - Unifi

[CHBMB]

Just now, jedimstr said:

Well ok then... but did you even look at the setting I pointed out.  Because that's there specifically for the issue you mentioned.  Resetting won't do squat for this.  You have to let the devices know about the host's IP for containerized controllers or you'll just keep sending the internal IP... which causes the Adopt/Disconnect loop.

 

Yes I did.  And I even tried a brand new pull of the container with fresh appdata and ssh'd in and used set-inform to tell the AP where the controller is, several times.  I understand what you're saying, I really do, after all who do you think tests half these containers before we push them public?  I'm not a newb by any stretch of the imagination.  Honest....

 

[jedimstr]

Just now, CHBMB said:

 

Yes I did.  And I even tried a brand new pull of the container with fresh appdata and ssh'd in and used set-inform to tell the AP where the controller is, several times.  I understand what you're saying, I really do, after all who do you think tests half these containers before we push them public?  I'm not a newb by any stretch of the imagination.  Honest....

 

 

I hear you and understand... but with comments like "don't want to walk people through it"... keep in mind many of us here aren't newbs either... very very far from it.

[sparklyballs]

3 minutes ago, CHBMB said:

 

I am familiar with the software and did indeed try several things to fix it before downgrading.  including set-inform, changing firmware and unifi software versions, hardware resets, more set-inform and further hardware resets.  Only thing that fixed it after 3 days of messing around was a downgrade.  I'm pretty damn certain that after my APs have been working flawlessly for a couple of years, and the only thing that changed was 5.7.20 that even resetting the AP and trying from fresh couldn't fix, that 5.7.20 was the cause.

 

 

i was also stuck on the never ending adopting loop as well as my wifi going down and the only way i could get my wifi back up and running was restoring old appdata from the earlier version and factory resetting my AP

 

ssh'ing in to the AP and trying to run any commands (even the set inform) resulted in it telling me the inform command was running and the unit was busy 

[jedimstr]

So for those of us with larger multiple deployments of UniFi gear using this container... if we were to successfully deploy the unstable branch (knowing the risk, or lack there of if you know how to export UniFi Controller Configurations and Import them into brand spanking new container images regardless of version... note, there's no need to worry about appdata in this case unless you have custom JSON overrides), what sort of logs/info/docs would you need to help you figure out any issues with the release?  I'm sure many of us would like to help.

[CHBMB]

1 minute ago, jedimstr said:

 

I hear you and understand... but with comments like "don't want to walk people through it"... keep in mind many of us here aren't newbs either... very very far from it.

 

I know that, but if you were us and had to support this, you'd want to make it VERY clear to people where they stand.  Unifi has always been a complete PITA from the get go, with requests to update the container the second a new version hits, so to satisfy those people we made an unsupported unstable branch, we talked about it internally and decided to do so on the grounds it was unsupported.  I make no assumptions when someone asks about this branch about their level of knowledge, but it's only fair to warn them.

 

FWIW I think I may well have been the first person to pull the unstable branch, and if it wasn't me it was sparklyballs.  We both had issues, we both had to downgrade.  He wrote the container.......

[sparklyballs]

2 minutes ago, jedimstr said:

So for those of us with larger multiple deployments of UniFi gear using this container... if we were to successfully deploy the unstable branch (knowing the risk, or lack there of if you know how to export UniFi Controller Configurations and Import them into brand spanking new container images regardless of version... note, there's no need to worry about appdata in this case unless you have custom JSON overrides), what sort of logs/info/docs would you need to help you figure out any issues with the release?  I'm sure many of us would like to help.

 

you're confusing us with ubiquitti  we just package the app in a docker image and any issues are upstream of us and certainly not confined to our image

 

and @CHBMB i was the first to update to 5.7

[CHBMB]

1 minute ago, jedimstr said:

So for those of us with larger multiple deployments of UniFi gear using this container... if we were to successfully deploy the unstable branch (knowing the risk, or lack there of if you know how to export UniFi Controller Configurations and Import them into brand spanking new container images regardless of version... note, there's no need to worry about appdata in this case unless you have custom JSON overrides), what sort of logs/info/docs would you need to help you figure out any issues with the release?  I'm sure many of us would like to help.

 

The issue with the software is upstream, nothing changes in the underlying dockerfile and associated code.  Help Unifi, tell them.  

 

The only change in the container between unstable and stable is this line afaik

[CHBMB]

2 minutes ago, sparklyballs said:

and @CHBMB i was the first to update to 5.7

 

I knew it was either you or me, I know you pushed the branch and I know you updated to 5.7.20 as well, but you're normally pretty reserved about upgrading stuff, so I thought I may have beat you to it.

 

Edited March 25, 2018 by CHBMB

[jedimstr]

2 minutes ago, sparklyballs said:

 

you're confusing us with ubiquitti  we just package the app in a docker image and any issues are upstream of us and certainly not confined to our image

 

and @CHBMB i was the first to update to 5.7

 

Nope, not confusing anything... if some of us have cloudkey's, direct installs, and other such installation methods for the controller working on 5.7.20, then something has to be up with how it's interacting with a containerized environment.  Whether that's up to people on this end of the issue or the other end of the issue to find and resolve, ¯\_(ツ)_/¯

 

If it's at an impasse, and it continues to work outside the container, but it continues to break inside the containers you package, and Ubiquiti doesn't do anything about it, then we all lose I guess.

[sparklyballs]

Just now, jedimstr said:

 

Nope, not confusing anything... if some of us have cloudkey's, direct installs, and other such installation methods for the controller working on 5.7.20, then something has to be up with how it's interacting with a containerized environment.  Whether that's up to people on this end of the issue or the other end of the issue to find and resolve, ¯\_(ツ)_/¯

 

If it's at an impasse, and it continues to work outside the container, but it continues to break inside the containers you package, and Ubiquiti doesn't do anything about it, then we all lose I guess.

 

it's not isolated to our container as i've already said 

 

i'm not searching through their forums again for it but there was a lengthy thread with people having the same issue that weren't using a docker image

[CHBMB]

1 minute ago, jedimstr said:

 

Nope, not confusing anything... if some of us have cloudkey's, direct installs, and other such installation methods for the controller working on 5.7.20, then something has to be up with how it's interacting with a containerized environment.  Whether that's up to people on this end of the issue or the other end of the issue to find and resolve, ¯\_(ツ)_/¯

 

If it's at an impasse, and it continues to work outside the container, but it continues to break inside the containers you package, and Ubiquiti doesn't do anything about it, then we all lose I guess.

 

The assumption you've made there though is that the ONLY people who have had problems have been using a container or as you stated earlier PEBKAC errors on Reddit.  

[jedimstr]

Also, just to re-iterate... I had the exact same issue with the neverending adopt/disconnected cycle, but mine happened when I upgraded the container awhile ago to 5.6.30 and whatever the previous version was.  Solution for me was as I mentioned above (not just set-inform/reset hardware, etc).

[jedimstr]

Just now, CHBMB said:

 

The assumption you've made there though is that the ONLY people who have had problems have been using a container or as you stated earlier PEBKAC errors on Reddit.  

 

Well, I did mention I "may be blind" but I didn't see the threads talking about this specific to 5.7.20.  The Adopt/disconnect issue threads actually go way before the beta versions of this release.

[sparklyballs]

Just now, jedimstr said:

Also, just to re-iterate... I had the exact same issue with the neverending adopt/disconnected cycle, but mine happened when I upgraded the container awhile ago to 5.6.30 and whatever the previous version was.  Solution for me was as I mentioned above (not just set-inform/reset hardware, etc).

 

 

this is the last time i'm going to say it in case the message isn't registering 

 

 

none of that solved the issue and the ONLY way was to factory reset the AP and restore my previous appdata

[sparklyballs]

5 minutes ago, jedimstr said:

Also, just to re-iterate... I had the exact same issue with the neverending adopt/disconnected cycle, but mine happened when I upgraded the container awhile ago to 5.6.30 and whatever the previous version was.  Solution for me was as I mentioned above (not just set-inform/reset hardware, etc).

 

 

if i eat bacon one time and it makes me sick 

the next time i get sick it doesn't necessarily mean i had bacon for dinner 

[CHBMB]

This was the thread.

 

https://community.ubnt.com/t5/UniFi-Wireless/issues-with-5-7-20/td-p/2280208

 

 

[CHBMB]

6 minutes ago, jedimstr said:

Also, just to re-iterate... I had the exact same issue with the neverending adopt/disconnected cycle, but mine happened when I upgraded the container awhile ago to 5.6.30 and whatever the previous version was.  Solution for me was as I mentioned above (not just set-inform/reset hardware, etc).

 

Exact same issue doesn't necessarily equal the exact same cause.   It may do, but it may not.  And whilst I understand the limitations of docker bridge networking in affecting the issue, I don't follow how a factory reset and then using SSH to tell the access point where the controller is (as in it's IP address) shouldn't work.....

[jedimstr]

18 minutes ago, CHBMB said:

This was the thread.

 

https://community.ubnt.com/t5/UniFi-Wireless/issues-with-5-7-20/td-p/2280208

 

 

 

Thanks for that... that's kinda what I asked for earlier regarding where the issues were mentioned....

 

With that in mind, the UniFi Wireless thread's TLDR:

 

1. most of the issues mentioned have to do with Wireless Uplink mode which is the pseudo-Mesh mode AP's have when disconnected from ethernet.  Not one of the issues mentioned so far in the thread here or by the both of you.

2. the only mentions of adopt/disconnect issues in that thread mentioned an issue with AP's holding on to controller IPs for a container versus a cloudkey when going back and forth with bold text saying to "Ignore this Error Report".  Not involved with the issues that you two or I have experienced regarding adopt/disconnect issues.

 

And I agree with both of you that my issues in the past though similar may not be the exact same issues you had with the 5.7.20, but I only offered up there as an example that the issue symptoms aren't necessarily tied to a release, but could be indicative of a similar situation with Container/IP retention.

 

But suffice it to say, I really don't mean to piss both of you off and all the work you guys do is extremely appreciated... but maybe a sample size of two versus what's been offered as potential more real world deployments could potentially help. But if you don't really want any logs or variations of setups from us on the unstable branch, that's your prerogative.

Edited March 25, 2018 by jedimstr

[jedimstr]

12 minutes ago, CHBMB said:

 

Exact same issue doesn't necessarily equal the exact same cause.   It may do, but it may not.  And whilst I understand the limitations of docker bridge networking in affecting the issue, I don't follow how a factory reset and then using SSH to tell the access point where the controller is (as in it's IP address) shouldn't work.....

 

Just to throw in a bit more info here... the newer controller software for some stupid reason can reset the set-inform if it thinks it knows the "correct IP".  It's more aggressive than previous versions in doing this when Provisioning.  That's why set-inform at the AP or Switch may not stick after awhile.  Controller thinks its smarter than the devices.  Also the reason for the override setting mentioned earlier.  

Edited March 25, 2018 by jedimstr

[CHBMB]

8 minutes ago, jedimstr said:

But if you don't really want any logs or variations of setups from us on the unstable branch, that's your prerogative.

 

If you decide to upgrade and genuinely think you've found an issue that is with the container, by all means lodge an issue on github with the relevant information.   But I think what we're trying to say is we're confident the issues we've experienced are neither due to PEBCAK errors or problems with the container itself, and we're satisfied that the root cause was the Unifi software.  

 

And running bleeding edge Unifi software is fine for some, notably those that can get themselves out of a mess if they need to, but we're absolving ourselves of any responsibility with this, which I'm sure you'll agree is an understandable standpoint as many many users on here and on other platforms are not as tech savvy as you and I.

 

We're all volunteers with lives, families and jobs to do, so helping Unifi support and debug their beta releases isn't something we feel we want to do with our spare time.

 

If you wish to take the mantle of helping anyone with the beta Unifi software here, then be our guest.

 

Edited March 25, 2018 by CHBMB

[CHBMB]

6 minutes ago, jedimstr said:

 

Just to throw in a bit more info here... the newer controller software for some stupid reason can reset the set-inform if it thinks it knows the "correct IP".  It's more aggressive than previous versions in doing this when Provisioning.  That's why set-inform at the AP or Switch may not stick after awhile.  Controller thinks its smarter than the devices.  Also the reason for the override setting mentioned earlier.  

 

I have override activated though.  Still doesn't explain my issue as far as I can see.

[blurb2m]

I know this might not be the specific issue you guys are discussing, but maybe it will be helpful for someone since you mention the override.

My Provisioning/Adopting/Disconnected Loop was fixed with the override in controller settings within UniFi 5.6.30 (older version than 5.7 you guys are discussing). Since checking the Override inform host with controller hostname/IP to my unRAID server IP I have not had any more loops.

 

[anethema]

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.

[JonathanM]

4 hours ago, jedimstr said:

 

 

I've had this with all my AP's, two Switches and USGPro on the current 5.6.30 release, and the previous release update.  I didn't fix it by downgrading though.  I SSH'd to the individual devices and had to force the set-inform to my controller's specific URL (ssh to the device and type "help" for instructions on how to do manually set-inform).  This is actually a common problem with containerized versions of the controller software if you have it bridged because the internal IP of the controller is different than what the devices will see.  

 

The longterm fix to this was provided by Ubiquiti in 5.6.30 under the Controller settings, but for some stupid reason isn't enabled by default.

Check the checkbox in this screengrab in your controller settings and set the domain name or external host IP for your unraid server if you don't have one dedicated to the docker container.  This is most definitely not a 5.7.20 issue, you just happened to encounter it with the 5.7.20 release.

 

How do you set a custom inform host port? That field won't accept X.X.X.X:XXXX syntax, it only will take the IP part. When I manually set-inform on the device, I have to enter the IP:PORT for it to work.

[jedimstr]

1 hour ago, jonathanm said:

How do you set a custom inform host port? That field won't accept X.X.X.X:XXXX syntax, it only will take the IP part. When I manually set-inform on the device, I have to enter the IP:PORT for it to work.

 

If you need a non-standard port for set-inform, you'll have to do it per device by SSH'ing in. If the IP set matches what the override at the controller level has, it shouldn't replace what is set on the device even if you use different ports.