topic Re: ZD 1100 not recognizing/provisioning AP 7363 or any AP in To Be Moved

ZD 1100 not recognizing/provisioning AP 7363 or any AP

bore_clement — Tue, 15 Apr 2014 10:22:15 GMT

Hi,
i have just put a ZD1100 online, and trying to connect some 7363 with no luck : in any case, it says that the AP is accepted, but afterwards either it says "upgrade failed" or it does nothing at all, waiting for 10 to 100 minutes... we did try one of the 7363 on another working ZD1100, it worked flawlessly upgrade and configuration.

I tried upgrading firware, then downgrading, factory reset... still same issue; updates on the ZD went smooth though, no trouble switching from a version to another.

With the "stock" firmware or with the latest, nothing to do : AP's get an IP for a DHCP server on the lan, the are displayed on the ZD, but nothing else...

I saw a SSH command to add controler IP to an AP, but didn't worked out.

Any idea how to resolve this one?

I have to say i though Ruckus ZD's were fault free... :p

Regards

Re: ZD 1100 not recognizing/provisioning AP 7363 or any AP

keith_redfield — Tue, 15 Apr 2014 16:13:01 GMT

Have you tried directly connecting the 7363 to the ZD? If not, can you describe how they are connected? (intervening devices and configuration). And are you using *any* vlans?

Re: ZD 1100 not recognizing/provisioning AP 7363 or any AP

bore_clement — Tue, 15 Apr 2014 16:42:37 GMT

Thanks for trying to help

Yes i did try that, and even mutliple switches, cables, ac adapters... In fact, i found out the troublemaker was the DHCP server ; i don't really know why, it gave correct ip infos, but was messing with the AP's.

The DHCP was provided by a Wifi gateway (called UCOPIA) , providing advanced captive portal, logging and interface with specific software ; as soon as we managed to get this dhcp server/gateway updated, it worked flawlessly.

So, the ruckus hardware is neat! And support is really good too, quick and efficient.

Thanks a ton

Regards,

Re: ZD 1100 not recognizing/provisioning AP 7363 or any AP

keith_redfield — Tue, 15 Apr 2014 17:23:44 GMT

Awesome! Thx for providing the resolution - I hate mysteries 🙂

Re: ZD 1100 not recognizing/provisioning AP 7363 or any AP

joakim_wasseng_ — Wed, 13 May 2015 08:04:32 GMT

Had the same problem as described in the heading (though not exactlly the same as PARIS INN)

After a power outage in one of my sites all my AP 7363 were stuck in provisioning after they regained power. I could log on to the AP:s directlly, but rebooting them did nothing, still stuck in provisioning. I resolved this issue by lowering the "Tunnel MTU"-value (Configure / Access Points) from default 1500 to 1400. All AP:s then got connected within 5 min. This having to do with package sizes getting to large and not fragmenting as they should.

Thought someone reading this post might find this info usefull 🙂

Re: ZD 1100 not recognizing/provisioning AP 7363 or any AP

michael_brado — Mon, 18 May 2015 18:04:06 GMT

Your tip is helpful for any remote APs connected over VPNs too. Often the encapsulation over these tunnels cause to much fragmentation,
especially if provisioning many WLANs, so reducing the MTU between ZD/APs from our side can sometimes help.

Re: ZD 1100 not recognizing/provisioning AP 7363 or any AP

jordon_lakoduk — Fri, 21 Jun 2019 02:46:07 GMT

This was the actual fix that just resolved the same issue I was having upgrading from 9.13.x to 10.1.1.0 build 55. All of the local APs grabbed their new configuration right away but the 20+ remote APs were all stuck in "provisioning" or "Disconnected". Went into Access Points (left tab) > Access Point Policies (tab within page) > Tunnel MTU and set to 1400 (acceptable range is: 850 ~ 1500). As soon as I applied that, all of the R500 APs which are remote (located across VPNs) were up and connected to the Zone Director within 5 minutes as Joakim mentioned above.

Not sure why this wouldn't be included in the Official Upgrade Guide. Many enterprises have their Access Points upgraded over VPN tunnels. Had to search high and low to find this suggestion. Thanks again.