Forum

I have several sites of clients being "dropped" for no particular reason when using our PEAP authenticated network.
the interface looks like this:

dot11 ssid REDWLAN
vlan 262
authentication open eap peap_methods2
authentication network-eap peap_methods2
authentication key-management wpa optional

interface Dot11Radio0
!
encryption vlan 262 mode ciphers tkip wep128
!
broadcast-key vlan 262 change 300

Our clients use the Odyssey Access Client, which makes it impossible to use AES and WPA2

The clients connect just fine, but then sporadically, they lose their connectivity after a few minutes. Sometimes in as little as 2, sometimes as much as 15.

The same AP allows uninhibited connectivity on our GUEST network, which uses no encryption

Any information to help would be appreciated

When you say 2 or 15, do you mean seconds or minutes?

The 300 should be a seconds counter.

If you mean seconds, I would set the counter to 3000, and see if that changes things.

If you mean minutes, I would not expect changing that parameter to make a difference (because of the 15 minute case).

I am assuming that [b]all[/b] your clients can handle key rotation.

I am going to make the assumption that you are using Radius for your authentication server. If that is they case there is a session rekey option within the Radius configuration that you might need to modify. I was look at this especially if you don't have an mechanisms in place to assist with roaming. Hope that helps

[code]Our clients use the Odyssey Access Client, which makes it impossible to use AES and WPA2[/code]

Why is that impossible? Is it because it's been locked down, preventing the users from changing it? If not, the right profile needs to be set up on it.

Gentlemen

thank you all very much for the responses. This has given me a lot of things to look into.

Yes, we use RADIUS. it is running on a Cisco ACS box.

The rotation is 300 seconds. The time that the clients remain connected is between 2 and 15 minutes before they get "dropped"

The Odyssey Access Client is locked down for the client. But, on my machine I do not have that problem, yet I cannot find the settings for AES or WPA2.

The Juniper network support site wasNO help at all, because I did not have the license data.

I am in network support for GE. Not the licensing peeps.

We probably spend about a gazillion dollars a year with Juniper, but that doesnt get me the support I need.

Not having support under those circumstances is infuriating !

I suggest you somehow locate your people with the Juniper contacts, and either convince, bribe, or blackmail them to add your name to the official Juniper contact list to get you the support you need.

Assuming that your users are not roaming, the major difference that jumps out at me between the two networks WPA and Guest is the encryption in place. Typically the issues that would lead to disconnects would be issues with the rekey, (are you do any sort of roaming mechanism to help with that) CCKM, OKC etc. The other issue could be with ACS I am assuming you checked the option in ACS, see the excerpt below

*************
?PEAP session timeout (minutes) ?The maximum PEAP session length you want to allow users, in minutes. A session timeout value greater than 0 (zero) enables the PEAP session resume feature, which caches the TLS session created in phase one of PEAP authentication. When a PEAP client reconnects, CiscoSecure ACS uses the cached TLS session to restore the session, which improves PEAP performance. CiscoSecure ACS deletes cached TLS sessions when they time out. The default timeout value is 120 minutes. To disable the session resume feature, set the timeout value to 0 (zero).
*************
In addition not sure how long your dhcp leases are but I will just the time on those as well. Will check in with you later

So it is reproduceable in a short matter of time. That should make analysis easy.
Drops are most of the time caused by radius session timeouts, wlan session timeouts and group key updates / key rotation. you can check the session timeout and logging at the ACS. Check the log at the AP. Also, use a wireless sniffer to see what is preceding the deauth. Post your results please.

My problem is, the site I'm refering to is in Dallas and I'm in Cincinnati. Trying to troubleshoot the problem, over a remote scenario is difficult at best. I have to relay instructions to the on-site guy, who is not really an IT guy.
So, I'm awaiting a reply.

I do know that they have NO wireless sniffer.

Is there one that can be downloaded at no cost? Does anyone know?

> I do know that they have NO wireless sniffer.
>
> Is there one that can be downloaded at no cost? Does anyone know?

Sniffers are pretty dependent on drivers. Wireshark is an excellent open source sniffer, but you need compatible drivers. It wouldn't hurt to install it on a computer that is having the problem and start a capture. The guy in Dallas could send the pcap file to you for analysis.

Dan