Dear Alan DeKok,
I wrote about cause of this problem a month ago:
--This is a forwarded message
From: 3APA3A <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Monday, April 1, 2002, 6:48:12 PM
Subject: radutmp bugs
===8<==============Original message text===============
Dear [EMAIL PROTECTED],
First bug is in radutmp_checksimul.
In call to session_zap (then user record found in radutmp but there is
no active user with this name on NAS) we send request->packet->sockfd.
sockfd will be socket for authentication, but later rad_process called
from session_zap does the check:
if (request->packet->sockfd != acctfd) {
it makes an error in log like "Accounting-Request packet sent to a
non-accounting port from client" and session_zap fails to remove this
hanging session.
I bet either
session_zap(request->packet->sockfd,
should be changed to
session_zap(acctfd,
or code should be rewritten without session_zap at all, because
session_zap in this implementation will cause problems, for example in
case of improper NAS or Radius server shutdown user can be billed the
time between two logons... So, at least radius must clean up radutmp
on startup.
Second problem is that ip address of NAS saved in radutmp is
PW_NAS_IP_ADDRESS. Existence of this attrbiute is never checked and if
this attribute isn't present any garbage may be instead of it.
I think we should add in radutmp_accounting
nas_address = request->packet->src_ipaddr;
ut.nas_address = request->packet->src_ipaddr;
as either default value or replacement to
case PW_NAS_IP_ADDRESS:
nas_address = vp->lvalue;
ut.nas_address = vp->lvalue;
break;
because this attribute is also used for session_zap() call.
--
http://www.security.nnov.ru
/\_/\
{ , . } |\
+--oQQo->{ ^ }<-----+ \
| ZARAZA U 3APA3A }
+-------------o66o--+ /
|/
You know my name - look up my number (The Beatles)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
===8<===========End of original message text===========
--
~/ZARAZA
Но ведь кому угодно могут прийти в голову яйца, пятки и епископы. (Лем)
--Friday, April 26, 2002, 9:34:42 PM, you wrote to [EMAIL PROTECTED]:
AD> "Chris A. Kalin" <[EMAIL PROTECTED]> wrote:
>> I actually saw this same problem way back in the post 0.3 CVS days (and
>> before), and I wasn't even involving checkrad. I would turn on
>> Simultaneous-Use, and I would immediately begin to get completely bogus
>> Client-Ip-Addresses in my accounting packets...IPs that had nothing to do
>> with my network (I remember 0.0.0.0 being one of the examples).
AD> Hmm... after quickly rooting through the code, the only thing I can
AD> come up with is the session_zap() function in src/main/session.c, and
AD> it's only called from the radutmp module.
AD> If removing 'radutmp' from the list of modules makes these packets
AD> stop, then the problem is the session_zap() routine. (Which may not
AD> initialize all of the data structures it creates)
AD> I haven't looked at it for a while, but it calls rad_process(),
AD> which is the main request processing function. Unfortunately,
AD> rad_process() is designed to be called ONLY from the main thread
AD> handler, and NOT from any child thread.
AD> Arg... On closer examination of the packet in the previous message,
AD> I think the problem *is* session_zap.
AD> It SHOULD initialize all of the entries in the data structures it
AD> creates.
AD> It SHOULD NOT call rad_process(). rad_respond() is safe, and
AD> better.
AD> Alan DeKok.
AD> -
AD> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
~/ZARAZA
Но Гарри... я безусловно отдаю предпочтение ему, за
высокую питательность и какое-то особенно нежное мясо. (Твен)
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
