Re: \000 in octets attribute?
Hi, I'm having a curious problem with a vendor-specific single-byte octets-attribute and attr_rewrite. Essentially, I'm trying to rewrite an ascii 0 to a single-byte 0x00 value. But after this rewrite rule, a zero-byte value is returned instead. Any way to get around this? With \001, \002, etc, all's well. (incidentally, this is freeradius version 1.0.1 in RHEL4) the RADIUS RFC forbids attributes with a terminating \000. The server knows that, and will shorten the octet attribute by cutting off the \000 - leaving an empty string behind. If your NAS really requires a trailing \000: fix the NAS. It is not RFC-compliant then. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgpRJ1xefwHBe.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: freeradius post
Hi, rlm_sql: Failed to create the pair: Unknown value for attribute ChilliSpot-Max-Output-Octets rlm_sql (sql): Error getting data from database Fix your dictionaries. This attribute doesn't exist. Isn't it Chili, not Chilli? THE ACCEPT rad_check_password: Found Auth-Type Local auth: type Local auth: user supplied User-Password matches local User-Password THE REJECT rad_check_password: Found Auth-Type Local auth: type Local auth: No password configured for the user auth: Failed to validate the user. Since you changed nothing in the server, I guess it's getting confused with this unknown attribute. It the problem persists after fixing that one, please get back to the list. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgp8zEiq4PSqz.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_detail and radrelay concurrence
hello, everyone
i use radrelay
there are errors in log from rlm_detail like
Error: rlm_detail: Couldn't open file /var/log/radius/radacct/detail-relay: Bad
file descriptor
while examine rlm_detail.c i found two places in it.
first while open (create if need) detail-file (line 204 rlm_detail.c).
second while do converting the FD to FP (line 243) after aquiring
filelock of detail file.
Bad file description error appear because radrelay
can remove detail file while rad_detail trying to aquire filelock, I
think (line 655 of radrelay.c).
rlm_detail.c:
201:if ((outfd = open(buffer, O_WRONLY | O_APPEND | O_CREAT,
202: inst-detailperm)) 0) {
203:radlog(L_ERR, rlm_detail: Couldn't open file %s: %s,
204: buffer, strerror(errno));
205:return RLM_MODULE_FAIL;
206:}
208:/*
209: * If we're not using locking, we'll just pass straight though
210: * the while loop.
211: * If we fail to aquire the filelock in 80 tries (approximately
212: * two seconds) we bail out.
213: */
214:locked = 0;
215:lock_count = 0;
216:do {
231:} while (!locked inst-locking lock_count 80);
...
239:/*
240: * Convert the FD to FP. The FD is no longer valid
241: * after this operation.
242: */
243:if ((outfp = fdopen(outfd, a)) == NULL) {
244:radlog(L_ERR, rlm_detail: Couldn't open file %s: %s,
245: buffer, strerror(errno));
246:if (inst-locking) {
247:lseek(outfd, 0L, SEEK_SET);
248:rad_unlockfd(outfd, 0);
249:DEBUG(rlm_detail: Released filelock);
250:}
251:close(outfd);
253:return RLM_MODULE_FAIL;
254:}
radrelay.c:
655:if (detail_move(r_args-detail, work) == 0) {
656:if (debug_flag 0)
657:fprintf(stderr, Moving %s to %s\n,
658:r_args-detail, work);
659:/*
660: * rlm_detail might still write
661: * something to detail.work if
662: * it opens detail before it is
663: * renamed (race condition)
664: */
665:ms_sleep(1000);
666:state = STATE_BACKLOG;
667:}
668:fpos = ftell(fp);
669:fseek(fp, 0L, SEEK_SET);
670:rad_unlockfd(fileno(fp), 0);
671:fseek(fp, fpos, SEEK_SET);
so detail_move can be called by radrelay while rad_detail already
opens detail (line 201) have outfd and try to aquire lock. after radrelay made
rad_unlockfd(fileno(fp), 0) (line 670), rlm_detail try to fdopen (line
243) and will get error.
As workaround we can give to rlm_detail recreate detail...
--- rlm_detail.c-orig 2006-06-15 12:09:43.0 +0600
+++ rlm_detail.c2006-06-15 12:22:49.0 +0600
@@ -119,6 +119,7 @@
struct stat st;
int locked;
int lock_count;
+ int opencount=0;
struct timeval tv;
REALM *proxy_realm;
charproxy_buffer[16];
@@ -195,6 +196,8 @@
*p = '/';
} /* else there was no directory delimiter. */
+
+reopen:
/*
* Open create the file, with the given permissions.
*/
@@ -241,8 +244,9 @@
* after this operation.
*/
if ((outfp = fdopen(outfd, a)) == NULL) {
- radlog(L_ERR, rlm_detail: Couldn't open file %s: %s,
- buffer, strerror(errno));
+ radlog(L_ERR, rlm_detail: Couldn't open file %s: %s. %s,
+ buffer, strerror(errno),
+ (opencount==0)?try reopen to create:return
MODULE_FAIL);
if (inst-locking) {
lseek(outfd, 0L, SEEK_SET);
rad_unlockfd(outfd, 0);
@@ -250,7 +254,10 @@
}
close(outfd);
- return RLM_MODULE_FAIL;
+ if (opencount++ == 0)
+ goto reopen;
+ else
+ return RLM_MODULE_FAIL;
}
/*
btw, why to sleep 1000ms on [EMAIL PROTECTED]
how rlm_detail can write something to detail.work, while file is locked
by radreplay?
Mike.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
On 2006-06-15 07:50, Stefan Winter [EMAIL PROTECTED] wrote: Hi, I'm having a curious problem with a vendor-specific single-byte octets-attribute and attr_rewrite. Essentially, I'm trying to rewrite an ascii 0 to a single-byte 0x00 value. But after this rewrite rule, a zero-byte value is returned instead. Any way to get around this? With \001, \002, etc, all's well. (incidentally, this is freeradius version 1.0.1 in RHEL4) the RADIUS RFC forbids attributes with a terminating \000. The server knows that, and will shorten the octet attribute by cutting off the \000 - leaving an empty string behind. If your NAS really requires a trailing \000: fix the NAS. It is not RFC-compliant then. Essentially, the vendor-specific attribute value is a 1-byte unsigned integer, not a string. Haven't done a live test yet, so I do not know how it handles the empty value. Perhaps all goes well. I'll let you know. My rfc-reading seems to contradict you a little bit, though? RFC2869 section 5: Note that none of the types in RADIUS terminate with a NUL (hex 00). In particular, types text and string in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [8] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings. -- Erik Bolsø Linpro AS - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
PEAP
Hi All, I just want to configure freeradius with PEAP ( MS-Chap V2) . iam new to freeradius and certificates. I just want to clear from experts here that does I need any certificate in client side if I use my ownca with open SSL ? Thanks for help Regards Naveen - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Essentially, the vendor-specific attribute value is a 1-byte unsigned integer, not a string. Haven't done a live test yet, so I do not know how it handles the empty value. Perhaps all goes well. I'll let you know. Then you are supposed to use the integer type, not octets (then, you don't even have to jump through hoops to achieve a 0: just use the integer 0, no need for \000). My rfc-reading seems to contradict you a little bit, though? No. I read this section quite a few times. octets is another word for string, i.e. treat what is in there as undistinguished octets (as opposed to: treat it as an integer). And that's why the section of RFC 2869 is perfectly right: you wanted to send a string that has a \000 (= hex 00, = NUL) as last character. And that's forbidden: RFC2869 section 5: Note that none of the types in RADIUS terminate with a NUL (hex 00). In particular, types text and string in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [8] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgpxiDC8yyzfv.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP
Hi (sorry, I'm not Alan, hope you don't mind) I just want to configure freeradius with PEAP ( MS-Chap V2) . iam new to freeradius and certificates. I just want to clear from experts here that does I need any certificate in client side if I use my ownca with open SSL ? No. PEAP can do without certs on the client side. You will need one for your server though. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgpIFpG9pRJb4.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Stefan Winter [EMAIL PROTECTED] writes: I'm having a curious problem with a vendor-specific single-byte octets-attribute and attr_rewrite. Essentially, I'm trying to rewrite an ascii 0 to a single-byte 0x00 value. But after this rewrite rule, a zero-byte value is returned instead. Any way to get around this? With \001, \002, etc, all's well. (incidentally, this is freeradius version 1.0.1 in RHEL4) the RADIUS RFC forbids attributes with a terminating \000. The server knows that, and will shorten the octet attribute by cutting off the \000 - leaving an empty string behind. If your NAS really requires a trailing \000: fix the NAS. It is not RFC-compliant then. RFC 2865 says Note that none of the types in RADIUS terminate with a NUL (hex 00). In particular, types text and string in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [7] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings. There is nothing here that forbids an attribute containing nothing but a NUL, or ending in NUL. The point is that the NUL in that case must be a *significant part* of the attribute value. RADIUS clients and servers MUST *handle* the NULs, not silently ignore them like string terminators. That is: blah\000 and blah have different value and length, but they are both allowed as attribute values. In particular, integer attributes will often have 0 as value (just grep the dictionary VALUEs), which of course ends in 0. Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: PEAP
Mean I dont want any CA or client certificate right even if I use my ownca by Openssl ? -Original Message- From: Stefan Winter [mailto:[EMAIL PROTECTED] Sent: Thursday, June 15, 2006 5:11 PM To: [EMAIL PROTECTED]; FreeRadius users mailing list Subject: Re: PEAP Hi (sorry, I'm not Alan, hope you don't mind) I just want to configure freeradius with PEAP ( MS-Chap V2) . iam new to freeradius and certificates. I just want to clear from experts here that does I need any certificate in client side if I use my ownca with open SSL ? No. PEAP can do without certs on the client side. You will need one for your server though. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Stefan Winter [EMAIL PROTECTED] writes: Essentially, the vendor-specific attribute value is a 1-byte unsigned integer, not a string. Haven't done a live test yet, so I do not know how it handles the empty value. Perhaps all goes well. I'll let you know. Then you are supposed to use the integer type, not octets No, that would be 4 octets. A 1-octet attribute allowing any value must be of type string (in RFC language, octets in FreeRADIUS). Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Authentication with Kerberos
Hello, I would like to set up that kind of configuration : EAP-PEAP(Mschapv2) Request --- AP --- Freeradius Kerberos authentication to an Active Directory In fact i would like to use Kerberos (wich is supported by Active Directory) instead of ntlm_auth, in freeradius features list avalaible onf the official website I have found : authentication to a Windows Domain Controller (via ntlm_auth and winbindd) Kerberos authentication Anyone can confirm this possibility to use Kerberos auth with freeradius and maybe any how-to or advices ? thank you Thomas Hahusseau - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
On 2006-06-15 11:09, Stefan Winter [EMAIL PROTECTED] wrote: Essentially, the vendor-specific attribute value is a 1-byte unsigned integer, not a string. Haven't done a live test yet, so I do not know how it handles the empty value. Perhaps all goes well. I'll let you know. Then you are supposed to use the integer type, not octets (then, you don't even have to jump through hoops to achieve a 0: just use the integer 0, no need for \000). But the radius integer type is a 4-byte value, which is three bytes too long. I've tested that, it doesn't work. My rfc-reading seems to contradict you a little bit, though? No. I read this section quite a few times. octets is another word for string, i.e. treat what is in there as undistinguished octets (as opposed to: treat it as an integer). And that's why the section of RFC 2869 is perfectly right: you wanted to send a string that has a \000 (= hex 00, = NUL) as last character. And that's forbidden: Nothing forbidding a NUL here... servers and clients MUST be able to deal with embedded nulls. A 1-byte string containing just \000 seems perfectly valid to me. RFC2869 section 5: Note that none of the types in RADIUS terminate with a NUL (hex 00). In particular, types text and string in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [8] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
RFC 2865 says Note that none of the types in RADIUS terminate with a NUL (hex 00). In particular, types text and string in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [7] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings. There is nothing here that forbids an attribute containing nothing but a NUL, or ending in NUL. The point is that the NUL in that case must be a *significant part* of the attribute value. RADIUS clients and servers MUST *handle* the NULs, not silently ignore them like string terminators. Reading is a tough task, obviously. They are required NOT to end with a NUL. So, That is: blah\000 and blah have different value and length, but they are both allowed as attribute values. blah\000 is an attribute that has a hex 00 as last character, while the RFC says In particular, types text and string in RADIUS do not terminate with a NUL (hex 00). So, it is NOT allowed as an attribute value. Maybe you are confused about _embedded_ NULs. blah\000foo is perfectly fine with the RFC, since the NUL is between other parts, thus _embedded_. blah\000 however isn't. Though I have to admit that FreeRADIUS is in a way not RFC-compliant because it will not handle embedded \000s correctly. In particular, integer attributes will often have 0 as value (just grep the dictionary VALUEs), which of course ends in 0. The OP talked about octets, which is a string. If he would be talking about integer, a 0 as value would be perfectly fine. Which I told him in my previous reply. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgpL43qMBAqIc.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP
Hi, Mean I dont want any CA or client certificate right even if I use my ownca by Openssl ? sorry, I was unable to parse your question. As in: the sentence does not make sense to me. What exactly do you want to know? I'll try my best to give a generic answer... The server needs one certificate to identify itself to the clients. It does not have to be a from a real CA, you can generate one from openssl yourself. You just have to configure the client to accept the certificate that is presented by the server during authentication. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgpFwcJMYt32Y.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Hi, Then you are supposed to use the integer type, not octets No, that would be 4 octets. A 1-octet attribute allowing any value must be of type string (in RFC language, octets in FreeRADIUS). Ah. Then you are in the unlucky position that you are not allowed to send a \000 to your NAS. Integer is too long, String may not terminate with a \000. Seems a bit braindead from the NAS to require that its integers are one octet only. Why not take a normal integer and restrict the allowed values to 0-255? Are bits a scarce resource where this thing comes from? I'd really like to hear what client exactly this is... Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgprZQyCWvabI.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Nothing forbidding a NUL here... servers and clients MUST be able to deal with embedded nulls. A 1-byte string containing just \000 seems perfectly valid to me. Did you read what I wrote about embedded vs terminating? I'm closing this incredibly pointless discussion, don't expect to hear from me again. Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgp6ZpOD5sMwC.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: public secret and public radius server. Is it secure?
Hi, this is again an example where a RadSec extension would come in extremely handy. Short wrapup: RadSec establishes connections via TCP and TLS and transports the RADIUS payload over it, so clients can be identified by their TLS certificate; IPs and shred secrets become obsolete. This is *extremely* useful, and solves a lot of deployment problems. I am working on a formal specification of RadSec right now, of which I hope it will somehow find a way into the Informational RFC track. There is a lot more potential in it than the OSC Whitepaper suggests. I'm available to work on it too, if you need help. Well, I wanted to get started in the next days. I thought of providing a rough draft, based on OSCs whitepaper, and share that with you and OSC. It will also go through a review on a (public) Task Force, the TERENA Task Force Mobility, creator of a worldwide roaming service for the education and research community: http://www.terena.nl/activities/index.php?action=set_filtersfilters[topic_id]=2 Later on, it is hopefully good enough to be considered as worthy of getting an (informational?) RFC number at the IETF. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgpvanpq65VeN.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Stefan Winter [EMAIL PROTECTED] writes: RFC 2865 says Note that none of the types in RADIUS terminate with a NUL (hex 00). In particular, types text and string in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [7] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings. There is nothing here that forbids an attribute containing nothing but a NUL, or ending in NUL. The point is that the NUL in that case must be a *significant part* of the attribute value. RADIUS clients and servers MUST *handle* the NULs, not silently ignore them like string terminators. Reading is a tough task, obviously. They are required NOT to end with a NUL. Obviously. Where in the quoted text from the RFC do you find the word end? That is: blah\000 and blah have different value and length, but they are both allowed as attribute values. blah\000 is an attribute that has a hex 00 as last character, while the RFC says In particular, types text and string in RADIUS do not terminate with a NUL (hex 00). terminate with != end with The RFC talks about NULs used as terminators. A terminator is a character that is not part of the string, but is used merely to signify the end of data. Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
On 2006-06-15 12:05, Stefan Winter [EMAIL PROTECTED] wrote: Hi, Then you are supposed to use the integer type, not octets No, that would be 4 octets. A 1-octet attribute allowing any value must be of type string (in RFC language, octets in FreeRADIUS). Ah. Then you are in the unlucky position that you are not allowed to send a \000 to your NAS. Integer is too long, String may not terminate with a \000. So I must do source-level hacks to be able to send a 1-octet \000 attribute, with current FreeRADIUS? Have I understood you correctly? No criticism implied, of course. Thanks for the help so far. -- Erik Bolsø Linpro AS - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Stefan Winter [EMAIL PROTECTED] writes: Nothing forbidding a NUL here... servers and clients MUST be able to deal with embedded nulls. A 1-byte string containing just \000 seems perfectly valid to me. Did you read what I wrote about embedded vs terminating? I'm closing this incredibly pointless discussion, don't expect to hear from me again. Too bad. I was hoping you would clarify why you think embedded excludes ending with and why you think terminating equals ending. BTW, would that mean that embedded also excludes starting with? Sorry, I know this may seem like an attempt to start a flame war. Believe me, it's not. I truly think you're misinterpreting the RFC, concluding exactly opposite to the intended meaning. Stripping NULs off the end of a string is interpreting them as string terminators. The RFC forbids this. It demands that implementations deal with embedded NULs. If FreeRADIUS strips any NULs, anywhere in the string, then FreeRADIUS is violating the RFC. IMHO. Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Hi, So I must do source-level hacks to be able to send a 1-octet \000 attribute, with current FreeRADIUS? Have I understood you correctly? At least, a more pragmatic reply. :-) Yes, in my understanding of the FR code, this would need source code modifications. Still my opinion is to instead hack the vendor of that other strange NAS/RADIUS server to not artificially require an 8-Bit integer. I'm still interested in the name of the product that behaves like that. Just to make sure I won't accidently buy it. Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgplnHVLxk4nO.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Erik Bolsø [EMAIL PROTECTED] writes: So I must do source-level hacks to be able to send a 1-octet \000 attribute, with current FreeRADIUS? Have I understood you correctly? Seems to work here, as long as the attribute is of type octets. This test file: [EMAIL PROTECTED]:/usr/local/test$ cat testfiles/3 User-Name = [EMAIL PROTECTED] Password = b NAS-Port-Type = xDSL Calling-Station-Id =\000 MS-CHAP-Challenge = 0x00 results in: [EMAIL PROTECTED]:/usr/local/test$ bin/radclient -x localhost:1812 auth testing123 -f testfiles/3 Sending Access-Request of id 178 to 127.0.0.1 port 1812 User-Name = [EMAIL PROTECTED] Password = b NAS-Port-Type = xDSL Calling-Station-Id = MS-CHAP-Challenge = 0x00 rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=178, length=20 Received on the server as: Packet-Type = Access-Request Thu Jun 15 13:55:14 2006 User-Name = [EMAIL PROTECTED] User-Password = b NAS-Port-Type = xDSL MS-CHAP-Challenge = 0x00 NAS-IP-Address = 127.0.0.1 Stripped-User-Name = ppp1 Realm = example.com Calling-Station-Id is a FreeRADIUS string, not to be confused with a RFC2865 string. MS-CHAP-Challenge is a FreeRADIUS octets type. Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
On 2006-06-15 14:00, Bjørn Mork [EMAIL PROTECTED] wrote: Erik Bolsø [EMAIL PROTECTED] writes: So I must do source-level hacks to be able to send a 1-octet \000 attribute, with current FreeRADIUS? Have I understood you correctly? Seems to work here, as long as the attribute is of type octets. Calling-Station-Id is a FreeRADIUS string, not to be confused with a RFC2865 string. MS-CHAP-Challenge is a FreeRADIUS octets type. Actually, it's the response from the server that needs to be single-byte 0x00 - if the ldap attribute in question is 0. Do tell if you find out how :) -- Erik Bolsø Linpro AS - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Authentication with Kerberos
the problem is that my wifi card (Cisco Aironet) doesn't support the TTLS i'll try to find one which support it . About TTLS is it that kind of EAP authentification with : Step 1 : TLS handshake , 1 certificat on radius server and 1 certificate on supplicant ? Step 2 : Kerberos or any other kind of authentication inside the TLS tunnel ? in fact I plan to use the PEAP authentication like that : Step 1 : building a TLS tunnel (Certificate on Radius server only) Step 2 : Supplicant sent login + hashed password Step 3 : freeradius ask Active Directory for a kerberos ticket/token Step 4 :freeradius send its token to the AD and ask for performing a search in ldap directory Step 5 : check in the token if freeradius is allowed to search inside LDAPStep 6 : comparason of hashed password. According to me that solution would remplace the ntlm auth , and it's not the supplicant which use kerberos but freeradius, to perform a secure authentication with LDAP database. could you give informations or telling me if I'm right ? thank you thomas2006/6/15, Josh Howlett [EMAIL PROTECTED]: thomas hahusseau wrote: Hello, I would like to set up that kind of configuration : EAP-PEAP(Mschapv2) Request --- AP --- Freeradius Kerberos authentication to an Active Directory This isn't possible - EAP-PEAP requires access to the plaintext passwordor NTLM hash.You should be able to do this with EAP-TTLS, however.best regards, josh. In fact i would like to use Kerberos (wich is supported by Active Directory) instead of ntlm_auth, in freeradius features list avalaible onf the official website I have found : * authentication to a Windows Domain Controller (via ntlm_auth and winbindd) * Kerberos authentication Anyone can confirm this possibility to use Kerberos auth with freeradius and maybe any how-to or advices ? thank you Thomas Hahusseau - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html-List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Hi, Seems to work here, as long as the attribute is of type octets. Hm, what exactly do you mean? Calling-Station-Id =\000 results in: Calling-Station-Id = This is the behaviour I described as fine (the \000 is kicked since it is the last character, and what remains is a completely empty attribute), and what your colleague would probably describe as bad: he thinks, the \000 should be sent in the packet. Actually, I don't think that Calling-Station-Id is on the wire at all, since empty attributes are supposed to be suppressed. And that's why the packet arrives on the server without this attribute: Received on the server as: Packet-Type = Access-Request Thu Jun 15 13:55:14 2006 User-Name = [EMAIL PROTECTED] User-Password = b NAS-Port-Type = xDSL MS-CHAP-Challenge = 0x00 NAS-IP-Address = 127.0.0.1 Stripped-User-Name = ppp1 Realm = example.com Since you _want_ the \000 to be sent, I don't see why it seems to work here? Maybe the only thing that would really give clarity about what is really happening is a pcap capture with ethereal or similar. Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgpt5uekqfyuv.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Erik Bolsø [EMAIL PROTECTED] writes: On 2006-06-15 14:00, Bjørn Mork [EMAIL PROTECTED] wrote: Seems to work here, as long as the attribute is of type octets. Calling-Station-Id is a FreeRADIUS string, not to be confused with a RFC2865 string. MS-CHAP-Challenge is a FreeRADIUS octets type. Actually, it's the response from the server that needs to be single-byte 0x00 - if the ldap attribute in question is 0. Do tell if you find out how :) Seems to work as expected too. Proxy-State is of octets type and RFC2865 requires the server to return it unchanged, which it does: [EMAIL PROTECTED]:/usr/local/test$ bin/radclient -x localhost:1812 auth testing123 -f testfiles/3 Sending Access-Request of id 20 to 127.0.0.1 port 1812 User-Name = [EMAIL PROTECTED] Password = b NAS-Port-Type = xDSL Calling-Station-Id = blah Proxy-State = 0x00 rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=20, length=23 Proxy-State = 0x00 Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Stefan Winter [EMAIL PROTECTED] writes: Seems to work here, as long as the attribute is of type octets. Hm, what exactly do you mean? Calling-Station-Id =\000 results in: Calling-Station-Id = This is the behaviour I described as fine (the \000 is kicked since it is the last character, In fact, the string will always be cut off at \000. But I guess this may be caused by the files parser and/or radclient. and what remains is a completely empty attribute), and what your colleague would probably describe as bad: he thinks, the \000 should be sent in the packet. Actually, I don't think that Calling-Station-Id is on the wire at all, since empty attributes are supposed to be suppressed. And that's why the packet arrives on the server without this attribute: Correct. And as long as the resulting string on the client is , then that's also correct behaviour. No discussion there Received on the server as: Packet-Type = Access-Request Thu Jun 15 13:55:14 2006 User-Name = [EMAIL PROTECTED] User-Password = b NAS-Port-Type = xDSL MS-CHAP-Challenge = 0x00 NAS-IP-Address = 127.0.0.1 Stripped-User-Name = ppp1 Realm = example.com Since you _want_ the \000 to be sent, I don't see why it seems to work here? Maybe the only thing that would really give clarity about what is really happening is a pcap capture with ethereal or similar. Notice the MS-CHAP-Challenge. That's why I said as long as the attribute is of type octets. Calling-Station-Id is truncated at the first NUL. MS-CHAP-Challenge is transmitted, even if it contains just a single NUL octet Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Notice the MS-CHAP-Challenge. That's why I said as long as the attribute is of type octets. Calling-Station-Id is truncated at the first NUL. MS-CHAP-Challenge is transmitted, even if it contains just a single NUL octet Okay, could you try to put 0x00 into the Calling-Station-Id and \000 into the MS-CHAP-Chellenge? Just to make sure it's not the notation or something, like that MS-CHAP-Challenge transmits the four characters 0,x,0,0. Or something similar. Still an ethereal capture would be great. Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgpDHMwiAs2eA.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius 1.1.1: 'sqlippools' concurrency problems
Alan DeKok [EMAIL PROTECTED] wrote: A simple solution would be to go to the bottom of rlm_sqlippool.c, and change it from RLM_TYPE_THREAD_SAFE to RLM_TYPE_THREAD_UNSAFE. Then re-compile re-install. That would be the case if I only had one single radiusd running, however as already mentioned this solution encompasses a number of radius servers each with its own mysql server adn the same storage (NDB cluster) behind the scenes i.e. virtually sharing data storage. By implementing the suggestion (which by the way didn't know it was possible so thanks for the tip) I would only solve it for one radius server (at the expense of a lower performance) but not wen several radius servers are at play. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Stefan Winter [EMAIL PROTECTED] writes: Notice the MS-CHAP-Challenge. That's why I said as long as the attribute is of type octets. Calling-Station-Id is truncated at the first NUL. MS-CHAP-Challenge is transmitted, even if it contains just a single NUL octet Okay, could you try to put 0x00 into the Calling-Station-Id That will be parsed as the 4 octet string 0x00. and \000 into the MS-CHAP-Chellenge? Just to make sure it's not the notation or something, like that MS-CHAP-Challenge transmits the four characters 0,x,0,0. Or something similar. Still an ethereal capture would be great. Capturing using Proxy-State should illustrate it: Capturing on lo Frame 1 (113 bytes on wire, 113 bytes captured) Arrival Time: Jun 15, 2006 15:27:14.775347000 Time delta from previous packet: 0.0 seconds Time since reference or first frame: 0.0 seconds Frame Number: 1 Packet Length: 113 bytes Capture Length: 113 bytes Protocols in frame: eth:ip:udp:radius Ethernet II, Src: 00:00:00:00:00:00, Dst: 00:00:00:00:00:00 Destination: 00:00:00:00:00:00 (00:00:00_00:00:00) Source: 00:00:00:00:00:00 (00:00:00_00:00:00) Type: IP (0x0800) Internet Protocol, Src Addr: 127.0.0.1 (127.0.0.1), Dst Addr: 127.0.0.1 (127.0.0.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 00.. = Differentiated Services Codepoint: Default (0x00) ..0. = ECN-Capable Transport (ECT): 0 ...0 = ECN-CE: 0 Total Length: 99 Identification: 0x (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x3c88 (correct) Source: 127.0.0.1 (127.0.0.1) Destination: 127.0.0.1 (127.0.0.1) User Datagram Protocol, Src Port: 32921 (32921), Dst Port: radius (1812) Source port: 32921 (32921) Destination port: radius (1812) Length: 79 Checksum: 0xfe62 (incorrect, should be 0x4ab0) Radius Protocol Code: Access Request (1) Packet identifier: 0x1c (28) Length: 71 Authenticator: 0x05D6BB4C4F13A6F3462324A77500B3CC Attribute value pairs t:User Name(1) l:18, Value:[EMAIL PROTECTED] User-Name: [EMAIL PROTECTED] t:User Password(2) l:18, Value:6B46A0A335701FC95CED632EFBD6708E t:NAS Port Type(61) l:6, Value:xDSL(16) t:Calling Station Id(31) l:6, Value:blah Calling-Station-Id: blah t:Proxy State(33) l:3, Value:00 Frame 2 (65 bytes on wire, 65 bytes captured) Arrival Time: Jun 15, 2006 15:27:15.792309000 Time delta from previous packet: 1.016962000 seconds Time since reference or first frame: 1.016962000 seconds Frame Number: 2 Packet Length: 65 bytes Capture Length: 65 bytes Protocols in frame: eth:ip:udp:radius Ethernet II, Src: 00:00:00:00:00:00, Dst: 00:00:00:00:00:00 Destination: 00:00:00:00:00:00 (00:00:00_00:00:00) Source: 00:00:00:00:00:00 (00:00:00_00:00:00) Type: IP (0x0800) Internet Protocol, Src Addr: 127.0.0.1 (127.0.0.1), Dst Addr: 127.0.0.1 (127.0.0.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 00.. = Differentiated Services Codepoint: Default (0x00) ..0. = ECN-Capable Transport (ECT): 0 ...0 = ECN-CE: 0 Total Length: 51 Identification: 0x (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x3cb8 (correct) Source: 127.0.0.1 (127.0.0.1) Destination: 127.0.0.1 (127.0.0.1) User Datagram Protocol, Src Port: radius (1812), Dst Port: 32921 (32921) Source port: radius (1812) Destination port: 32921 (32921) Length: 31 Checksum: 0xfe32 (incorrect, should be 0xf019) Radius Protocol Code: Access Reject (3) Packet identifier: 0x1c (28) Length: 23 Authenticator: 0x9696A6B7A298FC56A04A283D9C0124E9 Attribute value pairs t:Proxy State(33) l:3, Value:00 Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
Great, thanks. Then my guess is that xlat (which is invoked in radiusd to mangle strings) strips the value, while things work good on the client side, which doesn't use xlat. I think xlat also isn't involved with Proxy-State and friends, so these are untouched. But this is getting beyond my knowledge. Maybe someone with more karma can jump in here? Especially if it's even *desired* to generate \000 octet values... Greetings, Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473 pgpITHQo9PJUJ.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: \000 in octets attribute?
So I must do source-level hacks to be able to send a 1-octet \000 attribute, with current FreeRADIUS? Have I understood you correctly? No. Use the octets type, and set the value to 0x00. The problem comes because you're either using string type, or you're using octets, but assigning a string value of 0 to it. Don't. Use the native octets hex data, as documented. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius 1.1.1: 'sqlippools' concurrency problems
Robles Rodriguez,Alejandro [EMAIL PROTECTED] wrote: That would be the case if I only had one single radiusd running, however as already mentioned this solution encompasses a number of radius servers each with its own mysql server adn the same storage (NDB cluster) behind the scenes i.e. virtually sharing data storage. Then I suggest using a database that doesn't have concurrency problems. The ONLY way you will see this problem is if the database doesn't support multiple simultaneous writers. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RFC violations (was Re: \000 in octets attribute? )
=?iso-8859-1?Q?Bj=F8rn_Mork?= [EMAIL PROTECTED] wrote: Stripping NULs off the end of a string is interpreting them as string terminators. The RFC forbids this. No, it doesn't. And even if it did, who cares? It demands that implementations deal with embedded NULs. If FreeRADIUS strips any NULs, anywhere in the string, then FreeRADIUS is violating the RFC. IMHO. Perhaps you could try understand what the server actually does, and why. a) type octets is treated as opaque binary blobs b) type string can't have embedded NUL's, because they are used in C as end-of-string markers. This is perfectly compatible with the RFC's, because FreeRADIUS used type string for printable data, and NUL isn't printable. The RFC's use type text for printable and string for octets, because the original RFC's used string for both, which was wrong. FreeRADIUS used string for printable, and octets for non-printable, because it was started before the RFC's were fixed. And as for RFC violations, the RFC's document a recommended way to do things. Nothing more. You can violate them at will if they're wrong. (As seen in the string - string, text change above.) If the original RFC was perfect, why was it changed? FreeRADIUS violates a number of other recommendations in the RFC's, because time has shown those recommendations to be wrong or inefficient. e.g. the RFC 3579, section 2.6.1. It recommends keeping track of EAP sessions through some convoluted and fragile method. When Raghu did the original EAP implementation, he came up with a much better scheme. So much better, in fact, the there will be a new RFC within a year documenting his method as used in FreeRADIUS, and suggesting that it's probably a better way to do things. So don't get picky about RFC violations. Blind adherence to a specification is counter-productive. And if nothing else, the collective RADIUS experience of the FreeRADIUS developers is approaching the century mark. I'd be careful about arguing with people who have more experience than you in a field. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_detail and radrelay concurrence
Nicolas Baradakis [EMAIL PROTECTED] wrote: I think the fixes are in CVS head but they were never included in any stable release. Whoops, that's a bug. It should be fixed in both rlm_Detail radrelay. Alan DEKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_perl forking zombies
Greetings, I have FreeRadius 1.1.0 working on Debian 3.1 on an Intel box. When using rlm_perl, the authenticate() sub does its job and, eventually, calls a method to send an email to a certain address before returning OK. The problem is that this SMTP connection can take longer than wished, therefore I am forking the SMTP call, so the authentication process can go on as normal. The problem with this solution, though, is that--as I cannot wait for the SMTP connection to be done--the process is left as a zombie. I have, therefore, used a double forking solution, where the grandfather returns inmediately to the authorize() function, and the child forks again, and waits (waitpid()) for the new (grand)child to do the job, so no zombie is created. By itself, this works and no zombies are left behind, as expected. However, when used with FreeRadius, zombies are left behind. I have tried to 'IGNORE' SIGCHLD, to use reaper function (and all the other tricks in perlipc(1)) to no avail (I am even using Proc::Fork to simplify things so I am sure I am doing things properly). Is this a problem with my calling this inside the authenticate() function, or with rlm_perl, or...? Is this a problem with 1.1.0 and solved with a later version? Any help appreciated. thanks a lot! david PS- Perl is version 5.8.4 compiled with threads and ithreads PPS- has the RLM_PERL module documentation's been improved in more recent versions, by any chance? ___ Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. El correo electrónico vía Internet no permite asegurar la confidencialidad de los mensajes que se transmiten ni su integridad o correcta recepción. Telefónica no asume ninguna responsabilidad por estas circunstancias. This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by a professional privilege or whose disclosure is prohibited by law.If you are not the intended recipient you are hereby notified that any read, dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it. Internet e-mail neither guarantees the confidentiality nor the integrity or proper receipt of the messages sent. Telefónica does not assume any liability for those circumstances. ___ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl forking zombies
On Thu, Jun 15, 2006 at 05:42:45PM +0200, [EMAIL PROTECTED] said: Greetings, I have FreeRadius 1.1.0 working on Debian 3.1 on an Intel box. When using rlm_perl, the authenticate() sub does its job and, eventually, calls a method to send an email to a certain address before returning OK. The problem is that this SMTP connection can take longer than wished, therefore I am forking the SMTP call, so the authentication process can go on as normal. The problem with this solution, though, is that--as I cannot wait for the SMTP connection to be done--the process is left as a zombie. I have, therefore, used a double forking solution, where the grandfather returns inmediately to the authorize() function, and the child forks again, and waits (waitpid()) for the new (grand)child to do the job, so no zombie is created. By itself, this works and no zombies are left behind, as expected. However, when used with FreeRadius, zombies are left behind. I have tried to 'IGNORE' SIGCHLD, to use reaper function (and all the other tricks in perlipc(1)) to no avail (I am even using Proc::Fork to simplify things so I am sure I am doing things properly). Is this a problem with my calling this inside the authenticate() function, or with rlm_perl, or...? Is this a problem with 1.1.0 and solved with a later version? I can't tell you without seeing the script, but the way I would handle this (if I understand correctly) would be two fold. First, set up a signal handler for SIGCHLD that is a callback to a subroutine that calls waitpid(). Then, at the end of your script, if you haven't received SIGCHLD, and you're about to exit, jump to the routine that handles SIGCHLD. Then go back to just using a single fork. You could presumably track whether you're even supposed to have a child out there with a variable, so as to skip the jump at the end if you've already reaped your child process. My advice herre may be wrong, of course - I do not use rlm_perl, but I do use perl fairly regularly. -- -- | Stephen Gran | God is dead and I don't feel all too| | [EMAIL PROTECTED] | well either -- Ralph Moonen | | http://www.lobefin.net/~steve | | -- signature.asc Description: Digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_perl forking zombies
[EMAIL PROTECTED] wrote: By itself, this works and no zombies are left behind, as expected. However, when used with FreeRadius, zombies are left behind. FreeRADIUS has a wrapper around fork() that modules are expected to use. The reason is that the server is threaded, and some modules want to wait for the child to return. In a threaded environment, the SIGCHLD may be delivered to *another* thread, which causes problems. Hence the wrapper, which catches all of the SIGCHLD's, and ensures they're delivered to the correct destination. In your case, you're not calling the wrapper, so it never waits for that PID, and thus the zombie. A solution is to modify src/main/threads.c, function reap_children(). Right now it loops over known PIDs, and waits on them. Change it to wait for any PID, and then look that PID up in the list. If it's known, it's updated. Otherwise, the status is tossed. That should get rid of the zombies. If you can send a patch soon, it can make it into the next version of the server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems Using Digest-HA1 with MySQL storage backend
Alan DeKok wrote: Tavis P [EMAIL PROTECTED] wrote: mysql SELECT id,UserName,Attribute,Value,op FROM radius_check WHERE Username = '200110005339' ORDER BY id; ++--+--+--++ | id | UserName | Attribute| Value| op | ++--+--+--++ | 17 | 200110005339 | Digest-HA1 | e5282fc6665a69aed77b7d0a42d8f544 | = | ++--+--+--++ Try setting op to := Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html That fixed it, thank you Alan tavis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Bug with multiple IPs?
I have freeradius running on a machine with 2 IPs. I have it binding to all available IPs. xxx.xxx.xxx.44 is the main IP of the machine xxx.xxx.xxx.26 is the secondary IP. (eth0:1) When a request comes in on .26 freeradius processes it and THEN sends the reply out .44! Is this the way it is suppose to be acting? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems Using Digest-HA1 with MySQL storage backend
That fixed it, thank you Alan Tavis, could you please fill a 1.4.2 paragraph in the wiki that describes your FR setup with an SQL backend? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Bug with multiple IPs?
Matt wrote: I have freeradius running on a machine with 2 IPs. I have it binding to all available IPs. xxx.xxx.xxx.44 is the main IP of the machine xxx.xxx.xxx.26 is the secondary IP. (eth0:1) When a request comes in on .26 freeradius processes it and THEN sends the reply out .44! Is this the way it is suppose to be acting? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Hi Matt, Use the bind_address directive: bind_address = ip.add.res.s Regards --jm -- Jacques Marneweck http://www.powertrip.co.za/ http://www.powertrip.co.za/blog/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Bug with multiple IPs?
On Thursday 15 June 2006 13:20, Matt wrote: I have freeradius running on a machine with 2 IPs. I have it binding to all available IPs. xxx.xxx.xxx.44 is the main IP of the machine xxx.xxx.xxx.26 is the secondary IP. (eth0:1) When a request comes in on .26 freeradius processes it and THEN sends the reply out .44! Is this the way it is suppose to be acting? Did you build freeradius with the --with-udpfromto configure option? Another suggestion would be to have listen directives for each individual IP on your box, instead of the * catchall entry in radiusd.conf. I currently have one radius server setup with the second option, as the version it's running didn't have the udpfromto portion enabled (yeah yeah... time to rebuild). Kevin Bonner pgpiMqgnKxBII.pgp Description: PGP signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Bug with multiple IPs?
AHHHA! I did *not* use with-udpfromto... DOH! On 6/15/06, Kevin Bonner [EMAIL PROTECTED] wrote: On Thursday 15 June 2006 13:20, Matt wrote: I have freeradius running on a machine with 2 IPs. I have it binding to all available IPs. xxx.xxx.xxx.44 is the main IP of the machine xxx.xxx.xxx.26 is the secondary IP. (eth0:1) When a request comes in on .26 freeradius processes it and THEN sends the reply out .44! Is this the way it is suppose to be acting? Did you build freeradius with the --with-udpfromto configure option? Another suggestion would be to have listen directives for each individual IP on your box, instead of the * catchall entry in radiusd.conf. I currently have one radius server setup with the second option, as the version it's running didn't have the udpfromto portion enabled (yeah yeah... time to rebuild). Kevin Bonner - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FreeRadios rlm_sql dumps if databaase server hiccups
Hi, We use FreeRadius with unixODBC and the rlm_sql to connect to a Microsoft SQL database. All works great... except if the SQL database goes down, firewall has the translate table, someone trips over a network cable anything that causes the connection between the radius and SQL to be disturbed, it just says There are no DB handles available instead of reconnecting... the only way I've found to reconnect, is to restart... Any comments or thoughts on this problem? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Openvpn server and Freeradius client
running: Redhat Enterprise Linux version 4 Openvpn 2.0.7 (server) freeradius pam_radius-1.3.16 (client) Using the above the Openvpn server will authenticate an Openvpn client using a radius server on a remote machine. The above ONLY works when the username supplied by the Openvpn client is found in the passwd file on the Openvpn server. Yes it does use the radius server to authenticate. As you can imagine this is not the behavior I want. I have no clue where the problem(s) is/are?! Is it redhat, Openvpn, Freeradius or a combination of the three? Does anyone have a clue, hint, or idea what the problem might be? Can anyone point me in the right direction? hal - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FreeRADIUS + LDAP Authentication/Authorization + MySQL Accounting
Hello, I have been researching the use of FreeRADIUS on my network for the past few days. I'm not sure if FreeRADIUS can do what I want. Here is a list of my requirements: -Authentication through LDAP -Authorization through LDAP -Accounting through MySQL I have multiple Cisco and Foundry devices on my network. The RADIUS server will primarily be used for AAA for Telnet/SSH logins and eventually VPN dialin accounts. Is FreeRADIUS the software I should use? Thank you, Dan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: FreeRADIUS + LDAP Authentication/Authorization + MySQL Accounting
-Authentication through LDAP YES. Using it currently ! -Authorization through LDAP YES. See above :) -Accounting through MySQL YES. Doing traffic accounting. I have multiple Cisco and Foundry devices on my network. The RADIUS server will primarily be used for AAA for Telnet/SSH logins and eventually VPN dialin accounts. Is FreeRADIUS the software I should use? RADIUS provides AAA features and freeRADIUS is just one hell of a software :) I am using ProCurve with RADIUS support and I didnt have any troubles setting it up. ProCurve is based ( IMHO ) on Cisco software ( not 100% ) so you should be able to do whatever you need. Regards, Edvin Seferovic - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
