cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9479
Views
0
Helpful
15
Replies

Passive Client vs User Idle Timeout

EvaldasOu
Level 4
Level 4

Hello !

I'm on WLC 5508 . It doesn't matter if passive client feature is turned on or turned off , when you try to increase "User Idle Timeout" you can see this message:

In our network, a lot of clients gets deauthenticated. I thought it would be useful to enable "Passive-client" feature, or increase "user idle timeout" , but how these works with each other?  

Thank you for your time and for your answers!

15 Replies 15

qili2
Level 1
Level 1

From the message, it seems the idle timeout was not the problem, the multicast configuration on the WLC is somehow conflict with the passive client feature...

http://www.cisco.com/en/US/docs/wireless/controller/7.2/configuration/guide/cg_wlan.html#wpmkr1410105

Check this page for the step by step configuration instructions please.

Thanks.

Mhm... maybe I need to change this mode Just can't do this right now, because wireless is on action

Thank you again,

but what's the difference between these two? If "passive client" feature is enabled, does it really cares "user idle timeout" configuration?

How passive client and user idle timeout work with each other?

Passive client, is for a client that has a static ip address but doesn't do anything until its triggered, like a wireless print server,

The WLC doesn't put a client into the RUN state until it has learned its ip address. Look at a client, say a laptop, even with a static ip will tend to be chatty and try to talk so the WLC learns its address. In the case of a "passive client", it stays quiet until it gets triggered which it can't do until the WLC leans the address and puts it in the run state.

Make sense?

Steve

Sent from Cisco Technical Support iPad App

HTH,
Steve

------------------------------------------------------------------------------------------------
Please remember to rate useful posts, and mark questions as answered

Hi Stephen.

There was an issue in our wireless lan. The clients was getting deauthentication frames few times a day. Sometimes there was everything ok. I thought if they are inactive, they get deauthenticated after some time ( 300 seconds by default?). (Mhm...or maybe this feature can't work with normal wifi clients, because they will try to generate some traffic anyway) ("Chatty" as you said )

So I thought we need to change something with "user idle timeout" or enable "passive client" feature. Users are using DHCP addresses.

Do you want to say that "Passive client" feature can't be a solution in this situation?

And if it is enabled and working with DHCP clients too, who are looking at "user idle timeout" settings?

Passive client shouldn't have any effect in that situation. User idle might, but most laptops tend to send enough packets with just exchange querries to keep a device on the network, so long as the lid doesn't get closed or it's not configured to sleep after x amount of idle time to save battery.

Inconsistent issues like this are hard to nail down as you can't find a client you know is going to have e issue and debug/ capture against it to help you.

You could try upping the user idle timer, but I'd also start looking for rogue AP as well, just to be safe

Steve

Sent from Cisco Technical Support iPad App

HTH,
Steve

------------------------------------------------------------------------------------------------
Please remember to rate useful posts, and mark questions as answered

edited

Wasn't passive client feature also a good (required) feature to enable for WGB devices and certain host OS's running guest OS's such as VMware, etc?

It wasn't required for WGB, as they work without it, as for VMware I'd have to think back on the issues between routed vs virtual mode(?) on the images

Steve

Sent from Cisco Technical Support iPad App

HTH,
Steve

------------------------------------------------------------------------------------------------
Please remember to rate useful posts, and mark questions as answered

Thank you. That's very valuable information for me!

Today I saw that just mobile phone devices gets deauthenticated. I found a vendors by looking at these mac addresses:

58:55:ca:xx:xx:xx - Apple Inc.

00:1f:3a:xx:xx:xx- Hon Hai Precision Ind.Co., Ltd. (related with foxxcon also)

8c:64:22:xx:xx:xx - Sony Ericsson Mobile Communications AB

00:23:6c:xx:xx:xx - Apple Inc.

20:d6:07:xx:xx:xx - Nokia Corporation

There is someting wrong with authentication. WLAN configuration:

Please take a look at these logs.

My buddy had an issue with WGB and static addresses, and passive client cured his problem.

As for this issue, when you say a lot of clients get deauth. Are these clients actually complaining there is a issue or are you seeing these deauth in a log and wondering whats going on ?

"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
___________________________________________________________

Hi George.

I can see in the logs that there is a problem. But now it looks that the problem is just with "mobile phone" devices Looks like client side related issues.

Both features are independent.

#as soon as wlc sees no activity from its connected client, user idle timeout will kick in, once expired it'll send a probe to client, on no response it sends deauth and remove the client.

#Passive client is a feature to better handle(wlc learn ip, proxy arp) silent/static client or wired client behind wgb.

#The passive client documentation is bit incorrect, the first arp request from wired side actually hit the passive client, only the consecutive arps are not and will be proxied by WLC. Once the ip learnt by wlc, the entry stays until wlc sends deauth for any reason. Think of like dynamic ip-mac filter for the passive client.

#Let say the static client connected to AP/WLC forwarding some traffic then the arp is learnt which is the normal scenario.

#Static client joined but doesn't send any traffic and no client trying to connect to this static client, two things can happen here, if client not sending data it could be sending null-data and the connection is preserved, if it shuts the radio to conserve power then user idle timeout kicks in.

#1 file - 'i think it is iphone'

user idle timeout expired: it can be taken care by increasing the user-idle timeout

(Cisco Controller) >*DHCP Socket Task: Apr 20 08:16:21.572: e0:ca:94:ad:b0:7e DHCP successfully bridged packet to STA

*spamApTask2: Apr 20 08:46:59.446: 8c:64:22:36:74:09 Received Idle-Timeout from AP e8:ba:70:53:4a:20, slot 0 for STA 8c:64:22:36:74:09

*spamApTask2: Apr 20 08:46:59.446: 8c:64:22:36:74:09 apfMsDeleteByMscb Scheduling mobile for deletion with deleteReason 4, reasonCode 4

*spamApTask2: Apr 20 08:46:59.446: 8c:64:22:36:74:09 Scheduling deletion of Mobile Station:  (callerId: 30) in 1 seconds

*osapiBsnTimer: Apr 20 08:47:00.298: 8c:64:22:36:74:09 apfMsExpireCallback (apf_ms.c:608) Expiring Mobile!

*apfReceiveTask: Apr 20 08:47:00.298: 8c:64:22:36:74:09 apfMsExpireMobileStation (apf_ms.c:5009) Changing state for mobile 8c:64:22:36:74:09 on AP e8:ba:70:53:4a:20 from Associated to Disassociated

*apfReceiveTask: Apr 20 08:47:00.299: 8c:64:22:36:74:09 Sent Deauthenticate to mobile on BSSID e8:ba:70:53:4a:20 slot 0(caller apf_ms.c:5094)

Broadcast key update issue: it can be taken care by increasing the bcast key rotation timeout.


*dot1xMsgTask: Apr 20 08:55:47.931: 8c:64:22:36:74:09 Updated broadcast key sent to mobile 8C:64:22:36:74:09

*osapiBsnTimer: Apr 20 08:55:49.130: 8c:64:22:36:74:09 802.1x 'timeoutEvt' Timer expired for station 8c:64:22:36:74:09 and for message = M5

*dot1xMsgTask: Apr 20 08:55:49.130: 8c:64:22:36:74:09 Retransmit 1 of EAPOL-Key M5 (length 131) for mobile 8c:64:22:36:74:09

*osapiBsnTimer: Apr 20 08:55:50.130: 8c:64:22:36:74:09 802.1x 'timeoutEvt' Timer expired for station 8c:64:22:36:74:09 and for message = M5

*dot1xMsgTask: Apr 20 08:55:50.130: 8c:64:22:36:74:09 Retransmit 2 of EAPOL-Key M5 (length 131) for mobile 8c:64:22:36:74:09

*osapiBsnTimer: Apr 20 08:55:51.130: 8c:64:22:36:74:09 802.1x 'timeoutEvt' Timer expired for station 8c:64:22:36:74:09 and for message = M5

*dot1xMsgTask: Apr 20 08:55:51.130: 8c:64:22:36:74:09 Retransmit failure for EAPOL-Key M5 to mobile 8c:64:22:36:74:09, retransmit count 3, mscb deauth count 0


invalid MIC error from client: This is an client driver issue.

*Dot1x_NW_MsgTask_4: Apr 20 11:50:31.256: 58:55:ca:0a:6f:4c Received EAPOL-key M2 with invalid MIC from mobile 58:55:ca:0a:6f:4c

*osapiBsnTimer: Apr 20 11:50:32.252: 58:55:ca:0a:6f:4c 802.1x 'timeoutEvt' Timer expired for station 58:55:ca:0a:6f:4c and for message = M2

*dot1xMsgTask: Apr 20 11:50:32.252: 58:55:ca:0a:6f:4c Retransmit failure for EAPOL-Key M1 to mobile 58:55:ca:0a:6f:4c, retransmit count 3, mscb deauth count 0

*dot1xMsgTask: Apr 20 11:50:32.253: 58:55:ca:0a:6f:4c Sent Deauthenticate to mobile on BSSID e8:ba:70:53:6f:10 slot 0(caller 1x_ptsm.c:534)

#2 file - 'looks like apple product too' - All deauths are due to invalid mic failure.

"Do you've client mfp enabled on WLAN - if so disable it"

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: