Support Process?

  • 1
  • Question
  • Updated 5 months ago
  • Answered
I've been extremely frustrated with guest wifi setup - all the docs I can find and the scattered forum posts seem to reference a world before all browsers started doing strict https certificate checks. All I want is to offer the same experience I see in national chains (Starbucks, Panera, etc.) and there's not a single up-to-date FAQ or anything here.

So I decided to open a support ticket (first one ever). My day is busy - I may or may not be available at various times, I'm a freelancer working with multiple clients.  Here's everything that is annoying me about the process.  Am I doing this wrong?

  • Even though I'm signed in here when opening the ticket, I have to wait some period of time for a support agent to respond and then collect info that's already available (who am I, what's my number, what product, what serial # - this is IN MY PROFILE).
  • My question is simple - setup guest wifi w/radius auth, what is best current practice for this on Ruckus. I don't need a call, I just need a pointer to a HOWTO or if there isn't one, an email response outlining what you tell the other other customers that want guest wifi w/radius auth setup.  I'll make my config match whatever you want and then we'll go from there
  • Instead, I get an email back demanding a call. I hate the phone, I will choose text or email always. Also I can't promise I'll be available at any particular time (again, don't have to do that with email).  So I pick a range of times. I'm outside when a call w/o caller ID comes through, and I missed my chance by the time I notice there's a missed call, possibly from Ruckus.
  • Later I get an email that I've missed a call so I give another block of time.  This time the support agent ignores the phone # in the ticket, ignores the phone # in my profile, and calls the main number of the client.  They have no idea what he's talking about.  So I miss another call.  The support agent calls after the window at the correct number and I'm not here.
  • This I guess gives them license to just dump this back on me and I've not heard anything since.
Is this basically how support works?  A phone call for a simple "how to XYX" seems crazy, esp. when we're dealing with what I assume is offshore support.
Photo of Charles Sprickman

Charles Sprickman

  • 24 Posts
  • 10 Reply Likes

Posted 6 months ago

  • 1
Photo of Michael Brado

Michael Brado, Official Rep

  • 2874 Posts
  • 400 Reply Likes
Hello Charles,

   I've been a customer and in tech support, and I prefer email over phone calls too (as a customer).
As a TSE, I also prefer to have a chance to research the topic, and would probably send an email,
unless the customer asks for phone contact primarily.  I think our guys in your case were assuming
the quickest way to get in touch was the phone.  Did you say/ask that they contact you back by
email after opening your ticket?  But all that aside, still not a good experience so far, and I hope I
can help.

  I try to help customers find their own solutions (hopefully), and you mention you had found articles
and previous forum posts. I used our Support portal search bar with 'https webauth' and sorted thru
the articles about accessing a ZoneDirector or config on a SmartZone controller (I'm assuming you
have a ZD), and I found a couple KBAs that describe some issues, and about how ZD 9.13 may have
support or a CLI command workaround.

https://support.ruckuswireless.com/articles/000002334

Is HTTPS protocol for Guest Access login page, introduced in ZD 9.13 optional?
https://support.ruckuswireless.com/articles/000006012

   But... a Guest Access WLAN can only authenticate via a Guest Pass, or None (just pass-thru to
the optional Terms & Conditions, else go straight to their browser homepage).

  With regard to using a RADIUS server to authenticate guests for Wi-Fi, you need to consider a
WISPr/HotSpot authentication WLAN. This solution requires that you have an external AAA server,
and can setup a Login.html file on it to point user authentication to.  This file outlines the WISPr
authentication flow (ignore the Ruckus Confidential footer, its public now!).

https://support.ruckuswireless.com/articles/000002926

   And here is an article with a helpful Tech Note attached on how to configure secure HotSpots
on a ZoneDirector.https://support.ruckuswireless.com/articles/000002610

   If you wanted to use the ZD's database instead of an AAA server, it can host the Login.html file.
https://support.ruckuswireless.com/articles/000002039

   These are old version docs, but not a lot has changed on the ZD configuration side.  I hope that
they provide some helpful reference as you build your guest wi-fi solution.
(Edited)
Photo of Vinod Gangadharan

Vinod Gangadharan, Employee

  • 1 Post
  • 0 Reply Likes
Hi Charles,

We are looking into the issue & Manoj Samuel from Support will be reaching you for further assistance. 

Regards,

Vinod Gangadharan

Manager, Technical Support
Photo of EightOhTwoEleven

EightOhTwoEleven

  • 88 Posts
  • 23 Reply Likes
MAC auth with pretty pages (like Panera, Starbucks) is made very simple using Ruckus alongside their Cloudpath offering. We use it and it's fantastic.
Photo of Manoj Manoj

Manoj Manoj, Employee

  • 1 Post
  • 1 Reply Like
Hello Charles,

I have answered all your queries regarding WISPr workflow and Unleashed AP configuration.

Feel free to contact me for further assistance.

Regards,
Manoj Samuel.


Photo of Charles Sprickman

Charles Sprickman

  • 24 Posts
  • 10 Reply Likes
Manoj was very helpful!
Photo of Charles Sprickman

Charles Sprickman

  • 24 Posts
  • 10 Reply Likes
I'm also just going to outline what I found about the guest login process (using an external radius server and splash page) after playing with this in the "lab" and capturing all the traffic with wireshark.

Of note, in my support call there was talk of the initial redirection happening via DNS, but I did not see any DNS spoofing attempts.  This is the process I recorded:

  1. host joins wifi network
  2. DHCP request/granted (via the router)
  3. host makes any of dozens of requests, some via already-cached DNS entries, some make a DNS request to the DHCP-provided DNS server(s) - I'm following a new/"fresh" request after having flushed my local DNS cache
  4. host receives a correct DNS answer from configured DNS server
  5. host makes an http or (more often than not) an https request to a server, either something the user is trying to reach in the browser or any of the many background tasks.
  6. the ZD (or is the AP?) responds to the request with the spoofed IP of the destination host
  7. the reply is an http redirect (302) that redirects the user to the ZD, with a query string that includes the destination the user was requesting
  8. in my case, where the splash page is external, another 302 is issued that points to the external splash page and the query string now includes all sorts of extra info as well - like the client MAC, AP MAC and the final redirect URL. This request is let through, presumably by the "walled garden" list of allowed IPs
  9. once the correct login info is entered on the splash page, all the ZD redirections  and spoofing stop and requests proceed as normal
A few other random notes:

  • With something like Apple CNA, these requests initiated by the OS are all via http, which is why the experience is relatively smooth on apple devices (and why I can see all the traffic in wireshark, which is nice).
  • Firefox has its own built-in CNA check, did not realize that. It requests via https, so it does get tripped up on TLS cert issues
  • Didn't test windows, but I assume that's where we start seeing TLS certificate issues. I feel like step 6 probably throws up an ominous warning about the SSL cert not matching the hostname. Further redirects will trigger TLS warnings if you're using a self-signed cert.
  • It seems wise to put certs on all ZDs to at least get rid of one warning. I bought a 1 year cert for $9 for testing, LetsEncrypt has pushed the prices down (too bad the ZD can't just use LetsEncrypt natively!)
Photo of Michael Brado

Michael Brado, Official Rep

  • 2864 Posts
  • 399 Reply Likes
Your feedback is appreciated, and the test Cert provider suggestion is not SPAM enough for my edit..., thx.
(Edited)
Photo of Alexey

Alexey

  • 48 Posts
  • 9 Reply Likes
Charles
I like your hate.
I have got some expirience of interactions with many different vendors HDescks include Ruckus.
I have had the same opinion with you about Ruckus HD just a small time ago.

But i have corrected this my opinion becourse of :
in fact, it works.

From my point of view only.
They are not good enough on the low level priority incidents - it takes too much time and not effective often. It is common problem, not only Ruckus.
Their site & documentations are very convoluted - I ve seen some users not only me that where emphasized this problem (even rather difficult Cisco site are much more relevant) .
But Ruckus HD rather good in difficult cases decisions. They use Webex effective. 
Its all only my own private opinion.

Summary. From my point of view Ruckus HelpDesk is seem to be rather a.. specific.
A user should get time to get used to it.
But after some working time any user will be able to solve any problem. 
Or almost any :)