- Freeradius-Devel - lists.freeradius.org

Automatic report from sources (radiusd) between 18.11.2006 - 19.11.2006 GMT
by Automatic cvs log generator 19 Nov '06

19 Nov '06

CVS log entries from 18.11.2006 (Sat) 09:00:03 - 19.11.2006 (Sun) 09:00:03 GMT ===================================================== Summary by authors ===================================================== Author: nbk File: radiusd/doc/ChangeLog; Revisions: 1.57.2.31.2.29 File: radiusd/src/main/mainconfig.c; Revisions: 1.36.2.6.2.3 File: radiusd/doc/rlm_sqlcounter; Revisions: 1.3.6.2 File: radiusd/man/man8/radsqlrelay.8; Revisions: 1.1.2.3 File: radiusd/raddb/radiusd.conf.in; Revisions: 1.188.2.4.2.13 File: radiusd/src/modules/rlm_sqlcounter/rlm_sqlcounter.c; Revisions: 1.32, 1.11.2.3.2.6 File: radiusd/scripts/radsqlrelay; Revisions: 1.4.2.3 ===================================================== Combined list of identical log entries ===================================================== Description: Pull from CVS head: Add a new "-f" option to read the password from a file, instead of command line. (closes: #395) Modified files: File: radiusd/man/man8/radsqlrelay.8; Revision: 1.1.2.3; Date: 2006/11/18 13:05:08; Author: nbk; Lines: (+4 -0) File: radiusd/scripts/radsqlrelay; Revision: 1.4.2.3; Date: 2006/11/18 12:58:34; Author: nbk; Lines: (+15 -3) ------------------------------- Description: Pull from CVS head: Add a new "reply-name" directive to choose the attribute which will contain the remaining value for the counter in the reply packet when the user is successfully authorized. (closes: #403) Modified files: File: radiusd/doc/rlm_sqlcounter; Revision: 1.3.6.2; Date: 2006/11/18 14:45:18; Author: nbk; Lines: (+3 -0) File: radiusd/raddb/radiusd.conf.in; Revision: 1.188.2.4.2.13; Date: 2006/11/18 14:45:17; Author: nbk; Lines: (+3 -1) File: radiusd/src/modules/rlm_sqlcounter/rlm_sqlcounter.c; Revision: 1.11.2.3.2.6; Date: 2006/11/18 14:45:19; Author: nbk; Lines: (+34 -8) ===================================================== Log entries ===================================================== Description: Update for 1.1.4. Modified files: File: radiusd/doc/ChangeLog; Revision: 1.57.2.31.2.29; Date: 2006/11/18 15:43:45; Author: nbk; Lines: (+20 -1) ------------------------------- Description: Fix a corner case where the proxy port isn't set either in radiusd.conf or in proxy.conf. Bug reported by Tomas Martisius <tomas(a)puga.vdu.lt> See http://bugs.debian.org/388024 Modified files: File: radiusd/src/main/mainconfig.c; Revision: 1.36.2.6.2.3; Date: 2006/11/18 15:03:39; Author: nbk; Lines: (+5 -5) ------------------------------- Description: Update the sqlcounter_detach() function and always free memory on errors. Modified files: File: radiusd/src/modules/rlm_sqlcounter/rlm_sqlcounter.c; Revision: 1.32; Date: 2006/11/18 14:27:23; Author: nbk; Lines: (+68 -28) ===================================================== Summary of modified files ===================================================== File: radiusd/doc/ChangeLog Revisions: 1.57.2.31.2.29 Authors: nbk (+20 -1) ------------------------------- File: radiusd/doc/rlm_sqlcounter Revisions: 1.3.6.2 Authors: nbk (+3 -0) ------------------------------- File: radiusd/man/man8/radsqlrelay.8 Revisions: 1.1.2.3 Authors: nbk (+4 -0) ------------------------------- File: radiusd/raddb/radiusd.conf.in Revisions: 1.188.2.4.2.13 Authors: nbk (+3 -1) ------------------------------- File: radiusd/scripts/radsqlrelay Revisions: 1.4.2.3 Authors: nbk (+15 -3) ------------------------------- File: radiusd/src/main/mainconfig.c Revisions: 1.36.2.6.2.3 Authors: nbk (+5 -5) ------------------------------- File: radiusd/src/modules/rlm_sqlcounter/rlm_sqlcounter.c Revisions: 1.32, 1.11.2.3.2.6 Authors: nbk (+68 -28), nbk (+34 -8) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Re: fix for Radius failed query logging
by Peter Nixon 18 Nov '06

18 Nov '06

On Sat 18 Nov 2006 00:32, Dan Pascu wrote: > On Friday 17 November 2006 17:51, Peter Nixon wrote: > > On Fri 17 Nov 2006 15:00, Juha Heinanen wrote: > > > peter, > > > > > > you suggested to use accounting stop request for failed sip requests. > > > that is not a good idea, because what didn't start cannot stop > > > either. > > > > > > in other words, my stop records contain only a small number of > > > attributes enough to match the start record that holds many more > > > attributes. in case of failed request, i don't have a corresponding > > > start record, but i do need all the same attributes in failed request > > > that i have in start request. > > > > Hi Juha > > > > The amount of attributes that your (I guess you mean openser) stop > > records _currently_ contain have nothing to do with the issue at all. > > (Most NAS infact put much MORE info into the Stop records than the > > Start ones as that is typically the record you use for billing) > > > > My suggestion was to simply have the Failed records be of > > Acct-Status-Type "Stop". The RFC does not state that there has to be a > > I don't think this is a good idea, as it will introduce confusion about > the meaning and the behavior of the Stop record. A typical scenario is to > generate an SQL insert on a radius Start record and an SQL update on the > radius Stop record (for a successful call). For a failed call however if > it generates a Stop record, then in will need to do an SQL insert instead > of the typical SQL update, since for failed calls there is no start. This > is not a good idea IMO. FreeRADIUS handles this fine as reverts to INSERT if it desn't find a record to UPDATE on Stop. > From this point of view, a failed call should rather generate a Start > record (because it needs the SQL insert), but seen in context, this > doesn't make much sense, as there is no call starting (it is a failed > call after all) and there will be no Stop record following later. Some vendors generate both Start and Stop with 0 session-time on a failed call. This is actually something that you could easily make configurable in any case. To give all 3 options (Old "Failed" method, "Stop-Only" and "Start-Stop") would at most be 15 or 20 lines of extra code... I understand people wanting to keep backward "compatibility" for existing installations, but compatibility with RFCs and other vendor's RADIUS and billing systems should also be a priority in my opinion and making it a configurable option solves both problems. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

1 0

Re: fix for Radius failed query logging
by Peter Nixon 17 Nov '06

17 Nov '06

On Fri 17 Nov 2006 19:20, Adrian Georgescu wrote: > Hi Peter, > > Failed it is mentioned in RFC2866. Yes the mention is "15 Reserved for Failed" Reserved means, basically means currently undefined, but may be defined in a future RFC... This doesn't mean, go use it how you wish and hope the next RFC matches what you did.... > To explain to you a bit how SER/ > OpenSER typically works and it is in service for may years. > > Scenario 1 > > - Call starts - generates a start packet > - Cals stops - generates a stop packet Yep. Understood. > Scenario 2 > > - Call fails without starting - generates a failed packet, which > allows you to specify a custom database query different than the > start query OK. As I mentioned in my email, this can and should be done with a Stop packet that contains "Failed" or (some error code that indicates failed) as an additional attribute. > This behaviour is typically used by SER/OpenSER community for years. > It has nothing to do with Cisco and vendors specific attributes. It > is a situation where Accounting type Failed simply make sense and > there are countless numbers of VoIP deployments out there making good > use of it. Sure. I didnt say that it didnt make sense, but you are defining undefined behaviour from the rfc.. I also didnt say that its a bad idea, but that is a discussion for an RFC working group... > Now, as many things in SIP, RFCs are not always the place to look for > real life problems and their solutions. Many RFCs have been written > before decent field experience existed in the field and did not cover > the out-of-the lab requirements. By obeying blindly to what some RFC > mentions or lacks to mention it would mean that the progress of > mankind will be at the hand of some people with time and interest to > write RFCs. Yes. I agree, but in this case the RFC does specify a way for you to do what you need to do cleanly. > Once a technology gets adopted nobody has time anymore for > standardisation as it did before adoption. Radius was once an AAA > tool for dial-up networks. SIP and VoIP came later and this mailing > lists gives you feedback about it. I am sorry you feel this way. Standardisation is what makes things interoperable. I have been involved with VoIP for a long time also (just not openser), so I am not new to these issues. > Changing 10 lines of code will make many people praise Freeradius for > its good work for the fast growing VoIP/SIP community and will not > break anything else. Otherwise it should be no wonder why some switch > to radiator who seem to care more about what people really need in > place of what is missing from the RFCs. Well, it MAY break things in future if and when a new RFC defines how "Acct-Status-Type = Failed" should be used. I agree that given the type of change we are talking about this is a remote possiblity, however Alan has the final say in things of this nature. In any case, as Alan also mentioned in his reply, there are plans to make the sql modules extensible simply by adding new queries like this to the config file. In that case no code patch will be required to do what you want to do.. Simply adding one extra line the the config file will do the trick. This will allow custom sql queries on basically any attribute type giving people more than enough rope to hang themselves in weird and wonderfull new ways :-D Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

2 1

Re: fix for Radius failed query logging
by Peter Nixon 17 Nov '06

17 Nov '06

On Fri 17 Nov 2006 15:00, Juha Heinanen wrote: > peter, > > you suggested to use accounting stop request for failed sip requests. > that is not a good idea, because what didn't start cannot stop either. > > in other words, my stop records contain only a small number of > attributes enough to match the start record that holds many more > attributes. in case of failed request, i don't have a corresponding > start record, but i do need all the same attributes in failed request > that i have in start request. Hi Juha The amount of attributes that your (I guess you mean openser) stop records _currently_ contain have nothing to do with the issue at all. (Most NAS infact put much MORE info into the Stop records than the Start ones as that is typically the record you use for billing) My suggestion was to simply have the Failed records be of Acct-Status-Type "Stop". The RFC does not state that there has to be a Start record in order for there to be a Stop record and this is how most vendors do it. (If you wish to add an extra attribute that includes the word "Failed" then by all means do so..) Here is an example Start and Stop record from a Cisco 53XX series running H.323 (Sorry don't have any production SIP installations at present) Please take note of "Cisco-AVPair" attributes which may contain arbitary data (according the Cisco's dictionary) and the length of the records Sat Oct 16 06:38:54 2006 Acct-Session-Id = "00BA5EC6" h323-setup-time = "16:36:05.023 GMT+2 Sat Oct 16 2006" h323-gw-id = "gw1-5300." h323-conf-id = "A6C16E86 205211D9 87870003 BA6B5AFA" h323-call-origin = "originate" h323-call-type = "Telephony" Cisco-AVPair = "h323-incoming-conf-id=A6C16E86 205211D9 87870003 BA6B5AFA" Cisco-AVPair = "subscriber=Unknown" Cisco-AVPair = "out-intrfc-desc=" Cisco-AVPair = "gw-rxd-cdn=ton:0,npi:0,#:696990535792987" User-Name = "195.2.2.1" Acct-Status-Type = Start NAS-Port-Type = Async Cisco-NAS-Port = "ISDN 1:D:1" NAS-Port = 0 Called-Station-Id = "696990535792987" Service-Type = Login-User NAS-IP-Address = 212.1.1.1 Acct-Delay-Time = 5 Client-IP-Address = 212.1.1.1 Acct-Unique-Session-Id = "0657b177760ba193" Sat Oct 16 06:38:55 2006 Acct-Session-Id = "00BA5EC6" h323-setup-time = "16:36:05.023 GMT+2 Sat Oct 16 2006" h323-gw-id = "gw1-5300." h323-conf-id = "A6C16E86 205211D9 87870003 BA6B5AFA" h323-call-origin = "originate" h323-call-type = "Telephony" Cisco-AVPair = "h323-incoming-conf-id=A6C16E86 205211D9 87870003 BA6B5AFA" Cisco-AVPair = "subscriber=Unknown" Cisco-AVPair = "out-intrfc-desc=" Cisco-AVPair = "gw-rxd-cdn=ton:0,npi:0,#:696990535792213" Acct-Input-Octets = 440 Acct-Output-Octets = 0 Acct-Input-Packets = 22 Acct-Output-Packets = 0 Acct-Session-Time = 0 h323-connect-time = "16:36:05.675 GMT+2 Sat Oct 16 2006" h323-disconnect-time = "16:36:05.675 GMT+2 Sat Oct 16 2006" h323-disconnect-cause = "1C" Cisco-AVPair = "h323-ivr-out=Tariff:Unknown" Cisco-AVPair = "release-source=3" h323-voice-quality = "0" Cisco-AVPair = "gw-final-xlated-cdn=ton:0,npi:0,#:05357111111" Cisco-AVPair = "charged-units=0" Cisco-AVPair = "disconnect-text=invalid number (28)" Cisco-AVPair = "peer-address=696990535792987" Cisco-AVPair = "info-type=speech" Cisco-AVPair = "peer-id=69691" Cisco-AVPair = "peer-if-index=280" Cisco-AVPair = "logical-if-index=105" Cisco-AVPair = "acom-level=20" Cisco-AVPair = "coder-type-rate=g729r8" Cisco-AVPair = "noise-level=0" Cisco-AVPair = "voice-tx-duration=0 ms" Cisco-AVPair = "tx-duration=0 ms" User-Name = "195.2.2.2" Acct-Status-Type = Stop NAS-Port-Type = Async Cisco-NAS-Port = "ISDN 1:D:1" NAS-Port = 0 Called-Station-Id = "696990535792987" Service-Type = Login-User NAS-IP-Address = 212.1.1.1 Acct-Delay-Time = 5 Client-IP-Address = 212.1.1.1 Acct-Unique-Session-Id = "0657b177760ba193" Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

1 0

Automatic report from sources (radiusd) between 16.11.2006 - 17.11.2006 GMT
by Automatic cvs log generator 17 Nov '06

17 Nov '06

CVS log entries from 16.11.2006 (Thu) 09:00:01 - 17.11.2006 (Fri) 09:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/main/modcall.c; Revisions: 1.58 File: radiusd/share/dictionary.cisco.vpn3000; Revisions: 1.13, 1.7.4.3 ===================================================== Combined list of identical log entries ===================================================== Description: Corrected typo Modified files: File: radiusd/share/dictionary.cisco.vpn3000; Revision: 1.13; Date: 2006/11/17 00:01:43; Author: aland; Lines: (+2 -2) File: radiusd/share/dictionary.cisco.vpn3000; Revision: 1.7.4.3; Date: 2006/11/17 00:01:18; Author: aland; Lines: (+2 -2) ===================================================== Log entries ===================================================== Description: Move action2str to where it needs to be. Add comment at the start of modcall(), saying what it does. If we have a module action of RETURN or REJECT at "unroll" in modcall(), don't fall through to the next check. Instead, jump forward to do_return, which stops processing this group Modified files: File: radiusd/src/main/modcall.c; Revision: 1.58; Date: 2006/11/16 23:59:32; Author: aland; Lines: (+19 -15) ===================================================== Summary of modified files ===================================================== File: radiusd/share/dictionary.cisco.vpn3000 Revisions: 1.13, 1.7.4.3 Authors: aland (+2 -2), aland (+2 -2) ------------------------------- File: radiusd/src/main/modcall.c Revisions: 1.58 Authors: aland (+19 -15) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Re: Reemission bug in multi-threaded mode + FreeRADIUS 2.0 roadmap questions
by Chaigneau Nicolas 17 Nov '06

17 Nov '06

I apologize for being insistent, but I'm sending again this mail, as I did not receive a response since last week. We would like to have more precise information about what will be exactly in release 2.0 regarding FreeRADIUS retransmissions. This is important to us, because RADIUS retransmissions are a critical part of our system. Thanks a lot. Regards, Nicolas. > > It seems that "request->proxy" is 0 when the condition is tested, > > thus, FreeRADIUS considers there is no proxy outstanding for this > > request. > > Yes. It's an issue, but a minor one. The solution is to always > make the server synchronous, which has been done in the CVS head. > > Alan DeKok. I agree this is a minor issue. Setting up the serveur in synchronous mode is much simpler, although I think we would lose a few features that we need. Detecting a proxy server is dead and failover to a backup server is important to us. In the current 1.1.3 version, failover is possible only in asynchronous mode. Will failover still be possible in the next release of FreeRADIUS ? Also, we need to detect that a given proxied request did not receive any response, in order to send back a specific response to the NAS (Reject or Accept). Would it be possible in synchronous mode ? Will the possibility to choose between synchronous and asynchronous remain in the CVS head, or do you plan to completely remove asynchronous mode ? One more point about synchronous mode : currently, timeout and retries parameters are global to FreeRADIUS in the "proxy server" configuration section. If the retransmission mode is synchronous, wouldn't these parameters have to be defined per NAS, for instance in the clients.conf file ? each NAS can have different values for these settings. Nicolas. ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com

4 8

small typo/bug in dictionary.cisco.vpn3000 ?
by Markus Krause 16 Nov '06

16 Nov '06

Hi all, i think i found a small typo/bug in dictionady.cisco.vpn3000 in freeradius 1.1.3, shouldn't the line 82 ATTRIBUTE CVPN3000-WebVPN-Exchnage-NETBIOS-name 78 string be ATTRIBUTE CVPN3000-WebVPN-Exchange-NETBIOS-name 78 string ? (typo in "Exchnage" -> "Exchange") regards, markus -- Markus Krause email: krause(a)biochem.mpg.de Mogli-Soft: Support for Mac OS X, Webmail/Horde, LDAP, RADIUS by order of the Computing Center of the Max-Planck-Institute of Biochemistry Tel.: 089 - 89 40 85 99 Fax.: 089 - 89 40 85 98 ---------------------------------------------------------------------- This message was sent using https://webmail2.biochem.mpg.de If you encounter any problems please report to rz-linux(a)biochem.mpg.de

2 1

Re: [Devel] Re: fix for Radius failed query logging
by Peter Nixon 16 Nov '06

16 Nov '06

OK. This _looks_ like a RADIUS accounting packet, and the patch doesn't look horrible, but with the exception of the following in RFC 2866 I can't find anything mentioning "Acct-Status-Type = Failed" as being valid: 5.1. Acct-Status-Type Description This attribute indicates whether this Accounting-Request marks the beginning of the user service (Start) or the end (Stop). It MAY be used by the client to mark the start of accounting (for example, upon booting) by specifying Accounting-On and to mark the end of accounting (for example, just before a scheduled reboot) by specifying Accounting-Off. --snip-- The Value field is four octets. 1 Start 2 Stop 3 Interim-Update 7 Accounting-On 8 Accounting-Off 9-14 Reserved for Tunnel Accounting 15 Reserved for Failed <------------------*************** Based on which RFC does SER generate RADIUS accounting packets with "Acct-Status-Type = Failed"? I am CCing this mail to the FreeRADIUS devel list also. (I suggest that those of you on the SER list interested in this patch should join freeradius-devel also) Proposed patch to enable Acct-Status-Type = Failed support in FreeRADIUS at: http://download.dns-hosting.info/CDRTool/freeradius/freeradius-cvs-failed-a… Cheers Peter On Thu 16 Nov 2006 19:30, Adrian Georgescu wrote: > We use this for logging of Radius packets type Failed, which are > generated by negative codes in OpenSER. > > For example this Radius packet will not end up in sql without the > patch applied: > > Thu Nov 16 18:28:01 2006 > Acct-Status-Type = Failed > Service-Type = Sip-Session > Sip-Response-Code = 487 > Sip-Method = Invite > User-Name = "Unknown(a)gw02-mci.budgetphone.nl" > Calling-Station-Id = "sip:Unknown@gw02-mci.budgetphone.nl" > Called-Station-Id = "sip:31402910153@budgetphone.nl" > Sip-Translated-Request-URI = "sip: > 31402910153@192.168.2.115:5060" > Acct-Session-Id = "5b6bb3eb297fb5c14ac8052d7bbd2904@gw02- > mci.budgetphone.nl" > Sip-To-Tag = "f5c8a2d2f16cd3f7i0" > Sip-From-Tag = "as42ed4c4a" > Sip-Cseq = "102" > Source-IP = "193.67.155.227" > Source-Port = "5060" > Canonical-URI = "sip:31402910153@budgetphone.nl" > Billing-Party = "Unknown(a)gw02-mci.budgetphone.nl" > From-Header = ""Unknown" <sip:Unknown@gw02- > mci.budgetphone.nl>;tag=as42ed4c4a" > SIP-Proxy = "81.23.228.150" > NAS-IP-Address = 10.0.0.139 > Client-IP-Address = 10.0.0.139 > Acct-Unique-Session-Id = "60b16bfb79b215b1" > Timestamp = 1163698081 > > On Nov 16, 2006, at 6:25 PM, Klaus Darilion wrote: > > Hi! > > > > Maybe someone can explain shortly what this feature is and where it > > is needed? I'm using radius accounting but never had any issues > > (maybe because I'm using radiator). > > > > regards > > klaus > > > > Adrian Georgescu wrote: > >> Hello Petter, > >> The patch is available at: > >> http://download.dns-hosting.info/CDRTool/freeradius/freeradius-cvs- > >> failed-accounting.diff On Nov 16, 2006, at 5:09 PM, Peter Nixon > >> > >> wrote: > >>> On Wed 15 Nov 2006 23:07, Adrian Georgescu wrote: > >>>> Hello Peter, > >>>> > >>>> Thank you for helping us with including the OpenSER radius > >>>> attributes > >>>> in the mainstream Freeradius dictionary, > >>>> > >>>> Can you help the OpenSER community to have the failed query > >>>> accepted > >>>> by the Freeradius? We currently keep patches for Freeradius with > >>>> this > >>>> functionality and all who could help so far seem to be more > >>>> interested in seeing some RFCs about the problem instead of fixing > >>>> the code. > >>>> > >>>> Can you help? > >>> > >>> Hi Adrian > >>> > >>> I haven't seen the patch myself, so if you can send it to me with a > >>> description of what it is supposed to accomplish I will take a > >>> look at it. > >>> > >>> Cheers > >>> -- > >>> Peter Nixon > >>> http://www.peternixon.net/ > >>> PGP Key: http://www.peternixon.net/public.asc > >> > >> _______________________________________________ > >> Devel mailing list > >> Devel(a)openser.org > >> http://openser.org/cgi-bin/mailman/listinfo/devel > > > > -- > > Klaus Darilion > > nic.at -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

2 1

PEAP Authentication-EAPTLS_HANDLED : Help Please
by shibu.piriyath＠wipro.com 16 Nov '06

16 Nov '06

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

2 1

RE: EAP/MSCHAPv2 code question
by Julien.HOCHART＠fr.thalesgroup.com 16 Nov '06

16 Nov '06

Alan DeKok wrote: > What if someone doesn't follow the RFC's? You can't trust attackers >to do what they're supposed to do. Well, allright then. thanks. -- Julien

1 0