RE: Vendor-Specific reply? - editing the dictionary files - the right thing to do?
We're happily using FreeRADIUS under FreeBSD - recently, I've been asked to setup a vendor-specific reply for some of our users. I've been asked to send a Vendor 0x9 (Cisco) Attribute #26 Type 0x1 reply, with a specific value which the remote system will use. Thinking I was doing the right thing - I edited the dictionary.cisco and commented out the Attribute #26 already in there (h323-call-origin) - which I renamed as 'tdxtest'. Is the correct (or one correct?) way to do things? - How do I (or do I need) to specify the Attribute Type of 0x1 - I have a hunch this is what the 'string' bit does. I'm not sure about your second question, but we certainly have had no troubles editing the dictionary files. You might send your additions to Alan and/or the maintainers of the dictionaries (they may list themselves in the file header) so you don't have to edit things every time you reinstall. Either way, you might want to do an $INCLUDE and have your additions as a separate file, again so that your changes don't get overwritten when you do your next upgrade (you'll only have to replace the $INCLUDE directive itself, which is easy). The remote side say they get a Vendor 0x9 (Cisco) attribute #26 - but they're system says it's a bad attribute. Anyone got any pointers / suggestions? Yes. There = indicates direction over there Their = indicates possession their system (see above) They're = contraction of they are :-) Seriously, though, editing the dictionary files is common practice, at least around here. The biggest thing is that if you think you're adding things that really ought to be part of the stock dictionary, let someone know so it can be added to the distro (and make sure the vendor doesn't mind). --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Stop spaming
You know, working at an ISP, I see *so many* misconfigured mailsystems that sometimes I think that in a few years, the whole thing is going to collapse. Heh. Same goes for DNS servers. Four bad referrals, Three lame del(egation)s Two with no WHOIS and a partridge in a pear tree... Oh well, death of the net predicted, film at 11. Have you seen the Kentucky Fried Movie? Moscow in flames, missles headed toward New York! Film at 11. The popcorn you're eating has been pissed in. Film at 11. I'm not wearing any pants. Film at 11. :-) --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP/MD5 with XP FreeRADIUS
Has someone ever tried EAP/MD5 working with Windows XP and FreeRADIUS? Yes. It works... if configured properly on both sides. I found something strange.. EAPOL start - Identity Request and Reply. After FreeRADIUS sends challenge and Access Point forwards it, it seems XP doesn't understand challenge and XP sends identity reply again The authentication procedure becomes a loop and wouldn't end. What does your RADIUS configuration look like? Specifically: 1) Do you have EAP enabled in your radius.conf file? 2) Do you have the NAS (the Access Point) defined in your clients.conf file (along with the correct shared secret)? 3) What does this user's entry look like in the users file? Is it a problem of Windows XP? It's ok if I use XP + Windows 2000 RADIUS. Excuse me for disturbing us. Thank you. Not a problem. It's most likely the configuration on one side or another. Several people have been able to get EAP/MD5 to work with Windows XP. One thing to remember, though: EAP/MD5 is a rather insecure method of doing things, even with Windows 2000 RADIUS, because each user's password is stored on the RADIUS server in a decryptable (or even cleartext!) format. It is better to use EAP/TLS, which also works with FreeRADIUS and Windows XP. --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: FreeRADIUS, PAM, and Kerberos
[blah blah blah...] Making static dynamic in rlm_krb5... gmake[6]: Entering directory `/usr/src/freeradius-0.5/src/modules/rlm_krb5' gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I../../include -c rlm_krb5.c -o rlm_krb5.o rlm_krb5.c:39:18: krb5.h: No such file or directory rlm_krb5.c:40:21: com_err.h: No such file or directory Note that the -I/usr/kerberos/include isn't shown in the gcc line above. This smells like a configure/Makefile problem to me. I forgot to mention that this is FreeRADIUS 0.5 (not a CVS snapshot). --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: FreeRADIUS and PAM
PAM itself doesn't care about local vs. non-local accounts. If you're having trouble with this, you almost certainly have a module in your PAM config which you shouldn't -- such as pam_unix, which by definition requires local accounts and will give you a failure for anything else. Someone on the list may be able to pinpoint the exact trouble if you dump us your PAM config for freeradius. I did in a previous post, but here it is again for convenience: #%PAM-1.0 authrequired/usr/pam/lib/security/pam_krb5.so account required/usr/pam/lib/security/pam_permit.so I also tried the following: #%PAM-1.0 authrequired/usr/pam/lib/security/pam_krb5.so And... #%PAM-1.0 authsufficient /usr/pam/lib/security/pam_krb5.so authrequired/usr/pam/lib/security/pam_unix.so (Which allowed logins from anyone using either his/her Kerberos password or his/her local Unix password.) In all three cases, users are only allowed to login if they have local accounts. Also, note that in all three cases, what is shown above is the *complete* pam.d/radiusd file. I have not removed irrelevant lines from the file. If I need a session line as well, that's fine, but I'd love to know why PAM thinks so... --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: FreeRADIUS and PAM
McNutt, Justin M. [EMAIL PROTECTED] wrote: PAM does username/password authentication, nothing else. Not so. PAM can provide several different authorization functions as well. ... and for authentication, it does username/password (or equivalents) But RADIUS does more than authentication, which is my point. RADIUS is responsible for both authentication - via username/password - and authorization - via attribute pairs. So my original question, slightly reworded, is If PAM is able to authenticate me correctly, which it does, why does FreeRADIUS still return a reject unless there is a local account? This would seem to be a function of what FreeRADIUS requests of PAM. I figured this one out. FreeRADIUS has an option to delay the response. This delay - even if set to only a second or two - is more than the BayStack is willing to wait. Then the BayStack is a piece of crap. Was this observation really necessary. I provided the information above for everyone's use, not for value judgements of the BayStack. The BayStack is *not* a piece of crap, despite the fact that it doesn't do RADIUS authentication in the best possible way. That's why FreeRADIUS isn't a piece of crap, and is configurable. I agree, with the reservation that while FreeRADIUS works very well and is highly configurable, there is a severe lack of documentation (which is somewhat reasonable since it is still in 0.xx versions) and its developers are extremely opinionated and sensitive to criticism. :-/ Of course, you've now opened yourself up to a DoS attack, but that's life. True. However I need to deal with the problems in my network one at a time. Right now, convenient authenticated access to the switches for our administrators is the larger problem. I have several Nortel folks to whom I can speak about improvements to the RADIUS code if I need to address those other problems later. They have been listening when it comes to security issues in general (for example, they are implementing SNMPv3 quite soon), so I am confident that this is not a waste of time. THEREFORE, my biggest worry at the moment is how I can use FreeRADIUS to authenticate people logging into BayStacks, using PAM as the local authentication method on the RADIUS server side *without* having to create user accounts on the RADIUS server for every switch admin. --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: FreeRADIUS and PAM
McNutt, Justin M. [EMAIL PROTECTED] wrote: So my original question, slightly reworded, is If PAM is able to authenticate me correctly, which it does, why does FreeRADIUS still return a reject unless there is a local account? This would seem to be a function of what FreeRADIUS requests of PAM. I'm not sure why. As I said before, the PAM code in FreeRADIUS is copied pretty much verbatim from the Cistron source. And the 'username/password' authentication part of PAM is pretty hard to get wrong. I would suggest looking at the PAM logs, to see why it decides to not authenticate the user. Hrmmm... 'kay. What, you say? There's no PAM logs? Or, at least, no useful/helpful logs, and no way of debugging PAM's internals? I hate PAM. grin One other tack I was considering was setting up rlm_krb5, since I'm really using PAM as a front end to our Kerberos servers. While PAM gave me the additional fallback option of using a user's local password, it may not be worth it (since the logging is indeed not very good...). The BayStack is *not* a piece of crap, despite the fact that it doesn't do RADIUS authentication in the best possible way. They've gone out of their way to make it *harder* to use. That disappoints me. Say your NAS comes back up after a power outage, and fires 5k requests to the RADIUS server, when everyone dials in again. The server MAY take a second or so to respond, under the high load. In the mean time, the BayStack will time out (VERY quickly), and reject many of the users. This is equipment you want to base your network on? That would make *me* nervous... Except that in this case, the BayStack is not a NAS, it is merely a RADIUS client. It uses RADIUS to authenticate users who attempt to log into the switch for management purposes. This only happens a few times per day (let alone per second). When the BayStack becomes a NAS - and it will, as EAP becomes more practical for Ethernet-connected workstations - we will address the effective DoS scenario with Nortel. In the meantime, though, I still think it's a pretty good box. I agree, with the reservation that while FreeRADIUS works very well and is highly configurable, there is a severe lack of documentation (which is somewhat reasonable since it is still in 0.xx versions) Well, it *is* free software, which is generally well known for having poor documentation. Yes and no, but it's certainly fair to say that free software in its alpha version isn't going to have PDF manuals yet. :-) I mean the thing isn't even finished yet! :-P As it comes closer to v1.0, though, documentation - hopefully user-contributed - will become a necessity. I'll help where I can (I plan to stick with this server until somebody pries it from my RedHat box with a crowbar). and its developers are extremely opinionated and sensitive to criticism. :-/ I can't speak for others here, but I know *I'm* sensitive to a lot of things which aren't criticism. If you say The server core dumped on me, I hate it, it's crap, I'll most likely agree with you. On the other hand, many comments involve a lack of awareness of how RADIUS works, or how Unix systems work. There's not much that can be said there, other than go read the OTHER guy's documentation, that's not part of FreeRADIUS. Other comments involve people unwilling or unable to read what documentation exists, and *those* get blunt responses from me. THEREFORE, my biggest worry at the moment is how I can use FreeRADIUS to authenticate people logging into BayStacks, using PAM as the local authentication method on the RADIUS server side *without* having to create user accounts on the RADIUS server for every switch admin. Find out why PAM is rejecting the users, all the server knows from rlm_pam is that the authentication failed. nods 'Kay. Fair enough. --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-MD5: Password sources
There are 2 types of EAP authentications that are currently supported by Freeradius 1. EAP-MD5 2. EAP-TLS The one which you tested is EAP-md5. It is just similar to CHAP authentication. It works only with PLAIN TEXT passwords. So if you have plain text password stored in files, database or LDAP, then it works. EAP-TLS is Certificate based authentication. I don't understand where this restriction comes from. Once the FreeRADIUS server gets the password from the NAS, what prevents it from checking that password against /etc/shadow, PAM, another RADIUS server, or whatever? --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-MD5 - Can't seem to get it working.
We always get this: Mon Apr 1 15:14:24 2002 : Error: Received packet from 128.206.95.215 with invalid Message-Authenticator! The password is hard-coded into the users profile in the raddb file and we've quadruple-checked the RADIUS shared secret. The NAS is a Nortel Business Policy Switch 2000 and the EAP client is a Windows XP laptop (username gilpina, password datiswak, domain [NULL]). Server is a Slackware 7.1 box running FreeRADIUS 0.5 (release version). Ideas? Here's the section of the /usr/local/etc/raddb/users file for this user: gilpina Auth-Type := EAP, User-Password == datiswak Port-Priority = Platinum, Tunnel-Private-Group-Id = 201, Tunnel-Type = 13, Tunnel-Medium-Type = 6, Service-Type = Framed, NAS-Port-Type = Ethernet Here's what radiusd -X -y shows: Module: Instantiated unix (unix) Module: Loaded preprocess preprocess: huntgroups = /usr/local/etc/raddb/huntgroups preprocess: hints = /usr/local/etc/raddb/hints preprocess: with_ascend_hack = no preprocess: ascend_channels_per_line = 23 preprocess: with_ntdomain_hack = no preprocess: with_specialix_jetstream_hack = no preprocess: with_cisco_vsa_hack = no Module: Instantiated prepro^[[A^[[A root@dnps-linux1:/var/log/radius# killall radiusd root@dnps-linux1:/var/log/radius# cd root@dnps-linux1:~# cat radiusd.debug.log Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /usr/local/etc/raddb/proxy.conf Config: including file: /usr/local/etc/raddb/clients.conf Config: including file: /usr/local/etc/raddb/snmp.conf Config: including file: /usr/local/etc/raddb/sql.conf main: prefix = /usr/local main: localstatedir = /var main: logdir = /var/log/radius main: libdir = /usr/local/lib main: radacctdir = /var/log/radius/radacct main: hostname_lookups = no read_config_files: reading dictionary read_config_files: reading clients read_config_files: reading realms read_config_files: reading naslist main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 10240 main: delete_blocked_requests = 0 main: port = 0 main: allow_core_dumps = no main: log_stripped_names = no main: log_auth = yes main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = /var/run/radiusd.pid main: user = root main: group = root main: usercollide = no main: lower_user = no main: lower_pass = no main: nospace_user = no main: nospace_pass = no main: proxy_requests = yes proxy: retry_delay = 5 proxy: retry_count = 3 proxy: synchronous = no proxy: default_fallback = yes proxy: dead_time = 120 security: max_attributes = 200 security: reject_delay = 1 main: debug_level = 0 read_config_files: entering modules setup Module: Library search path is /usr/local/lib Module: Loaded eap eap: default_eap_type = md5 eap: timer_expire = 60 rlm_eap: Loaded and initialized the type md5 Module: Instantiated eap (eap) Module: Loaded Pam pam: pam_auth = radiusd Module: Instantiated pam (pam) Module: Loaded System unix: cache = yes unix: passwd = /etc/passwd unix: shadow = /etc/shadow unix: group = /etc/group unix: radwtmp = /var/log/radius/radwtmp unix: usegroup = no unix: cache_reload = 600 HASH: Reinitializing hash structures and lists for caching... HASH: user root found in hashtable bucket 11726 HASH: user bin found in hashtable bucket 86651 HASH: user daemon found in hashtable bucket 11668 HASH: user adm found in hashtable bucket 26466 HASH: user lp found in hashtable bucket 54068 HASH: user sync found in hashtable bucket 42895 HASH: user shutdown found in hashtable bucket 71746 HASH: user halt found in hashtable bucket 7481 HASH: user mail found in hashtable bucket 79471 HASH: user news found in hashtable bucket 5375 HASH: user uucp found in hashtable bucket 38541 HASH: user operator found in hashtable bucket 21748 HASH: user games found in hashtable bucket 47657 HASH: user ftp found in hashtable bucket 56226 HASH: user gdm found in hashtable bucket 50360 HASH: user nobody found in hashtable bucket 99723 HASH: user mcnuttj found in hashtable bucket 94877 HASH: user rohrss found in hashtable bucket 6971 HASH: user jscan found in hashtable bucket 11447 HASH: user gravess found in hashtable bucket 76481 HASH: user graves found in hashtable bucket 64346 HASH: user robertsmj found in hashtable bucket 85394 HASH: user ridgwaye found in hashtable bucket 84016 HASH: user irovicd found in hashtable bucket 10630 HASH: user gilpina found in hashtable bucket 40370 HASH: user blackwellta found in hashtable bucket 34722 HASH: user simmonsw found in hashtable bucket 1161 HASH: user waageb found in hashtable bucket 10993 HASH: user perryd found in hashtable bucket 21500 HASH: user Manager found in hashtable bucket 3361 HASH: user northt found in hashtable
RE: EAP-MD5 - Can't seem to get it working.
Never mind. I'm a dumb ass. I had a duplicate entry for this NAS in /usr/local/etc/raddb/clients which was screwing things up (it had a different shared secret). So I'm stupid. It works fine. I'm going home. :-P --J -Original Message- From: McNutt, Justin M. Sent: Monday, April 01, 2002 3:32 PM To: [EMAIL PROTECTED] Subject: EAP-MD5 - Can't seem to get it working. We always get this: Mon Apr 1 15:14:24 2002 : Error: Received packet from 128.206.95.215 with invalid Message-Authenticator! The password is hard-coded into the users profile in the raddb file and we've quadruple-checked the RADIUS shared secret. The NAS is a Nortel Business Policy Switch 2000 and the EAP client is a Windows XP laptop (username gilpina, password datiswak, domain [NULL]). Server is a Slackware 7.1 box running FreeRADIUS 0.5 (release version). Ideas? Here's the section of the /usr/local/etc/raddb/users file for this user: gilpina Auth-Type := EAP, User-Password == datiswak Port-Priority = Platinum, Tunnel-Private-Group-Id = 201, Tunnel-Type = 13, Tunnel-Medium-Type = 6, Service-Type = Framed, NAS-Port-Type = Ethernet Here's what radiusd -X -y shows: Module: Instantiated unix (unix) Module: Loaded preprocess preprocess: huntgroups = /usr/local/etc/raddb/huntgroups preprocess: hints = /usr/local/etc/raddb/hints preprocess: with_ascend_hack = no preprocess: ascend_channels_per_line = 23 preprocess: with_ntdomain_hack = no preprocess: with_specialix_jetstream_hack = no preprocess: with_cisco_vsa_hack = no Module: Instantiated prepro^[[A^[[A root@dnps-linux1:/var/log/radius# killall radiusd root@dnps-linux1:/var/log/radius# cd root@dnps-linux1:~# cat radiusd.debug.log Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /usr/local/etc/raddb/proxy.conf Config: including file: /usr/local/etc/raddb/clients.conf Config: including file: /usr/local/etc/raddb/snmp.conf Config: including file: /usr/local/etc/raddb/sql.conf main: prefix = /usr/local main: localstatedir = /var main: logdir = /var/log/radius main: libdir = /usr/local/lib main: radacctdir = /var/log/radius/radacct main: hostname_lookups = no read_config_files: reading dictionary read_config_files: reading clients read_config_files: reading realms read_config_files: reading naslist main: max_request_time = 30 main: cleanup_delay = 5 main: max_requests = 10240 main: delete_blocked_requests = 0 main: port = 0 main: allow_core_dumps = no main: log_stripped_names = no main: log_auth = yes main: log_auth_badpass = no main: log_auth_goodpass = no main: pidfile = /var/run/radiusd.pid main: user = root main: group = root main: usercollide = no main: lower_user = no main: lower_pass = no main: nospace_user = no main: nospace_pass = no main: proxy_requests = yes proxy: retry_delay = 5 proxy: retry_count = 3 proxy: synchronous = no proxy: default_fallback = yes proxy: dead_time = 120 security: max_attributes = 200 security: reject_delay = 1 main: debug_level = 0 read_config_files: entering modules setup Module: Library search path is /usr/local/lib Module: Loaded eap eap: default_eap_type = md5 eap: timer_expire = 60 rlm_eap: Loaded and initialized the type md5 Module: Instantiated eap (eap) Module: Loaded Pam pam: pam_auth = radiusd Module: Instantiated pam (pam) Module: Loaded System unix: cache = yes unix: passwd = /etc/passwd unix: shadow = /etc/shadow unix: group = /etc/group unix: radwtmp = /var/log/radius/radwtmp unix: usegroup = no unix: cache_reload = 600 HASH: Reinitializing hash structures and lists for caching... HASH: user root found in hashtable bucket 11726 HASH: user bin found in hashtable bucket 86651 HASH: user daemon found in hashtable bucket 11668 HASH: user adm found in hashtable bucket 26466 HASH: user lp found in hashtable bucket 54068 HASH: user sync found in hashtable bucket 42895 HASH: user shutdown found in hashtable bucket 71746 HASH: user halt found in hashtable bucket 7481 HASH: user mail found in hashtable bucket 79471 HASH: user news found in hashtable bucket 5375 HASH: user uucp found in hashtable bucket 38541 HASH: user operator found in hashtable bucket 21748 HASH: user games found in hashtable bucket 47657 HASH: user ftp found in hashtable bucket 56226 HASH: user gdm found in hashtable bucket 50360 HASH: user nobody found in hashtable bucket 99723 HASH: user mcnuttj found in hashtable bucket 94877 HASH: user rohrss found in hashtable bucket 6971 HASH: user jscan found in hashtable bucket 11447 HASH: user gravess found in hashtable bucket 76481 HASH: user graves found in hashtable bucket 64346 HASH: user
EAP-MD5: Password sources
Okay, new question: Now that I have the NAS talking to the RADIUS server properly, I need the RADIUS server to use something other than hard-coded passwords when it authenticates using Auth-Type := EAP. Here's an example from /usr/local/etc/raddb/users: gilpina Auth-Type := EAP Port-Priority = Platinum, Tunnel-Private-Group-Id = 201, Tunnel-Type = 13, Tunnel-Medium-Type = 6, Service-Type = Framed, NAS-Port-Type = Ethernet What would be the proper syntax for something like this: gilpinaAuth-Type := EAP, Password == PAM or gilpinaAuth-Type := EAP, Password == Unix ...so that the server checks the password against an external source, rather than a password hard-coded into the users file? Thanks! Justin McNutt Network Systems Analyst - Expert DNPS, Mizzou Telecom (573) 882-5183 One IP to rule them all, one IP to find them, One IP to bring them all, and in the darkness BIND them, In the land of Ether, where the packets fly. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-MD5 ?
Again, I don't understand why you have it set up to do PAM authentication, in addition to EAP. It should do one OR the other. Actually, I'm planning to do this myself... The EAP client (Aironet, BPS2K, etc.) authenticates to FreeRADIUS, but FreeRADIUS itself needs authoritative information somewhere, hence PAM. I, for example, wish to authenticate users against a Kerberos server, so my unix machines use PAM and pam_krb5.so. So with FreeRADIUS, I should (hopefully) be able to use the Kerberos server (via PAM) to *authenticate* users, but use the raddb/users database to *authorize* users (EAP attributes). --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP question
Nope. Triple-checked the shared secret. They match. Only one RADIUS server in this setup, not separate auth and acct (or did I misunderstand your suggestion?). If shared secret is right then we need to figure out, where the problem is. Can you send the radius logs. As Alan suggested can you also verify that Nortel switch that you are using is rfc 2869 compliant for Message Authenticator. We're checking with Nortel to make sure the BPS is truly RFC 2869 compliant. If so (if they say it's supposed to be), we'll run some more attempts and send you the logs. Run with -X when we do? --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP question
Okay, I patched misc.c to get around the gethostbyaddr_r problems in Linux (thanks for the information, everyone!) and now I'm trying to get EAP to work. Preface: The server compiles and runs. Libraries: glibc-2.2.4 openssl-0.9.6a UCD SNMP 4.1.2 (will upgrade soon) Linux-PAM 0.75 We're using Nortel switches and two different Auth-Types (PAM and EAP). The BayStack 450's and Passport 8600's can authenticate me (Auth-Type PAM) and I get in with the correct access depending upon the attributes I set, so I'm pretty sure I've got clients.conf, users, and radiusd.conf set up correctly (mostly). Now we're trying to get a Business Policy Switch 2000 (BayStack *460*) to do EAP authentication using the FreeRADIUS server. It should be using EAP-MD5. We're getting the requests, but radiusd throws the following into the log: [Date] Error: Received packet from 128.206.95.215 with invalid Message-Authenticator! [Date] Info: Sending duplicate authentication reply to client 128.206.95.215:1026 - ID: 63 ...repeated three times, presumably once per request from the switch. So what obvious thing am I missing here, and what sections of the config files would be useful if I posted them to this list? Thanks in advance for any advice! --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP question
[Date] Error: Received packet from 128.206.95.215 with invalid Message-Authenticator! [Date] Info: Sending duplicate authentication reply to client 128.206.95.215:1026 - ID: 63 Looks like Shared secret problem. You might also want to verify if auth acct have different shared secrets. Nope. Triple-checked the shared secret. They match. Only one RADIUS server in this setup, not separate auth and acct (or did I misunderstand your suggestion?). --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Last two snapshots don't compile
A number of BSD systems have taken the non-thread-safe fuctions foo(), and replaced them by thread-safe versions foo_r() It's only weird systems like Linux that have thread-safe functions returning pointers to static data. grin The way the server is written is that it will use the thread-safe versions if they exist. If not, it won't use them. Yup. I figured you were doing something like that with: #ifndef HAVE_GETHOSTBYADDR_R however: misc.c: In function `ip_hostname': misc.c:57: warning: passing arg 7 of `gethostbyaddr_r' from incompatible pointer type misc.c:57: too few arguments to function `gethostbyaddr_r' misc.c:57: warning: assignment makes pointer from integer without a cast misc.c: In function `ip_getaddr': misc.c:90: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type misc.c:90: too few arguments to function `gethostbyname_r' misc.c:90: warning: assignment makes pointer from integer without a cast It appears that gethostbyaddr_r() always wants all eight arguments: extern int gethostbyaddr_r (__const void *__restrict __addr, __socklen_t __len, int __type, struct hostent *__restrict __result_buf, char *__restrict __buf, size_t __buflen, struct hostent **__restrict __result, int *__restrict __h_errnop) __THROW; It's too bad that my C is so rusty that I now know just enough to be dangerous. Too much Perl hacking... :-P For reference, this is on a system running Linux 2.4.14 and glibc-2.2.4. --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Last two snapshots don't compile
On my host (Slackware Linux), the last two FreeRADIUS snapshots fail to compile with this error: misc.c: In function `ip_hostname': misc.c:56: warning: passing arg 4 of `gethostbyaddr_r' from incompatible pointer type misc.c:56: warning: passing arg 5 of `gethostbyaddr_r' makes pointer from integer without a cast misc.c:56: warning: passing arg 6 of `gethostbyaddr_r' makes integer from pointer without a cast misc.c:56: too few arguments to function `gethostbyaddr_r' misc.c:56: warning: assignment makes pointer from integer without a cast misc.c:40: warning: unused variable `result' misc.c: In function `ip_getaddr': misc.c:89: warning: passing arg 5 of `gethostbyname_r' from incompatible pointer type misc.c:89: too few arguments to function `gethostbyname_r' misc.c:89: warning: assignment makes pointer from integer without a cast Gethostbyaddr_r() appears to be either GNU/Linux-specific, or FreeRADIUS-specific. I can't find a man page for this function, and gethostbyaddr(3) only shows three arguments (rather than the six or so being passed in misc.c). Anybody have a quick fix for this before I go digging through the code? Thanks! Justin McNutt Network Systems Analyst - Expert DNPS, Mizzou Telecom (573) 882-5183 One IP to rule them all, one IP to find them, One IP to bring them all, and in the darkness BIND them, In the land of Ether, where the packets fly. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
