Spike Ilacqua [EMAIL PROTECTED] wrote:
If it works in debug, has issues in regular, check the permissions needed
to read the auth files.
I'm seeing basically the same thing, but I don't believe it's a
permision problem. The server does work in regular mode, it's only
after about 20
At 10:19 AM 8/23/2001 -0700, you wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Qinxue Chen [EMAIL PROTECTED] wrote:
The problem seems to be that the new request has the same
request ID,
request code, source IP, source port, but different vectors
(what's this?)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Qinxue Chen [EMAIL PROTECTED] wrote:
The problem seems to be that the new request has the same
request ID,
request code, source IP, source port, but different vectors
(what's this?)
It means that the request is a new one, and
No. Read the RFC. Understand how Authentication-Vector is
used. Your
case1 is correct, your case2 is handled.
The reason there is a problem is old requests are for some reason not
being cleared. That's all there is, don't try and make it
more complex,
it's a bug in the code, not
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Qinxue Chen [EMAIL PROTECTED] wrote:
The problem seems to be that the new request has the same request ID,
request code, source IP, source port, but different vectors (what's this?)
It means that the request is a new one, and
[EMAIL PROTECTED] (Miquel van Smoorenburg) wrote:
It means that the request is a new one, and different from the first
on.
The RFC's specifically allow for this.
They do? Where does it say that?. And at least for
accounting packets the vector is _supposed_ to change since the
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 15, 2001 6:57 AM
To: [EMAIL PROTECTED]
Subject: Re: Dropping conflicting authentication packet
Spike Ilacqua [EMAIL PROTECTED] wrote:
I'm trying to use freeradius 0.2 (on BSDI 4.0.1, no threads, no
sharded) with a 3COM
At 12:40 PM 8/22/2001 -0700, Qinxue Chen wrote:
I used two kinds of RADIUS servers. With Merit 3.6B, the server accept a lot
more traffic from the NAS servers. There is no single complain. With
freeradius (snapshot 08/20/01), we got a lot Dropping conflicting
authentication packets messages but
Qinxue Chen [EMAIL PROTECTED] wrote:
I used two kinds of RADIUS servers. With Merit 3.6B, the server accept a lot
more traffic from the NAS servers. There is no single complain. With
freeradius (snapshot 08/20/01), we got a lot Dropping conflicting
authentication packets messages but for only
-Original Message-
From: Chris Parker [mailto:[EMAIL PROTECTED]]
At 12:40 PM 8/22/2001 -0700, Qinxue Chen wrote:
I used two kinds of RADIUS servers. With Merit 3.6B, the
server accept a lot
more traffic from the NAS servers. There is no single complain. With
freeradius
Qinxue Chen [EMAIL PROTECTED] wrote:
What did the debug show?
With debug on, I couldn't see errors at all.
And how long did the server take to reply?
o Was the server replying to the request?
Definitely the newest request is dropped.
That is NOT an answer to the question.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Qinxue Chen [EMAIL PROTECTED] wrote:
What did the debug show?
With debug on, I couldn't see errors at all.
And how long did the server take to reply?
within miniseconds normally. Could the server cached the IDs somehow?
At 01:58 PM 8/22/2001 -0700, Qinxue Chen wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Qinxue Chen [EMAIL PROTECTED] wrote:
What did the debug show?
With debug on, I couldn't see errors at all.
And how long did the server take to reply?
within
If it works in debug, has issues in regular, check the permissions needed
to read the auth files.
I'm seeing basically the same thing, but I don't believe it's a
permision problem. The server does work in regular mode, it's only
after about 20 minutes it starts reporting Dropping conflicting
At 03:49 PM 8/22/2001 -0600, you wrote:
If it works in debug, has issues in regular, check the permissions needed
to read the auth files.
I'm seeing basically the same thing, but I don't believe it's a
permision problem. The server does work in regular mode, it's only
after about 20 minutes
From: Chris Parker [mailto:[EMAIL PROTECTED]]
At 03:49 PM 8/22/2001 -0600, you wrote:
If it works in debug, has issues in regular, check the
permissions needed
to read the auth files.
I'm seeing basically the same thing, but I don't believe it's a
permision problem. The server
Is this version 0.1, 0.2, or latest CVS?
0.2 on BSDI 4.0.1, compiled static without threads. I'll try CVS now.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
The problem seems to be that the new request has the same request ID,
request code, source IP, source port, but different vectors (what's this?)
as one of the old requests. From the problem I saw, it is not caused by the
NAS end. The freeradius didn't clear some old requests properly in the
At 05:40 PM 8/22/2001 -0700, you wrote:
The problem seems to be that the new request has the same request ID,
request code, source IP, source port, but different vectors (what's this?)
as one of the old requests. From the problem I saw, it is not caused by the
NAS end. The freeradius didn't
Spike Ilacqua [EMAIL PROTECTED] wrote:
I'm trying to use freeradius 0.2 (on BSDI 4.0.1, no threads, no
sharded) with a 3COM Total Control Hyper Arc (running V4.1.59). It
works for about 20 minutes but then stops authenticating and begins
logging Dropping conflicting authentication packet for
20 matches
Mail list logo
