Hello, I finally got around to upgrading our RADIUS servers to FR 1.1.1. Everything is working well except we seem to have a customer somewhere who is able to attempt to auth without sending a User-Name attribute and a blank User-Password. I'm not sure at this point if it is an attempted exploit or just a badly coded client. Here is an attempt: --- Walking the entire request list --- Cleaning up request 1 ID 88 with timestamp 44512aa3 Nothing to do. Sleeping until we see a request. rad_recv: Access-Request packet from host xxx.xxx.xxx.xxx:21674, id=218, length=203 Framed-Protocol = PPP User-Password = "" Calling-Station-Id = "##########" Called-Station-Id = "##########" NAS-Port-Type = Async Cisco-NAS-Port = "Async172" NAS-Port = 172 Connect-Info = "28800/26400 V34+/V44/LAPM (53333/26400)" Cisco-AVPair = "v92-info=V.92 QC MOH/QC Full Train Success/0/0" Service-Type = Framed-User NAS-IP-Address = xxx.xxx.xxx.xxx Processing the authorize section of radiusd.conf modcall: entering group authorize for request 2 rlm_realm: Proxy reply, or no User-Name. Ignoring. modcall[authorize]: module "suffix" returns noop for request 2 rlm_attr_rewrite: Could not find value pair for attribute Realm modcall[authorize]: module "fix_realm" returns noop for request 2 The very next line is the segfault. Here is my "fix_realm" module: attr_rewrite fix_realm { attribute = Realm searchin = packet searchfor = "blue.*$$" replacewith = "bluefrog.com" ignore_case = yes new_attribute = no max_matches = 1 append = no } (we used to use both bluefrognet.net and bluefrog.biz, so this attempts to normalize everyone since the username in the db is always user@bluefrog.com) I think the fact that there is no realm may be causing the segfault. Unfortunately, I have no idea how to recreate the situation myself and I have yet to try to track down the customer. I didn't see this problem listed on bugs.freeradius.org and don't recall seeing mention of it on the list. The other thing I changed in the authorize section of the config file is that I moved the suffix (and fix_realm) higher in the list (as you can probably tell from the debug output). Here is my authorize section: authorize { suffix fix_realm preprocess chap mschap eap files redundant { # slave first sql2 sql1 handled } } My old config wasn't using huntgroups, so I didn't need to fix_realm before preprocessing. I need to do that now, hence suffix and fix_realm are at the top. I will continue to dig at this problem from my end, but I thought maybe Alan or someone could modify radclient to send a packet like above and see if they can recreate the bug (or better yet, have a look at the code and go, "oh yeah, that is why that happened"). My C coding skills have all but rusted solid at this point. Let me know if you need any more information. Thanks! -- Dennis Skinner Systems Administrator BlueFrog Internet http://www.bluefrog.com