Hi all, we are using more terminal servers (2x Patton2800, 3x Cisco, 2xTC HiPer, 2xTC NETCard) all authorized by Merit Radius 3.6B starting from about 3 years ago without problems. Usernames and passwords (cca 4000) we have only in radius "users" files separated by prefix for each node. All used for PPP with PAP. All was working OK until we want move from plain text passwords to encrypted passwords now. Seems to be easy - just change item "Password=" to "Encrypted-Password=" and replace these password by encrypted ones. I have changed it so (I have a script which generate users files when needed from DB so only little change in this script). After this change - all these devices are authorizing with encrypted passwords without problems :-) - but TC :-( HiPer TC - first authenticating no user call at all... all authentications "FAILED". As I find soon it was caused by configuration authentication protocol = ANY and authentication preference = DEFAULT, I change it to =PAP, =PAP and now it seems to be working... NETCard TC - from begining was authenticating OK but NIGHTMARES came after a few hours - time to time radiusd started to answer all authentication requests as FAILED (also requests from non-TC nodes!). Only rescue from this state was kill and start again of radiusd. This state back again in time interval from a tens of second to tens of minutes after re-starting radiusd. Interesting also that radiusd accounting working still without problems in this state and also any user trying to login found in logfile - but unfortunately as FAILED of course :-(. When I next day check radiusd logfiles and find some dependency on these 21 crashes I found that every endless "FAILED" responses started exclusively by FAILED login of 3 same users on one of these our 2 TC Netcard nodes. Also I found that these users have set "using encrypted passwords" on they WinNT4 workstations or W95 (it means CHAP I thing). What strange NETCard send to radiusd what totaly confuse it??? So I try to change on NETCard PPP configuration like on HiPer above (...=PAP,...=PAP). After it I had tried by dialing from my friend (WNT,W95 fan :-) new configuration - esspecialy all these dirty CHAP,MS-CHAP setups and try to confuse my radius. Result of many dirty test setups seems to be a good - on these dirty calls TC never send even auth.request to radiusd at all and every call ended by timeout for dialing client. Also in logfile appeared change - there are no more any entry about so dirty call, only OK or FAILED of PAP authentications. But next day after some hours radiusd blocked again!!! Did anybody seen similar problem? What is buggy working with encrypted passwords and confusing - radius or NETcard? Notice that with plain text passwords and NETCard was never blocked into so state. Merit Radius 3.6B compiled and runing on Linux RH6.1 with kernel 2.2.13. Also interesting that same version of radius compiled and runing on Linux Slackware 3.5 kernel 2.0.35 working as "old backup radius" never blocked - even using same "encrypted" passwords. These 3 problematic users did not block same radiusd on Slackware system!!! Only FAILED and all was continue working without blocking!!! But system is overall old and I want to upgrade it :-( want not to leave radiusd there. So maybe also worst implementation of Merit radiusd on RH6.1 due to difference in system libraries etc... Due to all other types of terminal servers working with same configuration properly I thing that there may be something special on NETCard RADIUS protocol what Merit radius cannot process properly and what take place only in case when authenticating encrypted passwords. Are using someone other good-known, recomended or better configuration? On TC I have vendor extension disabled and also in "clients" file NETCard nodes presented only as NAT (should be better USR:NAT?), radius version set to 1 on both ends, USR_CCA in radiusd not compiled - is all it right or may be better? With plain passwords above was working good for me but maybe now should be altered... Any help welcomed! Thanks :-) Pavel - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.