Am Donnerstag, den 23.12.2004, 14:37 -0500 schrieb Alan DeKok:
The solution is to re-write some of the code for handling requests
timeouts. I've been looking at it recently, and have decided that
it could use some updates for other issues, and now this, too.
Sounds good! I'll wait then
Hi
I am using freeradius 1.0.1.
Let me try to understand. If a client loses its connection, we can use radzap to
comunicate with the NAS. Then it sends back a stop packet, and the login is
released. Is that correct?
But due to session_id is too long, it is not working. To fix it, we can use
On Thu, 23 Dec 2004, Carl Peterson wrote:
I am currently using freeradius as the authentication method for a chilli
hotspot. I use a Max-All-Session attribute to give prepaid users X amount of
discontinuous time. One of the users of some software I wrote to create and
monitor prepaid cards would
On Fri, Dec 24, 2004 at 09:39:58AM -0200, Luiz Gustavo Anflor Pereira wrote:
I am using freeradius 1.0.1.
Let me try to understand. If a client loses its connection, we can use radzap
to
comunicate with the NAS. Then it sends back a stop packet, and the login is
released. Is that correct?
Ok. I dont want to ask too much, but i am new on freeradius :-)
Are radzap and the radiusd server on the same machine? I have this situation,
and
it looks like they are cconcurring for the same port (1812). Is that correct?
Thanks again. Merry Christmas!!
On Fri, Dec 24, 2004 at 09:39:58AM
Luiz Gustavo Anflor Pereira [EMAIL PROTECTED] wrote:
Are radzap and the radiusd server on the same machine? I have this
situation, and it looks like they are cconcurring for the same port
(1812). Is that correct?
It's a bug in radzap. radzap shouldn't read radiusd.conf, but
should get
I'm hoping someone may be able to give me some pointers or thoughts. I have
a scenario where we have two separate external organizations who provide
service to our dialup customers. Each of these companies has their own
RADIUS servers which accept the request from whichever of the 1000's of NAS'
Hi...
My proxy setup seems to have a problem. I used the
NULL realm option for testing purposes. It looks like
this
realm NULL {
type = radius
authhost = 200.200.230.136:1812
accthost = 200.200.230.136:1813
secret = amin
}
when I send User information using Python radius
testing tools, the
л·Ç дµÀ:
To those who encounter the dead-end error :
radiusd.conf[9] Failed to link to module 'rlm_eap': unknown error
again and again:
The bug comes from rlm_eap.la. The make process introduces some
rubbish into rlm_eap.la's dependency_libs setting ¡ª¡ª '-L//libeap'
This works fine on
9 matches
Mail list logo
