Re: (RADIATOR) NT dialup and Radiator (Updated 8/10/99)
Framed-Compression = Van-Jacobsen-TCP-IP Framed-Compression = Van-Jacobson-TCP-IP I'm not sure why our PM3's suddenly get fussy over the spelling error when served by Radiator rather than Radius, but that's what appears to happen. It's probably a difference in the dictionary files. The text attributes aren't sent by radius, they are translated to numbers according to the dictionary files. If your users file or defaults say "Jacobsen" but the dictionary says "Jacobson", they won't match and the attribute can't be sent. Nor am I sure why Windows 95/98 clients don't seem to be affected. It blew our NT users (and Win3 users) right out of the water, though. I think it is possibly autodetected on some OS but not others. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) NT dialup and Radiator (Updated 8/10/99)
Something new 8/10/99: I removed Radiator from our system and put back the old radius we were using, Meret AAA, and NT customers can now connect. This is a Radiator issue, but I have no idea where to look for a solution. BTW this is running on a BSDI 4.0 system. Something interesting 8/9/99: I had an NT customer call me up today and he told me that he was able to connect and browse yesterday just fine for about two hours today he can't. The logfile and detail file showed no difference in what happened, except that it was logged in the detail file multiple times. There were two start accounting records and three stop all with the same session ID the only difference is that the "Acct-Delay-time" is different. I have noticed this in many other locations in the detail file as well. More info: When an NI customer connects and can't browse (open socket connections) they are able to ping, trace and perform host name lookups, so it doesn't appear to be a routing issue. Here are portions of the logfile at trace level 4. I have included what the startup looks like, what an NT (bad) connection looks liks and what a 98 (good) connection looks like. I am not sure why it says that thoes attribute numbers are not defined because they are, they are Ascend specific attributes, but that only seems to affect accounting. --START UP INFO FROM LOG FILE-- Mon Aug 9 09:42:03 1999: NOTICE: SIGTERM received: stopping Mon Aug 9 09:42:09 1999: DEBUG: Reading users file /etc/radiator/users Mon Aug 9 09:42:09 1999: DEBUG: Reading password file /etc/master.passwd Mon Aug 9 09:42:15 1999: DEBUG: Reading group file /etc/group Mon Aug 9 09:42:16 1999: INFO: Server started Mon Aug 9 09:42:16 1999: ERR: Attribute number 120 (vendor 529) is not defined in your dictionary Mon Aug 9 09:42:16 1999: ERR: Attribute number 122 (vendor 529) is not defined in your dictionary Mon Aug 9 09:42:16 1999: ERR: Attribute number 121 (vendor 529) is not defined in your dictionary Mon Aug 9 09:42:16 1999: DEBUG: Packet dump: *** Received from 209.244.17.8 port 53603 Code: Accounting-Request Identifier: 163 Authentic: Z]j249178196[233%Uvr130225200 Attributes: User-Name = "militarypress" NAS-Identifier = "209.244.42.44" NAS-Port = 391 Framed-Protocol = PPP Framed-Address = 216.98.152.250 Client-Port-DNIS = "6196644638" Caller-Id = "8585772916" Acct-Status-Type = Start Acct-Delay-Time = 0 Acct-Session-Id = "285706089" Acct-Authentic = RADIUS NAS-Port-Type = Async Mon Aug 9 09:42:16 1999: DEBUG: Handling request with Handler 'Realm=DEFAULT' Mon Aug 9 09:42:16 1999: DEBUG: SDB1 Adding session for militarypress, 209.244.42.44, 391 Mon Aug 9 09:42:16 1999: DEBUG: Handling with Radius::AuthFILE Mon Aug 9 09:42:16 1999: DEBUG: Accounting accepted Mon Aug 9 09:42:16 1999: DEBUG: Packet dump: *** Sending to 209.244.17.8 port 53603 Code: Accounting-Response Identifier: 163 Authentic: Z]j249178196[233%Uvr130225200 Attributes: Mon Aug 9 09:42:16 1999: DEBUG: Packet dump: *** Received from 216.98.155.2 port 1026 Code: Access-Request Identifier: 214 Authentic: 2051418169u:#157246183157154135184233j Attributes: User-Name = "beachchair1" User-Password = "133182b`145192E250}d(189o97170" NAS-Identifier = "216.98.155.2" NAS-Port = 3 NAS-Port-Type = Async Service-Type = Framed-User Framed-Protocol = PPP Connect-Info = "26400 LAPM/V42BIS" Mon Aug 9 09:42:16 1999: DEBUG: Handling request with Handler 'Realm=DEFAULT' Mon Aug 9 09:42:16 1999: DEBUG: SDB1 Deleting session for beachchair1, 216.98.155.2, 3 Mon Aug 9 09:42:16 1999: DEBUG: Handling with Radius::AuthFILE Mon Aug 9 09:42:16 1999: DEBUG: Radius::AuthFILE looks for match with beachchair1 Mon Aug 9 09:42:16 1999: DEBUG: Radius::AuthFILE looks for match with DEFAULT Mon Aug 9 09:42:16 1999: DEBUG: Handling with Radius::AuthUNIX Mon Aug 9 09:42:16 1999: DEBUG: Radius::AuthUNIX looks for match with beachchair1 Mon Aug 9 09:42:16 1999: DEBUG: Radius::AuthUNIX ACCEPT: Mon Aug 9 09:42:16 1999: DEBUG: Radius::AuthFILE ACCEPT: Mon Aug 9 09:42:16 1999: DEBUG: Access accepted for beachchair1 Mon Aug 9 09:42:16 1999: DEBUG: Packet dump: *** Sending to 216.98.155.2 port 1026 Code: Access-Accept Identifier: 214 Authentic: 2051418169u:#157246183157154135184233j Attributes: Framed-Address = 255.255.255.254 User-Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Netmask = 255.255.255.0 Framed-Routing = None Framed-MTU = 1500 Framed-Compression = Van-Jacobsen-TCP-IP Session-Timeout = 28800 Idle-Timeout = 1800 Mon Aug 9 09:42:16 1999: ERR: Attribute number 120 (vendor 529) is not defined in your dictionary Mon Aug 9 09:42:16 1999: ERR: Attribute number 122 (vendor
Re: (RADIATOR) NT dialup and Radiator (Updated 8/10/99)
I nearly went insane trying to track this one down when I ran into it. Change your users file from this : Framed-Compression = Van-Jacobsen-TCP-IP to this : Framed-Compression = Van-Jacobson-TCP-IP ...and see if it helps. It cleared up the same problem for me. VJ only affects TCP traffic, so pings (ICMP) and DNS (UDP) are unaffected when VJ is out of whack. I'm not sure why our PM3's suddenly get fussy over the spelling error when served by Radiator rather than Radius, but that's what appears to happen. If I proxy all our authentication traffic to our Radius server through Radiator running at trace 4, I can see that Radius serves it up with the spelling error intact. Nor am I sure why Windows 95/98 clients don't seem to be affected. It blew our NT users (and Win3 users) right out of the water, though. Lucent/Livingston's site has several pages with the spelling error given in example code, so I almost suspect that Radius example files may come with it or did come with it for a time. ---Mike Biesele - Original Message - From: John Davidson [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, August 10, 1999 12:48 PM Subject: (RADIATOR) NT dialup and Radiator (Updated 8/10/99) | Something new 8/10/99: I removed Radiator from our system and put back the old radius we were using, Meret AAA, and NT customers can now connect. This is a Radiator issue, but I have no idea where to look for a solution. BTW this is running on a BSDI 4.0 system. | | Something interesting 8/9/99: I had an NT customer call me up today and he told me that he was able to connect and browse yesterday just fine for about two hours today he can't. The logfile and detail file showed no difference in what happened, except that it was logged in the detail file multiple times. There were two start accounting records and three stop all with the same session ID the only difference is that the "Acct-Delay-time" is different. I have noticed this in many other locations in the detail file as well. | | More info: When an NI customer connects and can't browse (open socket connections) they are able to ping, trace and perform host name lookups, so it doesn't appear to be a routing issue. | | Here are portions of the logfile at trace level 4. I have included what the startup looks like, what an NT (bad) connection looks liks and what a 98 (good) connection looks like. I am not sure why it says that thoes attribute numbers are not defined because they are, they are Ascend specific attributes, but that only seems to affect accounting. | | --START UP INFO FROM LOG FILE-- [large amount of trace output deleted for brevity] | John Davidson | | | | Hi John - | | It would also be useful to include debug output at Trace level 4 showing what | is happening. I would have expected to see at least a couple of errors when | Radiator started up with this configuration. | | On Sat, 07 Aug 1999, [EMAIL PROTECTED] wrote: | Hi; | | We installed Radiator last weekend on our system and since that time our dialup NT (4.0) customers have had problems accessing the system. They authenticate just fine but can't browse. To really confuse things this only happens when they dialup into our PM3's not our Ascend's. | | I know that this doesn't sound like a Radius problem, but that is the only thing that has changed on our system. | | Here is the info from our config files that is relivant: | | From radius.cfg: | | Realm DEFAULT | AuthByPolicy ContinueUntilAccept | | AuthBy FILE | # The filename defaults to %D/users | /AuthBy | | # Log accounting to the detail file in LogDir | MaxSessions 1 | AcctLogFileName %L/detail | SessionDatabase SDB1 | /Realm | Realm thiswontmatchanything | # This clause says that for entries in the users file | # that specify Auth-Type=System, use the UNIX module to | # authenticate them | AuthBy UNIX | Identifier System | Filename /etc/master.passwd | /AuthBy | SessionDatabase SDB1 | /Realm | | | I have rewritten part of your config as follows: | | # SessionDatabase is a global parameter using either SQL or DBM | SessionDatabase SQL | DBSource | DBUsername ... | DBAuth ... | /SessionDatabase | | # This clause says that for entries in the users file | # that specify Auth-Type=System, use the UNIX module to | # authenticate them | AuthBy UNIX | Identifier System | Filename /etc/master.passwd | /AuthBy | | # Set up a DEFAULT Realm | Realm DEFAULT |AuthBy FILE |Filename %D/users # Make it clear what users file | /AuthBy |# Set maximum number of sessions to 1 |MaxSessions 1 |# Log
Re: (RADIATOR) NT dialup and Radiator (Updated 8/10/99)
THANK YOU!!! THANK YOU!!!THANK YOU!!! THANK YOU!!! THANK YOU!!!THANK YOU!!! THANK YOU!!! THANK YOU!!! THANK YOU!!! THANK YOU!!! I don't think I can say it enough times. That immediatly solved the problem. This also solved a THREE year problem we have been having with our 95/98 customers (unable to establish a compatable set of network protocolls). Everybody seems to be connecting faster and borwsing faster. Again thank you!!! John D [EMAIL PROTECTED] PS to radiator folk: This might be a good one to put in the Radiator FAQ? I nearly went insane trying to track this one down when I ran into it. Change your users file from this : Framed-Compression = Van-Jacobsen-TCP-IP to this : Framed-Compression = Van-Jacobson-TCP-IP ...and see if it helps. It cleared up the same problem for me. VJ only affects TCP traffic, so pings (ICMP) and DNS (UDP) are unaffected when VJ is out of whack. I'm not sure why our PM3's suddenly get fussy over the spelling error when served by Radiator rather than Radius, but that's what appears to happen. If I proxy all our authentication traffic to our Radius server through Radiator running at trace 4, I can see that Radius serves it up with the spelling error intact. Nor am I sure why Windows 95/98 clients don't seem to be affected. It blew our NT users (and Win3 users) right out of the water, though. Lucent/Livingston's site has several pages with the spelling error given in example code, so I almost suspect that Radius example files may come with it or did come with it for a time. ---Mike Biesele - Original Message - From: John Davidson [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, August 10, 1999 12:48 PM Subject: (RADIATOR) NT dialup and Radiator (Updated 8/10/99) | Something new 8/10/99: I removed Radiator from our system and put back the old radius we were using, Meret AAA, and NT customers can now connect. This is a Radiator issue, but I have no idea where to look for a solution. BTW this is running on a BSDI 4.0 system. | | Something interesting 8/9/99: I had an NT customer call me up today and he told me that he was able to connect and browse yesterday just fine for about two hours today he can't. The logfile and detail file showed no difference in what happened, except that it was logged in the detail file multiple times. There were two start accounting records and three stop all with the same session ID the only difference is that the "Acct-Delay-time" is different. I have noticed this in many other locations in the detail file as well. | | More info: When an NI customer connects and can't browse (open socket connections) they are able to ping, trace and perform host name lookups, so it doesn't appear to be a routing issue. | | Here are portions of the logfile at trace level 4. I have included what the startup looks like, what an NT (bad) connection looks liks and what a 98 (good) connection looks like. I am not sure why it says that thoes attribute numbers are not defined because they are, they are Ascend specific attributes, but that only seems to affect accounting. | | --START UP INFO FROM LOG FILE-- [large amount of trace output deleted for brevity] | John Davidson | | | | Hi John - | | It would also be useful to include debug output at Trace level 4 showing what | is happening. I would have expected to see at least a couple of errors when | Radiator started up with this configuration. | | On Sat, 07 Aug 1999, [EMAIL PROTECTED] wrote: | Hi; | | We installed Radiator last weekend on our system and since that time our dialup NT (4.0) customers have had problems accessing the system. They authenticate just fine but can't browse. To really confuse things this only happens when they dialup into our PM3's not our Ascend's. | | I know that this doesn't sound like a Radius problem, but that is the only thing that has changed on our system. | | Here is the info from our config files that is relivant: | | From radius.cfg: | | Realm DEFAULT | AuthByPolicy ContinueUntilAccept | | AuthBy FILE | # The filename defaults to %D/users | /AuthBy | | # Log accounting to the detail file in LogDir | MaxSessions 1 | AcctLogFileName %L/detail | SessionDatabase SDB1 | /Realm | Realm thiswontmatchanything | # This clause says that for entries in the users file | # that specify Auth-Type=System, use the UNIX module to | # authenticate them | AuthBy UNIX | Identifier System | Filename /etc/master.passwd | /AuthBy | SessionDatabase SDB1 | /Realm | | | I have rewritten part of y
Re: (RADIATOR) NT dialup and Radiator (Updated 8/10/99)
On Aug 10, 6:29pm, [EMAIL PROTECTED] wrote: Subject: Re: (RADIATOR) NT dialup and Radiator (Updated 8/10/99) THANK YOU!!! THANK YOU!!!THANK YOU!!! THANK YOU!!! THANK YOU!!!THANK YOU!!! THANK YOU!!! THANK YOU!!! THANK YOU!!! THANK YOU!!! I don't think I can say it enough times. That immediatly solved the problem. This also solved a THREE year problem we have been having with our 95/98 customers (unable to establish a compatable set of network protocolls). Everybody seems to be connecting faster and borwsing faster. Again thank you!!! John D [EMAIL PROTECTED] PS to radiator folk: This might be a good one to put in the Radiator FAQ? Quite right. Done. -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
