Re: (RADIATOR) USR Radius Problems
On Thu, 3 Feb 2000, Andy Dills wrote: > However, I get the weirdest Accounting packets from it. A user will > connect, and then disconnect, but for days after, I still get Start-Stop > and Accounting-On packets for the session! The packet trace shows "Bad Authenticator". So Radiator isn't going to ACK the packet, which means that the TCH will continue to try to resend it until it gets an ACK. Until you get upgraded (as mentioned earlier, and the proper fix for this), you can put "IgnoreAcctSignature" in your Radiator config for this clientthat will cause it to ignore the authenticator and accept the packet. Lon Stockton === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) rewriting usernames
On Mon, 1 Nov 1999, David S. Madole wrote: > To answer the original request, the following > will strip any "xxx\" prefix, any "@xxx" suffix, and any leading or > trailing spaces: > > # make life easier for our customers > RewriteUsername s/^.*\\|@.*$|^\s+|\s+$//g This is a gem, much better than mine for the job at hand. > If you are so concerned about performance that you're afraid to do > things like this, you either shouldn't be running a RADIUS server > written in Perl, or you shouldn't be running on a 386. If you were to > profile Radiator, you would find these rewrites to be of trivial > impact. Being "concerned about performance" is one thing, but outright wasting performance for no reason is another. My comments about this were based on the original poster having a separate RewriteUsername for individual operations which were more effectively combined as you demonstrated in your message...reducing the entire thing to just two Rewrites. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) rewriting usernames
On Sun, 31 Oct 1999, Chris M wrote: > >Remember that Regex matching in general (and RewriteUsername in specific) > >is sloooww. > > That depends on the machine that they are running on :) Well, slow is indeed a relative term. (: > It definitely happens, lowers our tech support calls by about 1-2% we > think in looking at the logs, especially on new users. Why burden > them with all this computer esoterica. Boils down to a philosophical discussion. I argue that knowing that "xyz" is different than "xyz " and what the words "case specific" means is an important basic knowlege in the internet-world rather than some obscure esoterica they need not be bothered with. Better to get such things straight at the beginning, probably with the result of fewer future tech support calls and customer frustration because of this same type of thing. > > # promote user lameness and increase security risks > > RewriteUsername tr/[A-Z]/a-z/ > > I fail to see how this increases security risks, if they don't' > have a password they aren't going anywhere. Enlighten me oh regexman! Granted it's a stretch, but that does mathmatically increase the pool of valid username/password pairs, by creating a huge number of "valid" usernames for each given password. Not quite as bad as lowercasing all inbound passwords (which creates multiple "valid" passwords for each username), but the same type of thing. Maybe not a significant increase of risk (i admitted it to be a strech :) but there anyway. The real argument was more the encouragement of user lameness. The faster they learn basics, the less they're calling support for stupid issues. IMO,YMMV === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) rewriting usernames
On Sun, 31 Oct 1999, Chris M wrote: > I'd like to strip leading characters including \ for users that are > using NT Domains and don't understand what they are doing on dialup :) > > So WORKGROUP\myname should be rewritten to myname. Off the top of my head RewriteUsername s/^.*\\(.*)/$1/ And if you insist on stripping the (nonexistant or incorrect) trailing spaces as well RewriteUsername s/^.*\\(.*)\s*$/$1/ > Here is what I have so far, this might be helpful to others also: > > > # Strip leading white space > RewriteUsername s/^\s+// > # Strip trailing white space > RewriteUsername s/\s+$// > # turn into lowercase and chop domain > RewriteUsername tr/A-Z/a-z/ > RewriteUsername s/^([^@]+).*/$1/ > # attempt to strip leading \ and characters up to it (no workee, help) > RewriteUsername s/^(\\+).*// Remember that Regex matching in general (and RewriteUsername in specific) is sloooww. You certainly want to cut down on the number of rewrite statements. For example, the first two you list could be done with one regex... "s/^\s*(.*)\s*$/$1/". On the other hand, I'd first make sure that you need to do that anyway; I've never seen leading and trailing spaces coming in on the username field, so that'd just be slowing it down for nothing in my case. In any case, both of the ones I tossed out at the top will strip leading spaces, and the second will strip trailing spaces (of course, only if a "\" is in the string to begin with). I'd suggest something like this for what you appear to want: # rewrite domain\username to username RewriteUsername s/^.*\\(.*)/$1/ # rewrite username@domain to username RewriteUsername s/^(.*)\@.*/$1/ # promote user lameness and increase security risks RewriteUsername tr/[A-Z]/a-z/ Please note I just wrote these regex's off the top of my head, so they may have typos or something odd wrong with 'emnone of my regex's have ever worked the first time aroundbt, you should be able to see the thinking behind 'em, expecially armed with that nice O'Rielly book. (: === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) LQQK 279
Another happy Radiator user, I assume? *grin* On 31 Aug 1999 [EMAIL PROTECTED] wrote: > http://www.cashporn.com/menslair/ > > > > === > Archive at http://www.thesite.com.au/~radiator/ > To unsubscribe, email '[EMAIL PROTECTED]' with > 'unsubscribe radiator' in the body of the message. > === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) New USR radius attributes
FYI, here's new radius attributes for the USR dictionary. -- Forwarded message -- Date: Sun, 22 Aug 1999 21:03:28 -0500 (CDT) From: Tatai SV Krishnan <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: (usr-tc) Radius Attributes Authentication: 0x9889(39049) - SUPPORTS_TAGS - This is sent in the radius authentication packet to inform the radius server that HiPerARC supports TAG based tunnelling attributes. Accounting: 0x9856(38998) - VTS_SESSION_KEY - This is implemented for sessions VTS 0x9858(39000) - CALL_ARRIVED_TIME - call arrived time 0x9859(39001) - CALL_LOST_TIME - call lost time. 0x986c(39020) _ ACCT_REASON - accounting reason. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Radmin Adding Users
On Fri, 13 Aug 1999, Paul Black wrote: > The second problem is that chpasswd takes its input on STDIN. Is the code > below (currently commented out) correct to do this? Here's the code snippet from my perl script that adds users... # ### generate and set password for new user. Uses 'chpasswd' from the ### shadow-utils package, see 'man 8 chpasswd' for operation. # $pwd = GenPassword(); #generate their password open(SETPASS,"|/usr/sbin/chpasswd"); #open a pipe to chpasswd print SETPASS "$usrn:$pwd\n"; #feed it username & password close(SETPASS); #shut it down Hope this helps! === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Timestamp and mySQL datetime
On Tue, 3 Aug 1999, David Booth wrote: > I collect stop records and insert into a mySQL table. I want a column for intime >(type datetime) that should be: > > intime = Timestamp - Acct-Session-Time > > I'm using a temp table for the radius log and a mySQL INSERT to my table because >when I try to insert with the calculation I get a lot of zero or empty entries. > > Anyone have any experience with this kind of calculation? I just store the stop_time and the call_duration in our sql table; storing the start_time as well would be redundant. Rather than performing the calculation at insert time, I just calculate it at query time if I need it. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) dictionary to use?
A recent reply to the list made me question my choice of dictionary.
I've got USR TC gear, and just assumed that I needed to be using the
"dictionary.usr" file. So I did, and it seems to be working fine. But
should I be using that, or the default one ("dictionary")?
===
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL help
On Tue, 16 Mar 1999, Mike McCauley wrote: > 1. Most SQL databases of any consequence have no problem with hundreds of > thousands or millions of rows. They really are very fast, provided they are > hosted on a reasonable box (doenst have to be super fast, just 100-200MHz or so > and a fastish disk), and the indexes are sensibly defined. So a very reasonable > strategy would usually be to have one accounting table per month or *nod* My comments were geared more towards the disk space consumed by the database than the performance of the db system. Granted, disk space is really cheap nowadays so my argument gets watered down as each day passes. Just something in me hates arbitrarialy wasting space by storing a lot of data that I don't need. There's an aside to that that's probably more US-centric. I specifically want to lose the customer-id --> ip address assigned/time-of-day mappings as soon as possible to protect customer privacy. Courts cannot subpeona records that don't exist. I figure for troubleshooting and being able to catch users conducting real attacks, I only need it hanging around for about a month. If somebody reports that one of my users is attacking somebody else's network or doing other BadThings, I always get the report within hours/days/weeks rather than months. > 4. Lon might be able to use some or all of radacct.cgi for his web page showing > customer usage. Oh yeah, already saw that gem. It will definately help when I write my stuff (CGI is s, like yucky man... I'm livin in the late 90's and have me a nice apache server with mod_perl and mod_asp (which allows perl *and* asp stuff to be embedded in the page). The OldTime sysadmin in me will do anything to reduce process-creation overhead. But the OldTime sysadmin in me also believes that a good way to enhance the performance of a machine is to quit letting users run programs. Matter of fact, if we could kick all the users off too. *grin*). Lon Stockton MoonStar === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) check/reply items
Beginning to work on getting my Radiator to do the authentication, and would be interested in hearing how people handled things (if they have a situation similar to the one I describe below). Auth with be done by SQL. I'm going to have to give a for-example or two * My NAS reports the ANI. I want to restrict some customers to only allowing logins if they're calling from an 'appropriate' number. Even better, if they're calling from one of a list of valid numbers. But the kicker is, if I don't specify any number, the login should be allowed from any number (as usual). * My NAS supports per-call filtering. Same kind of deal; if a customer has specific filters in the database, I'd like to use them, but use a standard filter if one's not listed. * Same kind of plan for Reject-Reason. * Can I specify a message to be sent upon successful auth? If so, same plan there. Now that I write all this, it seems it'd revolve around how radiator handles null values found in the various columns, and is probably mentioned in the ref manual (if it is obvious in the manual, ignore this message; I'll root it out when the time comes). Otherwise, it seems that I'd need an ReplyItemSelect and/or a CheckItemSelect config item (but Mike, don't go and write this tonight for me like I've seen you do with others...I've already burned Radiator on my production CD; your code is frozen here at 2.13). === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL help
On Tue, 16 Mar 1999, Stephen Roderick wrote: > On Tue, 16 Mar 1999, Mike McCauley wrote: > > > 5. Lons observation about not bothering to save Starts in the accounting > > database is correct. Theres nothing there thats not in the Stops. > > That would be great if this was true, but it seems like most of the vendor > stuff is only in the starts. Connect-Speed, etc. Strangeall that stuff is in my stop records (USR HiperARC as client). Maybe it's a config item somewhere in your nas? If not, *ouch*; I'd hate it if the start record's fields weren't a subset of the stop records. Okay, I'd be fine with it if I could convince the bloody thing to stuff the initial connection speed in at the start record and the final connection speed in the stopI hate the fact that I'm getting initial connect speeds in my Connect-Speed attrib rather than the final one. From watching my performance monitor, it looks like about a third of the connects upshift to higher speeds and another third downshifts to lower speeds, not to mention that all X2 calls initially connect at 3 and then upshift. I know my box has this info, but don't know how to get it to report same. With the USR Total Control, I know that the *NMC* has attribs to report both initial and final connect speedsmaybe I need to get my ARC to send traps to the NMC on call termination and let the NMC send the accounting? Anybody know? === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL help
On Thu, 11 Mar 1999, Ferhat Dilman wrote: > By the way, a daily working tables really work? 31 tables in SQL every > month? Daily tables are more reasonable since it is 11st of March and it is > around 400,000 records already in the database. You have to determine what information you want to keep and what you can discardi.e. do you really have a need to know the compression used on a given call three months ago? a year ago? In my operation, I only need that really specific data for about a month so I can do troubleshooting and the like. After that, I only need summaries. I need a summary that allows me to see usage statistics by customer for billing and statistical purposes, and I need a summary to see usage and other misc stats by nas/slot/channel for internal planning and the like. So, my plan is: 1) set my nas to send every radius attrib it can. 2) set my radiator to stuff it all in my calldetail table 3) provide access to calldetail via a webpage, where an admin can see 'em all, and a customer can see records that pertain to their account(s). This is for troubleshooting and customer satisfaction. 4) Daily, I update my custusage and nasusage summary tables. As an example, custusage table is thus-ish: create table custusage ( acctid text not null, username text not null, sumdate date not null, numcalls int, timeused int, oct_in int, oct_out int); Simply put, #calls and usage info for a given customer on a given day. (the acctid is a local-to-us thing...simply a foreign key into my customer master table which maps cust accounts with actual usernames.) 5) Also daily, I delete records from the calldetail that are older than 30 days (possible modification is to move older records to another table, dropping all data that I really really never have to have...at the moment, I just can't see needing any of it). And don't forget to vacuum. (: 6) Again, access to summary tables via httpd, as appropriate for internal use and customer satisfaction (lordy don't they love the pretty little graphs). I also don't record start records in my calldetail, they contain nothing of any consequence. Anything I'd possibly use start records for will be handled by my sessiontable. The point is more that you'll obviously have to consider some kind of data reduction to keep the info you want/need readily accessable without having to have obscene amounts of hard drive space. Sure, you never have to lose the calldetail stuff...nothing says you must delete it all, just start burning cds. But you also want to be able to casually issue a [select month,avg(numcalls),avg(duration) from custsum where date(stoptime)>='01/01/95' group by month] query without having to find and mount the right cd(s). Disclamer: I'm not a database administrator, so I officially don't know what I'm talking about. I haven't actually done all of the above yet: I just got Radiator, don't have 30 days of data in my tables yet, the summary tables are still being designed, and the httpd server isn't even on the machine yet. But, daz the plan. Any comments, suggestions, or potshots delivered approximately now would prove helpful...a month or two from now and I'll be finding out if my plan is worth a crap in a much harder to fix scenario. (: Lon Stockton MoonStar === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Realms based on prefix?
RTFM. Did you even read the docs at all? The example config file that came with radiator shows how to do exactly what you're talking about. Investigate the RewriteUsername keyword. On Wed, 10 Mar 1999, Oscar Garzon wrote: > Is there any way in Radiator to identify a realm based not on the domain > suffix, but on a prefix basis? That is... Realms control is working ok, > when the user types: > > [EMAIL PROTECTED] > > But now I would like a session to be handled with a different realm, when > the users types for instance: > > REALM/user > > being the "/" character, the field separator === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Assigning IP adresses from radius?
On Wed, 10 Mar 1999, mike grommet wrote: > Boy, its a day for questions from little me. I am experiencing problems > trying > to assign a static IP number to a user upon login. Investigate the UseAddressHint keyword...make sure it's doing what you think it's doing... === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Question: Authenticate by unix, but use SQL accounting?
On Wed, 10 Mar 1999, mike grommet wrote: > For management purposes, I would like to be able to keep my authentication > working as it is with my unix users file, but I would like to > store all accounting information, and session limit stuff in a SQL > database... 'Tis what I'm doing at the moment, albeit I have my previous radius server still doing authentication on another machineRadiator doesn't even see the auth requests at this point in time. Basically, I'm giving Radiator (and the server I constructed for it) a 'shakedown cruise' prior to making it do mission-critical work. So my config is fairly simple since all my Radiator is seeing is accounting packets and stuffing them in a SQL (Postgres) database. Further, as soon as I'm satisfied with the stability of my new server, I'll be doing auth on it too, but the auth will be by another SQL database...I want to get away from that unix passwd file crap asap. > >From reading the docs, it seems radiator can do this if I am doing authby > SQL, > but doesnt seem to include possibilities for this scenario... Am I missing > something? I'm shooting in the dark kinda as a newbie to the Radiator configuration, but I suspect that you'd have two authby clauses and a ContinueWhileAccept keyword or somesuch. The first authby clause deals with your passwd file authentication and doesn't do any accounting. The second authby clause doesn't do auth but stuffs the accounting in a SQL database. The Continue* keyword (whichever one it really is) ensures that a packet has to pass thru both. I'm sure there's a way to config it, but if all else fails, you could always just run two instances of Radiator on different ip's on the server in question, and config one to do authby unix for your auth stuff and the other to do authby sql for your acco stuff. Messy and inelegant if you ask me, but it's always nice to have a last-resort that is sure to work. (: > It sure would be nice to be able to do queries to an sql database to check > customer usage and such. That's what I thought, and boy did I underestimate how nice it really is. I knew it'd be nice, but I really had no idea how great it was until the db was there and AnyDataIWanted suddenly became no more of an issue than how to properly word my sql query. I've spent a couple of entire nights playing with all the queries that I can now do and finding out all kinds of stuff about my statistics. I can only say that I shoulda been doing this from the beginning. > I realize I could make an SQL database out of the unix password file, but I > would prefer to not > have to do this to achieve this functionality... That's my current plan, as soon as my new server with its linux, radiator, postgres, perl and apache shows me a month of continous troublefree uptime, I'm switching to doing my auth via sql as well. Same reason; having data in a *real* database makes everything easier. No more greppin' through a passwd file to find out who's on that server or how many accounts or or or. Especially when it comes to interesting things like having different check/reply items. I'm seeing a web page my customers can go to and specify that their child's account can't log in after 11pm, or that all their packets get routed thru our in-house filtering software. I'm also seeing policies such as 'if your bill is 30 days past due, you can only log on if 10% of my modems are idle; if you're 60 days past due, you can only access email and local resources...no surfin for you ya bum, and if you're 90 everything you do takes you to a 'pay your bill' webpage. And at 120...well, the results of a simple sql query gets auto-emailed to my lawyer. *grin*) Lon Stockton MoonStar === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) timestamp
On Tue, 2 Mar 1999, Mike McCauley wrote: > The bahaviour you are seeing is because the normal behaviour of > "integer-date" is to make an SQL date/time with 0 seconds. > > Its this way to be compatible with some other more braindead SQLs. Ahh, okay. Hmmph. Make the braindead ones use the formatted-date type, and give a break to people who use non-braindead stuff. *grin* > If you are at Radiator Revision 2.13, look at the new formatted-date type in > AcctColumnDef, where you can build an SQL date in any format you like. Too late. (: I am at 2.13; it was released a couple of days prior to me burning the master disk for our radius server...and it passed basic testing so I threw caution to the wind and burned my production cd with your new release rather than the older one. [all critical software on my server is burned on cd's which are mounted at appropriate parts of my filesystem (am running Linux). Stops scriptkiddies cold when they can't replace my binaries and libs and critical configs/cronjobs.] BTW, I can see where you're coming from when you say that y'all's opinion is that everybody of moderate size or better oughta be using SQL. Heck, I'm a *tiny* sized ISP (~350 customers), and a handful of days ago switched to my new server based on Linux/Radiator/Postgres/ApacheSSL. This stuff is slicker than eel shit, I'm tellin' ya. I'm learning more about everything I do simply because AnyNumberIWant is a quick sql select command. This is truly The Way It Is Supposed To Be. [and Mike, if you wanna use the slicker than eel shit comment as an endorsement from 'a rural Virginia ISP', feel free. *cackle*] Lon Stockton MoonStar === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) timestamp
I've got radiator configged to only do auth stops, and to stash the info with SQL. One of my colums is thus: AcctColumnDef STOPTIME,Timestamp,integer-date My database is PostgresSQL (running under Linux), and the column is defined as 'STOPTIME timestamp not null'. Everything is almost cool. I note that the timestamps recorded in the database are always approximately equal to the timestamp I see in the detail file (minus Acct-Delay-Time)...but the seconds are 'truncated', that is, the timestamp recorded always has the seconds set to '00'. I actually can live with it, but it's probably something blindingly obvious that I should know...and one year hence, I'll probably be ashamed I ever wrote this message, but I gotta know...what's going on here? Resolution issue in postgres's implementation of timestamp? Radiator? Me? === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
