Issues with AIR-AP3802 in WGB mode (UWGB)

[jtrohm]

TL;DR: 3802 WGB inconsistently associates and loses connection withing minutes if it does. WiFi is not controlled by me or anyone I have functional access to. It *WAS* working and now suddenly isn't. Looking for suggestions.

Detail:

Product/Model Number : AIR-AP3802I-B-K9
AP Running Image : 17.3.6.76

I work on the road extensively and carry a C1111-4PWB and AIR-AP3802i with me to act as a home office network in a box. The 3802 is in UWGB mode and I typically attach it to the hotel Wi-Fi so that the AP so as to act like a wired DIA with my laptop dock and various widgets behind it.

I am currently staying at a Marriott-branded hotel. I have been here for about three weeks and my setup has worked about as close to flawlessly as I can expect given the circumstances. However, this weekend they upgraded their access-points and I can rarely fully connect and never sustain that connection. The auth is open, so there is really nothing weird or complicated going on in terms of the configuration. I've tried switching to radio 1 to change band and have similar results. 

The MAC address of the access-points I am trying to attach to suggest that it is a Ruckus network. It presents the typical captured portal once per week, which I have authenticated past already when it occasionally works.

What I'm seeing is that that upon initial boot, the AP will associate, and the AP will get a DHCP address on the aux interface that can ping the gateway for 3-10 minutes. After that I lose the ability to ping even from the AP. The router will occasionally (but rarely) be able to obtain a DHCP lease. When it does, it will also be able to ping the gateway for a period of time and then lose access.

I see what appears to be excessive roaming events, but the WGB always shows associated when I look at "show wgb dot11 associations"

Below is an example of it half-working initially: 

MOBILE-WGB#show ip int brief
Interface            IP-Address      Method   Status                 Protocol   Speed      Duplex
wired0               172.31.255.99   static   up                     up         1000       full
wired1               unassigned      unset    down                   down       n/a        unknown
auxiliary-client     172.20.0.213    DHCP     up                     up         n/a        n/a
wifi0                n/a             n/a      up                     up         n/a        n/a
wifi1                n/a             n/a      administatively down   down       n/a        n/a

MOBILE-WGB#show wgb dot11 associations
Uplink Radio ID : 0
Uplink Radio MAC : F4:DB:E6:7C:CD:E0
SSID Name : MarriottBonvoy
Parent AP MAC : 74:3E:2B:07:F9:38
Uplink State : CONNECTED
Auth Type : OPEN
Uclient mac : 00:EE:12:34:56:78
Current state : WGB
Uclient timeout : 60 Sec
Channel : 1
IP : 172.20.0.213/20
Default Gateway : 172.20.0.1
DNS Server1 : 172.20.0.1
IPV6 : ::/128
Dot11 type : 11n
Assoc timeout : 5000 Msec
Auth timeout : 5000 Msec
Dhcp timeout : 60 Sec
RSSI : 64

MOBILE-WGB#ping 172.20.0.1
Sending 5, 100-byte ICMP Echos to 172.20.0.1, timeout is 2 seconds
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1.408/3.347/9.261 ms
MOBILE-WGB#

ROUTER#debug dhcp
DHCP client activity debugging is on
%Unknown DHCP problem.. No allocation possible
.Oct 28 16:06:53.511: DHCP: Waiting for 5 seconds on interface GigabitEthernet0/0/0
.Oct 28 16:06:58.514: DHCP: Try 2 to acquire address for GigabitEthernet0/0/0
.Oct 28 16:06:58.540: DHCP: allocate request
.Oct 28 16:06:58.541: DHCP: zapping entry in DHC_PURGING state for Gi0/0/0
.Oct 28 16:06:58.541: DHCP: deleting entry 7F5AC9FAC8 0.0.0.0 from list
.Oct 28 16:06:58.541: DHCP: new entry. add to queue, interface GigabitEthernet0/0/0
.Oct 28 16:06:58.541: DHCP: MAC address specified as  0000.0000.0000 (0 0). Xid is 49
.Oct 28 16:06:58.541: DHCP: SDiscover attempt # 1 for entry:
.Oct 28 16:06:58.541: DHCP: SDiscover: sending 315 byte length DHCP packet
.Oct 28 16:06:58.541: DHCP: SDiscover 315 bytes
.Oct 28 16:06:58.542:             B'cast on GigabitEthernet0/0/0 interface from 0.0.0.0
.Oct 28 16:07:02.324: DHCP: SDiscover attempt # 2 for entry:
.Oct 28 16:07:02.324: DHCP: SDiscover: sending 315 byte length DHCP packet
.Oct 28 16:07:02.324: DHCP: SDiscover 315 bytes
.Oct 28 16:07:02.325:             B'cast on GigabitEthernet0/0/0 interface from 0.0.0.0
.Oct 28 16:07:06.327: DHCP: SDiscover attempt # 3 for entry:
.Oct 28 16:07:06.327: DHCP: SDiscover: sending 315 byte length DHCP packet
.Oct 28 16:07:06.327: DHCP: SDiscover 315 bytes
.Oct 28 16:07:06.328:             B'cast on GigabitEthernet0/0/0 interface from 0.0.0.0
.Oct 28 16:07:08.330: DHCP: SRequest attempt # 1 for entry:
.Oct 28 16:07:08.330: DHCP: SRequest - ciaddr: 10.125.10.213
.Oct 28 16:07:08.330: DHCP: SRequest placed lease len option: 120
.Oct 28 16:07:08.330: DHCP: SRequest: 317 bytes
.Oct 28 16:07:08.330: DHCP: SRequest: 317 bytes
.Oct 28 16:07:08.332: DHCP: Received a BOOTREP pkt
.Oct 28 16:07:08.334: DHCP: Sending notification of ASSIGNMENT:
.Oct 28 16:07:08.334:   Address 10.125.10.213 mask 255.255.255.252
.Oct 28 16:07:08.335: DHCP Client Pooling: ***Allocated IP address: 10.125.10.213%Unknown DHCP problem.. No allocation possible
All possible debugging has been turned off

As you can see, initially after boot, the WGB has access to the AP and can ping the gateway, but DHCP response is malformed in some way preventing the router from getting its lease. The offer contains the correct address, so the request is properly formed with the correct MAC address configured in the UWGB config. 

I am NOT having issues when I connect to the WiFi directly with my laptop or my iPhone. This is exclusively an issue with the WGB and router interacting with the hotel wireless. It also appears to be exclusive to the new access-points as there was no issue prior to the hotel upgrades. 

Any ideas or suggestions are welcome. 

[Flavio Miranda]

@jtrohm 

 If you enable the hotspot on your phone and connect the Access Point to it, does it work ? If does, means there is no problem with your AP, which seems to be the case, it is difficult to suggest something.  We will never know what is the root cause of the problem, maybe a bug on the new Ruckus version or some new feature was implemented. 

Just for curiosity, there are a few debug command you could run for uwgb as follow

Debug Commands

• debug wgb uplink state-machine {events | info | error | critical | all}

• debug wgb uplink scan {events | info | error | critical | all}

• debug wgb uplink security {events | info | error | critical | all}

• debug wgb uplink configuration {events | info | error | critical | all}

[jtrohm]

Thank you Flavio for the response. I'm just seeing this now. Historically I've used 3700 series for this but left them at home and am still fumbling my way around the new code. 

What I've found is that this is related to the roaming events. It typically works right after a reboot or disable/enable of the radio. Once it starts roaming, it's a dice roll if it will work. I've been able to limit the impact by manipulating what it sees. Unfortunately, it looks like a lot of the radio tuning options don't yet work correctly. 

For example, when changing roaming parameters, I regularly see the error message: "% The WGB mode have not configured itseems, please check" After which, it is clear that no change was actually made.

The best I've been able to do so far is to disable channels of known suspect APs to avoid them being considered for roaming. I've also moved the AP around to try to optimize signal to reduce the roaming events that way. 

[Rich R]

I've never worked with the APs in WGB mode so not familiar with it at all but 17.3.6 and was riddled with bugs so for a start I would upgrade it to 17.12.4 https://software.cisco.com/download/home/286304536/type/286288051/release/15.3.3-JPQ3

But if it's a bug on the Ruckus APs or a new feature they've implemented to prevent bridging then there's nothing you can do about it.