On Sun, 22 Feb 1998, Thom Henderson wrote:
> This problem should be non-fatal as long as you are NOT using the "-s"
> option. The process that was forked off to handle the offending name will
> die causing that one login attempt to fail, but radiusd should continue to
> run.
>
> At least, that's what happens with ESVAnet radiusd.
Correction. That is what *appears* to happen, but it's not what is really
happening. At least, not here.
On further investigation it appears that radiusd.esva is working properly
and is not subject to this bug.
When tested with an account whose user service is an "rlogin" session to a
BSD/OS 2.1 host, the BSD/OS host fails to initiate the rlogin session.
During the initial "quick check" to see if we had this bug, the results
appeared to match the behaviour of the bug, but on deeper investigation it
is apparent that radiusd.esva is NOT hanging, and IS authenticating the
session properly.
When tested with an account whose user service type is PPP, everything
works normally.
I would suggest retesting other versions to ensure that something similar
isn't happening. Otherwise, I suspect that the problem is either:
a) Fixed by the recent bug fix patch released by Livingston, or
2) Located in user_find() in users.c. I surmise this because the only
change I made that would relate at all to this problem is that we found a
need to trim trailing spaces because of WebTV customers.