R710 AP image for vSZ carrier

  • 1
  • Question
  • Updated 2 years ago
  • Answered
Where to download or get the AP image for R710 to be recognize by vSZ carrier?
Photo of Randy Rosario

Randy Rosario

  • 2 Posts
  • 0 Reply Likes

Posted 4 years ago

  • 1
Photo of Kieran Oakes

Kieran Oakes

  • 2 Posts
  • 0 Reply Likes
You would need to contact Ruckus Support, I had this exact same issue yesterday and they promptly sent me the correct firmware.
Photo of Dionis

Dionis, AlphaDog

  • 80 Posts
  • 48 Reply Likes

The R710 is supported in release version 3.1.1 which can be downloaded from the support website at support.ruckuswireless.com or as mentioned by Kieran, you can contact support and a copy of this image can be sent to you.


Regards,

Photo of Michael Brado

Michael Brado, Official Rep

  • 2844 Posts
  • 397 Reply Likes
And here are helpful instructions to connect a new AP to the vSZ / SZ-100 platform.

https://support.ruckuswireless.com/answers/000004230
Photo of Michael Brado

Michael Brado, Official Rep

  • 2844 Posts
  • 397 Reply Likes
And the base image firmware (will join either ZD or SCG-200/vSZ/SZ-100 platforms, and auto-upgrade firmware from controller),
is version 100.2.0.0.336:

https://support.ruckuswireless.com/software/760-standalone-ap-software-100-2-0-0-336-r710
Photo of Michael Brado

Michael Brado, Official Rep

  • 2844 Posts
  • 397 Reply Likes
That's the version that should come installed on your R710 in fact. 
If you haven't yet connected your R710 to a controller, can you tell me what version you have/had originally Randy?
If you SSH into your AP's IP address, use (super / sp-admin) login credentials,
and run the 'get version' command.
I hope you might find the 'set scg ip a.b.c.d' etc, from the first KBA to be what you need/needed?
Photo of Ali

Ali

  • 29 Posts
  • 0 Reply Likes
This base image won't join the VSZ.  "set scg" command is not even available.
Photo of Randy Rosario

Randy Rosario

  • 2 Posts
  • 0 Reply Likes
Thank you all for the replies.  I already found out that there is an option in GUI to enter the controller IP address instead of doing the conventional way of set scg ip wherein the command is not working anymore on the new FW.
Photo of Martin

Martin, Official Rep

  • 309 Posts
  • 79 Reply Likes
hi Randy,
correct as of the new 100.x.x.x base image we use "set director ""

kind regards
Martin
Photo of Sean

Sean

  • 349 Posts
  • 93 Reply Likes
Also ensure you enable the discovery agent on the AP CLI:
set discovery-agent enable
Note: This is down to sometimes when you flash the AP with the Base 100 image that the discovery agent is disabled and the AP will not join the SCG.

Also you'll want to ensure that the lwapp2scg is enabled on the SCG too or the AP with base 100 image wont join:
configure
lwapp2scg
policy accept-all
exit
Good luck
(Edited)
Photo of Ali

Ali

  • 27 Posts
  • 0 Reply Likes
tried the "set director" command as well but it would not connect to the VSZ
Photo of Michael Brado

Michael Brado, Official Rep

  • 2822 Posts
  • 396 Reply Likes
Ali, what version of firmware is running on the AP?  Have you done a factory default to reset it first maybe?
The Solo AP images (100. x series) should join either ZD or SZ controllers, when directed by DHCP, DNS,
or the "set director ip a.b.c.d" or "set scg ip a.b.c.d" followed by a "reboot". 

Can you ping the vSZ from the LAN your AP is on?  (ie, going thru local switches only, or NAT/router, or VPN, etc)?
Photo of Ali

Ali

  • 27 Posts
  • 0 Reply Likes
"set scg ip" not available as shown below.  "set director" works but it does not join.  I put the zoneflex image 104.x.x on it and got the "set scg" command that allowed me to join the VSZ.
Photo of Dionis

Dionis, AlphaDog

  • 80 Posts
  • 48 Reply Likes
A few things, the 100.x image is a ZD based image. As such, you need to use the set director command to have it join the SmartZone. But you also have to allow ports 21 TCP a d 12223 UDP so that the SmartZone can talk or understand the LWAPP discovery request from the AP and auto upgraded.

The SmartZone 104.x code has both agents in it. The ZD LWAPP agent and the SmartZone agent for SmartZone discovery and joining.

You still may need to allow the lwapp discovery on the controller though, although you shouldn't. In inbound direction to the controller control plane IP you need ports 443, 22, 11443, at least for the AP to create and maintain a connection with the SmartZone. Make sure your firewall matches the port only on inbound and not both source and destination. The returning connection from the SmartZone would assign a dynamic port that will likely differ from 22 for example.
Photo of Ali

Ali

  • 27 Posts
  • 0 Reply Likes
VSZ was in a different subnet but there is no firewall involved, this was a pretty simple and straightforward setup.  Like I mentioned already tried the "set director" command didn't work.  As soon as I changed the image and ran the "set scg" command AP joined the controller.

I'll test it one more time if that helps.
Photo of Dionis

Dionis, AlphaDog

  • 80 Posts
  • 48 Reply Likes
It sounds like the LWAPP2SCG policy is disabled in the controller.

Login to the controller CLI and run the command "show run lwapp2scg"

If the results show the policy as deny all, then you are correct, it would not work. Go in config mode, lwapp2scg and accept all. Then try again, that should do it.
Photo of Ali

Ali

  • 27 Posts
  • 0 Reply Likes
Looks like that is it.  You got it.  It is Deny all.  I will change it and re test it with the stand alone mode image.  Thanks so much for your help.  I will post back the results once I complete testing.
Photo of Dionis

Dionis, AlphaDog

  • 80 Posts
  • 48 Reply Likes
Perfect, sounds good.
Photo of Lisandro Quiñones

Lisandro Quiñones

  • 11 Posts
  • 0 Reply Likes
Hello, I'm trying to connect a new AP R710 (version 100.2.0.0.336) to my vSZ hosted with Google Compute Engine VM. I was able to SSH connect to the AP and entered the following:

set discovery-agent enable
set director ip "vsz external IP with Google"

However, I still can't see the AP on my vSZ (version 3.2.0.0.790), please help.

Thank you.
Photo of Dionis

Dionis, AlphaDog

  • 80 Posts
  • 48 Reply Likes

Lisandro,

Ensure that if the vSZ is behind a firewall, you have opened up ports 11443, 11223, 22, 443, 91, 21 at least.

Thanks,

Photo of Lisandro Quiñones

Lisandro Quiñones

  • 11 Posts
  • 0 Reply Likes
Thank you Dionis, which protocol ports, TCP?
Photo of Dionis

Dionis, AlphaDog

  • 80 Posts
  • 48 Reply Likes
TCP for all, but 12223 which is UDP. 
Photo of Lisandro Quiñones

Lisandro Quiñones

  • 11 Posts
  • 0 Reply Likes
telnet 443 is not connecting, but I do have it opened in the firewall:



What am I missing?
Photo of Dionis

Dionis, AlphaDog

  • 80 Posts
  • 48 Reply Likes
443 is HTTPS, it may not connect. Make sure you don't have conflicting rules on that port.
Photo of Lisandro Quiñones

Lisandro Quiñones

  • 11 Posts
  • 0 Reply Likes
Done as instructed, but still no luck, how do I make sure I don't have any conflicts on the 443? The telnet on 443 is not connecting.

Photo of Dionis

Dionis, AlphaDog

  • 80 Posts
  • 48 Reply Likes
You could do a tcp trace and find out if any of those ports is being blocked somewhere..
Photo of Sean

Sean

  • 349 Posts
  • 93 Reply Likes
check in the logs of the AP:
get syslog log
if you see the following:
Jul 27 14:50:19 Ruckus AP daemon.info hub_registrar: OCSP: 'unknown' on ap-registrar.ruckuswireless.com - withhold query
Then the AP is calling to the Ruckus cloud.

To fix you need flash the AP with Base 104 code, factory reset and then issue:
set scg ip X.X.X.X
set discovery-agent enable
Good luck
Photo of Michael Brado

Michael Brado, Official Rep

  • 2793 Posts
  • 393 Reply Likes
Hello,

All Unleashed and Solo/Standalone AP code APs will check with the Ruckus AP Registrar (APR)
in the Cloud, upon boot up, to see if the AP has been assigned a controller, either by the Cloud WiFi
customers, or large MSPs who use an API to register/assign controllers to many APs at a time.

Searching our bug database, I find only one, ZF-8498: ZD 9.7.1.0.29 [cloud discovery] OCSP will
hold activity if AP can't reach the registrar server (resolved in 9.8 GA).  The bug said an AP reboot
would resolve the issue (if the AP had Internet access).
----

AP’s log:


May 23 18:33:11 RuckusAP daemon.info hub_registrar: OCSP: 'unknown' on ap-registrar.ruckuswireless.com - hold activity 

As RD said it will hold activity for one day. Now not sure after one day if the OCSP will be activity or not.

Workaround: reboot the AP.

Verified in build 9.7.1.0.30, it is fixed.The AP will send out query every 5 minutes in one hour when the AP can reach the server.

May 30 03:09:25 7055 daemon.info hub_registrar: OCSP: 'unknown' on ap-registrar.ruckuswireless.com - withhold query                 
cat: can't open '/tmp/ocsp-check': No such file or directory                                                                        
May 30 03:15:17 7055 daemon.info hub_registrar: OCSP: 'unknown' on ap-registrar.ruckuswireless.com - withhold query
----

I do like your two 'set' commands, which should be enabled by default however, if running 104 Solo AP code...
Photo of Sean

Sean

  • 349 Posts
  • 93 Reply Likes
There are certain AP's we have received that have this issue: R310, R510 etc.

There are other issues where you have to enable or disable the lwapp2scg command on the SZ dependant on which AP model you are trying to get to be accepted on to the network - as you can imagine it gets pretty frustrating having to do the workarounds of flashing the AP to remove corrupt code or altering  the lwapp2scg command on the SZ.
Photo of Dionis

Dionis, AlphaDog

  • 80 Posts
  • 48 Reply Likes
Sean, I have successfully deployed, every single AP model currently supported with Ruckus (Indoor models) successfully on a SmartZone running 3.4.1 and .2 and 3.5.1 without the need to do anything other than enabling lwap2scg scripts.  This is true for both, 100.x and 104.x code as well as 9.8 and newer and 3.x code.  

Only when using the 200.x (Unleashed) code, do I have to upgrade the AP to 104 or similar.  All others work automatically without a single failure yet.   
Photo of Sean

Sean

  • 349 Posts
  • 93 Reply Likes
So your not affected by this bug:

The R310 has the opposite requirement

We have approx 30,000 AP's in our estate, and ovbviously due to these numbers, we are bound to come across some errors every now and again.

The only reason I mentioned the above bug as certain AP's are having this issue in the RX10 range, so it may be applicable to the R710.

:)
Photo of Dionis

Dionis, AlphaDog

  • 80 Posts
  • 48 Reply Likes
No, im actually not affected. But i may also be running a different version of the 104.x code. At the moment im not home to test due to the storm, but when i get back will test.
Photo of Michael Brado

Michael Brado, Official Rep

  • 2793 Posts
  • 393 Reply Likes
Above issue ONLY affected H510 model APs on initial 104.0.0.0.1306 (H510 only) firmware. 
The 104.0.0.0.1347 (GA) release of Solo/Standalone for all AP models has the fix incorporated.
Photo of Sean

Sean

  • 349 Posts
  • 93 Reply Likes
This above statement is incorrect as we have seen the issue on certain AP's that came from a certain batch from production.

I cannot remember the serial numbers, but we have this confirmed by Ruckus themselves.

The main issue was that it was not calling out to the IP address configured when you issued the set scg ip command and it was stalling at the Ruckus cloud element.

The fix was as per my orginal statement.

:)