1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Live trial and documentation offer

Discussion in 'TinyPEAP Firmware' started by scaron, Apr 5, 2005.

  1. scaron

    scaron Network Guru Member

    I need to setup an access point in a "hostile" environment. All clients will be wireless and the unit will be connected to the Internet using a static IP. There are presently 2 laptops and 4 tablet PCs (Acer TravelMate) to which we will add 10 more tablets in the next 6 weeks (in increments of 2 units per week).

    These clients will constantly be authenticated and deauthenticated as they either roam around the building (and drop in & out of range ) or go away to other premises.

    To get started, the only thing I really need is the ability to generate a certificate with a DNS name other than tinypeap.com. (It will not be convenient for me to try to install new certificates as this activity goes on for 18 hours per day and I almost never see some of these people).

    I need to produce a documentation for this project which I will gladly post here whenever I am finished.

    Whenever beta 3 ;-) is released I will need to demonstrate that I can swap units without having to reconfigure 16 machines and 20some users.

    Interested?

    Regards,
     
  2. tinyPEAP

    tinyPEAP Network Guru Member

    Sounds really interesting to me. Smile
    I'll have 2.3 out sometime this week, and that should have the
    functionality you need.

    One thing to keep in mind is that there's really no de-authentication.

    -tak
    tinyPEAP Development Team
     
  3. scaron

    scaron Network Guru Member

    OK. I got myself an older WRT54G on which I downloaded the latest 2.12 tinyPEAP : this unit will be used to downgrade from the 54GS just to see if the configuration cand be moved across two units.

    The use of the word de-authentification may not be appropriate. I can observe that clients disassociate from the AP and I presume that they need to authenticate again to gain access to the "media" whenever they associate with the AP again. This is easily tested by changing the credentials before allowing the unit within range of the AP.

    In fact, lack of a formal de-authentification may explain why access to media is still granted after a user has logged off a session (with the system still running, of course ;-0)

    In the meantime, I'll setup the test unit.

    Regards,
     
  4. tinyPEAP

    tinyPEAP Network Guru Member

    hi,

    I've updated tinyPEAP to 2.13 and it now supports Subject Alt. Name
    from the advanced menu.
     
  5. scaron

    scaron Network Guru Member

    OK: I have one WRT54G flashed with 2.13 and the first two tablet PCs configured and ready to go. Installation is tomorrow.

    BTW, what is the maximum length for User name and password strings in the tinyPEAP configuration page?

    Regards,
     
  6. scaron

    scaron Network Guru Member

    OK, after 1 week of testing with 2 units in the hostile environment, eveything seems to hold without issues.

    I do have problems in my control group. I do not use the DHCP server in this AP and the 4 machines get their configurations from the domain DHCP server. I can observe that units going in sleep mode authenticate properly with the AP whenever they wake up but do not successfuly retrieve a valid configuration if there is no other activity on the bridge (wired to wireless). For example, keeping an open SSH connection to the AP is enough to make the problem disapear. This "control" configuration does not have an active WAN connection, so this may be the root cause of this problem. In theory this should not affect the VLAN to ETH1 bridge but I had ample opportunity to observe this ondition this week.

    You have an opened question regarding the maximum length of the user name/password.

    How do I move the configuration from the WRT54GS to a Windows based server? Will copying /tmp/peapd/peapd.conf, /tmp/peapd/peapusers, /tmp/peapd/certs/cert.crt, and /tmp/peapd/certs/.private/pkey.pem to a Windows based machine running peapd-beta1 be enough (yes, I know, I would have to edit peadp.conf :))?

    Last, but not least, will the WPA code in the WRT54GS V1.1 and V2.0 authenticate properly with the peapd running on the Windows server.

    Regards,
     
  7. tinyPEAP

    tinyPEAP Network Guru Member

    Hi Scaron,

    Glad to hear back from you, and I apologize for your previous question being left out.
    The username/password can be set up to 256 chars on the web interface.
    Any input above will be truncated by snprintf.
    As for the validation phase, the strings of arbitrary length can be chosen at the moment and the memory spaces are dynamically allocated for them.
    However, from the next version on, the username/password will be truncated to 64 chars when the larger input is selected.

    For your first question, would you mind describing what 'sleep mode' means?
    To my knowledge, I have not seen my APs being inactive, and it is
    quite interesting to hear that authentication seems to be failing due to this problem.

    For Windows-WRT54G configuration issue, you guessed it right.
    And yes, you will need to configure peapd.conf but I don't think you'll have any problem with it.

    Lastly, WPA stuff with Windows binary should never have any problem
    as they are two separate issues. WPA will start either TKIP or AES encryption phase as soon as 802.1x authentication phase with tinyPEAP
    ends successfully, and I do not see the reason for failing in this particular
    senario that you mentioned.
    I will setup the environment when I get home and let you know the result though.

    thank you,

    -tak
    tinyPEAP Development Team
     
  8. scaron

    scaron Network Guru Member

    Hello again,

    In kind:

    "sleep mode" is stand by. On the AcerMate, there is a Zzz led :)

    "authentication issue": In my control group, one system is Windows XP SP1 English US with an 802.11b adapter. The typical situation is that the unit somehow loses the credentials: we can see it connect to the AP (and we can see that the AP lists the mac address of the connecting client on the wireless status page) but XP insists on entering the credentials again. Therefore, we can conclude that XP has already validated the AP certificate. I am upgrading this unit to XP SP2 (including all subsequent updates) m,ainly because the "repair" function (God!) in SP2 disables and re-enables the wireless card, forcing the authentication process and the display of the window allowing the user to enter the credentials again.

    However, the problem also occurs on SP2 systems. I do not see why XP would junk the credentials on its own. By, the way, is there a way to take advantage of the "authenticate as guest" feature of the 802.1X setup for the wireless card?

    Regards,
     
  9. tinyPEAP

    tinyPEAP Network Guru Member

    Hi,

    Seems like the problem occurs when there's no traffic across the AP and the units.
    Can't you setup cronjob that pings the broadcast address or something?
    It seems to me that the problem is native to the AP/units.

    I'm quite surprised by what you've observed in this 'authentication' issue.
    Your machines actually dump the previously enterred credentials?
    I've personally noticed that Windows machine do not ask for user credential once the information is cached and there's no way to clear it.
    There was actually a microsoft white paper in which one of the developer mentioned about the 'clearing cache' hack through registry.
    So I'm a bit puzzled here...

    Third, can you think of the situation where this 'guest' feature could be beneficial? The RFC (v0) does not explicitly prohibit this, (not sure in PEAPv2 as I haven't had a chance to read it),
    but I think it really defies the whole point of having PEAP.

    Lastly, I haven't had a chance to acquire the new G/GS routers.
    Will let you know the result although this problem should dissapear as
    soon as I finish the porting anyways.

    -tak
    tinyPEAP Development Team
     
  10. scaron

    scaron Network Guru Member

    Hello,

    1) I did not setup a cron job as this is my control group and I will bear with the annoyance just a bit longer ;-) until I have something to chew on

    2) Windows XP SP2 PRO does dump the credentials. We have been trying to understand under which conditions. So far we have not found anything that is reproducible at will. In particular, the problems occurs with roaming and non-roaming accounts, so this is not a simple question of missing information. The problem is mostly observed when the system is powered on in the morning. The problem does not appear to be related with the AP lockup documented in 1) above: the AP is on battery backup and power is only cycled when the unit locks up.

    3) We have already established that (in its infinite wisdom) XP runs with cached credentials once someone has authenticated with the AP unit. So, unless the user actually logs off and turn the power off on his system, you do not know for sure that the credentials being used for one connexion actually belong to the user currently logged on. So, the real question with the "guest" login is which credentials will be used. If these credentials are machine specific, then there is little difference between running the guest login and user credentials that cannot be traced to the real user. If "guest" credentials are domain specific (which I doubt) your are down to a kind of "Friend or Foe" authentication. Finally, if "guest" credentials are universal, but the domain can enforce a policy of mandatory user authentication on WI-FI access, you solve the roaming access problem (since user credentials no longer need to be cached on the system before successfull logon can occur) (which also mean that user profiles can be deleted from the system) and you force XP to authenticate with the AP using credentials from the currently logged on user. In my opinion, this is well worth investigating.

    Regards,
     
  11. scaron

    scaron Network Guru Member

    Hello,

    Some reproducible at will info on the AP lockup problem:

    1) Set up a wired connection to the AP (In my case WRT54GS). In these tests, I maintain a SSH connection open (no keepalives) and a browser open displaying the wireless status page.

    2) Log on a wireless system (XP Sp2 WPA/TKIP) and make sure you have network connectivity (ping the wired system, for example). Log off this system. Refresh the wireless status page on the wired system and verify that you have this single system listed.

    3) Log on a different wireless system (XP Sp2 WPA/TKIP) and make sure you have network connectivity. Do NOT log off this system. Refresh the wireless status page on the wired system and verify that you have both systems listed.

    4) Let the entire setup rest for 30 minutes. Refresh the wireless status page on the wired system and verify that you have only the logged on system listed. Verify that the SSH session is still active. Finally, verify that you do not have network connectivity on the logged on system. Typically, you should have a DHCP auto-configuration IP. No amount of repair (or just ipconfig/renew or disable/enable the network card) will restore network connectivity.

    5) Do "reboot" from the SSH session. After 30 seconds to a minute, verify that network connectivity is restored to the logged on system. Refresh the wireless status page on the wired system and verify that you have both systems listed. Ping the other wireless system from the wired system and verify that you do NOT have network connectivity to the logged off system. This is exactly the expected behavior since XP should not be trying to authenticate in the logged off state.

    It would seem that going to / coming out of StanBy is an issue in itself either because it sends the AP in a wrong state or because the authentication needed to restore network connectivity is improperly handled. Also, pinging the broadcast address is not valid on this AP. Pinging the default gateway is about the same as maintaining an open SSH session with keep alives on the unit. I will try again later with keepalives set at 15 seconds.

    Regards,


    Regards,
     
  12. scaron

    scaron Network Guru Member

    OOPS ;-)

    I forgot the most important in point 5 of my last post. Although the logged off sytem has remain untouched througout the test, you CANNOT establish network connectivity when you log back on the system. If you doubleclick on the wireless network icon in the status bar and "view available wireless network" you will see that you are in the state "validating network identity" (liberal translation from the French XP SP2). The only way to restore network connectivity is to to a manual disconnect followed by a manual connect. No network credentials will be asked and the system will acquire an IP via DHCP, demonstrating that network connectivity is established.

    Please remember that, in these tests, the AP has been rebooted and is being accessed by the second system, demonstrating both wired and wireless access. There should be no difference if a user is logging on from a system that is booting up or from a system that has been left idle for a while waiting for the "three finger salute" (CTRL-ALT-DEL). I believe this is an authentication issue (PEAP or yours :)).

    Regards,
     
  13. tinyPEAP

    tinyPEAP Network Guru Member

    hi,

    Sorry for the slow reply.
    These are some interesting observations.
    Let me follow up in detail when I get home today.

    -tak
     
  14. tinyPEAP

    tinyPEAP Network Guru Member

    okie,

    Let's start with some terminology clarification as I am a bit confused.
    Log on a wireless system => an XP machine authenticating to tinyPEAP enabled WRT54G
    Log off from wireless network => a user of XP machine logging off
    you log back on the system => a user re-logging into an XP machine


    If I understand those terminologies listed above correctly, there may be a problem in our implementation.
    tinyPEAP itself does cache who has tried to authenticate and this cache
    also stores the state of the user.
    I will go back to the codes and see if I can find any glitches.

    As for the other open question about WRT54G/WPA + windows machine hosting tinyPEAP,
    the experiment seemed successful on my WRT54GS1.0 (as expected).
    Did you encounter any problems with this particular setup?

    Lastly, there has been a report from a writer from ZDNet about WRT54G being a bit unstable.
    According to him, the stability of passing/translating RADIUS packets are questionable and he has suggested to implement a cronjob
    which resets the router everyday at 4am (or any other appropriate time)
    Do you have any suggestion on this issue?
    Personally, I share the same feeling and I'm going to implement this unless you have some strong objection.

    -tak
    tinyPEAP Development Team
     
  15. scaron

    scaron Network Guru Member

    Hello,

    As far as terminology is concerned, I try to stick as close to MS standards as possible.

    Therefore

    1) log on to Windows XP means the actual logon process, that is entering the Windows XP user name, password, and domain. Wheter the system has valid credentials for tinyPEAP is irrelevant in this sentence. The PEAP authentication is implied if successfull network connectivity is verified. The credentials are presumed to be different than the user name, password, and domain used to logon the user. As far as can be observed, Windows XP SP2 explicitly asks for credentials if none are found in the cache.

    2) log off Windows XP means the actual logoff process (Start, Log OFF). As stated elsewhere, this does not de-authenticate the user with the AP and traffic is still allowed back and forth between the system and the AP.

    3) log back on the system means a new (successfull) logon. The PEAP credentials for this user may not be the same as those of the previous user (if any) of the system.

    Finally, I am unconcerned with the so-called "stability issue" of the wrt54gs v1.0. I can verify that a system authenticate properly with tinyPEAP and still fail to get DHCP data if the DHCP server is disabled on the AP and a DHCP server from the wired LAN is being used. All your cronjob will do is mask the problem if the frequency of error is less than once per 24 hours (for example). If the issue is network related (as I suspect it is) you will sove nothing. In the sample benchmark that I have setup for you using a WRT54GS v1.0, the problem occurs within 30 minutes. So, you can say that I have a "strong objection".

    Did you setup your test exactly as indicated (one WRT54GS v1.0, one wired system, 2 wireless systems). Obviously, I did not indicate that the wired system was providing DHCP: my mistake :-(.
     
  16. scaron

    scaron Network Guru Member

    Follow up:

    I now have 10 Acer TravelMates in my test group. This group is running from a WRT54G, not a GS. I do not observe in this group the same issues that I have in the control group running from a WRT54GS.

    In particular, it is becoming more and more obvious that a system that becomes idle for a long period a time (more than 15 minutes) does not have the same difficulties on the 54G than on the 54GS. Note that the Acer system enter ACPI stand-by mode much more quickly than a regular desktop machine with a wireless PCI card. However, those Acer that are brought up from the ACPI stand-by mode seem to be able to reconnect with the AP. Also, in my test group, the AP is the DHCP server AND the Internet gateway: this setup is more in line with your expected target market.

    Is there a way to obtain more sysloging information from tinyPEAP?

    Regards,
     
  17. tinyPEAP

    tinyPEAP Network Guru Member

    Hi,

    Thanks for the clarification in terminology.
    Unfortunately, there's no syslogs which can be obtained from tinyPEAP.
    (although we should)

    >I can verify that a system authenticate properly with tinyPEAP and still fail to get DHCP data if the DHCP server is disabled on the AP and a DHCP server from the wired LAN is being used.

    I'm a bit confused in what you are saying here. If you can reproduce the problem above, will you manually assign an ip address on the client machine, and see if the communication takes place?
    Mixing DHCP issue and tinyPEAP issue will only complicate the matter, and I'd like to straighten this up.

    For the weirdness with WRT54G/GS, I'm not too sure how to express my confusion. :p
    Is it possible to have your WRT54G from test-bed on the original setup?
    If the problem is caused through the model related issue,
    there's not much that can be done on my side.
    I personally cannot think of any advantage/disadvantage from the response time of your ACPI.

    -tak
    tinyPEAP Development Team
     
  18. scaron

    scaron Network Guru Member

    Lets clarify your first source of confusion.

    The WRT54GS unit is configured with NO services running other than tinyPEAP. That is, no DHCP server and no DNS forwarding among other things. Further, the unit is not connected to the Internet, as stated elsewhere, so there is no NAT or firewall service used either. There is one wired connection on the LAN side. Think of this unit as only a bridge where wireless access is controlled by tinyPEAP.

    In this configuration, successfull PEAP authentication gives you access to the media. Every other form of services (starting with DHCP) is provided by some machine on the wired side. In the statement that has you confused, I am saying that the Windows XP system appears to authenticate successfully with the AP but data does not pass through the brdige, starting with a simple DHCP broadcast.

    This configuration is designed to highlight such issues. Note that since you have stated that tinyPEAP does not syslog authentication attempts, I have added an alternate IP configuration on one of the wireless system in my control group. When the AP enters the "weirdness" state to use your vocabulary, I can verify that Windows XP SP2 displays the status of the wireless link as "connected" while using the alternate IP configuration. I can also verify that no data is passing between the system and the AP.

    Therefore, in the absence of logging information that would demonstrate that authentication actually took place, I must conclude that the status information provided by XP SP2 is in error and that in the "weirdness" state, the AP is just a fancy paper weight ;-).

    Now, for your second source of confusion.

    ACPI issues all relate to various information caches used in this scheme. I do not know what XP SP2 does when going into or coming out of stand-by mode. (Just in case, I keep the "Fast Reconnect" checkbox cleared on all systems.) The cache will probably be stale if the system is in stand by mode for a long while. The same observation holds for the cache in tinyPEAP. Finally, I can observe that Windows XP SP2 drops the credentials when tinyPEAP is active and authentication fails.

    The behavior is exactly the same as if the user had been deleted from the AP. Again, it is not presently possible to see witch part of the authentication is failing since there is no logging on either your side or XP's side.

    As for the issue being model related, we will have to wait until I can run tinyPEAP on the latest SveaSoft firmware. By the way, the new firware is probably packed and I would expect that there is no room for tinyPEAP. Therefore you will have to hack some utilities out of it. What are you plans in this area? I believe I have thrown enough resources your way to merit an intelligent answer.

    Regards,
     
  19. cuzzindavid66

    cuzzindavid66 Network Guru Member

    Does TinyPEAP work on WAP54G?

    Hi I'm a bit confused...can I install TinyPEAP to a Linksys WAP54G ver2? If so do I use the Linksys GUI (Help page) to upload the software? I have tried several times and it fails. I have even downloaded a "tftp" executable and used the command line which comes back with a small gui asking for the IP, password and what file. Is there a particular extension the file is supposed to have? HELP
     

Share This Page