Re: [PATCH] check rlm_detail writes

On Sat, Oct 23, 2010 at 02:08:29PM -0400, John Morrissey wrote:
> I've modified rlm_detail to check its writes and return RLM_MODULE_FAIL on
> short writes. I believe this should cause FreeRADIUS to avoid sending an
> Accounting-Response to the NAS, so the NAS will retry on disk-full/error
> situations.

Any feedback on this patch, Alan?

john
--

-- 
John Morrissey          _o            /\         ----  __o
jwm <at> horde.net        _-< \_          /  \       ----  <  \,
www.horde.net/    __(_)/_(_)________/    \_______(_) /_(_)__
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: [PATCH] check rlm_detail writes

John Morrissey wrote:
> On Sat, Oct 23, 2010 at 02:08:29PM -0400, John Morrissey wrote:
>> I've modified rlm_detail to check its writes and return RLM_MODULE_FAIL on
>> short writes. I believe this should cause FreeRADIUS to avoid sending an
>> Accounting-Response to the NAS, so the NAS will retry on disk-full/error
>> situations.
> 
> Any feedback on this patch, Alan?

  Looks OK.  Give me a few days, I'm out of the country on business.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Patch for memory leak in valuepair.c

Hi,

We have been experiencing a memory leak in radiusd which the attached
patch to valuepair.c appears to fix:

When a VALUE_PAIR with the 'Fall-Through' attribute is skipped over in
pairxlatmove(), 'tailfrom' is not updated. This means that the pair is
orphaned if the subsequent pair is moved.

(This is similar to the memory leak in valuepair.c fixed in 2.1.10, but
in a different part of the loop. This patch is against the 2.1.x branch
from git.)

Thanks,
James

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

radiusd -d help

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: Patch for memory leak in valuepair.c

James Ballantine wrote:
> When a VALUE_PAIR with the 'Fall-Through' attribute is skipped over in
> pairxlatmove(), 'tailfrom' is not updated. This means that the pair is
> orphaned if the subsequent pair is moved.
> 
> (This is similar to the memory leak in valuepair.c fixed in 2.1.10, but
> in a different part of the loop. This patch is against the 2.1.x branch
> from git.)

  Fixed, thanks.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: radiusd -d help

Rashard Roberts wrote:
> I have installed freeradius successfully under /etc.  I was inform by
> supervise to install under /opt/freeradius instead.  I was informed to
> use radiusd -d to tell the freeradius server where to look for the
> configuration files, but I am not familar with the handle -d. 

$ man radiusd

> I am just
> doing authentication against an AD server.  I know that I am going to
> need sbm.conf and krb5.conf files in order to run freeradius
> succesfully, but they are in the /etc directory and freeradius is in the
> /opt directory. So how do I tell freeradius where to find these files if
> freeradius is install in a completely different directory using radiusd -d?

  This is documented.

  For instructions on AD integration, see:

http://deployingradius.com

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

RE: Module-Failure-Message creation in rlm_mschap

>> Or, copy it from the request to the reply...

>Ok.  So, in rlm_eap_peap & rlm_eap_ttls, I will *copy*
>Request:Module-Failure-Message to Reply if it exists.
>Then, after restoring the saved Reply list, I will 
>*move* Reply:Module-Failure-Message back to Request
>(if it exists in the Reply list).
>
>Sound reasonable?

Hi Alan - I know you've been busy (and out of town), so I understand if you haven't had time to think about this. 
But, just in case you forgot, I thought I would "ping" you about it.  Are you ok with saving the
Module-Failure-Message Request attr. with the saved Reply attributes and then moving it back to the
Request list at time of restore?  Would you prefer to have it stored separately from the Reply attributes? 
I'd like to code the patch in a way that aligns with your preference to increase the chances of acceptance.

If you need more time to think about the best approach, that's ok too (and sorry to bug you if so).

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Re: Module-Failure-Message creation in rlm_mschap

Garber, Neal wrote:
> Hi Alan - I know you've been busy (and out of town),

  You have no idea.

> so I understand if you haven't had time to think about this.  But, just in case you forgot, I thought I would
"ping" you about it.  Are you ok with saving the Module-Failure-Message Request attr. with the saved Reply
attributes and then moving it back to the Request list at time of restore?  Would you prefer to have it stored
separately from the Reply attributes?  I'd like to code the patch in a way that aligns with your preference
to increase the chances of acceptance.

  Sure... copy it from the tunnel to the reply, and then move it back.
It's a hack, but a useful one.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

[PATCH] Add support for xlat'd challenge in rlm_eap_gtc

The FIXME in rlm_eap_gtc.c has gone on so long unloved.  God said, let 
there be xlat'ing and so there was...

This patch shamelessly steals the xlat functionality in
rlm_eap_tls.c and slaps it into rlm_eap_gtc.c, thus lettings
you do handy things such as:
----
challenge = "%{reply:Reply-Message}"
----

Signed-off-by: Alexander Clouter <alex <at> digriz.org.uk>
---
 .../rlm_eap/types/rlm_eap_gtc/rlm_eap_gtc.c        |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/src/modules/rlm_eap/types/rlm_eap_gtc/rlm_eap_gtc.c b/src/modules/rlm_eap/types/rlm_eap_gtc/rlm_eap_gtc.c
index b8d3a25..de7d6a2 100644
--- a/src/modules/rlm_eap/types/rlm_eap_gtc/rlm_eap_gtc.c
+++ b/src/modules/rlm_eap/types/rlm_eap_gtc/rlm_eap_gtc.c
 <at>  <at>  -110,14 +110,17  <at>  <at>  static int gtc_attach(CONF_SECTION *cs, void **instance)
  */
 static int gtc_initiate(void *type_data, EAP_HANDLER *handler)
 {
+	char challenge_str[1024];
 	int length;
 	EAP_DS *eap_ds = handler->eap_ds;
 	rlm_eap_gtc_t *inst = (rlm_eap_gtc_t *) type_data;

-	/*
-	 *	FIXME: call radius_xlat on the challenge
-	 */
-	length = strlen(inst->challenge);
+	if (!radius_xlat(challenge_str, sizeof(challenge_str), inst->challenge, handler->request,
NULL)) {
+		radlog(L_ERR, "rlm_eap_gtc: xlat failed.", inst->challenge);
+		return 0;
+	}
+
+	length = strlen(challenge_str);

 	/*
 	 *	We're sending a request...
 <at>  <at>  -130,7 +133,7  <at>  <at>  static int gtc_initiate(void *type_data, EAP_HANDLER *handler)
 		return 0;
 	}

-	memcpy(eap_ds->request->type.data, inst->challenge, length);
+	memcpy(eap_ds->request->type.data, challenge_str, length);
 	eap_ds->request->type.length = length;

 	/*
--

-- 
1.5.6.5

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Authentication by domain of company

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html