You wrote.... > I suspect the routers in question are Cisco's? If so, then you will need a > Service-Type = Framed-User as a Reply attribute. Your current definition for > DEFAULT has it only as a check item. Try this: > > DEFAULT Service-Type = Framed-User > Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Routing = None, > Framed-MTU = 1500, > Framed-Compression = Van-Jacobson-TCP-IP > > Note: Cisco's *always* expect to see the Service-Type in the Access-Accept > match the Service-Type in the Access-Request. Ok, I can give that a shot. But this brings to mind two followup questions: 1) It seems quirky to have Service-Type as both a check and reply item. Is there a "null" check item that would work instead of listing it twice? I know this is picky to the point of insanity, but thought I'd ask. 2) My radius.cfg says to check SQL first, then FILE with ContinueWhileAccept. Just out of curiosity, what would happen if I had a Framed-IP-Address in both the SQL replyattr AND the defuser file? For example, a large percentage of my users should use a framed ip of 255.255.255.254 and netmask of 255.255.255.255. I'd like to put that in my defuser. But for people with a static IP and netmask, I'd like the reply attr's in SQL to take precedence over the ones in DEFUSER. When radiator checks SQL and then FILE for reply attr's and like attributes are found, are they overwritten with the last one, the first one, or are both sent??? Thanks!!! Jay West === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
