December 2005 - Freeradius-Users - lists.freeradius.org

Calling-Station-ID not sent by pam_radius_auth.
by Christiaan Ehlers 25 May '11

25 May '11

Hi I currently running the following system: Server: FreeRadius, MySQL Client: pam_radius_auth, libnss_mysql.so I use the freeradius to auth and account ssh logins, here is my pam.d/sshd file on the client. #%PAM-1.0 auth sufficient /lib/security/pam_radius_auth.so debug auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account sufficient /lib/security/pam_radius_auth.so debug account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022 session sufficient /lib/security/pam_radius_auth.so debug conf=/etc/radiusclient/servers session required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_limits.so session optional /lib/security/pam_console.so Now when I authenticate I can see that the Calling-Station-ID gets passed, but when I do authentication that field seems to be missing. Here is the output of radiusd -X Ready to process requests. rad_recv: Access-Request packet from host 10.0.0.1:3698, id=220, length=89 User-Name = "test" User-Password = "123pass" NAS-IP-Address = 10.0.0.1 NAS-Identifier = "sshd" NAS-Port = 2673 NAS-Port-Type = Virtual Service-Type = Authenticate-Only Calling-Station-Id = "10.1.1.1" 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 = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 users: Matched entry DEFAULT at line 153 modcall[authorize]: module "files" returns ok for request 0 radius_xlat: 'test' rlm_sql (sql): sql_set_user escaped user --> 'test' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE Username = 'test' ORDER BY id' rlm_sql (sql): Reserving sql socket id: 7 radius_xlat: 'SELECT radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupche ck.Value,radgroupcheck.op FROM radgroupcheck,usergroup WHERE usergroup.Username = 'test' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id' radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radreply WHERE Username = 'test' ORDER BY id' radius_xlat: 'SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgrouprep ly.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = 'test' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id' rlm_sql (sql): Released sql socket id: 7 modcall[authorize]: module "sql" returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type pap auth: type "PAP" Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 0 rlm_pap: login attempt by "test" with password 123pass rlm_pap: Using password "$1$n/uxpq.r$FBKqAEC8KvsK13QVHRwAf/" for user test authentication. rlm_pap: Using CRYPT encryption. rlm_pap: User authenticated succesfully modcall[authenticate]: module "pap" returns ok for request 0 modcall: group Auth-Type returns ok for request 0 Sending Access-Accept of id 220 to 10.0.0.1:3698 Framed-IP-Address := 10.1.1.1 Framed-Protocol := PPP Service-Type := Framed-User Framed-Compression := Van-Jacobson-TCP-IP Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Accounting-Request packet from host 10.0.0.1:3698, id=66, length=72 User-Name = "test" NAS-IP-Address = 10.0.0.1 NAS-Identifier = "sshd" NAS-Port = 2673 NAS-Port-Type = Virtual Acct-Status-Type = Start Acct-Session-Id = "00002673" Acct-Authentic = RADIUS Processing the preacct section of radiusd.conf modcall: entering group preacct for request 1 modcall[preacct]: module "preprocess" returns noop for request 1 rlm_acct_unique: Hashing 'NAS-Port = 2673,Client-IP-Address = 10.0.0.1,NAS-IP-Address = 10.0.0.1,Acct-Session-Id = "00002673",User-Name = "test"' rlm_acct_unique: Acct-Unique-Session-ID = "a0ec8ab13c262f56". modcall[preacct]: module "acct_unique" returns ok for request 1 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[preacct]: module "suffix" returns noop for request 1 modcall[preacct]: module "files" returns noop for request 1 modcall: group preacct returns ok for request 1 Processing the accounting section of radiusd.conf modcall: entering group accounting for request 1 radius_xlat: '/usr/local/var/log/radius/radacct/10.0.0.1/detail-20050603' rlm_detail: /usr/local/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /usr/local/var/log/radius/radacct/10.0.0.1/detail-20050603 modcall[accounting]: module "detail" returns ok for request 1 modcall[accounting]: module "unix" returns ok for request 1 radius_xlat: '/usr/local/var/log/radius/radutmp' radius_xlat: 'test' modcall[accounting]: module "radutmp" returns ok for request 1 radius_xlat: 'test' rlm_sql (sql): sql_set_user escaped user --> 'test' radius_xlat: 'INSERT into radacct (AcctSessionId, AcctUniqueId, UserName, Realm, NASIPAddress, NASPortId, NASPortType, AcctStartTime, AcctStopTime, AcctSessionTime, AcctAuthentic, ConnectInfo_start, ConnectInfo_stop, AcctInputOctets, AcctOutputOctets, CalledStationId, CallingStationId, AcctTerminateCause, ServiceType, FramedProtocol, FramedIPAddress, AcctStartDelay, AcctStopDelay) values('00002673', 'a0ec8ab13c262f56', 'test', '', '10.0.0.1', '2673', 'Virtual', '2005-06-03 14:20:01', '0', '0', 'RADIUS', '', '', '0', '0', '', '', '', '', '', '', '', '0')' rlm_sql (sql): Reserving sql socket id: 6 rlm_sql (sql): Released sql socket id: 6 modcall[accounting]: module "sql" returns ok for request 1 modcall: group accounting returns ok for request 1 Sending Accounting-Response of id 66 to 10.0.0.1:3698 Finished request 1 Going to the next request Cleaning up request 1 ID 66 with timestamp 42a05901 Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 220 with timestamp 42a05901 Nothing to do. Sleeping until we see a request. As you can see the CallingStationId is empty, also there is no mention of it in the Accounting request packet. If this is not supported by the accounting, is there a way to get it from the authentication section? Would also like to say that I know this is more related to the PAM module and I assume this makes this mail a bit out of context in this mail group, but any help would be most appreciated. Kind Regards Christiaan Ehlers

4 3

no DB handles
by Lucas Aimaretto 31 Oct '07

31 Oct '07

Hi all, I've seen many of these messages in the radius.log ... Wed Jun 15 15:10:23 2005 : Info: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0 What does it mean ? How to solve this ? Best regards, Lucas -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.3/15 - Release Date: 14/06/2005

11 23

RE: Newbie question re. dictionary files.
by Bohannan, Chad W 25 Feb '06

25 Feb '06

Try changing NS-Admin-Privilege = "Read-Only-Admin" To NS-Admin-Privilege = "1" Chad -----Original Message----- From: freeradius-users-bounces(a)lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] On Behalf Of Mark Tunnell Sent: Friday, November 04, 2005 1:23 PM To: freeradius-users(a)lists.freeradius.org Subject: Newbie question re. dictionary files. I'm using FreeRADIUS 1.0.5. to authenticate admin logins to a NetScreen5. I'm able to authenticate accounts just fine. Now I'd like to begin pulling administrative privileges from the Radius server, but I haven't figured out how to do that. I've referenced the dictionary.netscreen file in my clients.conf file, nastype = netscreen, but I'm embarrassed to say I can't figure out the format for including the dictionary attributes for a user in my users file. I've tried various permutations like: markt Auth-Type := Local, User=Password == "testing" NS-Admin-Privilege = "Read-Only-Admin" and: markt Auth-Type := Local, User=Password == "testing" Netscreen-NS-Admin-Privilege = "Read-Only-Admin" Nothing's working. Can some one show me the correct syntax? Thank you, Mark - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

2 1

AW: Freeradius vs. ActiveDirectory
by Völker, Christian 13 Feb '06

13 Feb '06

Yohoo! >> I hope, I could help some people trying to use AD for radius. >there is another way - use the krb module to authenticate against AD Are there any advantages/ disadvantages ldap <-> krb5?

5 13

Dictionary files for HP Procurve switch?
by Mark Tunnell 25 Jan '06

25 Jan '06

Can anyone point me to dictionary file for an HP ProCurve 2650 switch? I've got basic authentication functioning but I don't have the information I need to get the privilege level working. Thanks, Mark

6 9

Re: Authorization
by Stefan Adams 19 Jan '06

19 Jan '06

Dusty, Thanks for your fine input and the reminder on the index (I completely forgot about that). I'll give the ldap module filter a go with the attr_rewrite. I like keeping attributes with the user object, rather than spreading usernames around to various other objects. With this implementation, to me, the extra benefit is that I can just add a radiusGroupName attribute = X to each user object. BTW, on the attr_rewrite, can I use more advanced regex than just ................: ? It works and always will work, but it would be more clear in the config file if I could say "([A-F0-9]{2})-([A-F0-9]{2})-([A-F0-9]{2})-([A-F0-9]{2})-([A-F0-9]{2})-([A-F0-9]{2}):" or something to that effect... I couldn't get ANY regex to work except the . Does that seem right? Stefan > Message: 4 > Date: Mon, 19 Dec 2005 14:52:10 -0500 (EST) > From: Dusty Doris <freeradius(a)mail.doris.cc> > Subject: Re: Freeradius-Users Digest, Vol 8, Issue 82 > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Message-ID: <20051219143705.I21565(a)mail.doris.name> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Mon, 19 Dec 2005, Stefan Adams wrote: > > > Hey, guys! Thanks for the great replies!! I like what you suggested > > better than what I've come up with in the mean time. I think what I > > came up with will work, it just seems messy/wrong/inefficient. What > > do you think? > > > > modules { > > ldap { > > : > > filter = > > > >"(&(uid=%{Stripped-User-Name:-%{User-Name}}) > >(radiusGroupName=%{Called-Station-ID}))" > > : > > } > > attr_rewrite getssid { > > attribute = Called-Station-Id > > searchin = packet > > searchfor = ".................:" > > replacewith = "" > > ignore_case = yes > > new_attribute = no > > } > > } > > > > authorize { > > # for WinXP, 802.1x, EAP-PEAP, MS-CHAPv2 > > preprocess > > eap > > getssid > > ldap > > } > > > > This cuts off the first 17 bytes and then a colon of the > > Called-Station-ID (My AP transmits a dash separated MAC followed by a > > colon and then the SSID). Then it uses this rewritten > > Called-Station-ID and uses that as a filter in the LDAP search. > > Therefore, if the SSID a user tries to connect to is not listed as an > > attribute of the user's LDAP object, the user is denied. > > > > Does that make sense? > > That's a pretty neat idea. The benefit of that is if you had multiple > ldap instances and wanted to implement fail-over within freeradius. To do > it the traditional way, you would need this for fail-over with ldap-group > checks if say you had two ldap instances. > > DEFAULT Called-Station-Id =~ /studentregex/, ldap1-Ldap-Group == > "students" > > DEFAULT Called-Station-Id =~ /studentregex/, ldap2-Ldap-Group == > "students" > > That is so it will check with ldap1 instance first. If that fails, then > check ldap2. > > By doing it your way, you won't need to do that anymore. Instead a > redundant block in authorize would get you what you need already since the > radiusGroupname inside your search filter takes care of the Ldap-Group > check. > > I wonder if you could use regex matches of Called-Station-ID in the > huntgroups file. You'll have to test this out, I doubt it would work, but > its another interesting idea. I don't know if huntgroups excepts regex > and if it can use things like Called-Station-Id > > in huntgroups > > students Called-Station-Id =~ /studentregex/ > faculty Called-Station-Id =~ /facultyregex/ > > Then in users file. > > DEFAULT Ldap-Group == %{Huntgroup-Name} > > Or you're way. > > (&(uid=%{Stripped-User-Name:-%{User-Name}})(radiusGroupName=%{Huntgroup-Name}))" > > See doc/configurable_failover and doc/rlm_ldap to see what I'm talking > about with the failover. If you have a load balancer in front of that > ldap server, you won't need to worry about it. But if you don't and you > want to add redundancy, then its something you'll need to think about some > day. Freeradius can do the redundancy for you w/out a load balancer or > shared IP using configurable failover. Actually in the upcoming 1.1 > release it will also do load balancing for you in addition to failover > inside your ldap blocks. > > Hope I'm not too confusing. My point is I like your idea and if its > working for you, it doesn't sound like a bad one to me. You might want to > try hitting it hard to see if the rewrite slows anything down, but I would > bet it doesn't. > > I'd also make sure to add an eq index to radiusgroupname, since you'll be > using that as part of your search filter.

8 8

FreeRADIUS 1.0.5 rlm_ldap crashing
by Paul Khavkine 16 Jan '06

16 Jan '06

Hi Guys. I'm doing a stress test on 1.0.5 running on FreeBSD 5.4-RELEASE and when start_tls is enabled radiusd crashed somwhere in the rlm_ldap module. I can't seem to make it produce a core file to properly inspect it. The server is running as root and core dumps are enabled in the config file. When i disable start_tls it does not crash. It always crased with signal 6 at random periods. Here's an error: rlm_ldap: attempting LDAP reconnection rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: (re)connect to ldap01.totftds.int.distributel.net:389, authentication 0 rlm_ldap: ldap_get_conn: Checking Id: 1 rlm_ldap: ldap_get_conn: Got Id: 1 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to ldap01.totftds.int.distributel.net:389, authentication 0 rlm_ldap: setting TLS CACert File to /usr/local/radiusd/current/etc/raddb/certs/cacert.pem rlm_ldap: setting TLS CACert File to /usr/local/radiusd/current/etc/raddb/certs/cacert.pem radiusd in free(): error: chunk is already free rlm_ldap: starting TLS Abort Any pointers on how to debug this problem ? Thanx Paul

4 15

Interesting EAP-TLS condition, any insights?
by Timothy J. Miller 03 Jan '06

03 Jan '06

This is a neat one. EAP-TLS is working just fine between an XP supplicant, a Cisco AP1200 WAP running 12.3(4)JA, and FreeRADIUS 1.0.1 (plus a patch to allow multiple root CAs for EAP-TLS trust). Client certificates are on smartcards, and the AP has a reauthentication timer set, with the intent that clients will be kicked off the WLAN (eventually) when the card is removed (since without the card reauthentication can't complete). Only it doesn't seem to work that way. What appears to happen is this: The authentication starts but never completes, since the client can't complete the TLS handshake without the smartcard inserted (and PIN entered). FreeRADIUS blocks at the "Requiring client certificate" step, as I would expect. However, the AP holds the authentication pending but *leaves the client fully connected*. This means that as long as an incomplete reauthentication is pending, a previously-authenticated client remains online. Not the effect I was looking for. The Cisco AP has an optional setting for RADIUS timeout, but this only seems to apply for the initial packet; since the RADIUS server responded to the initial access-request, that timeout doesn't apply. I tried ramping down max_request_time and setting delete_blocked_requests to yes, but it didn't have any effect; FreeRADIUS never sends an access-reject. There appear to be no controls on XP to force a complete deauthentication after a timeout that I can find. Will porting forward to current rev address this, or does anyone else have an insight? -- Tim

3 6

Peap mschapv2 proxy early termination of EAP
by Andy Goy 02 Jan '06

02 Jan '06

Hi Alan I have a number of XP and Windows 2K wifi clients to Proxim AP700 AP's using FreeRADIUS on Fedora C4 These use eap peap mschapv2 The system works well on ver 1.0.2 using usernames/passwords in the users file or by configuring LDAP and using a LDAP database, and logs to mysql I now need to authenticate by proxy to a legacy SteelBelted radius server capable of PAP,CHAP and MSCHAPv2 but not able to support EAP I configured the proxy.conf for the realm wifi (with nostrip) and I can communicate with the legacy server, it sends back a reject due to not supporting EAP I therefore need to terminate EAP on Freeradius and pass on the MSchapv2 to the proxy server Having read all I can on early termination of EAP I added the LOCAL realm realm LOCAL { type = radius authhost = LOCAL accthost = LOCAL } I have added 2 lines to the users file DEFAULT FreeRADIUS-Proxied-To !* 127.0.0.1, Proxy-To-Realm := LOCAL, Auth-Type = EAP (line 167) DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Proxy-To-Realm := wifi (line 168) The first line (at line 167) causes the proxy to be cancelled and the eap is handled locally, it gets to the mschapv2 part matched (at line 168) It appears as if its going to send the request to wifi, with no EAP, then it stops. The AP then retries the request, with the same result. This seems to be due to WARNING: Cancelling proxy to Realm LOCAL, as the realm is local rather than proxying only the mschapv2 to wifi I have upgraded to v 1.0.5 I still get the same results Authorise and accounting in radiusd.conf has EAP and mschap Is it possible ? I have researched from your site as much as possible before asking, Am I missing a configuration option? Your help would be much appreciated, Thanks Andy. eap.conf eap { default_eap_type = peap timer_expire = 60 ignore_unknown_eap_types = no tls { private_key_password = whatever private_key_file = ${raddbdir}/certs/cert-srv.pem certificate_file = ${raddbdir}/certs/cert-srv.pem CA_file = ${raddbdir}/certs/demoCA/cacert.pem dh_file = ${raddbdir}/certs/dh random_file = ${raddbdir}/certs/random include_length = yes # check_crl = yes # check_cert_cn = %{User-Name} } # peap { default_eap_type = mschapv2 proxy_tunneled_request_as_eap = no } mschapv2 { } } Listening on authentication *:1812 Listening on accounting *:1813 Listening on proxy *:1814 Ready to process requests. rad_recv: Access-Request packet from host 172.24.2.10:6001, id=40, length=154 User-Name = "andygoy@wifi" NAS-IP-Address = 172.24.2.10 Called-Station-Id = "00-20-a6-56-3a-4a:XXHOTSPOTFC1" Calling-Station-Id = "00-13-ce-0e-f5-c6" NAS-Identifier = "XX-HOTSPOT-1" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0202001101616e6479676f794077696669 Message-Authenticator = 0x206d804b1c31514e5743b1c03efdfcaf Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 radius_xlat: '/etc/var/log/radius/radacct/172.24.2.10/auth-detail-20051230' rlm_detail: /etc/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /etc/var/log/radius/radacct/172.24.2.10/auth-detail-20051230 modcall[authorize]: module "auth_log" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 rlm_realm: Looking up realm "wifi" for User-Name = "andygoy@wifi" rlm_realm: Found realm "wifi" rlm_realm: Proxying request from user andygoy to realm wifi rlm_realm: Adding Realm = "wifi" rlm_realm: Preparing to proxy authentication request to realm "wifi" modcall[authorize]: module "suffix" returns updated for request 0 rlm_eap: Request is supposed to be proxied to Realm wifi. Not doing EAP. modcall[authorize]: module "eap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 users: Matched entry DEFAULT at line 167 modcall[authorize]: module "files" returns ok for request 0 modcall: leaving group authorize (returns updated) for request 0 WARNING: You set Proxy-To-Realm = LOCAL, but it is a LOCAL realm! Cancelling invalid proxy request. 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: leaving group authenticate (returns handled) for request 0 WARNING: Cancelling proxy to Realm LOCAL, as the realm is local Sending Access-Challenge of id 40 to 172.24.2.10 port 6001 EAP-Message = 0x010300061920 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x0b7df43e9fc35a77966d3c95bb99a754 Finished request 0 Going to the next request etc etc----------------------------------------------------------------------- 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 andygoy@wifi PEAP: Adding old state with 0e aa Processing the authorize section of radiusd.conf modcall: entering group authorize for request 6 modcall[authorize]: module "preprocess" returns ok for request 6 radius_xlat: '/etc/var/log/radius/radacct/127.0.0.1/auth-detail-20051230' rlm_detail: /etc/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /etc/var/log/radius/radacct/127.0.0.1/auth-detail-20051230 modcall[authorize]: module "auth_log" returns ok for request 6 modcall[authorize]: module "chap" returns noop for request 6 rlm_realm: Looking up realm "wifi" for User-Name = "andygoy@wifi" rlm_realm: Found realm "wifi" rlm_realm: Proxying request from user andygoy to realm wifi rlm_realm: Adding Realm = "wifi" rlm_realm: Preparing to proxy authentication request to realm "wifi" modcall[authorize]: module "suffix" returns updated for request 6 rlm_eap: Request is supposed to be proxied to Realm wifi. Not doing EAP. modcall[authorize]: module "eap" returns noop for request 6 modcall[authorize]: module "mschap" returns noop for request 6 users: Matched entry DEFAULT at line 168 modcall[authorize]: module "files" returns ok for request 6 modcall: leaving group authorize (returns updated) for request 6 PEAP: Calling authenticate in order to initiate tunneled EAP session. Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 6 rlm_eap: Request found, released from the list rlm_eap: EAP/mschapv2 rlm_eap: processing type mschapv2 Not-EAP proxy set. Not composing EAP modcall[authenticate]: module "eap" returns handled for request 6 modcall: leaving group authenticate (returns handled) for request 6 PEAP: Tunneled authentication will be proxied to wifi PEAP: Remembering to do EAP-MS-CHAP-V2 post-proxy. Tunneled session will be proxied. Not doing EAP. modcall[authenticate]: module "eap" returns handled for request 6 modcall: leaving group authenticate (returns handled) for request 6 WARNING: Cancelling proxy to Realm LOCAL, as the realm is local Finished request 6 Going to the next request Waking up in 4 seconds... rad_recv: Access-Request packet from host 172.24.2.10:6001, id=46, length=249 The content of this e-mail and any attachment is private and may be legally privileged. If you are not the intended recipient, any use, disclosure, copying or forwarding of this e-mail and/or its attachments is unauthorised. If you have received this e-mail in error please notify the sender by e- mail and delete this message and any attachments immediately from this system. Kingston Communications (HULL) PLC is a public limited company incorporated in England and Wales with registration number 02150618 and whose registered office is at 37 Carr Lane, Hull HU1 3RE

2 1

Re: FreeRadius +TLS (base on openssl)
by Bustamante David 01 Jan '06

01 Jan '06

Disculpas, en este momento estoy de vacaciones y no podré responder los mensajes. David

4 5