Appears to be stable so far with replacement HG659

Hmmm it appears the issues are now recurring. I'm going to try reconfiguring the Unifi network in case there's an issue there, but this is getting rather puzzling - the issue still disappears when the second UAP is disconnected!

Really hoping for some ideas on this one! 

I've reconfigured the Unifi setup from scratch, there has been a new printer installed since the issue started (scheduled replacement of old leased printer). I've replaced both the problem UAP and the Spark HG659b.

Whenever the second UAP-AC-Lite is connected, the printer won't scan to email. The connection is also unreliable in the area with the second UAP.

There are no IP conflicts, no significant WiFi interference, the printer is on a wired connection and can print just fine. I'm stumped! I've never had a UAP that was unreliable, and I've never encountered another issue like this one...

My only real conclusion is that the next step is to replace the H659b with something else (Draytek Vigor 2133 or similar for Spark Fiber).

Sounds to me like the devices connect to the 2nd AP and then lose the route to the gateway.

• Can you connect to both AP's via SSH and stay connected at all times?
• From a wired PC, is the ping response the same & steady for both AP's?
• Can you ping the printer from both AP's continuously, even through a perceived outage of the phones not having internet access?
• Got any 24/7 monitoring ala PingPlotter or LibreNMS that will show repeat failure patterns?
• Have you considered somebody sanity checking your Unifi config?

I note with intrerest you have adopted both UAPs to your laptop. Does this mean the UAP doesn't have a 24/7 connection to the controller (as I assume you take your laptop off-site)? I would have thought for roaming etc to work correctly the controller has to be able to manage the UAPs at all times. But can't see how that would affect the copier.

Is it possible to reset things on the copier? It might have a bad DHCP lease that's holding on to an conflicting IP address.

KiwiSurfer:

 

I note with intrerest you have adopted both UAPs to your laptop. Does this mean the UAP doesn't have a 24/7 connection to the controller (as I assume you take your laptop off-site)? I would have thought for roaming etc to work correctly the controller has to be able to manage the UAPs at all times. But can't see how that would affect the copier.

 

Is it possible to reset things on the copier? It might have a bad DHCP lease that's holding on to an conflicting IP address.

 

Controller is only really needed to configure, but best practices definitely says it should stay online 24/7. Most cases a controller not being contactable will be when using guest networks with captive portals or tokens though, and I highly doubt this is the case here.

KiwiSurfer:

 

I note with intrerest you have adopted both UAPs to your laptop. Does this mean the UAP doesn't have a 24/7 connection to the controller (as I assume you take your laptop off-site)? I would have thought for roaming etc to work correctly the controller has to be able to manage the UAPs at all times. But can't see how that would affect the copier.

 

Ubiquiti's incorrect use of the term "controller" is what confused you.  Ubiquiti access points are autonomous (i.e. there is no control plane).  Autonomous access points were the ones we were playing with in the late 1990s.  Airespace created the first wireless LAN controller (and the Lightweight Access Point Protocol initially used to control access points) to resolve all the issues with autonomous access points - poor roaming, poor RF management, etc (as you correctly noted in your post).  Ubiqiuiti's "software controller" is just a small management server for the autonomous access points and, as stated in an earlier post, is not required to be accessible by the Ubiquiti access points as there is no control plane from the access points to the "software controller" to maintain.

This is why enterprise wireless deployments never involve Ubiquiti.  Enterprise wireless deployments always require a control plane whether centralised (Aruba, Cisco, etc.) or distributed (Aerohive, Extreme, etc.).  

Crowdie:

 

This is why enterprise wireless deployments never involve Ubiquiti.  Enterprise wireless deployments always require a control plane whether centralised (Aruba, Cisco, etc.) or distributed (Aerohive, Extreme, etc.).  

 

Have to say I disagree with that - unless you really want to redefine what "enterprise" means. I can name several examples of large scale (one with several hundred sites across NZ supporting thousand of users) in NZ that are now UBNT based with UniFi wireless and switching.

sbiddle:

 

Crowdie:

 

This is why enterprise wireless deployments never involve Ubiquiti.  Enterprise wireless deployments always require a control plane whether centralised (Aruba, Cisco, etc.) or distributed (Aerohive, Extreme, etc.).  

 

 

Have to say I disagree with that - unless you really want to redefine what "enterprise" means. I can name several examples of large scale (one with several hundred sites across NZ supporting thousand of users) in NZ that are now UBNT based with UniFi wireless and switching.

 

Ubiquiti are not included in the Gartner Enterprise Wireless reports, for example, as they are not enterprise grade.  SOHO and SME yes.  Enterprise no.

Our largest companies wouldn't even consider Ubiquiti as it can't meet their basic requirements.  For example (this was recently listed as a requirement by an enterprise customer) can Ubiquiti provide:

• Real time monitoring of Skype for Business audio calls with automatic issue resolution.
• All Skype for Business audio calls with a MOS score below the agreed level to be shown in real time on floor plans with the cause of the low MOS score displayed.
• The ability to "follow" a specific wireless client on a floor plan showing the recorded MOS score of the Skype for Business audio call at that location.  You should be able to pause/fast forward/rewind the wireless client through its traveled path as required for fault finding.

Enterprise customers have moved beyond basic "coverage requirements" deployments.  They automatically expect the signal strength and coverage will be appropriate just like somebody talking to an architect automatically expects their new house will have walls and a roof.