Re: Status...
Hopefully in 1.0 release, rlm_ldap can work well with FreeBSD 5.1 Currently it has problem.. so i stick with FreeBSD 4.8 (and 4.9) --haizam - Original Message - From: "Alan DeKok" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, November 08, 2003 2:11 AM Subject: Status... > I'll be in Minneapolis all next week at a conference. My usual > 5 minute response time will increase dramatically. > > > As for other issues, there are fixes which could go into 0.9.3. The > CVS head still has some issues (u_int... should be uint), and linking > problems. > > I think we're approaching a 1.0.0 release. The CVS head has *huge* > feature improvements over 0.9.x, so it looks like time for a stable > "1.0". January 2004 is starting to look good for a release date. > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
x
x - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Problem with EAP-TTLS+AEGIS Client
Hello, we are facing a problem when trying to test EAP-TTLS with the
Meetinghouse AEGIS Client
We are using a Cisco 2950 as an AP (EAPOL authentication) with recent IOS.
freeradius latest cvs (two or three days old)
Aegis 2.1.0
OpenSSL 0.9.7c
Unfortunately we haven't been able to find a sniffer capable of reporting the
TLS traffic within an EAP-TTLS (or EAP-TLS for that matter) conversation.
So I am mostly speculating what the problem is.
As can be seen from the radiusd -X -xxx output after sending a TLS Hello with
the server certificate the client returns with a TLS ACK. I am guessing that one
TLS fragment got to the client and it is ACKing for another. Though the eap_tls
module seems to not accept that ACK.
>From what i 've found the eaptls_ack_handler() never seems to be called. If it
is an openssl or rlm_eap_tls module problem i don't know. From the documentation
on openssl.org it seems that the handler will only be called if the received
packet is ok so it can just be that the packet is malformed somehow.
In any case I don't really know where to go from here. One thing that would help
would be if someone confirmed that eap-ttls works with such a configuration.
tls {
private_key_password = ""
private_key_file = /etc/1x/private.pem
certificate_file = /etc/1x/cert.pem
CA_file = /etc/1x/CA.pem
dh_file = /etc/1x/DH
random_file = /etc/1x/random
fragment_size = 1024
# include_length = no
}
--
Kostas Kalevras Network Operations Center
[EMAIL PROTECTED] National Technical University of Athens, Greece
Work Phone: +30 210 7721861
'Go back to the shadow' Gandalfrad_recv: Access-Request packet from host 147.102.247.20:1812, id=45, length=102
NAS-IP-Address = 147.102.247.20
NAS-Port-Type = Async
User-Name = "papage"
Service-Type = Framed-User
Framed-MTU = 1500
Calling-Station-Id = "00-00-86-33-52-43"
EAP-Message = 0x020e000b01706170616765
Message-Authenticator = 0x33b1b4adac3a64f2951c083441512065
Sun Nov 9 21:52:25 2003 : Debug: modcall: entering group authorize for request 40
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authorize]: calling preprocess
(rlm_preprocess) for request 40
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authorize]: returned from preprocess
(rlm_preprocess) for request 40
Sun Nov 9 21:52:25 2003 : Debug: modcall[authorize]: module "preprocess" returns ok
for request 40
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authorize]: calling chap (rlm_chap) for
request 40
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authorize]: returned from chap
(rlm_chap) for request 40
Sun Nov 9 21:52:25 2003 : Debug: modcall[authorize]: module "chap" returns noop for
request 40
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authorize]: calling eap (rlm_eap) for
request 40
Sun Nov 9 21:52:25 2003 : Debug: rlm_eap: EAP packet type response id 14 length 11
Sun Nov 9 21:52:25 2003 : Debug: rlm_eap: No EAP Start, assuming it's an on-going
EAP conversation
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authorize]: returned from eap (rlm_eap)
for request 40
Sun Nov 9 21:52:25 2003 : Debug: modcall[authorize]: module "eap" returns updated
for request 40
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authorize]: calling suffix (rlm_realm)
for request 40
Sun Nov 9 21:52:25 2003 : Debug: rlm_realm: No '@' in User-Name = "papage",
looking up realm NULL
Sun Nov 9 21:52:25 2003 : Debug: rlm_realm: No such realm "NULL"
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authorize]: returned from suffix
(rlm_realm) for request 40
Sun Nov 9 21:52:25 2003 : Debug: modcall[authorize]: module "suffix" returns noop
for request 40
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authorize]: calling files (rlm_files)
for request 40
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authorize]: returned from files
(rlm_files) for request 40
Sun Nov 9 21:52:25 2003 : Debug: modcall[authorize]: module "files" returns
notfound for request 40
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authorize]: calling mschap (rlm_mschap)
for request 40
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authorize]: returned from mschap
(rlm_mschap) for request 40
Sun Nov 9 21:52:25 2003 : Debug: modcall[authorize]: module "mschap" returns noop
for request 40
Sun Nov 9 21:52:25 2003 : Debug: modcall: group authorize returns updated for request
40
Sun Nov 9 21:52:25 2003 : Debug: rad_check_password: Found Auth-Type EAP
Sun Nov 9 21:52:25 2003 : Debug: auth: type "EAP"
Sun Nov 9 21:52:25 2003 : Debug: modcall: entering group authenticate for request 40
Sun Nov 9 21:52:25 2003 : Debug: modsingle[authenticate]: calling eap (rlm_eap) for
request 40
Sun Nov 9 21:52:25 2003 : Debug: rlm_eap
Re: command-line SQL management utilities
On Tue, 4 Nov 2003, Damian Gerow wrote: > Thus spake Alan DeKok ([EMAIL PROTECTED]) [04/11/03 11:26]: > > There's dialup_admin, which is in the tree. It's based on PHP & the > > web, but it's similar. > > > > It may be possible to make the dialup_admin tools also wrok as > > command-line tools, or to make a "generic" command line tool which > > dialup_admin can use, too. > > I'm hoping to provide a companion to the web interface, but don't know PHP > very well. I don't know perl very well either, but that's what I'm shooting > to use. I've already written a password management utility (expire, > reactivate users, change passwords, put users on hold), so the next step is > user creation and generic attribute management. I would suggest the same thing. PHP is mainly for web applications, perl for command line utils. And it would be nice to also have command line utils in companion with dialupadmin mainly for mass user creation/administration. > > I'm willing to share my (ugly) code with anyone that wants it. I figure I'm > not the only one who wants command-line control of the users database. > Unfortunately, it's SQL only. I've never touched LDAP with perl. One nice thing would be to try and distinguish script operation from the actual database operations. Mainly keep them all in a separate included file(s). dialupadmin shares that kind of logic. Then someone else can easily create ldap specific code. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- Kostas Kalevras Network Operations Center [EMAIL PROTECTED] National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radclient memory leak?
"Max Liccardo" <[EMAIL PROTECTED]> wrote: > I noticed that radclient doesn't never free the "RADIUS_PACKET *req" > memory allocated via rad_alloc. > Should I submit a patch or there's something "inside" that I don't > understand? radclient doesn't allocate more than one RADIUS_PACKET, as I recall. It also exists after doing the request/reply, so any memory leak doesn't matter, as the program doesn't exist any more. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client_DNS_Pri
Stephen Fulton wrote: > At 11:19 PM 07/11/2003 +0100, you wrote: > > Have you tried setting the appropriate AV in either the radreply or > groupradreply tables? yes i have. mysql> SELECT * FROM radgroupreply; ++---++++--+ | id | GroupName | Attribute | op | Value | prio | ++---++++--+ | 1 | other | Framed-MTU | := | 1492 |0 | | 5 | other | Client_DNS_Pri | := | 62.80.96.5 |0 | ++---++++--+ but not work. When i override the Framed-MTU, that works fine. >> How can i override the Client_DNS_Pri ATTRIBUTE, in my >> radius SQL Table? >> >> Sending Access-Request of id 213 to xxx.xxx.xx.xxx:1812 >> User-Name = "[EMAIL PROTECTED]" >> User-Password = "" >> NAS-IP-Address = ns1 >> NAS-Port = 0 >> rad_recv: Access-Accept packet from host xxx.xx.xx.xxx:1812, id=213, >> length=62 >> Framed-MTU = 1492 >> Service-Type = Framed-User >> Framed-Protocol = PPP >> Client_DNS_Pri = 195.129.111.50 >> Client_DNS_Sec = 195.129.111.49 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client_DNS_Pri
At 11:19 PM 07/11/2003 +0100, you wrote: Have you tried setting the appropriate AV in either the radreply or groupradreply tables? -- Steve Hello, How can i override the Client_DNS_Pri ATTRIBUTE, in my radius SQL Table? Sending Access-Request of id 213 to xxx.xxx.xx.xxx:1812 User-Name = "[EMAIL PROTECTED]" User-Password = "" NAS-IP-Address = ns1 NAS-Port = 0 rad_recv: Access-Accept packet from host xxx.xx.xx.xxx:1812, id=213, length=62 Framed-MTU = 1492 Service-Type = Framed-User Framed-Protocol = PPP Client_DNS_Pri = 195.129.111.50 Client_DNS_Sec = 195.129.111.49 -- mario - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
radclient memory leak?
hi Folks, I noticed that radclient doesn't never free the "RADIUS_PACKET *req" memory allocated via rad_alloc. Should I submit a patch or there's something "inside" that I don't understand? max - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
SNAP20031105 runtime error
>On Nov 5, 2003, at 8:36 AM, Andreas Wolf wrote: > >> >> On Nov 5, 2003, at 4:48 AM, Adam Jendrosek wrote: >> >>> [EMAIL PROTECTED] wrote: When starting Freeradius (latest snap) the program crashes with the following message: Module: Loaded System unix: cache = no unix: passwd = "(null)" unix: shadow = "(null)" unix: group = "(null)" unix: radwtmp = "/usr/local/var/log/radius/radwtmp" unix: usegroup = no unix: cache_reload = 600 Module: Instantiated unix (unix) Module: Loaded eap eap: default_eap_type = "ttls" eap: timer_expire = 60 eap: ignore_unknown_eap_types = no /usr/local/sbin/radiusd: relocation error: /usr/local/lib/rlm_eap-1.0.0-pre0.so: undefined symbol: eaptype_name2type >>> >>> Look's like somebody have forgotten to add the symbol >>> eaptype_name2type into the makefile. >>> You should use nm or ldd to watch rlm_eap-1.0.0-pre0.so to verify >>> this error and modify the appropriate makefile. >>> >> >> like I pointed out earlier yesterday the missing symbol is in >> libeap.so. >> Looks like it just got fixed. >> > >actually, I was wrong, it appears to still be broken. >I am not an expert with those Makefiles but the adding >libeap/eapcommon.c to >the SRC variable fixed it for me: >> Index: Makefile.in >> === >> RCS file: /source/radiusd/src/modules/rlm_eap/Makefile.in,v >> retrieving revision 1.7 >> diff -r1.7 Makefile.in >> 2c2 >> < SRCS= rlm_eap.c eap.c mem.c state.c >> --- >> > SRCS= rlm_eap.c eap.c mem.c state.c libeap/eapcommon.c > >'configure' and 'make' again > >-Andreas In the makefile there is the link to the newly introduced libeap missing, therefore the correct way to fix it is to add the following line instead RLM_LIBS = -Llibeap -leap to the Makefile.in as shown above. Do a 'clean', 'configure' and 'make' again. Regards, Markus >>> regards, >>> Adam >>> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
