Re: 093 Crashes with unknown tokens
Matt Sapp wrote: Greg, While you may have misunderstood Alan's terseness as him being nasty to you, please look at the situation. You're saying that if there was a configuration file error, then by all means, stop the server, but if it's "just" a users file error, then it shouldn't be halted and the server should keep going on with some half-correct information. Well, I'm perfectly happy if the user that contains the "wonky" data (most often, it's not really a typo, but a new token we're experimenting with) gets ignored. I'm content with having *one* customer call me because they can't get authenticated than have the whole system come down because there's something different in a single user. Personally, I don't see how the users file being in proper shape is any less critical than any other configuration file being correct. You'd be much better off implementing some solution to make sure the users file is correct (perhaps some type checking in whatever system you use to manage your users -- surely you don't have a bunch of type-prone data entry people editing the users file by hand, do you?). The users file has a very specific format, and it's not hard to follow. If you have proper checks in your management system, this is a moot point, and this has been pointed out in reference to the dialup_admin package. Interestingly, the old Livingston radius format didn't need the commas at the end of the lines. I was really surprised when none of the other radius servers I looked (Free, Open, Gnu) could read that file. I can live with having to generate the file differently to work in the updated format. (Was that an RFC change, or was Livingston just broken?) As another example, GnuRadius doesn't like an ampersand in a username, but FreeRadius does. Should my system come down becuase I've got what seems to be *valid* data, but the radius server doesn't understand it? [RFC 2138 has provisions for non-alphanumerics in the User-Name field.] -Greg G - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Alan DeKok wrote: Greg G <[EMAIL PROTECTED]> wrote: It does, but not what you'd hoped. It looks like I'm going to wind up using GNU Radius, because it *doesn't* exit when it encounters something it doesn't understand in the user file. It discards the entry for the invalid user. Meaning that the server doesn't behave as intended, and it's probably difficult for the administrator to figure that out. So you're left with a server which isn't doing what you want... No, it's doing just what I want. It's logging the problem with the user entry and getting on with processing. There's no reason that an single authentication item in the users file should halt the server. If it's a problem in the configuration file or something critical like that, absolutely there should be no further action. I understand that you have a different opinion, but that doesn't negate mine, or the fact that this is how I'd like it to work. Pointing me at the readme file isn't much help either, since that boils down to "fix it, or don't. Whatever." -Greg G
Re: 093 Crashes with unknown tokens
Alan DeKok wrote: Greg G <[EMAIL PROTECTED]> wrote: Ah, yes. The "you've got to do what I want NOW for FREE!" response. No, it's the "Hey, asshole, maybe you know the code better than I do" reponse. I *do* know the code better than you, and I disagree with your position. All else aside, that should tell you something. It does, but not what you'd hoped. It looks like I'm going to wind up using GNU Radius, because it *doesn't* exit when it encounters something it doesn't understand in the user file. It discards the entry for the invalid user. It doesn't seg fault if I make an acct request. And I don't have to fight with someone whose idea of gathering up new coders is "Fix it" without any help or guidance whatsoever. The main README file is ever so applicable to this situation. Go read it, and stop wasting your time posting baseless complaints on the list. So my asking for a feature is a baseless complaint? Rght. -Greg G
Re: 093 Crashes with unknown tokens
Alan DeKok wrote: Greg G <[EMAIL PROTECTED]> wrote: Well exuse the hell out of me for not having worked with open source stuff before. You've got a great bedside manner, ya know. Ah, yes. The "you've got to do what I want NOW for FREE!" response. No, it's the "Hey, asshole, maybe you know the code better than I do" reponse. Perhaps you didn't understand my explanations as to why I disagreed with your position. Perhaps you didn't care. Either way, it's not my problem. You didn't give me any explanation other than "because I said so" and "go sift through my code, loser". -Greg G
Re: 093 Crashes with unknown tokens
Well exuse the hell out of me for not having worked with open source stuff before. You've got a great bedside manner, ya know. -Greg G Alan DeKok wrote: Greg G <[EMAIL PROTECTED]> wrote: I may have to, but I can't do that short-term. I really need a radius server that I can force to re-read the users file on-demand. FreeRadius seems to be able to do that, but isn't quite as stable as I'd like. I've found that the SIGHUP will bring down the server if it's still in the start-up phase. It probably should ignore the HUP signal until it's ready. Yup. Because FR is exiting when it runs into a key that it doesn't know, thereby bringing down the whole authentication system. I regard that as worthy of complaining about. Then fix it. You have the source. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Alan DeKok wrote: Greg G <[EMAIL PROTECTED]> wrote: Well, if I have one bad entry in a users file with 10,000 users in it, I'd rather it just ignore that user with the bad entry. Then use SQL. I may have to, but I can't do that short-term. I really need a radius server that I can force to re-read the users file on-demand. FreeRadius seems to be able to do that, but isn't quite as stable as I'd like. I've found that the SIGHUP will bring down the server if it's still in the start-up phase. It probably should ignore the HUP signal until it's ready. How would you recommend that I do that? The file will parse correctly. And it's not something that should be a *fatal* mistake. It's not really a mistake, either. If it's not really a mistake, why are you complaining? Because FR is exiting when it runs into a key that it doesn't know, thereby bringing down the whole authentication system. I regard that as worthy of complaining about. -Greg G
Re: What goes in acct_users & a seg fault
Chris Parker wrote: At 01:11 PM 11/21/2003, Greg G wrote: Chris Parker wrote: So, the packet being sent is an invalid accounting packet, as it doesn't contain NAS-IP-Address or NAS-Identifier. Nor a session-id. Now that's strange, because this packet is being sent from radclient. I thought I had seen it work in 092 with the default acct_users, but it's seg faulting in 093 either way. echo "User-Name = test1" | radclient radiusserver.mydomain.net acct a_secret radclient sends what you tell it to send. If you tell it to send an invalid accounting packet ( since you aren't including one of the manadatory attributes ), it will do so. If you want to send a valid accounting packet, add more attributes to your call to radclient. Ah. I see. OK. I'm having trouble figuring out what a good set of attributes are to send through for this. I'm giving it all 4 parameters that it's asking for (User-Name, NAS-IP-Address, NAS-Port-Id, Acct-Session-Id) and it's still seg faulting, so I guess I'll have to wait until this gets fixed anyay. -Greg G - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Chris Parker wrote: Nothing is unclear about it. I would prefer that the daemon not fail out if there's a data error in one of the files. It should report that error to a log and continue on. Otherwise, it becomes a fairly trivial task to crash out the daemon. Our users file is fairly dynamic and if someone makes a typo putting in a new entry, I don't want the whole system coming down. Sorry, I prefer my failures to be deterministic. I don't want the server carrying on and running with a partial config and doing something un- expected. For config issues, I agree, but if there's an unknown key in the *users* file, I don't think the system should stop. Especially if it's a key that's only in one or two users (which is usually the case here). If you are concerned with making typos, you may want to look at the 'dialup-admin' package, which allows you to easily manage an SQL database rather than a flat users file. Your chances of making a typo would then be greatly reduced imho, and if you did typo on one entry for a user, it would not affect any other users. I will look into it, but I also don't want the authentication server to stop if we take the database down for maintenance. We're a bit tied to the file method at the moment, although I suspect that feeding directly from our database will be better and might be in the plan. -Greg G - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: What goes in acct_users & a seg fault
Chris Parker wrote: At 12:39 PM 11/21/2003, Greg G wrote: I'm trying to figure out what goes into the acct_users. I had thought it was user entries like those in the users file, but that doesn't seem to really be the case. It appears to be getting parsed the same way (based on 'My-Key' entries that get rejected). However, at run-time, that doesn't appear to be the case. In fact, I get a seg-fault. Huh? You are making things more difficult for yourself than need be. In most cases you won't need to put anything in acct-users. OK. That wasn't really clear, but that's easy to handle. rad_recv: Accounting-Request packet from host xxx.xxx.xxx.xxx:36538, id=167, length=27 User-Name = "test1" modcall: entering group preacct for request 0 http://www.freeradius.org/rfc/rfc2866.html#Accounting-Request Any attribute valid in a RADIUS Access-Request or Access-Accept packet is valid in a RADIUS Accounting-Request packet, except that the following attributes MUST NOT be present in an Accounting- Request: User-Password, CHAP-Password, Reply-Message, State. Either NAS-IP-Address or NAS-Identifier MUST be present in a RADIUS Accounting-Request. It SHOULD contain a NAS-Port or NAS- Port-Type attribute or both unless the service does not involve a port or the NAS does not distinguish among its ports. So, the packet being sent is an invaled accounting packet, as it doesn't contain NAS-IP-Address or NAS-Identifier. Nor a session-id. Now that's strange, because this packet is being sent from radclient. I thought I had seen it work in 092 with the default acct_users, but it's seg faulting in 093 either way. echo "User-Name = test1" | radclient radiusserver.mydomain.net acct a_secret That being said, the server shouldn't seg-fault in that instance. It should reject the packet as invalid and not try to process it further. We'll look into this and correct the behaviour. That works for me. -Greg G - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 093 Crashes with unknown tokens
Alan DeKok wrote: Greg G <[EMAIL PROTECTED]> wrote: Nothing is unclear about it. I would prefer that the daemon not fail out if there's a data error in one of the files. It should report that error to a log and continue on. To doing what? Are you really asking that the server send RADIUS responses with the WRONG information in them? Well, if I have one bad entry in a users file with 10,000 users in it, I'd rather it just ignore that user with the bad entry. Our users file is fairly dynamic and if someone makes a typo putting in a new entry, I don't want the whole system coming down. Then double check the files before you let the server use them. It's not the servers fault you made a mistake. How would you recommend that I do that? The file will parse correctly. And it's not something that should be a *fatal* mistake. It's not really a mistake, either. We use some custom items now and then. -Greg G
Re: 093 Crashes with unknown tokens
Alan DeKok wrote: Greg G <[EMAIL PROTECTED]> wrote: Here's what I get from FR 0.93 /usr/local/etc/raddb/users[9]: Parse error (reply) for entry 007gold: Unknown attribute My-Key Errors reading /usr/local/etc/raddb/users radiusd.conf[921]: files: Module instantiation failed. And then back to a prompt. That's bad since I won't always be able to watch the radiusd start up. So... it doesn't crash. It gives an error, which tells you what went wrong, and why. What, exactly is unclear about the error message? Nothing is unclear about it. I would prefer that the daemon not fail out if there's a data error in one of the files. It should report that error to a log and continue on. Otherwise, it becomes a fairly trivial task to crash out the daemon. Our users file is fairly dynamic and if someone makes a typo putting in a new entry, I don't want the whole system coming down. -Greg G
What goes in acct_users & a seg fault
I'm trying to figure out what goes into the acct_users. I had thought
it was user entries like those in the users file, but that doesn't seem
to really be the case. It appears to be getting parsed the same way
(based on 'My-Key' entries that get rejected). However, at run-time,
that doesn't appear to be the case. In fact, I get a seg-fault.
rad_recv: Accounting-Request packet from host xxx.xxx.xxx.xxx:36538,
id=167, length=27
User-Name = "test1"
modcall: entering group preacct for request 0
modcall[preacct]: module "preprocess" returns noop for request 0
rlm_realm: No '@' in User-Name = "test1", looking up realm NULL
rlm_realm: No such realm "NULL"
modcall[preacct]: module "suffix" returns noop for request 0
modcall[preacct]: module "files" returns noop for request 0
modcall: group preacct returns noop for request 0
modcall: entering group accounting for request 0
rlm_acct_unique: WARNING: Attribute NAS-Port-Id was not found in
request, unique ID MAY be inconsistent
rlm_acct_unique: WARNING: Attribute Acct-Session-Id was not found in
request, unique ID MAY be inconsistent
rlm_acct_unique: Hashing ',Client-IP-Address =
xxx.xxx.xxx.xxx,NAS-IP-Address = xxx.xxx.xxx.xxx,,User-Name = "test1"'
rlm_acct_unique: Acct-Unique-Session-ID = "4a16e50737b1c920".
modcall[accounting]: module "acct_unique" returns ok for request 0
radius_xlat:
'/usr/local/var/log/radius/radacct/xxx.xxx.xxx.xxx/detail-20031121'
rlm_detail:
/usr/local/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d
expands to /usr/local/var/log/radius/radacct/xxx.xxx.xxx.xxx/detail-20031121
Segmentation Fault(coredump)
#
(gdb) bt
#0 0xff0c69a8 in memccpy () from /usr/lib/libc.so.1
#1 0xff10d6bc in fputs () from /usr/lib/libc.so.1
#2 0xfe6a0c0c in do_detail (instance=0x401c020, request=0x142080,
pair=0x142160) at rlm_detail.c:225
#3 0x1d830 in call_modsingle (component=3, sp=0x140800,
request=0x142080, default_result=7) at modcall.c:201
#4 0x1d988 in modcall (component=3, c=0x140800, request=0x142080) at
modcall.c:312
#5 0x1d8d8 in call_modgroup (component=3, g=0x140800, request=0x142080,
default_result=2) at modcall.c:226
#6 0x1da14 in modcall (component=3, c=0x1407c0, request=0x142080) at
modcall.c:303
#7 0x17884 in rad_accounting (request=0x142080) at acct.c:69
#8 0x15118 in rad_respond (request=0x142080, fun=0x177c8
) at radiusd.c:1537
#9 0x14b84 in rad_process (request=0x142080, dospawn=0) at radiusd.c:1244
#10 0x145b4 in main (argc=1, argv=0xef3c) at radiusd.c:1020
Hmm. That line seems to be "fputs(ctime_r(&request->timestamp,
buffer), outfp);"
I can't set a breakpoint there, though. I'm not sure if it's in a
shared library or because it's getting built with -g -O2.
-Greg G
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
093 Crashes with unknown tokens
Here's what I get from FR 0.93 /usr/local/etc/raddb/users[9]: Parse error (reply) for entry 007gold: Unknown attribute My-Key Errors reading /usr/local/etc/raddb/users radiusd.conf[921]: files: Module instantiation failed. And then back to a prompt. That's bad since I won't always be able to watch the radiusd start up. -Greg G - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: 092 Crashes with unknown tokens
Alan DeKok wrote: Greg G <[EMAIL PROTECTED]> wrote: I'm working on migrating from a Livingston 2.1.0 radius server to FreeRadius 0.9.2, and I'm running into some odd stuff. The most notable of this stuff is that if there's a key in the users file that FR doesn't recognize, it crashes! Key? What are keys? Sorry, I didn't explain myself well. Here's a sample entry from my users file. I'm calling the thing to the left of the = sign a key. This entry will crash FR 092, when it gets to the "My-Key = My-Value" entry. test_user Crypt-Password = "07IycyqZJjvKw" Framed-Address = 255.255.255.254, Framed-Compression = Van-Jacobsen-TCP-IP, Framed-MTU = 1500, Framed-Netmask = 255.255.255.255, User-Service-Type = Framed-User, My-Key = My-Value, Port-Limit = 1, Framed-Routing = None, Framed-Protocol = PPP I haven't yet chased this down, as I wanted to ask if this was already a known issue. Nope. See 'doc/bugs' for more details. OK. I'll rebuild the server and see what I get. At least I'm doing the first part. :) -Greg G
092 radping calls radwho incorrectly?
It looks like radping is calling radwho with both a -o and a -e option. radwho doesn't take either of these options, and consequently doesn't run. Hmmm. Here's the other odd thing. I can't see where that radping script is being created. Do I maybe have something from a different radius distro? -Greg G - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
092 Crashes with unknown tokens
I'm working on migrating from a Livingston 2.1.0 radius server to FreeRadius 0.9.2, and I'm running into some odd stuff. The most notable of this stuff is that if there's a key in the users file that FR doesn't recognize, it crashes! That's bad. I haven't yet chased this down, as I wanted to ask if this was already a known issue. Thanks. -Greg G - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
