Wireless Access

Hi Guys,

Good evening,

 

lately i  noticed that Some android/mobile devices - getting an hard life to connect to Aruba (OPEN SSID) after disconnect and manually trying to connect.

 

Some general details:

*Tested on few Aruba OS - now it's on 6.2.1.5)

*OPEN SSID

*NO ENCRYPTION AT ALL

*THE DEVICE STUCK ON CONNECTING..For a while (it's only connecting good in the first time - if u try to manually disconnect/forget the ssid and then connect again ...It's just stuck on connecting... For a few minutes .And then try and try)

*SSID GOT NO BLACKLISTING ENABLED*

*ALL FIREWALL / DDOS OPTIONS ARE OFF*

*DHCP/DNS/ICMP/NNAT ALLOWED IN THE FIRST ROLE*

*PC'S got no issues at all*

 

if I'm looking on the user - i can see status - auth-assoc reason = 0 (What does it mean?)

 

other devices that aren't android/mobile devices (LAPTOPS) working like charm.

 

Tested on few Android devices (4.1 / 4.2 / 4.3 / 4.4.2) - Samsung S3 NOTE2 NOTE3 S4 / other LG devices / Windows Mobile

 

Please advise.

 

Anyone else notice this kind of issue?

 

Have a gr8 week,

 

Me

Try to make Bandsteering "Prefer" instead of "Force 5ghz" and see if that changes anything.

Hi Hi.

it's AP-68 Units.
THE BAND STEERING IS OFF IN THE VAP , and it's on only G

The AP 68 is a single stream access point. Does it occur when the access point is under load?

I'm sitting in front of 1 unit - and i'am the only client :)

It's only happening on Android devices....

User debug? On the dashboard, are there channel utilization numbers and noise (6.2 and above) for that access point?

0-15%...Im now sitting at my home. i been tested it also in our lab ...the channel usage is not the reason...laptops connecting fine...android devices connected fine...and if u trying to disconnect/forget the network and to connect agian..they just keep writing...connecting....getting an ip address...connecting...getting an ip address...forever. *AGIAN - ONLY ANDROID DEVICES*

Sounds like the same problem I am seeing (similar devices), and first noticed on 6.2.1.3 and still see on 6.3.1.2.  I suppose that's why you commented on my thread. :)

 

Do you see the client associated to an AP?

Is the client in the user table?

Does the client have an IP address?   If yes, does the default router have an ARP entry for it?

1. Just when it's connected - if i disconnect and try to connect, i see the client :
status - auth-assoc reason = 0
But after a few minutes it's also disappeing even due the android keep trying to connect.
2. Didnt checked it
3. Yes - when it able to connect - it's keep getting an IP. (like normal clients)
Default router = Aruba controller (Controller got an external IP)

Send me the CLI commands that u ran - i will replicate them on my enviroment - and i will send u guys the output (i'm now going to my lab at the office to bring 1 more android device + 1 more windows mobile device)

---

@kdisc98 wrote:

1. Just when it's connected - if i disconnect and try to connect, i see the client :
status - auth-assoc reason = 0
But after a few minutes it's also disappeing even due the android keep trying to connect.
2. Didnt checked it
3. Yes - when it able to connect - it's keep getting an IP. (like normal clients)
Default router = Aruba controller (Controller got an external IP)

Send me the CLI commands that u ran - i will replicate them on my enviroment - and i will send u guys the output (i'm now going to my lab at the office to bring 1 more android device + 1 more windows mobile device)

---

Our symptoms are similar if the device has an IP, show associated "show ap association <client-mac>, but doesn't appear in the user table.  Be sure to find out if the device shows in the user table.

 

Any chance this is a 3000 series controller?

The controller is 6000-M3 (NOT 3000 Series)

Hi Guys

Good night (At least here it's 01:07)

• A6000-M3
• AP-68 Unit
• SplitTunnelVAP (With Captive)
• External DHCP server

so.. i brought two other more devices. (Windows Mobile and another Android) All devices connected fine in the first time (getting an IP seeing captive and everything)

 

So I tested the issue..every time i manully disconnect (after i'm connected)  i'am unable to connect :(

**ITS NOT RELATED TO ANDROID ONLY - SEEN ALSO ON WINDOWS MOBILE PHONE**

Then i upgraded to 6.3.1.3 from 6.2.1.5 - same issue.

 

so i took out some debug output on one of the clients(Android)

 

* I notice this line:

Feb 17 01:04:41     authmgr    VDR - mac d0:22:be:40:a9:23 rolename Aruma_AccesRule fwdmode 3 derivation_type Initial Role Contained vp not present.
Feb 17 01:04:41     authmgr    VDR - mac d0:22:be:40:a9:23 rolename NULL fwdmode 3 derivation_type Matched User Rule vp present.

 

anyone know what is that mean? anyone seeing anything else i missed in the following debug output?

attached screenshot:

 

Thanks agian.

I'am hitting bed for now - continue debuging this issue tommorw morning.

 

 

 

 

DEBUG OUTPUT AS TXT FILE ATTACHED TO THIS POST

Disassoc from sta: d0:22:be:40:a9:23: AP 172.16.1.172-d8:c7:c8:55:bd:c1-d8:c7:c8:cd:5b:dc Reason STA has left and is disassociated

 ..means that the device roamed away or disconnected for whatever reason.  It is very common.

 

For us to get to the bottom of this, we need to focus on a single deployment and a single AOS version.  If we start looping in many different versions of code and many different deployments, we may never get to the bottom of this.

 

When did this start happening?  If it never worked, was a case ever opened?

AP68s are rare, so I cannot test this.

There are quite a few deployments that have your type of setup and work so we probably have to dig into your configuration.

The debug simply says that the client is disconnecting.  Nothing really to report from that.

If you are doing split tunnel captive portal, this is a RAP.  Are you dropping broadcast and multicast for these VAPs?

What is providing DHCP for these clients in this specific deployment?

 

Hi Cjoseph

GOOD MORNING. :smileyhappy:

 

I know what disassoc is :) *AND MY DEVICE DOSENT CONNECTING TO ANY OTHER AP or SSID - it just keep trying connecting to this ARUBA AP*

that's not what causing the device not to connect this is just an output of the device re-trying to connect with out a success.

the device keep trying to connect - and the aruba keep see that assoc and then diassoc - becuase the devices (any  device) stuck on connecting...... after i manully disconnect it and try to connect agian.

 

The device just cant connect to the AP....!!! after manuuley disconnect,that what i took out thoese logs.

and the debug showing that is device disassoc..Because ,after i manully disconnect i'am trying agian to connect with no success and the debug output is disassoc...

 

When did this start happening?   Dunno - on daily base devices are connecting - but as long as they dont manually disconnect there is no issue.

 

If it never worked, was a case ever opened? It worked for years. . .without being noticed i guess.

 

The debug simply says that the client is disconnecting.  Nothing really to report from that.

I know ...... i need u to read agian all what i wrote. . . DEVICE CONNETED WELL. I MANULLY DISCONNET IT. WAITING 2-3 SEC AND TRYING TO CONNET ...THE DEVICE WILL NOW CONNET.

 

If you are doing split tunnel captive portal, this is a RAP.  Are you dropping broadcast and multicast for these VAPs?

yep - and i also tried without that config..same results

 

What is providing DHCP for these clients in this specific deployment?

 

Extranl DHCP. (UBUNTU SERVER) on a TRUNK PORT.

 

Thanks for u support...i need to solve this issue soon.

Hope that Some AirHeads assitance will show me the light in this issue.

 

Thanks agian.

 

Me

kdisc98,

 

Please open a support case so that they can get to the bottom of this.  This is not something that can be resolved easily on a forum due to the number of variables involved. 

kdisc98,

 

What is your ACL to allow DHCP to those devices?  What is the output of "show rights <role>" for users in the "logon" and post-authentication roles?

 

THANK U - cjoseph - and everyone else that helped me / sent me great tips and direction to eliminate the issue.

 

Issue solved. AirHeads Rocks!

 

Attached link to a PDF what cause it and  how i solve it.

 https://www.dropbox.com/s/jvoys40w3h9yoxo/debug.pdf

 

Teaser to the PDF :)

HINT:   (USER ROLES) :smileyhappy:

---

@cjoseph wrote:

kdisc98,

 

What is your ACL to allow DHCP to those devices?  What is the output of "show rights <role>" for users in the "logon" and post-authentication roles?

 

---

IT WAS THE PRE CAPTIVE- AUTH ROLES :)  *users that connect and then manully choose to disconnect  after 2-3 even without pressing the login button,and then trying agian to assicate to the ap , just cant reconnect.

 

Thanks agian! :womanlol:

 

Kdisc98,

When you swap out the AP68 do you have the same issues? If you have a single stream access point paired with a single stream device like a smartphone, you are already at a disadvantage from an RF perspective. With that being said, we do not see AP68s in the field as much as all of the other access points, so of there is an issue, it would not have received much visibility.

I have more then 300+ units of AP68 deployed on diffrent public locations.

It's not the single stream issue..android devices got no issues with other 1 single stream AP - home equipment (i tested it with netgear/linksys/drytek and more)

Do your androids work with other Aruba access points?

Yes they do - also with AP68 units.

(Example: giving service to more than 20,000 unique devices on daily base - only on 1 controller :) )

 

I think it's something belong to the AOS + Split-tunneling + AccessRole/AAA. something making the android unable to connect after they disconnect ...something that dosent effect any other device.

 

very very strange.

 

Any CLI commands - that u recommned me to run in order to get some debug info , that will be helpful for me.

 

Let me get this straight:

 

You don't have problems with other access points and androids

You DO have problems with androids and theAP68

You are ALSO using split tunneling?

You don't have problems with other access points and androids <-> never notice any issue that is related only for android devices in the past.

You DO have problems with androids and theAP68 <> I will bring other AP model and i will connect it as split - and i will let u know if its AP MODEL related ...i have sites with AP-68 with no problems at all (none split-tunnel sites)

You are ALSO using split tunneling? <>

:) ALL THE 300+ AP68 on that controller (located on different sites/branches - doing split tunnel after captive portal :) for years (2007-2008) I'm running this kind of solution )

Any specific CLI COMMANDS for DEBUG i should run in order to get some more info - why it's occurring? please advise

You can start with user debug.  The most definitive capture of this behavior is a packet capture, however.

 

 

You can start with user debug.  The most definitive capture of this behavior is a packet capture, however.

 

I will do it when i will be back with 2 more devices :) * I will keep this post updated*

I encrouted something in the RN of 6.3.1.3: (I'am using 6.2.1.5)

 

BUG ID 94345

(BTW:I'am using an EXTRANL DHCP SERVER and not INTERNAL)

---

@kdisc98 wrote:

I encrouted something in the RN of 6.3.1.3: (I'am using 6.2.1.5)

 

BUG ID 94345

(BTW:I'am using an EXTRANL DHCP SERVER and not INTERNAL)

---

Kdisc,

 

That issue above is resolved if you use an external DHCP server.  Try that and if that still does not work, you are not hitting that bug.  Please test with a different access point to see if it is access point specific.  We cannot fix any problem that we cannot replicate, so we need to know the exact setup that this occurs on.  If your description is too general and it cannot be replicated, we have little chance of fixing it. You should probably open a TAC case in parallel, as well.

I'm using Extranl DHCP server but with version AOS 6.2.1.5