Error: Received conflicting packet
Alan DeKok
aland at deployingradius.com
Mon Oct 12 16:19:27 CEST 2009
rihad wrote:
> Being 100% correct protocol-wise means nothing, if the software can't
> fit well into an environment.
So you agree that the NAS is broken.
> Just a recent example off the top of my
> head: dnscache. Its security and DNS protocol support are astonishing.
> But due to it being unable to work reasonably under certain
> circumstances, and due to its author preferring to stick with the
> arguable RFC specification which is outright buggy, I was forced to go
> back to BIND. In reply to my post Jeremy Kister was kind enough to
> describe the problem very well:
> http://marc.info/?l=djbdns&m=125265930702615&w=2
> and linked from above:
> http://securepoint.com/lists/html/djbdns/2007-01/msg00033.html
Why do you insist that FreeRADIUS is at fault, when you have already
been told that the NAS is broken? Why are you not calling Cisco, and
asking them to fix their broken NAS?
Do you hate FreeRADIUS? Are you interested in blaming it for every
problem in the network?
And your argument about RFC compliance is made to the wrong person.
There's a RADIUS RFC called "issues and fixes", which points out
problems with older RFC's, and says how they should be fixed. Guess
who's co-author? There's another RFC that's up and coming, called
"guidelines", about how to write RADIUS RFC's so that they can easily be
implemented. Guess who's co-author?
And have you looked at the FreeRADIUS source code? There are things
in the RFC's that it *doesn't* do, because they're stupid. There are
other things that are *now* in RFC's, because FreeRADIUS did them first.
Sorry... your debug messages show two things: slow Perls scripts, and
a buggy NAS. Nothing else. You have *not* identified bad behavior in
FreeRADIUS, unlike others recently on this list.
Alan DeKok.
More information about the Freeradius-Users
mailing list