Strange WPA Enterprise issue

Forums Network Management ZeroShell Strange WPA Enterprise issue

  • This topic is empty.
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #40768

    I’ve been trying to get WPA Enterprise working for a few hours now with a friend of mine I work with. We are actually attempting to use Zeroshell for a network of APs for a wireless network that was put together “on the cheap” using Linksys WRT54GS series hardware.

    Yes, I followed the guide I wrote months ago. 🙂 The biggest difference I can see is that we’ve used Zeroshell beta 5 and beta 6. (Only difference is that beta 5 has one extra log line: TLS_accept:error in SSLv3 read client certificate A )

    We are getting authenticated successfully and can surf the net, but within a minute or two it appears that we are getting kicked out by the access point. Here’s a piece of the radius log:

    17:05:06 rlm_eap_mschapv2: Issuing Challenge
    17:05:06 Login OK: [boatrbw] (from client localhost port 0)
    17:05:06 Login OK: [boatrbw] (from client Cassat port 52 cli 009096a9ab76)
    17:06:29 rlm_eap_mschapv2: Issuing Challenge
    17:06:29 Login OK: [boatrbw] (from client localhost port 0)
    17:06:29 Login OK: [boatrbw] (from client Cassat port 52 cli 009096a9ab76)
    17:08:43 rlm_eap_mschapv2: Issuing Challenge
    17:08:43 Login OK: [boatrbw] (from client localhost port 0)
    17:08:43 Login OK: [boatrbw] (from client Cassat port 52 cli 009096a9ab76)
    17:10:11 rlm_eap_mschapv2: Issuing Challenge
    17:10:11 Login OK: [boatrbw] (from client localhost port 0)
    17:10:11 Login OK: [boatrbw] (from client Cassat port 52 cli 009096a9ab76)

    Each time listed above where we logged in is actually a re-login. We’ve been kicked between each of these logins.
    We’ve tried different physical access points, different client machines, but it still fails very much the same way. We have tried both DD-WRT and the stock Linksys firmware with the same results. (In my home network, I only used DD-WRT for demonstration purposes. My production access point is an Airport.)

    Any ideas what I’m doing wrong?


    Just to add a bit more information: Most of the time, there is only a very tiny window of time from when the connection is authenticated that websites or even pings will work. Sometimes it is only a few seconds, other times a minute or more. Then, the workstation will start re-attempting authentication.


    I get the following from my SysLog Server. If you notice the last line, which states successful authentication. I dont see that in your logs. Seems the station authenticates the server but when the server is supposed to authenticate the station, you’re not proceeding any further in the handshakes.

    Sep-11-2007 11:54:01 PM Daemon.Info XX.XX.XX.XX UDP radiusd[3503]: rlm_eap_mschapv2: Issuing Challenge

    Sep-11-2007 11:54:01 PM Daemon.Notice XX.XX.XX.XX UDP radiusd[3505]: Login OK: [UUUUUUU] (from client localhost port 0)

    Sep-11-2007 11:54:01 PM Daemon.Notice XX.XX.XX.XX UDP radiusd[3501]: Login OK: [UUUUUUU] (from client PPPPP port NN cli MMMMMMMMMMMM)

    Sep-11-2007 11:54:01 PM User.Notice XX.XX.XX.X UDP 802.1X: PEAP: “UUUUUUU” successfully authenticated on Access Point XX.XX.XX.XX

    The certificates are passed first (I believe) which you are logging in ok, so I believe the problem must lie in the username/password. Too long, ascii chars? Just to be thorough try using a simple username, with a simple password with only letters and numbers.

    I used your guide Paul to setup my own ZeroShell setup so excuse me if I’m being too elementary. Just trying to tease your brain, I’m sure you’ll figure it out.

    Furthermore, that error you’re getting in version 5 just means you’re not using a client certificate as you would if you were using TLS as an auth protocol. Using TTLS or PEAP gives you this error but is perfectly normal and is just a note that there is no client cert. of which there is supposed to be none.

    Personally using Beta6 with WPA2 Enterprise
    Buffalo AP with DD-WRT Firmware
    Vista and XP clients


    I’m pretty sure I’m getting those messages too, but they are in the 802.1X log in Zeroshell. (I only copied a piece of the radiusd log)

    Authentication would seem to be completing, but the session only stays up for mere seconds, no matter how close the client is to the AP…



    I’m back at work and verified that I am seeing those messages in the 802.1X log that match up with the radiusd log.


    One other unusual thing about this setup: I’m using public IP Addresses on zeroshell and the access points.

    I don’t really see how this could cause this behavior, but today I loaded my home config on the zeroshell machine at work and we created a lab environment that pretty much matched my home, as far as IP Addressing goes. It worked fine with our test hardware (laptop, AP, and Zeroshell server).

    We then moved it to our production network, changed the IP Addressing of the zeroshell machine and the AP to public IPs and modified the Access Point section in Zeroshell to use the new (public) IP address of the AP (keeping a simple test shared secret) and pointed the AP to the new (public) IP of the zeroshell machine. Logging in via wireless would result in a connection for only a few seconds. I could actually get a few pings from the wireless client to the zeroshell server, then it would drop off.

    After this failure, I tried this test:
    1. I enabled the DHCP server on the AP
    2. I attached zeroshell directly to one of the Ethernet ports on the AP
    3. I enabled the NTP server on zeroshell
    4. I configured the AP to use zeroshell as its NTP source
    5. I disconnected the link to the production network

    In this scenario, the production Ethernet switches are out of the loop, as is all Internet connectivity. In this case, the laptop would connect, grab an IP Address from the AP, get a few pings and replies from the wireless client to zeroshell, then lose connectivity.

    So, at this point, I’ve eliminated hardware (since it worked fine with my original configuration using private IP Addresses, and the production hardware is not in use). Very minimal config changes were made to move the config to public IP Addresses. I don’t see how private vs. public addresses would cause this problem…

    Why isn’t this working??? Anyone else using public IPs on the zeroshell and their AP’s?


    We still haven’t completed sorted this issue, but I’m starting to think it has something to do with interference. In a different office a good distance away from the rest of the APs, we can get WPA authentication via Zeroshell and the Linksys WRT54GS, and it stays up just fine.

    Anyone have any suggestions for good replacement APs that have worked well in a decent sized environment w/ WPA Enterprise authentication?


    If interference is that bad, try changing the channel on your access point. You stated in your first post you tried different access points with the same result, so I wouldnt be so quick to blame the quality of the AP. Try changing the channel and see if maybe a higher gain antenna will override this interference.

    I live in NYC and I can clearly see 25 APs from my apartment with Netstumbler. Setting my AP to channel 1 makes my connection very unstable although channel 11 for me is rock solid.


    Well, we figured the problem out. I wish I could say it was some obscure setting on the AP, or a problem with the test client machines, but it was actually really not that hard…

    Network Operations is evaluating a product called “Air Defense”, which they thought was running in a passive mode, only listening and reporting on things it heard, like an IDS. But, today we discovered that the Air Defense sensors were actually taking action to terminate the connections of these “rogue” Access Points… Turn off the nearby Air Defense sensor, and suddenly the wireless connections on our test units were rock solid using WPA Enterprise security. The fact is, the area we were testing my home configuration didn’t have a sensor nearby, so it worked great. So, I changed the IP addressing to match our production environment and moved the equipment to where it would actually operate, the sensor would see our “unauthorized traffic” and knock us off every time.

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.