Ah, I see what you mean. Ok that will work as well ;-)
Paul
Kostas Kalevras wrote:
> On Sun, 7 Dec 2003, Alan DeKok wrote:
>
>
>>Paul Sijben <[EMAIL PROTECTED]> wrote:
>>
>>>I found now WHY a change in attr_rewrite when used in pre-Proxy does not
>>>work. It operates on request->packet rather
Alan DeKok wrote:
> Paul Sijben <[EMAIL PROTECTED]> wrote:
>
>>I found now WHY a change in attr_rewrite when used in pre-Proxy does not
>>work. It operates on request->packet rather than request->proxy.
>
>
> That should be fixed.
>
>
>>Now the question is which ought to be fixed; the call
On Sun, 7 Dec 2003, Alan DeKok wrote:
> Paul Sijben <[EMAIL PROTECTED]> wrote:
> > I found now WHY a change in attr_rewrite when used in pre-Proxy does not
> > work. It operates on request->packet rather than request->proxy.
>
> That should be fixed.
>
> > Now the question is which ought to be f
Paul Sijben <[EMAIL PROTECTED]> wrote:
> I found now WHY a change in attr_rewrite when used in pre-Proxy does not
> work. It operates on request->packet rather than request->proxy.
That should be fixed.
> Now the question is which ought to be fixed; the call to pre-proxy in
> procy.c
Absolu
I found now WHY a change in attr_rewrite when used in pre-Proxy does not
work. It operates on request->packet rather than request->proxy.
Now the question is which ought to be fixed; the call to pre-proxy in
procy.c or the pre-proxy chain that uses standard calls to operate on
the request?
I am n
> I am happy to help fix it as I need this to work soon. However I would
> appreciate some pointers where to look.
src/lib/valuepair.c, function paircreate()
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
James,
this looks like the same thing I am seeing in both attr_rewrite and with
rlm_perl.
I am afraid this is a bug.
I am happy to help fix it as I need this to work soon. However I would
appreciate some pointers where to look.
Paul
James Nedila wrote:
> freeradius-0.9.3
>
>
Alain cocconi <[EMAIL PROTECTED]> wrote:
> I had a problem with xlat that didn't care about last char if it was '$' or
> '%' or '\' so I trace it and found that
> if the last char was one of them the code was not executed... so if I'm not
> wrong this little patch should solve it
Yes, it does,
Hi,
I had a problem with xlat that didn't care about last char if it was '$' or
'%' or '\' so I trace it and found that
if the last char was one of them the code was not executed... so if I'm not
wrong this little patch should solve it
thank
--- xlat.c.orig Tue Mar 18 16:50:54 2003
+++ xlat.c
"Chris Knipe" <[EMAIL PROTECTED]> wrote:
> radius_xlat: Running registered xlat function of module exec for string
> '/bin/echo Nas-Port-Id = 0'
> Segmentation fault (core dumped)
...
> Even though it may be wrong (I'm pretty sure it is), FR shouldn't core
> IMHO...
Have you read the docume
radius_xlat: Running registered xlat function of module exec for string
'/bin/echo Nas-Port-Id = 0'
rlm_exec (exec): Executing /bin/echo Nas-Port-Id = 0
radius_xlat: '/bin/echo Nas-Port-Id = 0'
Exec-Program: /bin/echo Nas-Port-Id = 0
Exec-Program output: Nas-Port-Id = 0
Exec-Program-Wait: value-pa
On Wed, 2003-10-08 at 17:55, Chris Parker wrote:
> At 10:45 AM 10/8/2003, Josh Howlett wrote:
> >I am using freeradius (0.9) to proxy RADIUS packets.
> >
> >I have run into a possible bug. A username with a Windows domain
> >prepended to the user in the format "C
At 10:45 AM 10/8/2003, Josh Howlett wrote:
I am using freeradius (0.9) to proxy RADIUS packets.
I have run into a possible bug. A username with a Windows domain
prepended to the user in the format "CC\\username" gets proxied in the
format "C\\username"; because th
I am using freeradius (0.9) to proxy RADIUS packets.
I have run into a possible bug. A username with a Windows domain
prepended to the user in the format "CC\\username" gets proxied in the
format "C\\username"; because the domain is "CC" the authentication
fails:
(i
In other news for Fri, Oct 03, 2003 at 10:57:14AM -0400, Alan DeKok has been seen
typing:
> [EMAIL PROTECTED] (Rens Houben) wrote:
> > Okay, so is this a configuration error on my part (and if so, where do I
> > start looking to fix it?) or a bug in freeradius?
> It
[EMAIL PROTECTED] (Rens Houben) wrote:
> > Because no one made it.
>
> Okay, so is this a configuration error on my part (and if so, where do I
> start looking to fix it?) or a bug in freeradius?
It's a bug in the server.
As for how to fix it, I already said that
In other news for Fri, Oct 03, 2003 at 10:01:36AM -0400, Alan DeKok has been seen
typing:
> Rens Houben <[EMAIL PROTECTED]> wrote:
> > So why didn't it?
> Because no one made it.
Okay, so is this a configuration error on my part (and if so, where do I
start looking
Rens Houben <[EMAIL PROTECTED]> wrote:
> > The chain of functions in rlm_preprocess should pass a REQUEST* data
> > structure, too.
>
> So why didn't it?
Because no one made it.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
In other news for Thu, Oct 02, 2003 at 04:42:17PM -0400, Alan DeKok has been seen
typing:
> Rens Houben <[EMAIL PROTECTED]> wrote:
> > I'm aware of that. I'm wondering why, but that traceback's about as far
> > as I got.
> The chain of functions in rlm_preprocess should pass a REQUEST* data
Rens Houben <[EMAIL PROTECTED]> wrote:
> > The issue is that the paircmp() call in hunt_paircmp(), of
> > rlm_preprocess, passes a NULL for the REQUEST* data structure. It
> > shouldn't.
>
> I'm aware of that. I'm wondering why, but that traceback's about as far
> as I got.
The chain of fun
In other news for Thu, Oct 02, 2003 at 02:37:41PM -0400, Alan DeKok has been seen
typing:
> [EMAIL PROTECTED] (Rens Houben) wrote:
> > This error occurs when the calling IP address matches an entry in the
> > huntgroups, regardless of any other information in the database.
> The issue appears t
[EMAIL PROTECTED] (Rens Houben) wrote:
> This error occurs when the calling IP address matches an entry in the
> huntgroups, regardless of any other information in the database.
The issue appears to be that the entry in the 'huntgroups' file is
doing a comparison using the 'Group' attribute. It
I've been working with Freeradius for some time now, and for some reason
whenever I tried to configure huntgroups, a segfault occurred. Recently
I got back to work on it and got around to pushing the unstripped
version through gdb, as well as adding an insane number of extra DEBUG2
statements throu
eger attribute,
empty string) a special case for pairmake, because such a bug could easily
be introduced by somebody not aware of this special case.
peter
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Peter Stamfest <[EMAIL PROTECTED]> wrote:
> The problem surfaces through the return of NULL at line 601 in
> pairparsevalue in src/lib/valuepair.c which makes pairmake return NULL in
> the case of an integer that does not start with a digit ("" does not start
> with a digit).
Ah. Fixed, thanks.
On Tue, 9 Sep 2003, Alan DeKok wrote:
> Date: Tue, 09 Sep 2003 14:19:49 -0400
> From: Alan DeKok <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: Minor (but crashing) bug in rlm_mschap
>
> Peter Stamfest <[EMAIL PROTECTE
Peter Stamfest <[EMAIL PROTECTED]> wrote:
> With freeradius-0.9.1 radiusd constantly crashed (using radiusd -X) when
> doing MSCHAP. I tracked the problem to the code that generates the
> SMB-Account-CTRL value from SMB-Account-CTRL-TEXT if SMB-Account-CTRL was
> missing (BTW: I am using LDAP to st
Hi there,
With freeradius-0.9.1 radiusd constantly crashed (using radiusd -X) when
doing MSCHAP. I tracked the problem to the code that generates the
SMB-Account-CTRL value from SMB-Account-CTRL-TEXT if SMB-Account-CTRL was
missing (BTW: I am using LDAP to store data). The integer value for
SMB-A
Alan DeKok wrote:
>Craig <[EMAIL PROTECTED]> wrote:
>
>
>>I have tried to do the following to reject people who don't provide their
>>caller ID.
>>
>>
>...
>
> It's a bug. I've looked at the code, and it appears that there are
to reject people who don't provide
their
caller ID.
...
It's a bug. I've looked at the code, and it appears that there are
situations where !* and =* don't work.
This may be fixed before 0.9, and it SHOULD be fixed before 1.0.
Alan DeKok.
- List info/subscri
llowing to reject people who don't provide their
caller ID.
...
It's a bug. I've looked at the code, and it appears that there are
situations where !* and =* don't work.
This may be fixed before 0.9, and it SHOULD be fixed before 1.0.
Alan DeKok.
-
List info/subscr
wrote:
I have tried to do the following to reject people who don't provide their
caller ID.
...
It's a bug. I've looked at the code, and it appears that there are
situations where !* and =* don't work.
This may be fixed before 0.9, and it SHOULD be fixed bef
If you have this in your sql.attrmap file then it should go to right place
checkItem Expiration Expiration
I am using dialupadmin also and works fine to me
alantu wrote:
> HI all
> when use dialupadmin to add the expiration attribute to users,the attribute always
> add
HI all
when use dialupadmin to add the expiration attribute to users,the attribute always
addes to the "radreply" not the "radcheck" .
How to order it add to "radcheck" tables?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
driver modules,
> e.g. DB2.
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of
> > Alan DeKok
> > Sent: Thursday, July 31, 2003 7:08 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Newbie-ish HUP qu
wbie-ish HUP question (0.9.0) (solution - a bug?)
>
>
> Peter Nixon <[EMAIL PROTECTED]> wrote:
> > If I have time (and no one else beats me to it) I will
> implement this
> > tonight..
>
> Please also get rid of the "not_implemented" function in
Peter Nixon <[EMAIL PROTECTED]> wrote:
> If I have time (and no one else beats me to it) I will implement this
> tonight..
Please also get rid of the "not_implemented" function in
sql_postgresql.c. It's evil.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/lis
not a good
> > thing :)
>
> OK, did some further testing and have come to the conclusion it is a bug
> (developers, opinions ;)
>
> Basically, without looking at it in too much detailed, I worked out that
> the daemon was calling sql_destroy_socket on the rlm_sql_postgres mod
ve also
> found, it does
> the same thing with any signal sent to the process; it outputs
> that "Error:
> sql_postgresql: calling unimplemented" message and dies. Probably
> not a good
> thing :)
>
OK, did some further testing and have come to the conclusion it is
On Thu, Jul 31, 2003 at 10:11:46AM +0200, Loboda Adam wrote:
> I guess I've found another bug in freeradius. I'm now using freeradius 0.81
> running on Solaris 7 / sparc
> I got turned on authentication against /etc/shadow, /etc/passwd, /etc/group
> The problem is when the
Hi everyone
I guess I've found another bug in freeradius. I'm now using freeradius 0.81
running on Solaris 7 / sparc
I got turned on authentication against /etc/shadow, /etc/passwd, /etc/group
The problem is when the line of definition for some group located in
/etc/group file e
Chris Parker writes (in part):
>
> Wow, you caught that fast. It was disabled about 30 minutes ago
> due to a spider from China crawling the site and trying to recurse
> throught the cvs archives.
>
> Failing the pretty GUI, there is always the command line cvs interface.
>
> http://www.freeradi
"Vic Abell" <[EMAIL PROTECTED]> wrote:
>
> Unfortunately it's not possible for me to read the code,
> because the CVS web interface at:
>
> http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/
>
> returns "Internal Server Error."
>
> Is there another method to access the CVS archives?
At 11:04 AM 7/29/2003 -0500, Vic Abell wrote:
Alan DeKok writes:
>
> "Vic Abell" <[EMAIL PROTECTED]> wrote:
> > > *last = t;
> > > last = &t->next
> >
> > If t == NULL, won't &t->next attempt to de-reference a
> > NULL pointer?
>
> Yes, but I didn't show all of the code I commited.
>
> Chec
Alan DeKok writes:
>
> "Vic Abell" <[EMAIL PROTECTED]> wrote:
> > > *last = t;
> > > last = &t->next
> >
> > If t == NULL, won't &t->next attempt to de-reference a
> > NULL pointer?
>
> Yes, but I didn't show all of the code I commited.
>
> Check the CVS version of files.c
>
> > Isn't l
"Vic Abell" <[EMAIL PROTECTED]> wrote:
> > *last = t;
> > last = &t->next
>
> If t == NULL, won't &t->next attempt to de-reference a
> NULL pointer?
Yes, but I didn't show all of the code I commited.
Check the CVS version of files.c
> Isn't last (currently) supposed to point to the end
Alan DeKok wrote:
>
> "Vic Abell" <[EMAIL PROTECTED]> wrote:
> > When processing a $INCLUDE directive, the following code in
> > pairlist_read() of main/files.c may cause any accumulated
> > pair information to be lost when the recursion of the function
> > returns a NULL to its PAIR_LIST **list ar
"Vic Abell" <[EMAIL PROTECTED]> wrote:
> When processing a $INCLUDE directive, the following code in
> pairlist_read() of main/files.c may cause any accumulated
> pair information to be lost when the recursion of the function
> returns a NULL to its PAIR_LIST **list argument. This can
> happen, fo
When processing a $INCLUDE directive, the following code in
pairlist_read() of main/files.c may cause any accumulated
pair information to be lost when the recursion of the function
returns a NULL to its PAIR_LIST **list argument. This can
happen, for example, when the users file has a $INCLUDE tha
Let a user entry in raddb/users
DEFAULT Auth-Type := Accept
Reply-Message := `%{sql:SELECT 'before %{User-Name:-default value} after'}`
Debug output:
Sat Jul 26 22:43:12 2003 : Debug: Thread 1 handling request 0, (1 handled so far)
User-Name = "[EMAIL PROTECTED]"
User-Passw
On _2003-07-16 at 11:45, Boian Jordanov wrote:
> On _ 2003-07-01 at 20:20, Manuel Sousa wrote:
> > Hi all,
> >
> > I just tried the latest CVS (couple of hours ago) version and found a
> > bug when using 2 instances of the module.
>
> There is a patch a
On Wed, 2003-07-16 at 09:45, Boian Jordanov wrote:
> On _ 2003-07-01 at 20:20, Manuel Sousa wrote:
> > Hi all,
> >
> > I just tried the latest CVS (couple of hours ago) version and found a
> > bug when using 2 instances of the module.
>
> There is a pat
On _ 2003-07-01 at 20:20, Manuel Sousa wrote:
> Hi all,
>
> I just tried the latest CVS (couple of hours ago) version and found a
> bug when using 2 instances of the module.
There is a patch against latest CVS that should fix it. Enjoy.
--
Best Regards,
Boian Jordanov
r software applications, and found a vary
similar bug with the $ being the last character.
The same workaround worked for that as well. This lead me to believe that it
was either a fault of the compiler, or an external RegEx library being
called. (I may be completely off track here so dont take my word on th
Hiya
I have setup redundant {} so that should the MySQL process on the system fail,
it fails back to a secondary server.
During testing I have noticed a slight log bug (possibly :) ). If 2 servers
are used sql1 and sql2, if during operation sql1 goes away and stops responding
Manuel Sousa <[EMAIL PROTECTED]> wrote:
> I just tried the latest CVS (couple of hours ago) version and found a
> bug when using 2 instances of the module.
rlm_perl is experimental. It may not even work at all.
Alan DeKok.
-
List info/subscribe/unsubscri
On _ 2003-07-01 at 20:20, Manuel Sousa wrote:
> Hi all,
>
> I just tried the latest CVS (couple of hours ago) version and found a
> bug when using 2 instances of the module.
> I noticed that using 2 different instances the perl code of second
> instance replac
Hi all,
I just tried the latest CVS (couple of hours ago) version and found a
bug when using 2 instances of the module.
I noticed that using 2 different instances the perl code of second
instance replaces the code of the first instance, i give a couple of
examples bellow
Mike Sturdee <[EMAIL PROTECTED]> wrote:
> Being that this is in a production environment, are there any bugs or
> instibilities that would keep me from running that now?
No. Any bug which is still in the CVS head has been there since
0.8.1. Otherwise, many of the bugs in 0.8.1 hav
Being that this is in a production environment, are there any bugs or
instibilities that would keep me from running that now?
On Tue, 1 Jul 2003, Alan DeKok wrote:
> Mike Sturdee <[EMAIL PROTECTED]> wrote:
> > Haven't tried the CVS.. would it be possible to patch into the "stable"
> > release?
>
Mike Sturdee <[EMAIL PROTECTED]> wrote:
> Haven't tried the CVS.. would it be possible to patch into the "stable"
> release?
No. The code has changed too much.
In addition, we expect that the current CVS will become the next
stable release, probably on Monday.
Alan DeKok.
-
List info/su
Haven't tried the CVS.. would it be possible to patch into the "stable"
release?
On Tue, 1 Jul 2003, Alan DeKok wrote:
> Mike Sturdee <[EMAIL PROTECTED]> wrote:
> > Our new radius server "FreeRADIUS Version 0.8.1, for host
> > i386-portbld-freebsd4.8, built on Jun 29 2003 at 14:19:19" has been
>
Mike Sturdee <[EMAIL PROTECTED]> wrote:
> Our new radius server "FreeRADIUS Version 0.8.1, for host
> i386-portbld-freebsd4.8, built on Jun 29 2003 at 14:19:19" has been
> crashing/freezing with the log showing:
...
Does this happen with the latest CVS snapshot? If not, then it's
already been t
Our new radius server "FreeRADIUS Version 0.8.1, for host
i386-portbld-freebsd4.8, built on Jun 29 2003 at 14:19:19" has been
crashing/freezing with the log showing:
Tue Jul 1 08:41:57 2003 : Error: rlm_ldap: ldap_search() failed: Bad
search filter
Tue Jul 1 08:41:57 2003 : Error: rlm_ldap: ldap
Oliver Graf <[EMAIL PROTECTED]> wrote:
> hm, not null, it should do as the other possible versions and return
> the IP as string. Simply setting hp in error case to NULL should do
> it.
Added, thanks.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.ht
On Thu, Jun 26, 2003 at 07:33:22AM +0200, Oliver Graf wrote:
> On Wed, Jun 25, 2003 at 01:52:25PM -0400, Alan DeKok wrote:
> > "Alan Litster" <[EMAIL PROTECTED]> wrote:
> > > When using radtest/radclient from 20030619 on the machine to test
> > > radiusd on a box running 20030625 it works. So it se
On Wed, Jun 25, 2003 at 01:52:25PM -0400, Alan DeKok wrote:
> "Alan Litster" <[EMAIL PROTECTED]> wrote:
> > When using radtest/radclient from 20030619 on the machine to test
> > radiusd on a box running 20030625 it works. So it seems to me as if
> > something has changed with the newer radclient?
>
"Alan Litster" <[EMAIL PROTECTED]> wrote:
> When using radtest/radclient from 20030619 on the machine to test
> radiusd on a box running 20030625 it works. So it seems to me as if
> something has changed with the newer radclient?
Yeah, I hate glibc. There's no man page for gethostbyname_r, and
I've tried it on two machines, one running SuSE 8.1 the other SuSE 8.2.
'host localhost' resolves correctly on both machines and /etc/hosts
contains the correct entry.
Prior to upgrading to freeradius-snapshot-20030625.tar.gz I had
freeradius-snapshot-20030619.tar.gz running which worked correctl
Does the machine know what localhost? By default it should be in the
/etc/hosts file, but it could have been removed which may cause the
problem.
On Wednesday, June 25, 2003, at 09:43 AM, Alan Litster wrote:
Hi,
I've just upgraded my FreeRADIUS installation to the latest snapshot,
freeradi
"Alan Litster" <[EMAIL PROTECTED]> wrote:
> When I run "radtest user password 127.0.0.1 0 testing123", it works fine.
> Though when I run
> "radtest user password localhost 0 testing123" it doesn't do anything but
> respond:
>
> radclient: localhost:
>
> It doesn't even hit the radius serve
Hi,
I've just upgraded my FreeRADIUS installation to the latest snapshot,
freeradius-snapshot-20030625.tar.gz.
When I run "radtest user password 127.0.0.1 0 testing123", it works fine.
Though when I run
"radtest user password localhost 0 testing123" it doesn't do anything but
respond:
ra
Hi!
> Really didn't notice that, happened couple of times, wonder why pppd
> sends 2 acct-starts and sometimes with different session IDs.
> Sorry to report this as it ain't a bug then, and thanks for the fast
> reply.
Yes, problem in pppd's radius plug-in.
Acct-Sess
Really didn't notice that, happened couple of times, wonder why pppd
sends 2 acct-starts and sometimes with different session IDs.
Sorry to report this as it ain't a bug then, and thanks for the fast
reply.
Manuel Sousa
On Tue, 2003-06-17 at 14:54, Chris Parker wrote:
> At 02:24
At 02:24 PM 6/17/2003 +0100, Manuel Sousa wrote:
Hi, all
I've been using freeradius and noticed that sometimes the
Acct-Unique-Session-ID gave me different values for the same inputs.
A partial output of radiusd -X is:
rlm_acct_unique: Hashing 'Acct-Session-Id = "3EEF21621014",User-Name =
"noc"'
r
Hi, all
I've been using freeradius and noticed that sometimes the
Acct-Unique-Session-ID gave me different values for the same inputs.
A partial output of radiusd -X is:
rlm_acct_unique: Hashing 'Acct-Session-Id = "3EEF21621014",User-Name =
"noc"'
rlm_acct_unique: Acct-Unique-Session-ID = "889e46
c driver instead of
FreeTDS ?
Best regards,
Bangla
- Original Message -
From: "Roman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 12, 2002 12:19 PM
Subject: postgresql accounting (bug?)
> Hi!
>I use freeradius 0.5 with postgresql 7.2 on Fr
look to find out exactly what "bad thing" the
> child did to cause this.
Find out which PID is used for checkrad. If the server is sending a
TERM signal to another PID, then that's a bug. If the server IS
sending the TERM signal to checkrad, but a radiusd process is getting
xpiration: reverting to '=='
>
> Is this a bug or I miss something?
>
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Dialupadmin puts = operator for expiration by default.
freeradius complains
Invalid operator for item Expiration: reverting to '=='
Is this a bug or I miss something?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
I have freerdaus-0.8.1 and Mandake9 and portslave.
I use Simultaneous-Use :=1.
When second attemp of login is determing, freeradius runs checkrad.
* When I manualy run it - script works correctly. *
Inspite of exit code of checkrad, freeradius send stop-package to 1st
sesion,
and permit access
On Fri, 21 Feb 2003, Alan DeKok wrote:
> Kristina Pfaff-Harris <[EMAIL PROTECTED]> wrote:
> > Running 'checkrad cisco (etc)' on a certain of our ciscoes came back with
> > "Timeout: No Response from IP address". When called from radiusd, this
> > killed the radius daemon completely.
A little more
If checkrad were changed to only output a 0 instead of the dump it
currently produces when it can't connect to snmp on the NAS I think that
could possibly correct the problem, I think that radiusd only expects a 1
character response, maybe it flips when it gets 7 lines of information?
Just an idea
Kristina Pfaff-Harris <[EMAIL PROTECTED]> wrote:
> The wierd thing is, checkrad DOES respond -- it just responds with a
> timeout, and if that weren't strange enough, checkrad appears to be
> exiting normally, that is, it's not hanging or anything.
Yeah, but if it doesn't respond within 10 secon
On Fri, 21 Feb 2003, Alan DeKok wrote:
> That's confusing as all get out. The code which runs checkrad tries
> to kill it if checkrad doesn't respond. But it sends *checkrad* a
> TERM signal, and doesn't send one to the RADIUS server.
The wierd thing is, checkrad DOES respond -- it just respo
Kristina Pfaff-Harris <[EMAIL PROTECTED]> wrote:
> Running 'checkrad cisco (etc)' on a certain of our ciscoes came back with
> "Timeout: No Response from IP address". When called from radiusd, this
> killed the radius daemon completely.
That's confusing as all get out. The code which runs check
A little more info. Looks like maybe an SNMP issue with checkrad?
I modified checkrad to log what it was called as from radiusd, so that I
could recreate what happened when it crashed the server. When I say
"(etc)" below, it's shorthand for the arguments that radiusd called
checkrad with.
Runnin
While we're on the subject, I think I might be retarded. (Again)
Thanks for Kristina, I have it running checkrad properly, however,
regardless of whether it returns 2, 0, 1, -1, "cheese" .. no matter what,
it gives the LOGIN OK and wipes the old session from the radutmp.
Regards,
Justin Wheeler
On Fri, 21 Feb 2003, Adam Fladwood wrote:
> When using checkrad w/ a PM3 if the public snmp string is not set to
> 'public' in the portmaster checkrad will timeout, not that big of an
> issue - however, it causes the entire radius daemon to crash, saying it
> couldn't process signal 15, and shutdo
Just wanted to drop a message to the list about a bug that I came across,
it may already have been discovered, but doing some google searches
nothing came up.
When using checkrad w/ a PM3 if the public snmp string is not set to
'public' in the portmaster checkrad will timeout, not that
"Walter Stroebel" <[EMAIL PROTECTED]> wrote:
> Let me rephrase the bug description:
>
> My module contains the following code to determine the length of a
> attribute:
>
> if (pair->type == PW_TYPE_STRING || pair->type == PW_TYPE_IPADDR) {
>
My mistake! Mr. DeKok is absolutely right regarding the PW_TYPE_ABINARY!
I meant: PW_TYPE_OCTETS.
My apologies,
Walter.
-Original Message-
From: Alan DeKok [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 19, 2003 11:06
To: [EMAIL PROTECTED]
Subject: Re: Bug in proxy.c
"W
Fair enough, I've obviously not read all of the source and it has been some time since
I last read the RFC's.
Let me rephrase the bug description:
My module contains the following code to determine the length of a attribute:
if (pair->type == PW_TYPE_STRING || pair->type =
"Walter Stroebel" <[EMAIL PROTECTED]> wrote:
> At line 288 in the 0.8.1 version in /src/main/proxy.c
> CHAP-CHALLENGE attribute is forwarded as PW_TYPE_STRING.
> This should be PW_TYPE_ABINARY.
Huh? No. Absolutely not.
> I've checked the version currently
Title: Bug in proxy.c
At line 288 in the 0.8.1 version in /src/main/proxy.c
CHAP-CHALLENGE attribute is forwarded as PW_TYPE_STRING.
This should be PW_TYPE_ABINARY.
I've checked the version currently in CVS and the bug is still there.
Regards,
Walter.
"Ivan F. Martinez" <[EMAIL PROTECTED]> wrote:
> The radzap program has support for specifying the server IP, but it
> does not check the correct secret for the IP.
>
> Here is a patch to solve this :
Applied, thanks.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.
The radzap program has support for specifying the server IP, but it does not check the
correct secret for the IP.
Here is a patch to solve this :
--- radzap.c.oriFri Feb 7 18:07:17 2003
+++ radzap.cFri Feb 7 18:17:19 2003
@@ -245,13 +245,14 @@
return ntohs(svp->s_port);
}
"Joel Vandal" <[EMAIL PROTECTED]> wrote:
> I'm not sure if it's a normal behavior or a bug ... but if my password is
> test and I enter test123, the rlm_pap module say that my password is valid.
Yeah, it's a bug. The code should be using 'strcmp'
Hi,
I'm not sure if it's a normal behavior or a bug ... but if my password is
test and I enter test123, the rlm_pap module say that my password is valid.
When I check the source code of rlm_pap.c, I see :
if (strncmp((char *) passwd_item->strvalue,
(char *) requ
LS,
When changing over from an older version of freeradius to 0.8.1 i
decided to use the hints for our slip/ppp/mpp users. With the aid
of DEFAULT entries i than add the common attributes to the reply.
No problem sofar.
However, very few of my users have an idle timeout different from
the default
1 - 100 of 231 matches
Mail list logo
