- Freeradius-Users - lists.freeradius.org

accounting analysis
by Marc-Henri Boisis-delavaud 22 Sep '05

22 Sep '05

Hello do you a free tool to generate analysis from freeradius accounting ? ----------------------------------- Marc

2 1

RE: cannot return access accept from proxy to client
by Wilson Lie 22 Sep '05

22 Sep '05

I suspect that the freeradius will return failed at once when "username" attribute is not found and because the username attribute won't be included in the "access-accept' packet . The "sql" can be executed successfully when host B acts as authentication server. So maybe I should ask can freeradius be configured as both authentication server and proxy server at the same host ? Hope someone can help on this. Many thanks! ================================================================ You should make the SQL query so that it won't make an error when certain attributes are not present or empty. See the example sql.conf file. Turn sql traces on and run in debug mode to see what queries are done. Check why they are failing and correct the queries. -- Groeten, Regards, Salutations, ____________________________________________________________ (c) 2005 Interactive Technology Holdings Limited Group. All rights reserved. CONFIDENTIALITY: This communication and any attachment(s) is intended solely for the person or organisation to which it is addressed and it may be confidential. This communication may contain confidential or legally privileged material and may not be copied, redistributed or published (in whole or in part) without our prior written consent. This communication may have been intercepted, partially destroyed, arrive late, incomplete or contain viruses and no liability is accepted by any member of the Interactive Technology Holdings Limited Group as a result. If you are not the intended recipient, employee or agent responsible for delivering the message to the intended recipient you must not copy, disclose, distribute or take any action in reliance on it. If you have received this communication in error, please immediately reply and highlight the error to the sender immediately and destroy the original from your computer.

2 1

PEAP Public_key_exchange padding
by Juan Daniel Moreno 22 Sep '05

22 Sep '05

Hi, I am using a freeRadius 1.0.4 and I would like to know something about client_key_exchange(). Into this function it is necessary to specify a padding system that the server accepts. My question is, which of these paddings: RSA_PKCS1_PADDING RSA_PKCS1_OAEP_PADDING RSA_SSLV23_PADDING RSA_NO_PADDING is accepted by freeRadius 1.0.4? Thank you very much. Juan Daniel MORENO

2 1

RE: custom variable in config files
by Tariq Rashid 22 Sep '05

22 Sep '05

i'm having a go at cracking this problem. i've discovered that any variable declared in radiusd.conf (var = abc) cannot be expanded when used in $INCLUDED files ( ${var} ) ... i'm seeing that during the search for the $var in the linked list of variables ... the list (known as main) used for the included files is not the same one as the one used for variables created in radiusd.conf. that is: * if i delcare aaa, bbb, ccc in radiusd.conf * and i declare xxx, yyy, zzz in proxy.conf * then trying to search for ${ccc} in proxy.conf actually traverses xxx, yyy, zzz and NOT aaa, bb, ccc so far i think i am seeing the item pairs being added to the wrong list and not appended to the proper list? can a more experienced developer have a look to confirm? i'm doing this using a combination of radlog() and ddd. also - why the need for "lineno" in the config item data structures? surely this is a bad idea - and prone to error when inlcuding files? what's the lineno for included files? tariq -----Original Message----- From: freeradius-users-bounces(a)lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org]On Behalf Of Alan DeKok Sent: 15 September 2005 18:56 To: FreeRadius users mailing list Subject: Re: custom variable in config files "Tariq Rashid" <tariq.rashid(a)uk.easynet.net> wrote: > thanks for the suggestion and clarification. trying what you suggested gives me ... > > Config: including file: /opt/freeradius102/etc/raddb/proxy.conf > config: No such entry network_address for string ${network_address}.126:1812 > Errors reading radiusd.conf Ah... I ran into that the other day. Expanding configuration variables in $INCLUDE'd files may not work, and I'm not sure why. It's a bug. Alan deKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

1 0

Erratic EAP/TLS authentication problems
by Jim Potter 22 Sep '05

22 Sep '05

Hi all, I've got a debian freeradius (1.0.3 with EAP compiled in) server which is being erratic - I can't really identify where the problem is, in that it works fine for about 90% of requests, and fails the rest - I know this is very vague, but has anyone else had similar experiences, or would anyone who has this running successfully be prepared to send me a copy of their config files. thanks in advance Jim Potter -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

choosing userprofile by NAS
by Florian Prester 22 Sep '05

22 Sep '05

Hi, how can I serve different information to the same user depending on the Huntgroup having all information stored in a LDAP-server? meaning: userA logging in NAS_A: receives IP-A supplied by LDAP userA logging in NAS_B: receives IP-B supplied by LDAP -- ---------------------------------------------------------- Dipl. Inf. Florian Prester Network Administration Regionales RechenZentrum Erlangen Universitaet Erlangen-Nuernberg Germany Tel.: +499131 8527813

1 0

Re: Freeradius and PPPoe Server ?
by Paweł Małkowski 22 Sep '05

22 Sep '05

2005/9/19, Charles Price <charlie.price(a)w3z.co.uk>: > No, you wouldn't. You would like to use pppd on your linux machine as a > client. Windows XP talks to pppd (through pppoe-server) - and pppd talks to > freeradius. All freeradius does is make decicsions on behalf of pppd - your > PPPoE clients should not even be aware of it! > sorry, but I don't understand you :( Could you explain this to me once again ? What should I do to login with WIndows to freeradius (throught ppp) ? -- Pawel volfen Malkowski

1 0

access-accept
by Callis 21 Sep '05

21 Sep '05

Hi, I have successfully configured my radius server but when i put it in debug mode to test i do not see it sending access-accept to radius packets. I have looked through the radiusd.conf but can not find anything there. Am trying to run my server in debug mode to solve a problem on my cisco AS5300 which seem not see the accept response from the server. Can anyone help me to solve this problem? Thank you.

2 1

Re: EAP/TLS PEAP on Suse 9.3 Ldap backend eDirectory
by Daniel Hesse 21 Sep '05

21 Sep '05

cant seem to make it send the whole log RALINK SUPPLICANT....last try rad_recv: Access-Request packet from host 10.10.4.20:2543, id=212, length=123 NAS-IP-Address = 10.10.4.20 NAS-Port-Type = Wireless-802.11 NAS-Port = 0 Framed-MTU = 1400 User-Name = dhesse Calling-Station-Id = 001109229950 Called-Station-Id = 000e6acd7ff5 NAS-Identifier = dhlab_3com EAP-Message = 0x0201000b01646865737365 Message-Authenticator = 0xf3433859c74cded00607917bab4695f2 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module preprocess returns ok for request 0 modcall[authorize]: module chap returns noop for request 0 modcall[authorize]: module mschap returns noop for request 0 rlm_realm: No '@' in User-Name = dhesse, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop for request 0 rlm_eap: EAP packet type response id 1 length 11 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module eap returns updated for request 0 users: Matched entry DEFAULT at line 152 modcall[authorize]: module files returns ok for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for dhesse radius_xlat: '(uid=dhesse)' radius_xlat: 'o=StormLake' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to gwfs1.mmrcsl.org:389, authentication 0 rlm_ldap: setting TLS CACert File to /etc/raddb/certs/mmrc-ca.b64 rlm_ldap: setting TLS Require Cert to demand rlm_ldap: starting TLS rlm_ldap: bind as cn=radical,o=StormLake/g0usa^ to gwfs1.mmrcsl.org:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in o=StormLake, with filter (uid=dhesse) rlm_ldap: Added the eDirectory password in check items rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user dhesse authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module ldap returns ok for request 0 modcall: group authorize returns updated for request 0 rad_check_password: Found Auth-Type EAP auth: type EAP Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module eap returns handled for request 0 modcall: group authenticate returns handled for request 0 Sending Access-Challenge of id 212 to 10.10.4.20:2543 EAP-Message = 0x010200061920 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xd42ed53b218b1d136112f3f7e82b0a57 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 212 with timestamp 43318085 Nothing to do. Sleeping until we see a request. rad_recv: Access-Request packet from host 10.10.4.20:2545, id=213, length=123 NAS-IP-Address = 10.10.4.20 NAS-Port-Type = Wireless-802.11 NAS-Port = 0 Framed-MTU = 1400 User-Name = dhesse Calling-Station-Id = 001109229950 Called-Station-Id = 000e6acd7ff5 NAS-Identifier = dhlab_3com EAP-Message = 0x0201000b01646865737365 Message-Authenticator = 0x8d112d0f7b1bc7d921e7d92af52bd2e6 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 1 modcall[authorize]: module preprocess returns ok for request 1 modcall[authorize]: module chap returns noop for request 1 modcall[authorize]: module mschap returns noop for request 1 rlm_realm: No '@' in User-Name = dhesse, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop for request 1 rlm_eap: EAP packet type response id 1 length 11 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module eap returns updated for request 1 users: Matched entry DEFAULT at line 152 modcall[authorize]: module files returns ok for request 1 rlm_ldap: - authorize rlm_ldap: performing user authorization for dhesse radius_xlat: '(uid=dhesse)' radius_xlat: 'o=StormLake' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in o=StormLake, with filter (uid=dhesse) rlm_ldap: Added the eDirectory password in check items

1 0

Re: EAP/TLS PEAP on Suse 9.3 Ldap backend eDirectory
by Daniel Hesse 21 Sep '05

21 Sep '05

HMMMM only part of the log was included....strange!!! here it is again WINXP TLS_accept: SSLv3 read client key exchange A rlm_eap_tls: <<< TLS 1.0 ChangeCipherSpec [length 0001] rlm_eap_tls: <<< TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 read finished A rlm_eap_tls: >>> TLS 1.0 ChangeCipherSpec [length 0001] TLS_accept: SSLv3 write change cipher spec A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 write finished A TLS_accept: SSLv3 flush data (other): SSL negotiation finished successfully SSL Connection Established eaptls_process returned 13 rlm_eap_peap: EAPTLS_HANDLED modcall[authenticate]: module eap returns handled for request 2 modcall: group authenticate returns handled for request 2 Sending Access-Challenge of id 180 to 10.10.4.20:2500 EAP-Message = 0x0104003119001403010001011603010020fb444951ea0360a043b79a34ac4ca533ae9744e6dc6fd7cda10c7b0470fbc55b Message-Authenticator = 0x00000000000000000000000000000000 State = 0xd86ec63a7680f4308aeb922aa999e201 Finished request 2 Going to the next request --- Walking the entire request list --- Waking up in 5 seconds... rad_recv: Access-Request packet from host 10.10.4.20:2501, id=181, length=136 NAS-IP-Address = 10.10.4.20 NAS-Port-Type = Wireless-802.11 NAS-Port = 0 Framed-MTU = 1400 User-Name = dhesse Calling-Station-Id = 001109229950 Called-Station-Id = 000e6acd7ff5 NAS-Identifier = dhlab_3com State = 0xd86ec63a7680f4308aeb922aa999e201 EAP-Message = 0x020400061900 Message-Authenticator = 0x76ad5ea260dbcc6ec8c011c9c7faa527 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 3 modcall[authorize]: module preprocess returns ok for request 3 modcall[authorize]: module chap returns noop for request 3 modcall[authorize]: module mschap returns noop for request 3 rlm_realm: No '@' in User-Name = dhesse, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop for request 3 rlm_eap: EAP packet type response id 4 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module eap returns updated for request 3 users: Matched entry DEFAULT at line 152 modcall[authorize]: module files returns ok for request 3 rlm_ldap: - authorize rlm_ldap: performing user authorization for dhesse radius_xlat: '(uid=dhesse)' radius_xlat: 'o=StormLake' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in o=StormLake, with filter (uid=dhesse) rlm_ldap: Added the eDirectory password in check items rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user dhesse authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module ldap returns ok for request 3 modcall: group authorize returns updated for request 3 rad_check_password: Found Auth-Type EAP auth: type EAP Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 3 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Received EAP-TLS ACK message rlm_eap_tls: ack handshake is finished eaptls_verify returned 3 eaptls_process returned 3 rlm_eap_peap: EAPTLS_SUCCESS modcall[authenticate]: module eap returns handled for request 3 modcall: group authenticate returns handled for request 3 Sending Access-Challenge of id 181 to 10.10.4.20:2501 EAP-Message = 0x0105002019001703010015bc0c8b230b6818687fdf49953a86ea2a7c92d8f0be Message-Authenticator = 0x00000000000000000000000000000000 State = 0x34fc3101d2597dcae9f02eb68c529953 Finished request 3 Going to the next request Waking up in 5 seconds... rad_recv: Access-Request packet from host 10.10.4.20:2502, id=182, length=164 NAS-IP-Address = 10.10.4.20 NAS-Port-Type = Wireless-802.11 NAS-Port = 0 Framed-MTU = 1400 User-Name = dhesse Calling-Station-Id = 001109229950 Called-Station-Id = 000e6acd7ff5 NAS-Identifier = dhlab_3com State = 0x34fc3101d2597dcae9f02eb68c529953 EAP-Message = 0x02050022190017030100171d156bb7f6783f7d189e1907099a9fa7309a04e469c5b1 Message-Authenticator = 0xe538669776929af733db5ebd93558b24 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 4 modcall[authorize]: module preprocess returns ok for request 4 modcall[authorize]: module chap returns noop for request 4 modcall[authorize]: module mschap returns noop for request 4 rlm_realm: No '@' in User-Name = dhesse, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop for request 4 rlm_eap: EAP packet type response id 5 length 34 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module eap returns updated for request 4 users: Matched entry DEFAULT at line 152 modcall[authorize]: module files returns ok for request 4 rlm_ldap: - authorize rlm_ldap: performing user authorization for dhesse radius_xlat: '(uid=dhesse)' radius_xlat: 'o=StormLake' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in o=StormLake, with filter (uid=dhesse) rlm_ldap: Added the eDirectory password in check items rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user dhesse authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module ldap returns ok for request 4 modcall: group authorize returns updated for request 4 rad_check_password: Found Auth-Type EAP auth: type EAP Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 4 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS eaptls_verify returned 7 rlm_eap_tls: Done initial handshake eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: Identity - dhesse rlm_eap_peap: Tunneled data is valid. PEAP: Got tunneled identity of dhesse PEAP: Setting default EAP type for tunneled EAP session. PEAP: Setting User-Name to dhesse Processing the authorize section of radiusd.conf modcall: entering group authorize for request 4 modcall[authorize]: module preprocess returns ok for request 4 modcall[authorize]: module chap returns noop for request 4 modcall[authorize]: module mschap returns noop for request 4 rlm_realm: No '@' in User-Name = dhesse, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop for request 4 rlm_eap: EAP packet type response id 5 length 11 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module eap returns updated for request 4 users: Matched entry DEFAULT at line 152 modcall[authorize]: module files returns ok for request 4 rlm_ldap: - authorize rlm_ldap: performing user authorization for dhesse radius_xlat: '(uid=dhesse)' radius_xlat: 'o=StormLake' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in o=StormLake, with filter (uid=dhesse) rlm_ldap: Added the eDirectory password in check items rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user dhesse authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module ldap returns ok for request 4 modcall: group authorize returns updated for request 4 rad_check_password: Found Auth-Type EAP auth: type EAP Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 4 rlm_eap: EAP Identity rlm_eap: processing type mschapv2 rlm_eap_mschapv2: Issuing Challenge modcall[authenticate]: module eap returns handled for request 4 modcall: group authenticate returns handled for request 4 PEAP: Got tunneled Access-Challenge modcall[authenticate]: module eap returns handled for request 4 modcall: group authenticate returns handled for request 4 Sending Access-Challenge of id 182 to 10.10.4.20:2502 EAP-Message = 0x010600371900170301002c2e60ef6cbaeb243c56acedee7a7f10fd837170ff8a7cf9db7376f6b80f3978e34405f8355b645ec66f716d00 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x5658e0fa40025a64a9c21e91575b399d Finished request 4 Going to the next request Waking up in 5 seconds... rad_recv: Access-Request packet from host 10.10.4.20:2503, id=183, length=218 NAS-IP-Address = 10.10.4.20 NAS-Port-Type = Wireless-802.11 NAS-Port = 0 Framed-MTU = 1400 User-Name = dhesse Calling-Station-Id = 001109229950 Called-Station-Id = 000e6acd7ff5 NAS-Identifier = dhlab_3com State = 0x5658e0fa40025a64a9c21e91575b399d EAP-Message = 0x020600581900170301004dde7841f54a1023bc51de5b1049a3f40bc6a3885985ce3a25d2bb4eccc1b5750fb81735d317f01cdf5be04fa5ffb8d4ba2d8c4797bcc127929b672758a2ffe8fc4618d3ac27af90766780edb361 Message-Authenticator = 0xb1ca667f588b5c0be2ebe759ba2d3d71 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 5 modcall[authorize]: module preprocess returns ok for request 5 modcall[authorize]: module chap returns noop for request 5 modcall[authorize]: module mschap returns noop for request 5 rlm_realm: No '@' in User-Name = dhesse, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop for request 5 rlm_eap: EAP packet type response id 6 length 88 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module eap returns updated for request 5 users: Matched entry DEFAULT at line 152 modcall[authorize]: module files returns ok for request 5 rlm_ldap: - authorize rlm_ldap: performing user authorization for dhesse radius_xlat: '(uid=dhesse)' radius_xlat: 'o=StormLake' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in o=StormLake, with filter (uid=dhesse) rlm_ldap: Added the eDirectory password in check items rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user dhesse authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module ldap returns ok for request 5 modcall: group authorize returns updated for request 5 rad_check_password: Found Auth-Type EAP auth: type EAP Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 5 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS eaptls_verify returned 7 rlm_eap_tls: Done initial handshake eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: EAP type mschapv2 rlm_eap_peap: Tunneled data is valid. PEAP: Setting User-Name to dhesse PEAP: Adding old state with 27 d7 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 5 modcall[authorize]: module preprocess returns ok for request 5 modcall[authorize]: module chap returns noop for request 5 modcall[authorize]: module mschap returns noop for request 5 rlm_realm: No '@' in User-Name = dhesse, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop for request 5 rlm_eap: EAP packet type response id 6 length 65 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module eap returns updated for request 5 users: Matched entry DEFAULT at line 152 modcall[authorize]: module files returns ok for request 5 rlm_ldap: - authorize rlm_ldap: performing user authorization for dhesse radius_xlat: '(uid=dhesse)' radius_xlat: 'o=StormLake' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in o=StormLake, with filter (uid=dhesse) rlm_ldap: Added the eDirectory password in check items rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user dhesse authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module ldap returns ok for request 5 modcall: group authorize returns updated for request 5 rad_check_password: Found Auth-Type EAP auth: type EAP Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 5 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 5 rlm_mschap: Told to do MS-CHAPv2 for dhesse with NT-Password rlm_mschap: adding MS-CHAPv2 MPPE keys modcall[authenticate]: module mschap returns ok for request 5 modcall: group Auth-Type returns ok for request 5 MSCHAP Success modcall[authenticate]: module eap returns handled for request 5 modcall: group authenticate returns handled for request 5 PEAP: Got tunneled Access-Challenge modcall[authenticate]: module eap returns handled for request 5 modcall: group authenticate returns handled for

1 0