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 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 accounting to the detail file in LogDir
> | >               AcctLogFileName %L/detail
> | > </Realm>
> | >
> | > >
> | > > From users:
> | > >
> | > > DEFAULT         Auth-Type=System
> | > >         User-Service-Type = Framed-User,
> | > >         Framed-Protocol = PPP,
> | > >         Framed-IP-Address = 255.255.255.254,
> | > >         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
> | > >
> | >
> | > The standard dictionary supplied with Radiator does not define
> | > "User-Service-Type", but rather "Service-Type", so that may be your
> problem.
> | >
> | >  If your pm3's and ascends are behaving differently to the same set of
> reply
> | > items as shown above, then the problem must be with the reply items. You
> should
> | > check the debug output on the NAS equipment to see what is going on.
> | >
> | > hth
> | >
> | > Hugh
> | >
> | > --
> | > 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.
> | >
> |
> | ===
> | 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.
> 


===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Reply via email to