RE: IMPORTANT - RE: (RADIATOR) Duplicates Packets
Hello Mike - On Fri, 10 Mar 2000, Mike Nerone wrote: > Ah...I got ya. But wouldn't it be a small matter to remove the > Acct-Delay-Time before computing the MD5 checksums, and so detecting > retransmissions, as well, thus killing two birds with one stone? > Its the NAS that builds and sends the packet, according to the RFC - not much Radiator can do about it unfortunately. > As it stands now, these need to be detected by the billing report software, > correct? > Sadly, yes. BTW - the next IETF meeting is in Adelaide at the end of the month . regards Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: IMPORTANT - RE: (RADIATOR) Duplicates Packets
Ah...I got ya. But wouldn't it be a small matter to remove the Acct-Delay-Time before computing the MD5 checksums, and so detecting retransmissions, as well, thus killing two birds with one stone? As it stands now, these need to be detected by the billing report software, correct? Mike Nerone <mailto:[EMAIL PROTECTED]> Network Operations Manager Internet Direct, Inc. <http://www.idworld.net/> > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of Hugh Irvine > Sent: Wednesday, March 08, 2000 9:32 PM > To: Mike Nerone; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: IMPORTANT - RE: (RADIATOR) Duplicates Packets > > > > Hello Mike - > > On Thu, 09 Mar 2000, Mike Nerone wrote: > > Well, for the purpose of this issue, we have to assume that for > one reason > > or another a duplicate packet did, in fact, arrive at > Radiator's accounting > > port. That's the only way this concern even comes into play. > After all, why > > build duplicate packet detection into Radiator unless it can detect > > duplicate packets. > > > > I really suspect I'm misunderstanding something here, so please > explain it > > to me, because what I'm hearing is this scenario: > > > > In this discussion, duplicate packet means exactly that - a > packet that for > some reason or other was duplicated within the network > infrastructure. This can > sometimes happen with queues on heavily loaded links, or multiple > transmission > paths when links go up and down (or flap). > > Duplicate *does not* mean a retransmission from a NAS after a > timeout period > has elapsed (and the Acct-Delay-Time has changed), hence the difficulty. > > hth > > Hugh > > -- > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. > Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. > > > > === > Archive at http://www.starport.net/~radiator/ > To unsubscribe, email '[EMAIL PROTECTED]' with > 'unsubscribe radiator' in the body of the message. > === Archive at http://www.starport.net/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: IMPORTANT - RE: (RADIATOR) Duplicates Packets
Hello Mike - On Thu, 09 Mar 2000, Mike Nerone wrote: > Well, for the purpose of this issue, we have to assume that for one reason > or another a duplicate packet did, in fact, arrive at Radiator's accounting > port. That's the only way this concern even comes into play. After all, why > build duplicate packet detection into Radiator unless it can detect > duplicate packets. > > I really suspect I'm misunderstanding something here, so please explain it > to me, because what I'm hearing is this scenario: > In this discussion, duplicate packet means exactly that - a packet that for some reason or other was duplicated within the network infrastructure. This can sometimes happen with queues on heavily loaded links, or multiple transmission paths when links go up and down (or flap). Duplicate *does not* mean a retransmission from a NAS after a timeout period has elapsed (and the Acct-Delay-Time has changed), hence the difficulty. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: IMPORTANT - RE: (RADIATOR) Duplicates Packets
On Wed, Mar 08, 2000 at 07:03:28PM -0600, Mike Nerone wrote: > Well, for the purpose of this issue, we have to assume that for one reason > or another a duplicate packet did, in fact, arrive at Radiator's accounting > port. That's the only way this concern even comes into play. After all, why > build duplicate packet detection into Radiator unless it can detect > duplicate packets. > > I really suspect I'm misunderstanding something here, so please explain it > to me, because what I'm hearing is this scenario: > > 1. The only way Radiator sees a dup is if, for some reason, Radiator's ack > packet doesn't make it back to the NAS, thereby causing a retransmission. > 2. Any time the NAS retransmits, it's going to have a different > Acct-Delay-Time (time has, after all, passed). > 3. Any duplicate Radiator received will therefore have a different > Acct-Delay-Time. > 4. Radiator compares (a checksum of) the whole packet when checking for > duplicates. > 5. Therefore, Radiator will perforce fail to recognize the duplication of > any accounting packets. > > I know I'm going to kick myself when I hear this. :) > That's how it works. I've try to make up a system for myself which opens up the packets and stores stuff liked Account-Session-Id, username, nas, nas port, session time. It can then checks when a duplicate packet comes in to whether it matches the previously accepted stop packets - if it matches the above items it ACKs it back to the NAS but internally discards it. However, I ended up painted into a corner with some bugs my limited perl skills didn't nail and gave it up. [EMAIL PROTECTED] === Archive at http://www.starport.net/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: IMPORTANT - RE: (RADIATOR) Duplicates Packets
Well, for the purpose of this issue, we have to assume that for one reason or another a duplicate packet did, in fact, arrive at Radiator's accounting port. That's the only way this concern even comes into play. After all, why build duplicate packet detection into Radiator unless it can detect duplicate packets. I really suspect I'm misunderstanding something here, so please explain it to me, because what I'm hearing is this scenario: 1. The only way Radiator sees a dup is if, for some reason, Radiator's ack packet doesn't make it back to the NAS, thereby causing a retransmission. 2. Any time the NAS retransmits, it's going to have a different Acct-Delay-Time (time has, after all, passed). 3. Any duplicate Radiator received will therefore have a different Acct-Delay-Time. 4. Radiator compares (a checksum of) the whole packet when checking for duplicates. 5. Therefore, Radiator will perforce fail to recognize the duplication of any accounting packets. I know I'm going to kick myself when I hear this. :) Mike Nerone <mailto:[EMAIL PROTECTED]> Network Operations Manager Internet Direct, Inc. <http://www.idworld.net/> > -Original Message- > From: Hugh Irvine [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 08, 2000 3:08 PM > To: Mike Nerone; [EMAIL PROTECTED] > Subject: IMPORTANT - RE: (RADIATOR) Duplicates Packets > > Perhaps a brief description of the Radius protocol is in order > here as I have > seen a number of questions about Acct-Delay-Time recently. > > The problem you are seeing occurs because Radius uses the UDP transport > protocol for all its packet forwarding. If the NAS sends a Radius > accounting > packet when a session terminates (accounting Stop), it sets the > Acct-Delay-Time > to zero (0) - ie. the event happened now. If the NAS does not > receive a reply > from the Radius server, either because the packet was lost in transit, or > because there was a packet collision on an ethernet, or whatever, > the NAS will > timeout on the first transmission (according to the > retransmission timer and > the retry count) and send another accounting packet. However, > time has moved on > since the first transmission, so by definition the > Acct-Delay-Time has changed > - ie. the event occurred some number of seconds ago. Therefore, > the contents of > the packet have changed, therefore Radiator thinks it is seeing a > new packet. > > Note that the above is only a problem if Radiator has already > seen the first > packet, but the reply either did not arrive at the NAS, or the > reply arrived > too late, ie. after the retransmission timer on the NAS had expired. > > What all of the above indicates is that you need to be very > careful in your > network design and in your choice of retransmission timers and backend > processing to make sure that it is not your design that is > causing the problem. === Archive at http://www.starport.net/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
IMPORTANT - RE: (RADIATOR) Duplicates Packets
Hello Mike - On Thu, 09 Mar 2000, Mike Nerone wrote: > I am in the process of implementing Radiator at the moment (converting from > hacked Livingston radiusd), and I wanted to make sure this isn't a problem. > It seems unlikely that this has not already been addressed, but here goes > anyway: > > I have looked at my detail logs, and I see varying Acct-Delay-Time fields in > duplicate packets for all of these types of NAS's: > > Lucent (Livingston) Portmaster 2 > Lucent (Livingston) Portmaster 3 > Total Control > Ascend Max 4000 > > Happily, I don't see any for our Nortel CVX 1800, but it's conceivable that > there just haven't BEEN any duplicates (some of the counts for the other > NAS's were quite low, as well). > Perhaps a brief description of the Radius protocol is in order here as I have seen a number of questions about Acct-Delay-Time recently. The problem you are seeing occurs because Radius uses the UDP transport protocol for all its packet forwarding. If the NAS sends a Radius accounting packet when a session terminates (accounting Stop), it sets the Acct-Delay-Time to zero (0) - ie. the event happened now. If the NAS does not receive a reply from the Radius server, either because the packet was lost in transit, or because there was a packet collision on an ethernet, or whatever, the NAS will timeout on the first transmission (according to the retransmission timer and the retry count) and send another accounting packet. However, time has moved on since the first transmission, so by definition the Acct-Delay-Time has changed - ie. the event occurred some number of seconds ago. Therefore, the contents of the packet have changed, therefore Radiator thinks it is seeing a new packet. Note that the above is only a problem if Radiator has already seen the first packet, but the reply either did not arrive at the NAS, or the reply arrived too late, ie. after the retransmission timer on the NAS had expired. What all of the above indicates is that you need to be very careful in your network design and in your choice of retransmission timers and backend processing to make sure that it is not your design that is causing the problem. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.starport.net/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Duplicates Packets
I am in the process of implementing Radiator at the moment (converting from hacked Livingston radiusd), and I wanted to make sure this isn't a problem. It seems unlikely that this has not already been addressed, but here goes anyway: I have looked at my detail logs, and I see varying Acct-Delay-Time fields in duplicate packets for all of these types of NAS's: Lucent (Livingston) Portmaster 2 Lucent (Livingston) Portmaster 3 Total Control Ascend Max 4000 Happily, I don't see any for our Nortel CVX 1800, but it's conceivable that there just haven't BEEN any duplicates (some of the counts for the other NAS's were quite low, as well). Mike Nerone <mailto:[EMAIL PROTECTED]> Network Operations Manager Internet Direct, Inc. <http://www.idworld.net/> > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On > Behalf Of tmercado > Sent: Wednesday, March 08, 2000 3:03 AM > To: tom minchin > Cc: [EMAIL PROTECTED] > Subject: Re: (RADIATOR) Duplicates Packets > > Hello Tom, > > I was checking the TRACE 4 log and I found that the packets are not > identical. I have the same field like CISCO, the Acct-Delay-Time that > is different for the duplicate packet and also the timestamp field. > > Ok here is the problem, so how can I change radiator to check only the > NAS-IP-Address and the Acct-Session-Id for duplicates? > I will check the MAX TNT documentation to see if there are a way to avoid > send the Acct-Delay-Time field in the packet. > > How did you solve the problem with CISCO? > > At the end I send a copy of the original packet and the duplicate. > > Best regards. > > Teddy === Archive at http://www.starport.net/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Duplicates Packets
Hello Tom, I was checking the TRACE 4 log and I found that the packets are not identical. I have the same field like CISCO, the Acct-Delay-Time that is different for the duplicate packet and also the timestamp field. Ok here is the problem, so how can I change radiator to check only the NAS-IP-Address and the Acct-Session-Id for duplicates? I will check the MAX TNT documentation to see if there are a way to avoid send the Acct-Delay-Time field in the packet. How did you solve the problem with CISCO? At the end I send a copy of the original packet and the duplicate. Best regards. Teddy On 08-03-2000 12:51 PM tom minchin <[EMAIL PROTECTED]> wrote: > > It compares the whole packet (well the MD5 checksum from memory). > > *hops on hobby horse* > > This means if your duplicate packets aren't identical then Radiator can't > detect and ignore duplicates (eg Cisco has Acct-Delay-Time which changes > in value for each retransmitted packet). > > Check your Trace 4 log and compare the Stop records and see what the difference > is. > > *heads to sunset* > > [EMAIL PROTECTED] > Sat Feb 26 00:29:13 2000 User-Name = "" NAS-IP-Address = xx.xx.xx.xx NAS-Port = 107 NAS-Port-Type = Async Acct-Status-Type = Stop Acct-Delay-Time = 21 Acct-Session-Id = "305110595" Acct-Authentic = RADIUS Acct-Session-Time = 3294 Acct-Input-Octets = 482876 Acct-Output-Octets = 328545 Acct-Input-Packets = 9985 Acct-Output-Packets = 2410 Ascend-Disconnect-Cause = remoteEndHungup Ascend-Connect-Progress = prLanSessionUp Ascend-Xmit-Rate = 33600 Ascend-Data-Rate = 33600 Ascend-PreSession-Time = 15 Ascend-Pre-Input-Octets = 353 Ascend-Pre-Output-Octets = 336 Ascend-Pre-Input-Packets = 12 Ascend-Pre-Output-Packets = 12 Ascend-First-Dest = 255.255.255.255 Ascend-Multilink-ID = 1100 Ascend-Num-In-Multilink = 0 Acct-Link-Count = "<0><0><0><1>" Acct-Multi-Session-Id = "044c" Ascend-Modem-PortNo = 9 Ascend-Modem-SlotNo = 5 Ascend-Modem-ShelfNo = 1 Calling-Station-Id = "3460796" Called-Station-Id = "321900" Framed-Protocol = 262 Framed-IP-Address = xx.xx.xxx.xx Timestamp = 951510532 Sat Feb 26 00:29:16 2000 User-Name = "" NAS-IP-Address = xx.xx.xx.xx NAS-Port = 107 NAS-Port-Type = Async Acct-Status-Type = Stop Acct-Delay-Time = 28 Acct-Session-Id = "305110595" Acct-Authentic = RADIUS Acct-Session-Time = 3294 Acct-Input-Octets = 482876 Acct-Output-Octets = 328545 Acct-Input-Packets = 9985 Acct-Output-Packets = 2410 Ascend-Disconnect-Cause = remoteEndHungup Ascend-Connect-Progress = prLanSessionUp Ascend-Xmit-Rate = 33600 Ascend-Data-Rate = 33600 Ascend-PreSession-Time = 15 Ascend-Pre-Input-Octets = 353 Ascend-Pre-Output-Octets = 336 Ascend-Pre-Input-Packets = 12 Ascend-Pre-Output-Packets = 12 Ascend-First-Dest = 255.255.255.255 Ascend-Multilink-ID = 1100 Ascend-Num-In-Multilink = 0 Acct-Link-Count = "<0><0><0><1>" Acct-Multi-Session-Id = "044c" Ascend-Modem-PortNo = 9 Ascend-Modem-SlotNo = 5 Ascend-Modem-ShelfNo = 1 Calling-Station-Id = "3460796" Called-Station-Id = "321900" Framed-Protocol = 262 Framed-IP-Address = xx.xx.xxx.xx Timestamp = 951510528 -- Teddy Victor, Mercado Rodrigo Div. Comunicaciones PROCOM S.R.L. e-mail: [EMAIL PROTECTED] Santa Cruz Bolivia === Archive at http://www.starport.net/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Duplicates Packets
On Wed, Mar 08, 2000 at 04:38:51AM +, tmercado wrote: > Hello Hugh, > > Ok, I'm running Radiator with a Trace 4. We have to wait to see what happend, > anyway, I think that the delay is not the problem, because the DupInterval is > seted to 60 seconds, so if the MAX TNT send a duplicate after a timeout > occurs (i.e. 7 seconds), radiator must ignore it. > > The question now is, why is not happening that? > So, to check for duplicates packets, Radiator compares all data in the packet? > or the acct-session-id and NAS-IP-address fields only? > > The database is ok, I was testing it with radpwtst and I can do between 120 to > 130 request trougth radiator in a second (i.e. authenticate a user and save start > and stop packets for that user), so is very fast. At this time, the rate for > the real system is between 3 to 5 request in a second. > It compares the whole packet (well the MD5 checksum from memory). *hops on hobby horse* This means if your duplicate packets aren't identical then Radiator can't detect and ignore duplicates (eg Cisco has Acct-Delay-Time which changes in value for each retransmitted packet). Check your Trace 4 log and compare the Stop records and see what the difference is. *heads to sunset* [EMAIL PROTECTED] === Archive at http://www.starport.net/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Duplicates Packets
Hello Hugh, Ok, I'm running Radiator with a Trace 4. We have to wait to see what happend, anyway, I think that the delay is not the problem, because the DupInterval is seted to 60 seconds, so if the MAX TNT send a duplicate after a timeout occurs (i.e. 7 seconds), radiator must ignore it. The question now is, why is not happening that? So, to check for duplicates packets, Radiator compares all data in the packet? or the acct-session-id and NAS-IP-address fields only? The database is ok, I was testing it with radpwtst and I can do between 120 to 130 request trougth radiator in a second (i.e. authenticate a user and save start and stop packets for that user), so is very fast. At this time, the rate for the real system is between 3 to 5 request in a second. I will send you the logfile. Best regards Teddy Mercado On 03-03-2000 11:02 PM Hugh Irvine <[EMAIL PROTECTED]> wrote: > > The best thing to do now is run Radiator with a Trace 4 so you can see in the > debug output where the delays are occuring. Every entry is timestamped and you > will see at what time the request packet arrives, what happens to the packet, > what interactions occur with the database, etc. You should be able to see from > the timestamps at what stage in the request processing the delays are happening > and from there discover the source of the problem. > > You can also send me a copy of the trace output and I will have a look also. > > 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, MacOS X > > > > === > Archive at http://www.thesite.com.au/~radiator/ > To unsubscribe, email '[EMAIL PROTECTED]' with > 'unsubscribe radiator' in the body of the message. > -- Teddy Victor, Mercado Rodrigo Div. Comunicaciones PROCOM S.R.L. e-mail: [EMAIL PROTECTED] Santa Cruz Bolivia === Archive at http://www.starport.net/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Duplicates Packets
Hello Teddy - On Sat, 04 Mar 2000, Teddy Victor, Mercado Rodrigo wrote: > > I don't answer, because all this time I was testing the new configuration > (i.e with DupInterval seted to 60 seconds) but the problem persist. I have > two Ascend MAX TNT with a total of 10 E1 links (300 dial-up channels) and > the average of users always conected to internet is between 200 and 250. > > In the Max TNT I had seted the accounting timeout in the External-Auth > profile to 7 seconds, so if the Max don't get an answer within this time, > it will send a second packet. > > I'm using the ODBC option to retrieve and save all information over > Informix including the RADONLINE table for simultaneous use check. > I seted the timeout in the MAX TNT to 7 seconds and all duplicates packets > have the acct-delay-time = 7, and the timestamp of the packet is 7 seconds > plus the original packet. > > I was looking for external causes for the problem (delay in the database, > etc), but all looks fine. > > Any sugestion? > The best thing to do now is run Radiator with a Trace 4 so you can see in the debug output where the delays are occuring. Every entry is timestamped and you will see at what time the request packet arrives, what happens to the packet, what interactions occur with the database, etc. You should be able to see from the timestamps at what stage in the request processing the delays are happening and from there discover the source of the problem. You can also send me a copy of the trace output and I will have a look also. 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, MacOS X === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Duplicates Packets
Hello Hugh, I don't answer, because all this time I was testing the new configuration (i.e with DupInterval seted to 60 seconds) but the problem persist. I have two Ascend MAX TNT with a total of 10 E1 links (300 dial-up channels) and the average of users always conected to internet is between 200 and 250. In the Max TNT I had seted the accounting timeout in the External-Auth profile to 7 seconds, so if the Max don't get an answer within this time, it will send a second packet. I'm using the ODBC option to retrieve and save all information over Informix including the RADONLINE table for simultaneous use check. I seted the timeout in the MAX TNT to 7 seconds and all duplicates packets have the acct-delay-time = 7, and the timestamp of the packet is 7 seconds plus the original packet. I was looking for external causes for the problem (delay in the database, etc), but all looks fine. Any sugestion? Best regards. Teddy Mercado At 10:27 a.m. 11/02/00 +1100, you wrote: >Hello Teddy - > >On Fri, 11 Feb 2000, Teddy Victor, Mercado Rodrigo wrote: > > Hello, > > > > I'm new in the business of RADIUS. At this time I'm using RADIATOR to > > authenticate users and everything is Ok, except for one thing. I have > > duplicates stop packets in my accounting file with the same > Acct-Session-Id > > and I don't know why. > > > > I suppouse the problem is the return packet from the radiator to RAS is > > been lost on the way, so the RAS re-send the packet because it didn't > > receive the ACK package. I check the LAN with a protocol analyzer and > > everything looks well. > > > > Someone knows how to avoid this problem? or some way to do radiator keep a > > track of the stop packets, so it will never save the same packet twice? > > > >What have you set the DupInterval to in your Client clause? The default is 2 >seconds (you should only use 0 for your localhost). > >Have a look at section 6.4 in the Radiator 2.14.1 reference manual. > >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 Teddy Victor, Mercado Rodrigo Div. Comunicaciones PROCOM - BOLIVIA email: [EMAIL PROTECTED] [EMAIL PROTECTED] Tel. ++591 3 360802 / 322366 Fax. ++591 3 360802 === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Duplicates Packets
Hello Teddy - On Fri, 11 Feb 2000, Teddy Victor, Mercado Rodrigo wrote: > Hello, > > I'm new in the business of RADIUS. At this time I'm using RADIATOR to > authenticate users and everything is Ok, except for one thing. I have > duplicates stop packets in my accounting file with the same Acct-Session-Id > and I don't know why. > > I suppouse the problem is the return packet from the radiator to RAS is > been lost on the way, so the RAS re-send the packet because it didn't > receive the ACK package. I check the LAN with a protocol analyzer and > everything looks well. > > Someone knows how to avoid this problem? or some way to do radiator keep a > track of the stop packets, so it will never save the same packet twice? > What have you set the DupInterval to in your Client clause? The default is 2 seconds (you should only use 0 for your localhost). Have a look at section 6.4 in the Radiator 2.14.1 reference manual. 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.
