Hi Mike, Hugh, and others, I have three questions. Please forgive me if some may look too obvious since I am new to RADIUS:
1. In your test for the Orinoco product(s), did you test for AP-500 and AP-1000? For the Orinoco APs, can you post the attributes to be passed to RADIUS for authentication and the reply message (attributes)? In particular, the test on 802.1X --- I am still not clear about the "EAP_Message" and "Message_Authenticator". In any event, I wonder whether level 4/5 trace log output example will suffice to answer this question. 2. I wonder you or anyone in the list can help and/or comment the best way to do the following: <NAS ADR_1> <NAS ADR_2> ... <NAS ADR_k> <AuthBy Opt_1> <AuthBy Opt_2> ... <AuthBy Opt_w> I would like NAS in ADR_1 to be authenticated through <AuthBy Opt1>, and if it does not succeed, try <AuthBy Opt2>. For ADR_2, have it authenticated through <AuthBy Opt_w>, and if not successful, try <AuthBy Opt_1>, and if still not successful, then <AuthBy Opt_2>. This situation will araise when RADIUS is running properly, but the DB in one AuthBY fails, then we want RADIUS to use the DB in an alternative site, thus switching to another AuthBy. My question is: What is the best way to set up the conf file for this situation? 3. When AuthBY SQL, is there a way not to expose the DB access information? I am particularly concern the need of storing DB acccess information in the conf file (and the Unix environment variable such as ORACLE_USERID in the initialization file for Perl DBI). Since the DB access will require more than just DML query, but also transaction involving insert, update and delete, if RADIUS or conf file got compromised, one will have all the information needed to do damage on the DB side. Thanks in advance! Bon On Sat, 21 Sep 2002, Mike McCauley wrote: > Hello All, > > We have just finished local testing of Radiator 3.1.1 with Orinoco AP-2000 > Access Points. We tested successfully witha range of authentication methods, > wireless clients and platforms. > > One important point to note is that successful interoperation with the Odyssey > TTLS client requires that the access point have the latest firware > v2.0.0(266). > > Feedback to me. > Cheers. > > > -- > Mike McCauley [EMAIL PROTECTED] > Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW > 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au > Phone +61 3 9598-0985 Fax +61 3 9598-0955 > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > TTLS etc on Unix, Windows, MacOS etc. > > === > Archive at http://www.open.com.au/archives/radiator/ > Announcements on [EMAIL PROTECTED] > To unsubscribe, email '[EMAIL PROTECTED]' with > 'unsubscribe radiator' in the body of the message. > === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.