Re: (RADIATOR) DupInterval question

1999-05-26 Thread Mike McCauley

Hi Dave.

Your analysis of this problem seems correct: the NAS is frequently not seeing,
or perhaps is not understanding the reply from Radiator. By changing the
DupInterval to 0, you have got Radiator to reply to every request, including
the retransmitted ones.

There should be no real problem with leaving it set to 0, but I think that
there is a more deep seated problem here, and I think you should investigate
further.

My initial reaction to this is that there is some intermittent network problem
or similar causing a high packet loss rate (but maybe in one direction only, ie
Radiator to the NAS). It might be in the radiator host, the NAS or anywhere
between.

I would be looking very closely at what happens with these "lost" replies.

First you should probably see what ping tells you about packet loss rate when
you ping from the Radiator host to the portmaster.

Then you should see with snoop, or tcpdump or a sniffer whether the replies are
making it out of your radiator host onto the wire. You dont mention what sort
of hardware you are on, but I have seen some odd lost packet behaviour with
certain PC based ethernet cards.

Sorry to go on about it, Im sure you know what to do to track down a network
problem. Thats what I think this is.

Please let me know how you get on.
Cheers.


On May 26,  8:10pm, Dave Close wrote:
> Subject: (RADIATOR) DupInterval question
> I'm presently only using Radiator in a fairly new network (but working
> to extend that to many other locations). This new network has six
> sites, one directly on the Ethernet with the servers and five remote
> via frame-relay. Radiator has been working like a charm on the Ethernet
> site for more than a month, but the remote sites just came up last week.
>
> What I see for these sites is a lot of failed access requests. The NAS,
> a PortMaster 3, sends the request, Radiator approves it and sends back
> an accept, then the NAS sends a duplicate access request about three
> seconds later. Radiator ignores the duplicate request, but the NAS
> sends another one a few seconds after that which is also ignored. This
> is repeated several times before the user gives up. However, it isn't
> consistent. About 40% of the accepts are successful, no duplicate
> requests are received, and the caller is connected.
>
> Looking at the Radiator log, it seemed clear that the accept was not
> making it back to the NAS for some reason. I changed the DupInterval
> parameter for Radiator to zero and now all valid callers are
> authenticated successfully. The log file still indicates that there are
> duplicate requests but now they are being ignored. Eventually, usually
> after two or three failures, the NAS hears the accept and the caller is
> connected.
>
> This makes no sense to me. We are using PortMaster 3s in over a hundred
> sites around the world and have never seen this problem. But only in
> this one network are we using Radiator. The network itself does not
> seem a candidate for the problem; it is almost completely unloaded
> still and the accepts did sometimes work. BTW, I saw no failures of
> accounting requests. Maybe the NAS doesn't care about getting a reply
> for those?
>
> What problems will we experience if I leave the DupInterval set to
> zero? Or, alternatively, are there any other suggestions for how to
> solve this problem?
> --
> Dave Close  Quik Internet
> +1 949 548 2171 Costa Mesa California
> [EMAIL PROTECTED] http://www.quik.com/
>
>
> ===
> Archive at http://www.thesite.com.au/~radiator/
> To unsubscribe, email '[EMAIL PROTECTED]' with
> 'unsubscribe radiator' in the body of the message.
>-- End of excerpt from Dave Close



-- 
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.



(RADIATOR) DupInterval question

1999-05-26 Thread Dave Close

I'm presently only using Radiator in a fairly new network (but working 
to extend that to many other locations). This new network has six 
sites, one directly on the Ethernet with the servers and five remote 
via frame-relay. Radiator has been working like a charm on the Ethernet 
site for more than a month, but the remote sites just came up last week.

What I see for these sites is a lot of failed access requests. The NAS, 
a PortMaster 3, sends the request, Radiator approves it and sends back 
an accept, then the NAS sends a duplicate access request about three 
seconds later. Radiator ignores the duplicate request, but the NAS 
sends another one a few seconds after that which is also ignored. This 
is repeated several times before the user gives up. However, it isn't 
consistent. About 40% of the accepts are successful, no duplicate 
requests are received, and the caller is connected.

Looking at the Radiator log, it seemed clear that the accept was not 
making it back to the NAS for some reason. I changed the DupInterval 
parameter for Radiator to zero and now all valid callers are 
authenticated successfully. The log file still indicates that there are 
duplicate requests but now they are being ignored. Eventually, usually 
after two or three failures, the NAS hears the accept and the caller is 
connected.

This makes no sense to me. We are using PortMaster 3s in over a hundred 
sites around the world and have never seen this problem. But only in 
this one network are we using Radiator. The network itself does not 
seem a candidate for the problem; it is almost completely unloaded 
still and the accepts did sometimes work. BTW, I saw no failures of 
accounting requests. Maybe the NAS doesn't care about getting a reply 
for those?

What problems will we experience if I leave the DupInterval set to 
zero? Or, alternatively, are there any other suggestions for how to 
solve this problem?
-- 
Dave Close  Quik Internet
+1 949 548 2171 Costa Mesa California
[EMAIL PROTECTED] http://www.quik.com/


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