3APA3A <[EMAIL PROTECTED]> wrote:
> I wrote about cause of this problem a month ago:
Yes, but...
> I bet either
>
> session_zap(request->packet->sockfd,
>
> should be changed to
>
> session_zap(acctfd,
Both of these are completely wrong, now that I look further at the
code. The problem is that the 'sockfd' in session_zap() isn't used by
*anything* in that function. Sure, it's placed into stoppkt->sockfd,
but that is completely wrong. The stop packet is a FAKE packet,
generated internally by the server. It MUST NOT be associated with
any real socket, so that there is NO possibility of a NAS getting a
reply packet to the fake request (which the NAS never sent)
The real problem is that session_zap() is calling rad_process().
The rad_process() function assumes that it's being called ONLY from
the main thread, so calling it from a child thread handling a request
is completely wrong, and may cause the server to do unexpected things.
> 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.
That's already done in radutmp:
/*
* If we didn't find out the NAS address, use the
* originator's IP address.
*/
if (nas_address == 0) {
nas_address = request->packet->src_ipaddr;
ut.nas_address = nas_address;
}
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
