Hello Angel -
The port from which the reply is sent back is the same as the request was received on, which is specified by the AuthPort/AcctPort parameters (UDP 1645/1646 by default). regards Hugh On Wed, 3 Jul 2002 13:52, Angel Bustos wrote: > Hi Hugh, > > Very clear your point. > Just to begin a good search of this issue: do I begin searching for any > specific port for the Radiator "sent-back" accounting response? > I believe that I'll begin by disabling Redhat 7.2 default ipchains > firewalling rules and I'd know the port or ports range that Radiator uses > for sending back the accounting response, it will be helpful. > > Thanks again for your support, > > > Angel Bustos > email: [EMAIL PROTECTED] > > Hugh Irvine writes: > > Hello Angel - > > > > Let me try to explain. > > > > If Radiator is receiving the accounting requests, is processing them > > correctly, and is sending back an accounting-response - it then follows > > that there is no problem with Radiator itself. > > > > The first thing to check is the local ethernet interface on the Radiator > > host, using snoop or tcpdump or ethereal or whatever. This is to make > > sure that the accounting-response is actually getting onto the wire and > > is not being blocked by local access rules or filters. > > > > The second thing to check is the transmission path between the Radiator > > host and the remote proxy, again to make sure there are no filters or > > firewalls blocking the return path. Remember - just because you can > > receive a packet does not mean that a return packet can get back. > > > > The last thing to check is the remote proxy (or indeed NAS) to make sure > > that the accounting-response is getting back. If it is getting back, but > > the proxy (or NAS) resends another packet, then clearly the problem is > > there and requires either a bug fix or whatever. If the > > accounting-response is *not* getting back - then go back to point 2 > > above. > > > > Tracking down these sorts of problems is time-consuming and tedious, but > > such is the life of a network engineer.... > > > > regards > > > > Hugh > > > > On Fri, 28 Jun 2002 11:47, Angel Bustos wrote: > >> Hi Hugh, Dave et al, > >> > >> I'm receiving just accounting forward from a customer for further > >> processing, and I've noticed the same problem; a lot of retransmissions > >> (connectivity with our customer is really good however); > >> > >> I've followed your advice and i've set explicitly DupInterval to 2 > >> seconds in our customer's NAS Client clause, and I can see in our > >> logfile lots of INFO messages: > >> > >> Thu Jun 27 22:30:56 2002: INFO: Duplicate request id 28 received from > >> x.x.x.x(48766): ignored > >> > >> I understand from this the same thing Dave pointed: Radiator just > >> ignore and discard retransmission without further action, but the > >> retransmissions ocurred wasting BW in our case > >> > >> I saw the rfc's in Radiator /doc directory and it seems that radius > >> protocol cannot sent "rejects" backward to avoid wasting BW by lots of > >> UDP re-transmissions; > >> Radiator by itself, could have another feature to avoid this waste of > >> bandwidth or I'm missing completely the point? > >> > >> Best regards, > >> > >> Angel Bustos > >> [EMAIL PROTECTED] > >> > >> On Thu, 27 Jun 2002, Hugh Irvine wrote: > >> > Hello Dave - > >> > > >> > You normally configure the timeout and retransmit values in your > >> > NAS(s) so there will only ever be a small number of retransmissions. > >> > If your NAS sends more requests than you tell it to, it is an issue > >> > that must be addressed by your supplier. > >> > > >> > BTW - the DupInterval configured in the Client clauses defines the > >> > number of seconds in the sliding window during which a retransmission > >> > is considered a duplicate. > >> > > >> > I suggest you read the RFC's for further information (included in the > >> > Radiator distribution in the "doc" directory). > >> > > >> > regards > >> > > >> > Hugh > >> > > >> > On Thu, 27 Jun 2002 07:04, Dave Kitabjian wrote: > >> > > "Wed Jun 26 16:03:16 2002: INFO: Duplicate request id 87 > >> > > received from 10.52.0.1(1026): ignored" > >> > > > >> > > This message was logged for an Accounting request that was clearly > >> > > retransmitted since it had a large Acct-Delay-Time value. > >> > > > >> > > But if Radiator keeps ignoring the request, the NAS will keep > >> > > retransmitting, and the circle of life will go on and on and on... > >> > > > >> > > Does the RFC say to ignore dups? Wouldn't it make more sense to > >> > > Reject them somehow? Or, if the original one was already processed > >> > > successfully, it could simply send back an Accept and then discard > >> > > it as a dup? > >> > > > >> > > Dave > >> > > > >> > > === > >> > > Archive at http://www.open.com.au/archives/radiator/ > >> > > Announcements on [EMAIL PROTECTED] > >> > > To unsubscribe, email '[EMAIL PROTECTED]' with > >> > > 'unsubscribe radiator' in the body of the message. > >> > > >> > -- > >> > Radiator: the most portable, flexible and configurable RADIUS server > >> > anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. > >> > - > >> > Nets: internetwork inventory and management - graphical, extensible, > >> > flexible with hardware, software, platform and database independence. > >> > === > >> > Archive at http://www.open.com.au/archives/radiator/ > >> > Announcements on [EMAIL PROTECTED] > >> > To unsubscribe, email '[EMAIL PROTECTED]' with > >> > 'unsubscribe radiator' in the body of the message. > >> > >> === > >> Archive at http://www.open.com.au/archives/radiator/ > >> Announcements on [EMAIL PROTECTED] > >> To unsubscribe, email '[EMAIL PROTECTED]' with > >> 'unsubscribe radiator' in the body of the message. > > > > -- > > Radiator: the most portable, flexible and configurable RADIUS server > > anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. > > - > > Nets: internetwork inventory and management - graphical, extensible, > > flexible with hardware, software, platform and database independence. > > === > > Archive at http://www.open.com.au/archives/radiator/ > > Announcements on [EMAIL PROTECTED] > > To unsubscribe, email '[EMAIL PROTECTED]' with > > 'unsubscribe radiator' in the body of the message. > > ___________________________________________________________________________ >_ > > Conéctese Gratis a Internet desde http://www.brujula.net/gratis -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.