Re: Client-IP-Address occasionally incorrect
Oleg Derevenetz <[EMAIL PROTECTED]> wrote: > There is dup, so rad_check_ts() must return 1, and session is > valid. There is no reason to call session_zap(), is'nt it ? The session should be zapped ONLY if checkrad decides that the user is not logged in on that port. > Fri Apr 26 21:30:41 2002 checkrad ascend xx.xx.xx.xx 20219 atuser 7498134= > 1 > No SNMP answer from ascend. > user at port S20219: atuser (dec) > Returning 1 (double detected) And the radutmp module does NOT zap the session if the check for duplicate logins returns '1' Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client-IP-Address occasionally incorrect
"Victor Sanchez" <[EMAIL PROTECTED]> wrote: > accounting_start_query = "INSERT into radacct ;INSERT into > " > > when i use it with update work fine, but in a insert say > /etc/raddb/sql.conf[124]: Line is not in 'attribute = value' format > > any idea to update, and insert in 2 diferent database as the same time Grab the latest CVS snapshot. The buffers used internally in the configuration file reader have been increased in size. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client-IP-Address occasionally incorrect
At 08:17 PM 4/26/2002 +0200, Victor Sanchez wrote:
>i need to update 2 database with the data of the radius.
>
>y test to put this in the sql file:
>
>accounting_start_query = "INSERT into radacct ;INSERT into
>"
>
>when i use it with update work fine, but in a insert say
>/etc/raddb/sql.conf[124]: Line is not in 'attribute = value' format
>
>any idea to update, and insert in 2 diferent database as the same time
Use two instances of the sql module.
sql one {
foo = bar
}
sql two {
foo = baz
}
authorize {
one
two
}
accounting {
one
two
}
-Chris
--
\\\|||/// \ StarNet Inc. \Chris Parker
\ ~ ~ / \ WX *is* Wireless!\ Director, Engineering
| @ @ |\ http://www.starnetwx.net \ (847) 963-0116
oOo---(_)---oOo--\--
\ Wholesale Internet Services - http://www.megapop.net
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client-IP-Address occasionally incorrect
i need to update 2 database with the data of the radius. y test to put this in the sql file: accounting_start_query = "INSERT into radacct ;INSERT into " when i use it with update work fine, but in a insert say /etc/raddb/sql.conf[124]: Line is not in 'attribute = value' format any idea to update, and insert in 2 diferent database as the same time - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client-IP-Address occasionally incorrect
ãÉÔÉÒÕÀ Oleg Derevenetz <[EMAIL PROTECTED]>: > Hm-m... But I don't understand, how it can call session_zap() in such > case > (checkrad.log): > > Fri Apr 26 21:30:41 2002 checkrad ascend xx.xx.xx.xx 20219 atuser > 74981341 > No SNMP answer from ascend. > user at port S20219: atuser (dec) > Returning 1 (double detected) > > There is dup, so rad_check_ts() must return 1, and session is valid. > There is > no reason to call session_zap(), is'nt it ? Oh-oh. I have error in this case: Fri Apr 26 21:30:52 2002 : Error: Check-TS: timeout waiting for checkrad So rad_check_ts() returned 2. But is there a reason to zap session record ? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client-IP-Address occasionally incorrect
Oleg Derevenetz <[EMAIL PROTECTED]> wrote: > If rad_check_ts() returns 1 (dup found), and no multilink is there, > this code simply increments request->simul_count, but if not, it > does session_zap() (and generates "fake" Accounting-Stop record with > fields such in my case). So it seems to be a problem in > rad_process(). No, it looks like it's in session_zap(). Try editing src/main/session.c, function session_zap(). Change code from: ... rad_process(stopreq, ...) ... to: ... rad_accounting(stopreq); request_free(&stopreq); ... That should *help*, at least. I'll try to edit && commit a slightly larger fix to the code today. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client-IP-Address occasionally incorrect
ãÉÔÉÒÕÀ Alan DeKok <[EMAIL PROTECTED]>: > Arg... On closer examination of the packet in the previous message, > I think the problem *is* session_zap. > > > It SHOULD initialize all of the entries in the data structures it > creates. > > It SHOULD NOT call rad_process(). rad_respond() is safe, and > better. Hm-m... But I don't understand, how it can call session_zap() in such case (checkrad.log): Fri Apr 26 21:30:41 2002 checkrad ascend xx.xx.xx.xx 20219 atuser 74981341 No SNMP answer from ascend. user at port S20219: atuser (dec) Returning 1 (double detected) There is dup, so rad_check_ts() must return 1, and session is valid. There is no reason to call session_zap(), is'nt it ? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client-IP-Address occasionally incorrect
ãÉÔÉÒÕÀ "Chris A. Kalin" <[EMAIL PROTECTED]>:
> 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). And I
> would
> get them from my MAX TNTs, my PM3s, my Cisco AS5200s, and the various
> RADIUS
> servers that proxied to me. Some packets would be fine, others would
> be
> bogus.
> It was so weird and pervasive I just canned the implementation and
> didn't
> really troubleshoot past isolating Simultaneous-Use as the cause.
> I've
> actually been meaning to revisit this now that .5 is out and see if life
> is
> better.
> Although it is reassuring to see that it didn't only bite me. :)
So, there is a piece of code in rlm_radutmp.c/radutmp_checksimul():
radutmp_unlock(fd);
rcode = rad_check_ts(u.nas_address, u.nas_port, login,
session_id);
radutmp_lock(fd);
if (rcode == 1) {
++request->simul_count;
/*
* Does it look like a MPP attempt?
*/
if (strchr("SCPA", u.proto) &&
ipno && u.framed_address == ipno)
request->simul_mpp = 2;
else if (strchr("SCPA", u.proto) && call_num &&
!strncmp(u.caller_id,call_num,16))
request->simul_mpp = 2;
}
else {
/*
* False record - zap it.
*/
session_zap(u.nas_address, u.nas_port, login,
session_id, u.framed_address,
u.proto, 0);
}
If rad_check_ts() returns 1 (dup found), and no multilink is there, this code
simply increments request->simul_count, but if not, it does session_zap() (and
generates "fake" Accounting-Stop record with fields such in my case). So it
seems to be a problem in rad_process().
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client-IP-Address occasionally incorrect
"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). Hmm... after quickly rooting through the code, the only thing I can come up with is the session_zap() function in src/main/session.c, and it's only called from the radutmp module. If removing 'radutmp' from the list of modules makes these packets stop, then the problem is the session_zap() routine. (Which may not initialize all of the data structures it creates) I haven't looked at it for a while, but it calls rad_process(), which is the main request processing function. Unfortunately, rad_process() is designed to be called ONLY from the main thread handler, and NOT from any child thread. Arg... On closer examination of the packet in the previous message, I think the problem *is* session_zap. It SHOULD initialize all of the entries in the data structures it creates. It SHOULD NOT call rad_process(). rad_respond() is safe, and better. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client-IP-Address occasionally incorrect
FWIW, I just tried it again on that same RADIUS server . I changed my DEFAULT entry in my users file from: DEFAULT Auth-Type := PAM to Simultaneous-Use := 1, Auth-Type := PAM and POOF...for any particular RAS I'd get three valid packets, than a bogus one, then another two or three good ones, then another bogus - just like I saw when I tried this last. The NAS-IP-Address would always be correct, but the Client-IP-Address would be garbage. Oh, and the Acct-Session-Time, -Input-Octets, -Output-Octets, -Input-Packets, and -Output-Packets would all be 0. I turned it off before I did too much damage, so I didn't have time to packet sniff or anything. This was a right around 0.4 CVS version, but the exact date escapes me right now. I can provide complete config files if anyone is interested, but I'm going to try this with the current CVSs first. Oh, and Linux 2.4.9. Chris Kalin - Original Message - From: "Alan DeKok" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 26, 2002 11:32 AM Subject: Re: Client-IP-Address occasionally incorrect > Oleg Derevenetz <[EMAIL PROTECTED]> wrote: > > When I enabled Simultaneous-Use check for some user classes, I've > > got the same problem as Mervyn Jack - invalid packets with fake > > Client-IP-Address. > > That's really weird. The Client-IP-Address is taken from > request->packet->src_ipaddr, which is taken directly from the > recv_from() system call. > > So if the address is wrong, then it sounds to me like the OS is > lying to the server about where the packet came from. > > >Client-IP-Address = 70.114.105.32 [FAKE !] > > Does this address have *any* relation to addresses on your network, > or is it random (and changing) garbage? > > > These packets arrived only when user with Simultaneuos-Use (atuser in this > > case) tried to login and checkrad returned OK (this user already exists on > > NAS). > > I find it *really* bizarre that the NAS is sending fake accounting > records when it's queried via checkrad. > > Have you used 'tcpdump' from another machine, to verify that the > packet is sent on the wire, and isn't some artifact of the server > and/or OS? > > If the packet *is* coming from the NAS, have you asked Ascend/Cisco > for support? > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client-IP-Address occasionally incorrect
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). And I would get them from my MAX TNTs, my PM3s, my Cisco AS5200s, and the various RADIUS servers that proxied to me. Some packets would be fine, others would be bogus. It was so weird and pervasive I just canned the implementation and didn't really troubleshoot past isolating Simultaneous-Use as the cause. I've actually been meaning to revisit this now that .5 is out and see if life is better. Although it is reassuring to see that it didn't only bite me. :) Chris Kalin - Original Message - From: "Alan DeKok" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 26, 2002 11:32 AM Subject: Re: Client-IP-Address occasionally incorrect > Oleg Derevenetz <[EMAIL PROTECTED]> wrote: > > When I enabled Simultaneous-Use check for some user classes, I've > > got the same problem as Mervyn Jack - invalid packets with fake > > Client-IP-Address. > > That's really weird. The Client-IP-Address is taken from > request->packet->src_ipaddr, which is taken directly from the > recv_from() system call. > > So if the address is wrong, then it sounds to me like the OS is > lying to the server about where the packet came from. > > >Client-IP-Address = 70.114.105.32 [FAKE !] > > Does this address have *any* relation to addresses on your network, > or is it random (and changing) garbage? > > > These packets arrived only when user with Simultaneuos-Use (atuser in this > > case) tried to login and checkrad returned OK (this user already exists on > > NAS). > > I find it *really* bizarre that the NAS is sending fake accounting > records when it's queried via checkrad. > > Have you used 'tcpdump' from another machine, to verify that the > packet is sent on the wire, and isn't some artifact of the server > and/or OS? > > If the packet *is* coming from the NAS, have you asked Ascend/Cisco > for support? > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client-IP-Address occasionally incorrect
Oleg Derevenetz <[EMAIL PROTECTED]> wrote: > When I enabled Simultaneous-Use check for some user classes, I've > got the same problem as Mervyn Jack - invalid packets with fake > Client-IP-Address. That's really weird. The Client-IP-Address is taken from request->packet->src_ipaddr, which is taken directly from the recv_from() system call. So if the address is wrong, then it sounds to me like the OS is lying to the server about where the packet came from. >Client-IP-Address = 70.114.105.32 [FAKE !] Does this address have *any* relation to addresses on your network, or is it random (and changing) garbage? > These packets arrived only when user with Simultaneuos-Use (atuser in this > case) tried to login and checkrad returned OK (this user already exists on > NAS). I find it *really* bizarre that the NAS is sending fake accounting records when it's queried via checkrad. Have you used 'tcpdump' from another machine, to verify that the packet is sent on the wire, and isn't some artifact of the server and/or OS? If the packet *is* coming from the NAS, have you asked Ascend/Cisco for support? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Client-IP-Address occasionally incorrect
Mervyn Jack <[EMAIL PROTECTED]> wrote: > Once or twice a day we are getting an accounting directory created named > as a hostname of one of our dial-up IP addresses, not a hostname of a > valid Client ip address. Hmm.. that doesn't sound correct. > The detail file only has one entry, the NAS-ip address (name) is > correct, the dial-up IP address is correct, but the Client-IP-Address > (name) is completely wrong, and is one of our other dial-up hostnames. Look through the code which adds the Client-IP-Address. It's in src/modules/rlm_preprocess/rlm_preprocess.c It adds the Client-IP-Address based on request->packet->src_ipaddr, which in turn is created when the packet is received in src/lib/radius.c The source IP is the address returned by the 'recvfrom' call. If that address isn't correct, blame your OS. > The same linux box runs our secondary DNS server, so you wouldn't think > it would get it wrong. > > I tried enable the writing of detail.auth, but the -A option does not > work for freeradius. No. The command-line parameters are deprecated, and shouldn't be used. Use the 'radiusd.conf' file instead. > If there is a quick fix for this I will wait, otherwise I will have > to turn off hostname lookup and see if we get any directories > created with invalid ip addresses. That's about all you can do right now. Until there is a bug verified in the server, there is no way to fix it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
