• Advertisement

HTC mobile phone access WLAN problem

Configuring Wireless Cisco Networks and Wireless Controllers.

Re:HTC mobile phone access WLAN problem

Postby Guest » Wed Jul 22, 2009 6:09 pm

Hi,

 

I will try to disable client load balance per WLAN.. ( I have also enable band select, maybe it is the reseon of high rejection?? )

 

Best Regards,

 

Jackson Ku

Guest
 

Advertisement

Re:HTC mobile phone access WLAN problem

Postby Guest » Wed Jul 22, 2009 6:23 pm

Is the HTC mobile phone dual band?

I doubt band-select is releated, BUT if you client is going from .11A to .11B/G to .11A to .11B/G that might be resetting the 3 rejection counter each time....  just a theory...

 

If this is the only client that doesn work. thats crazy.....

Guest
 

Re:HTC mobile phone access WLAN problem

Postby Guest » Wed Jul 22, 2009 7:55 pm

Hi,

 

We have two smart phone ( Motorola & HTC with Android 2.2 ) with similar problem. The Nokia smart phone ( Platform S40 ) was ok.

 

Today we tested with Motorola smart phone, it have 802.11g only. The problem solved after I disabled client load balance on WLAN...

 

Why the WLC rejected the associated request from Motorola & HTC smart phone???

 

Best Regards,

 

Jackson Ku

Guest
 

Re:HTC mobile phone access WLAN problem

Postby Guest » Wed Jul 22, 2009 9:23 pm

Glad to know it is working..

 

At first I dont think the problem was the device but the conffigured load balance...

Well, since you wanted to have certain ammount of units in the network, per AP.  If the AP reaches that limit, any new association response will be responded with code 17 saying to the client "hey dude, im full, look for a different AP" its the client later again who decides either if it look for another one or keeps trying to associate to the same AP in the area...

 

 

This feature can be used in order to load-balance clients across LAPs       on a single controller. The clients select the AP based on the client       Signal-to-Noise Ratio (SNR) to that AP and the load-balancing window.

Aggressive load-balancing works at the association phase. If enabled       and the conditions to load-balance are met, when a wireless client attempts to       associate to a LAP, association response frames are sent to the client with an       802.11 response packet that includes status code 17. This code indicates that       the AP is too busy to accept any more associations.

It is the responsibility of the client to honor, process or discard       that association response frame with reason code 17. Some clients ignore it,       even though it is part of the 802.11 specification. The standard dictates that       the client driver must look for another AP to connect to since it receives a       "busy" message from the first AP it tries. Many clients do not do this and send       the association request again. The client in question is allowed on to the       wireless network upon subsequent attempts to associate.

The controller only sends one association response frame with reason       code 17 to the client. If the client decides to discard the reason code 17, the       client can try the same AP again and this time the AP allows the client to       complete the association.

If the client honors the association response status code 17, the       client then attempts to associate to a different AP. For example, if       load-balancing is enabled and the load-balancing window is configured as five       clients, when a sixth client tries to associate to the AP, the client receives       an 802.11 Association Response frame with status code 17, which indicates that       the AP is busy.

 

 

Here it is the link on how it works...

http://www.cisco.com/en/US/products/ps6366/products_tech_note09186a00809c2fc3.shtml

Guest
 

Re:HTC mobile phone access WLAN problem

Postby Guest » Wed Jul 22, 2009 11:00 pm

As your documentation suggests, subsequent retries should not be denied though... I think we see 5 rejections in a row on the same AP, when it really should have been accepted after 3 (as far as I understand).

 

Id suggest a TAC case to properly track this.Any chance we can get a wireless sniffer capture of when the client is associating?

Guest
 

Previous


  • Advertisement


Similar topics

Basic cisco ip phone configuration using CME
Forum: Cisco IP Communications
Author: boga83
Replies: 0

uc520 problem
Forum: Cisco IP Communications
Author: Guest
Replies: 0

nat problem with ver 8.4
Forum: Cisco Security
Author: Guest
Replies: 0

QoS on trunked access links
Forum: Cisco Switching
Author: Anonymous
Replies: 4

cannot call dn on a 7962 phone
Forum: Cisco IP Communications
Author: Guest
Replies: 1


Return to Cisco Wireless

Who is online

Users browsing this forum: No registered users and 2 guests