Maybe thats why the Ruckus website is absent of any mentioning the security flaw - probably not posting anything until they have a fix. Pretty damn late to the party if you ask me.

Maybe switching our campus wifi infrastructure to Ruckus was a BAD idea last year. Fortunately I only started with a few buildings. If they don't put out a patch ASAP, it's good riddance Ruckus and Hello Aruba or someone else.

Chatted with a rep who said there will be a "response" by the end of the day.

I, too, don't understand how you can have 2.5 months to come up with something and "wait til the end of the day" is what they came up with.

You KNOW there is a MAJOR issue. You KNOW your customers and competitors will be looking at your response. You know exactly WHEN the announcement will be made. And yet, you have NOTHING available.

"At Ruckus Support, we value Security above all else. The WPA2 vulnerabilities were just released to the public, but Ruckus engineers have had this information for much longer and have been working tirelessly to address, correct, and test patches for all of our systems. We will have these available very soon. Thank you for your patience, we want to make sure we get this one right."

DearPlease help with a firmware update for the ZF7363 and ZF7321 models for this new vulnerability found in WPA-2. Is there any way to contact them or all those who are registered will we get an email automatically when they have the update to know that is already available?

DearPlease help with a firmware update for the ZF7363 and ZF7321 models for this new vulnerability found in WPA-2. Is there any way to contact them or all those who are registered will we get an email automatically when they have the update to know that is already available?

The issue is related to 802.11r (fast bss-transition) to enhance roaming, which if disabled on WLANs eliminates vulnerability to attack of AP-to-client traffic. The krackattacks.com site describe it as:
“it works by exploiting a four-way handshake that's used to establish a key for encrypting traffic. During the third step, the key can be resent multiple times. When it's resent in certain ways, a cryptographic nonce can be reused in a way that completely undermines the encryption.”

This is a Client vulnerability issue. A man-in-the-middle with AP sending your SSID and using your APMAC address. If one of your clients joins this malicious AP, there is a hole in the client that allows theclient to connect even if the passphrase is not correct(!).

After this happens this, and only this single client, can be sniffed.

Our product is designed to alert Admins if such a rogue AP is present. Only AP manufacturers who use theirAPs as RAPs in Mesh (ie connecting to Guest WLAN) are vulnerable (as Aruba stated).

Things to think about:1) all current certs and Wi-Fi passwords are still secure (attacker doesn't get the pw)2) AES does not allow for code injection (tkip does, don't use it).3) Android 6 has more issues that might make this attack easier.4) Disabling 802.11r will mitigate the attack5) Patching either side (client or distribution system) stops the attack from happening on WLAN6) MITM attacks can happen if attacker inserts a new cert, end user is prompted with cert error.7) Do not move to WEP

Still waiting for a corporate Security message I can post to Support and will share here. Thanks.

This is welcome but where are the patches to eliminate the AP side vuln, at big dog paris we were promised a much more responsive Ruckus when it comes to software updates. The fact that the likes of Mikrotik and Ubiquiti have fixes out already is not showing Ruckus in a good light. The other big players in our field have patches as well as an official response out already. The ball has been dropped. Is someone going to pick it up and save the match?

Given the information above, it does not constitute waiting 6 of your PDT working hours (2PM PDT) to produce what was given. There isn't enough clarification given to soundly say simply disabling 802.11r on a Ruckus products will fix the issue either - this was not the full scope of the vulnerability. At this point in the day I am worried about the dismissive tone and action to the issue. I hope the formal security message doesn't ring this way as well.

Put simply, most other vendors have a fix or at the very least a statement as of hours ago on this. Regardless of how critical other vendors thought this would be they have addressed their end. I don't resonate with updating our endpoints instead, turning off the 802.11r feature on our devices, or anything other than fixing the vulnerability through firmware. You should have already deployed your new firmware/patches and put your obligation to rest. It's concerning this is not remotely the case.

Has anyone thought about the possibility that they might not have been notified until today? Has anyone seen evidence that RW was notified 2 months ago? This whole thread seems to expect that given 8 hours notice a company can analyze a vulnerability, patch code, do complete regression testing, and release patches.

They are a major player in the wireless market. They've said all major players were notified a couple of months ago. I can't see any possibility where someone forgot a company in the top 5, based on market share.

And even if they work, there should be at LEAST one security nerd there who would have seen the initial announcement and started salivating at figuring out what the root of the vulnerability was. As has been noted, some vendors even broke "embargo" and fixed this more than a month ago (OpenBSD was scolded, Mikrotik apparently was not). If Ruckus doesn't have one of "those guys", god help us.

Here's what the message to management should be, and it should STING:

Ubiquitihad a fix before you

Ubiquiti sent an email blast to customers before you informing them of the vulnerability and the fix

Mikrotik had a fix before you - yes, the Latvians beat you too

Both companies called out above are seen as barely beyond consumer grade stuff in some circles (and in some Ruckus sales pitches)

All the enterprise vendors had a fix out before you (but Ubiquiti is the one that should embarrass you)

Many of your customers read about this elsewhere and are aware that you had the information about this problem in-hand back in August

I don't mean to pile-on, now that there is an official response, but...

This advisory is full of grammatical errors, contradictions, and the very first line expresses doubt this is even a problem. Waiting all this time to come out with this just furthers the idea that there was no plan and someone started slapping this response together at 8am this morning.

Thanks for the comments David. Please note this is a Cloudpath response and Cloudpath is not involved in the 4 way WPA2 handshake. Please do look out for a more comprehensive update that will cover Access Points and Controllers soon.

Michael, maybe you can clear up some confusion for me on this. In the bulletin above, Ruckus is saying: "No Ruckus products are affected unless deployed in Mesh or Point-to-Point topologies, or
802.11r is enabled."

However, a blog post, also from Ruckus, says the following:

Vulnerabilities exist on both sides of the 4-way handshake relationship (client and AP) and both sides need to be patched.

Until client vendors provide updates, disabling 802.11r can help mitigate the attack by eliminating one source of vulnerability (Fast BSS Transitions, otherwise known as 802.11r roaming).

Does turning off 802.11r mitigate the issue, or does it eliminate the issue? Semantics, but extremely important semantics.

If vulnerabilities exist on both sides of the 4-way handshake, and vendors need to patch them to make them secure (and Ruckus uses WPA)... ??? The blog post and the official statement appear to be contradicting each other. I'd prefer NOT to go back and tell my bosses that I was wrong with what I told them last night.

Ruckus, where are the firmware updates?! This is a pathetic response.
Almost every other manufacturer has firmware fixes available and you don’t. Even Netgear does for their consumer routers!
It is beyond belief that you clearly did not take this seriously, and STILL don’t it would seem.
Time to dump Ruckus. This is not an enterprise product, and certainly not enterprise level support.

This is my first touch with Ruckus. A month ago, I inherited a position in a company where the wireless network is done with 6x Ruckus R500 Wireless APs. Yesterday I contacted Ruckus support and they promised firmware by the end of the day. I have to say, that first impression I got from Ruckus is not an enterprise class and will probably move to ubiquiti.

Just to be clear here, any Ruckus update will not secure your network. It will fix KRACK vulnerabilities with regards to mesh and the use of 802.11r. There are much broader steps that are required to ensure your networks are secure like updating all clients to ensure they have had their respective KRACK patches applied, after all the majority of the vulnerabilities are client based. You should also look at implementing an WIDS/WIPS system (be it the embedded solution of a controller or standalone) to alert against malicious rougue AP's as this will be a tell tale sign of a potential attack using KRACK.

I think you're being a little harsh here. Yes they were late to the party with regards to an announcement vs many of the other enterprise vendors. However, they are not the only ones who are yet to release patch firmware. Cisco for example has currently only one level of controller firmware with a fix for all AP types, 8.3.130.0. All others show as TBD. If i have something in the next day or so then i will be satisfied (not happy) about the response time on firmware but i still find the delay on an announcement, especially when it didn't include a date/time for firmware release to be unacceptable.

Yesterday I opened a support case about poor wifi performance after upgrading to the latest firmware. A tech promised to call me today at 3pm. Well, no call at 3pm, 4pm or 5pm. Replied to email I got ([email protected]) and guess what? Got out of office reply! I'm speechless.

Sorry Kari, bad TSE! Don't make promises you can't keep, but if something did come up today, out of office should direct all current customers to please contact us and ask to be re-queued to TSEs currently on shift to take over!

Ruckus was informed many weeks/months ago about this issue and the disclosure date.

But the customers was left alone!!

I was informed since two day's (CET timezone) about this issue. I waited forthe public disclosure yesterday and opened a case at ruckus cause no information about it was found online.

All other major vendors did have the updates ready and informed their customersat the same time the issue was going public. They had their communication readyand send it out to their partners and customers at the right time.

Ruckus didn't they don't even inform the partners!!

What I as customer with contract and as partner has expected:

1. No out of office notification if someone mails to your security contact ([email protected]) This E-mail has to go to an high priorized and monitored queue in an ticket system,

2. That your support people and partners would inform one or two day's before the public disclosure.

3. That you have the right communication for all your customers ready and put it in the right time on the right places (webside, newsletter, twitter...)

4. That you have your firmware fixes ready to deploy and if it is possible some advanced monitoring ready for this issue and for broken clients.

What I now expect:

1. really fast update availability, even for older systems and without contract*

2. transparent communication what went wrong and why

3. better documentation and reporting how to fix the problem in our company's, not even on the wireless system side:

* How to detect clients with this problem * For which clients are updates available

I'm located in germany, the public disclosure was now nearly 24hour away,even the radio stations here broadcast informations about this issue fasterthen you.

At this morning the German Federal Office for Information Security has send outan public announcement that all people should update their clients andaccesspoints / routers if possible or contact their vendors for updates.

The phones are ringing with customers, cto's and so on. All want to have astatus about this issue and a dead line then it is fixed.

Yes the major problem are the client's, but the accespoints and controllersshould be fixed also and I expect that I get some help from my wireless systemto detect the problem on the clients if I have a managed wireless solution not one single accesspoint.

Our company has already rolled out the patcheѕ for our clients. Even microsoft has the patches already in place.

For me it looks like ruckus has ignored the advisory and now the try to react on it. This has nothing todo with enterprise support!!

There is absolute no excuse for this!!

For me the trust in your security support is gone, and there must be very good arguments that we will stay with ruckus after our contract ended.

Yes, they could have been out faster - but as the statement now say, it's ﻿only﻿ an issue if you turned on 802.11r on your SSID's or use Mesh networks (which, I hope, you don't).How can you ask ﻿Ruckus﻿ to list what ﻿clients﻿ are affected??Calm down, and be professional - there has been tons of security issues in IT in the past, and the world is not ending due to that.

If you have customers that rely on WPA only, then they deserve to be under attack.

I think there should be a way, have you taken a look what other vendors do:

Q: Can I detect if someone is attacking my network or devices?

A: Aruba software checks for replay counter mismatches on a perclient basis and will produce a log message if detection is triggered. The log message begins with “Replay Counter Mismatches“, followed by additional details.

Aruba has also released new RFProtect (WIDS) features and signatures to help detect attacks.

for example.

Also it should be no problem to build a list with patches for the major systems and publish them.

If I read this right:

"Here, the client will install an all-zero encryption key instead of reinstalling the real key."

They work with an all-zero key can this not be detected from the wirless system?

"Be professional ... If you have customers that rely on WPA only, then they deserve to be under attack."

Wow Jakob, do you work at Ruckus?

I appreciate they finally took the time to tell us not to worry about anything unless you use features that are turned off by default, or mesh networking </sarcasm>. Thanks for assuming most costumers don't care as they would rarely deploy a mesh network, right?

That blog post ("the ruckus room") is embarrassing. They don't even mention if they have a fix in the pipeline. Telling their customers who use "mesh" to "turn it off" is stupid. It's a feature, don't be surprised if people use it.

That blog post ("the ruckus room") is embarrassing. They don't even mention if they have a fix in the pipeline. Telling their customers who use "mesh" to "turn it off" is stupid. It's a feature, don't be surprised if people use it.

For 7731, P300, and mesh deployments, there is noknown workaround for CVE-2017-13077, CVE-2017-13078, CVE-2017-13079,CVE-2017-13080, and CVE-2017-13081. However, because Ruckus products useCCMP for Mesh and bridging connectivity, exploitation of these vulnerabilities ismade significantly difficult, as per Section 6.1 of the KeyReinstallation Attacks: Forcing Nonce Reuse in WPA2 report.

Open-Mesh announced they will have a firmware upgrade this afternoon (10/17/2017). Open-Mesh, the product which gives a you free lifetime license for their cloud controller, you just need to purchase the hardware. Not sure why it's taking Ruckus so long.

Ruckus, you better get your crap together and resolve this. You're already being snickered at in a few of the sysadmin mailing lists I'm part of.

In a couple more days those snickers are going to turn into turn into something much more damaging. Because you're such a big player in the wifi market, you're already getting mocked for not having a fix ready when it was announced, but at least right now you're lumped in with tons of other companies.

As the days go on those other companies are going to deliver their patches and you're going to be left out in the rain, tossing excuses and copy pasta to frustrated sysadmins with leftover end of year budgets they'll rightfully decide to spend somewhere else.

We love our Ruckus products but your lack of progress in this matter means to be secure, we may have to turn off our products, and we can't have that in our organization, so we're simply forced to switch vendors.

Is it safe to assume that Ruckus doesn't give a damn about their paying customers right? Since the patches are no were to be seen... I would like to ask the community for Ubiquity recommendations since we'll most likely be moving over.

I'm sure this will not be a popular comment but, I think some of these comments are blown way out of proportion. I also am not happy about Ruckus's delay of response and available firmware updates given the lead time they've been given. But they don't have it. I wouldn't apply the new code immediately anyway until some of you bled on it. I'm willing to bet that most of us have bigger security issues to deal with than a proof of concept hack on a single device, which requires them to be physically on-site, setup a rogue AP and write there own code for the exploit, as the code to exploit the vulnerablity isn't in the wild, then they might gain access to someones facebook feed. LOL

In addition can I borrow some of your budget dollars so I can jump vendors whenever I'm unhappy with their performance. Thats a luxury that I cannot afford, time or money wise. :)

I hope you don't work in an industry where you need to meet compliance or privacy regulations Todd, because the effort or proximity required for the attack doesn't mean anything at all to the overseeing organizations. I would imagine folks interested in taking advantage of this already have a wifi pineapple and a kali linux machine - maybe even some code to work off of now that smarter nerds know exactly how this all works. It's not hard to make a business case to deploy new WAPs when you already own the expensive ones from the vendor that is slow to respond to security incidents.

Hi Jesse, please don't take this comment as me defending Ruckus, it isn't, but if you are 'unlucky' enough to work in a sector that requires yo to meet privacy and or compliance regulations then you most likely have a fully functioning and very highly tuned WIDS/WIPS which will give you more protection to this issue than some of the other guys posting on here.

On the basis that all this vendor bashing seems to be falling on deaf ears, on the basis that no one other than Michael from the vendor has bothered to comment on their own forum and we still dont have a patch. I would suggest that the tit for tat between users is pointless.

Remember, we all want the same thing.

Maybe we would be better spending our time offering advice to each other on how to mitigate the threat in the meat time until a patch is released because ultimately, it will come out before anyone on this thread has a chance to switch vendor.

I'm not "unlucky" because I have regulations to keep in mind. You would be lucky if your users just browse Facebook all day like Todd. Just because you are subject to regulations doesn't mean you have additional budget/staff to put a WIDS/WIPS in place, they typically spend that on a robust properly configured AP (that gets timely support). In our case we don't administer every customer network post sales cycle. The only thing more frustrating than how Ruckus has handled this is the people trivializing their commitment to the issue and it's resolution.

Follow me here... Their official release plays down the vulnerability and then says:"Ruckus will be releasing security patches to address all above mentioned vulnerabilities. It is
recommended that customers upgrade their network(s) with these patches as soon as they
become available."

If it isn't a big deal, and doesn't affect your customers, why patch it at all - ever? Because it IS worth fixing... Sometime... When you decide to switch partners in this case, it's not because a patch isn't available at that moment, it's because of the damage done.

Hi Jesse, apologies if i offended you, my comment was not meant to. There may be a few people trivialising this issue but no more than there are people blowing out of proportion.

This is my opinion: Is it a valid vulnerability? Yes. Does it need to be patched? Yes. Even after the patch is the full threat nullified? Not unless you have 100% governance over every client on your WLAN's and can ensure they are all patched. Is it relatively difficult to actually take advantage of? Yes. Even if you are attacked, is it likely to cause a large scale security breach? Unless you are unlucky enough to have them capture traffic on a single MiTM attack for a user who is sending sensitive data upstream on an unpatched client, in an areas serviced by unpatched mesh AP's or a WLAN configured with 802.11r, no.

I appreciate it is annoying, and i have had to answer questions today from my customers about how long it has taken Ruckus to post an advisory and how long it will take for a patch but thats part of being in tech. There's a serious security treat almost every month, this month its WiFi's turn.

Yes Ruckus' comms haven't been what would be expected of a top enterprise WiFi vendor, and im sure that many of us will be having conversations with our reps over the coming days but hopefully they will learn from this.

None taken really, and I agree with your points above. I think it's another question of industry whether or not the big issue is if you could potentially snoop something significant in clear text to bring down the organization. In our case it isn't really about that.

The thing about regular security threats in IT is that you typically spend your money with folks you expect to fix things in a timely manner and exhibit exceptional communication. I don't think we hit either of those marks as we can both agree. So do you stick with somebody that predominately works in the industry they have a lackluster response in? Is this due to all the mergers, etc that have happened over the past year with them? I don't know, nor frankly do I care. I expect more from the company than device up-time.

@Jesse,If you are in a place where they need secure connections, you don't care about WPA - then you run VPN on top, of use applications that use SSL connections between peers, making sure you don't rely on encryption between the wifi endpoints.Heck, Apple enforced all App-connections to backend servers use SSL encryption, this summer, so you as a customer know that Apps now don't rely on encryption on the wire itself.Hell, that is what all users do on 99% of all hospitality locations around the world on a daily basis.

We see customers that just moved from WEP to WPA because their old creditcard terminals did not support other than WEP.. So, if it's not more important than that, maybe we should help remind the customers that they need to make sure the Apps they use are secure...

Don't assume I am only talking about guest wifi. I haven't said anything to imply that.

Do you know how VPNs actually work? I don't often use them inside of the same network over wifi <eye roll>.

That's really the key distinction here... It doesn't matter if they are using WEP/WPA/WPA2... That's not to say it's a good idea to be using anything other than WPA2. The attack surface is still there for properly configured access point(s). Where's my new firmware?

Not every application utilizes encryption to their back end, especially when the service is LAN side. I have said this repeatedly, but it is yet another question of your industry, and what applications you require to operate.

The customers don't typically know anything about their application other than its business value to them and the fact that they need it for operations. Even if they do care, they may not have a choice between secure/insecure applications to provide security over the wire regardless of price.

Jesse,All I'm saying is: If security is ﻿that﻿ important for your customers, that they are calling you even before the scope of this vulnerability is out in the open (it's still a ﻿lab﻿ case), then they should already be using Apps that use SSL communication directly between the client app and the backend.Oh, and if you've read the krack site, it's mostly a clientside﻿ issue

I work at a university. Should I tell all our students to use VPN? While for sensitive information requiring VPN use should be done, it's not practical in all situations.

I think another aspect of this is the PR side. When the CIO says they have people asking "does this affect us" it shouldn't require a long explanation of "yes, but only if you're not using VPN, not using secure apps, etc etc.

You can play Ruckus' cards all you want. "It's still a lab case..." Really? If I could prove there was another WPA2 vulnerability to where you could steal the PSK, but it wasn't in the wild yet, would you expect Ruckus to have a patch before somebody packaged up in a nice little tool for script kiddies? Would you care if you could just update Windows to mitigate the new threat? Apparently you wouldn't, and that makes you incompetent and naive in network security. I won't address your other noise again about apps using SSL.

Nobody is arguing that we shouldn't have to patch our clients, but even they have stated to patch BOTH. Well we can't do that yet. According to the latest word that will be two weeks away at the earliest for 'some' devices. Now we are waiting on a managers response about how everything is just fine, so long as 'xyz' is in place, or not in use. That's not acceptable. If you wanted to reassure everyone of the risks to certain features and the network safety otherwise, that should have been in the day one security brief assuring us of this with an ETA date on the firmware releases and which models.

Playing Ruckus' card - Really? Gezus..All I'm saying is: keep the perspective! This thread is going nuts over how all wifi is suddenly useless, when facts is, it's not!This thread is going nuts over how all security is suddenly compromised and peoples highly secret communications is at risk, and I'm simply pointing out: It the communications it ﻿that secret﻿, you should ﻿have other security measures in place﻿!I'm not fond if how Ruckus is handling this either, but stop making the world come to and end over this, when in fact it's not.

Thank you valued Customers and Partners for your patience as final action plans have been worked out.

(In response to questions such as “where is my patch” and “why is this taking so long”?)

Providing patches for affected products is our first concern and we understand its urgency to your business. We expect patches for most firmware releases to be available on October 30th, with all patches to be completed by November 15th. In the interim, the following steps will minimize risk:

- Disable 802.11rwherever enabled. This step eliminates the short-term need for patches to Ruckus infrastructure in all but the two scenarios described below.

- Patch client devices asthose patches become available. Unpatched clients will continue to be a risk tonetwork security, regardless of what other steps are taken.

With the above steps taken, two Ruckus use cases and products continue to pose a network security risk: meshed APs and point-to-point links. That risk is minimized through use of rogue AP detection and subsequent corrective action.

Full protection against KRACK will be assured once all infrastructure software has been updated (and 802.11r re-enabled) and all clients have been updated.

Really? Sometime between October 30th and November 15th? Ruckus had known about this for how long? Has Ruckus bothered to see how quickly their competitors got patches out? Impressive to see how succinctly the ball has been dropped here.

Now tthe problem exists that ruckus was not ready for this problem. So let us not do the fingerpointing let us find solutions. As described in my posting I see some expections:

1. really fast update availability, even for older systems and without contract*

2. transparent communication what went wrong and why

3. better documentation and reporting how to fix the problem in our company's, not even on the wireless system side:

* How to detect clients with this problem * For which clients are updates available

You have us shown point 1 about the speed we can discuss but it is necessary that the patches are stable and working. So If you have startet with the development too late the dates you announced are fine from my point if view.

Now my points 2 and 3 is missing. Can you tell us something about it and can you make it public please?

To get the trust from your userbase it is necessary to show us what went wrong and why and what will be take in place to prevent this happening the next time.

Disappointing response from Ruckus. If other major vendors were able release a patch after lifting the embargo, why can't Ruckus? Disabling 802.11r mitigates risk for now but I've deployed many Mesh APs on one of our clients because of structured cabling challenges.

The WPA2 patch firmware will also be provided to customers who don't currently have active support contracts, * but you will need to create a "Guest" account on our Support portal. Please do this in advance if you don't have one now.

All Guest users should to be able to access/read the Ruckus Warranty and Software License Agreement on our Programs page for example, which is Published with Available to Anyone status:https://support.ruckuswireless.com/programs

Hi Michael, you say that "firmware will be provided to customers who dont currently have active support contracts" but i see no mention of this in the RN's. So, for example, how would i go about applying 9.10.2 to a ZD that has expired support contract? I cant initiate the upgrade because i have an expired support entitlement file on the controller.

Thanks Michael, I'll get this checked out. Just a couple more questions on this if its ok:When did the 30 days timer start?For the entitlement check, what if the ZD doesn't have access to check with the server and the local license file has expired?

Realize im throwing curve balls but we have multiple customers who all have very different scenarios.

I thought I'd update my question with my own answer and explain the process I had to perform on the ZD's without support contracts so I could patch them for the krack attack.

I contacted Ruckus Support via https://support.ruckuswireless.com/contact-us I started an online chat session and explained the scenario. The rep I originally spoke to said he would have to escalate it to the engineers and someone would contact me. Within a very short period of time (can't recall but it was fast), someone reached out to me via email to let me know they'd contact me by phone in 15 mins. I explained the situation, then replied to their original email with my ZD serial numbers.

They replied a short time later with 3 entitlement files (aka support contracts) and I could upload those to the Administer >> Support tabs on each ZD.

Two of the entitlement files were for one day only (they were the oldest ZD's I had without a support contract. I had to follow the support path which mean updating from 9.8.x -> 9.9.x ->9.10.x -> 9.12 -> 10.0.1.0 (or something very similar, refer to the update documents to see the exact path you need to follow)

The rep told me they would expire in one day whether or not I would use them and he wanted me to perform the first update with him over the phone so he knew it was going to work. Once I performed the first update successfully I let the rep go so I could let him assist other people. It took a bit of time to follow the support path but I was able to successfully upgrade the ZD's without support contract thanks to the Support Team at Ruckus.

The ZD's support contract expired on the next day but everything was up to date. The third support contract was for a bit longer, but none of them was for 30 days.

I have to say, I am not a fan of the 10.0.x UI... I really miss the dash board with all the important info like Serial Number, Software Version, Up Time and the customized widgets we could setup. The important factor is the systems are now protected.

Regardless, the updates were successful thanks to Ruckus for letting us do that!

Thanks Jeff, im a bit concerned with the 1 day support file as this means we have to contact support on the day that we plan to do the upgrade and get the file before we can start but if we have a scheduled upgrade window this puts unnecessary pressure on. Will give it a shot and see how it goes!

The rep from Ruckus said if the support contract expired before we could upgrade the ZD's to just contact them again and they can extend the support contract for a bit longer with a new entitlement file.

We do residential homes and small businesses so the impact wasn't high risk to our clients. The businesses knew it was important enough that a 4 minute or less interruption was worth the small downtime.

The third ZD support contract was extended for longer than a day (not saying how much longer)... not sure if this was a mistake but don't want to get the rep into trouble if he extended past the time frame he was suppose to create it for. It's for our lab ZD so it will be put to good use.

If upgrade to 9.10 is free. My concern is how to get the customer to 9.10 if they have unsupported AP's like 7025. Especially as there is no longer the 7055 which was a halfway house in the respect that it was supported on older versions and spanned the gap to H500.

I guess you will have to reach out to Ruckus when it's released on monday, if the path is not clear, and your customers are stuck on old systems.Or you have to explain your customers that they are on many-year-old systems that is simply way out of support.. and should be written off years ago.

Jakob, im curious why you say they should have been written off many years ago when you know nothing about the use case of the networks. What makes you think that a customer should upgrade their wireless infrastructure just because the manufacturer decides that they will drop support for hardware they have replaced if it is still performing the job that it was purchased to do?

If they have 7025 AP's, it was End Of Sale'd on may 31 2015, end EOL'ed nov. 30 2014.That is 3 years ago.While 'the job they were bought to perform' might still be valid, you've known for 3 years that this product is EOL.Your luck, though, is that the model is still under support for another year - have they bought support? You write: ﻿No﻿. ﻿If﻿ Ruckus put's out upgrades for systems without valid support contracts, they are in luck - but you've gotta admit:

1: They are on 3+ year old system2: They have ﻿not﻿ bought into supportHow in the world do they think they can expect support?Anyway, they 7025 does not even, as far as I know, support 802.11r, so they flaw is not even on their system!They have to make sure the clients are updated.

Reg. 'written off'.Here in Europe, at least, it's common practice to make sure IT equipment is written off within 3 years. You simply budget with a replacement after 3 years.You can hope not to have to spend the budget, but it's good practice to have the budget.

And will you be replacing all of the newly installed AC Wave 1 installations in 2 years time when Ruckus drops support for the full range after AX is released?

Whether they have support or not is irrelevant if the hardware is stopping them from upgrading.

Jokob, i'm based in the UK and have worked enough around Europe to know that it is not common place at all. Maybe in certain verticals, large enterprise for example, yes. But a blanket statement that its common place for the budget to replace IT equipment every 3 years, especially if still functioning perfectly adequately, i find hard to believe.

There are other flaws that just 802.11r. There is Mesh and there is the option on the wireless vendor to introduce additional measures in AP firmware to mitigate client side vulnerabilities by rejecting variations in the replay counters from that stored by the AP for example. As far as I know Ruckus hasn't confirmed exactly what will be released as part of the patch yet. You cant always ensure all clients are updated especially with guest networks.

Anyways, we are getting away from the point here, my question was simply to ask if anyone had had conversations with Ruckus about older versions of firmware that 9.10.

I find this discussion a bit hilarious :-) I've been working in IT in Finland for over 15 years, seen a wide variety of companies from small to large. It's highly unlikely to replace wlan APs every three years. Or switches, or storage arrays or servers. Laptops and mobile phones usually.

Anyways, I bought Asus RT-N56U for home in early 2011. At first it was missing some nice-to-have functions, which I emailed Asus. And guess what? After a while they released new FW with the featrures I had asked for. And FWs kept on coming. The latest FW was released in March 2017, over 6 years after I bough the device.

Couple of weeks back I emailed Asus asking if they are releasing firmware to address WPA2 krack, and yes, they are although they couldn't give me the date yet. :-) Now that I call customer care. No registrations, no support agreements, just go to the website, download and update. No doubt, my next home AP will be Asus. Not because they'd be technically ahead of others, but because they listen and care about their customers.