RE: (RADIATOR) Hacking around an upstream issue.
Sounds like a broken NAS, sending alive packets for a terminated session... /Ingvar The NAS's appear to be sending an Alive packet for a Session after we have received the Stop packet for the _same_ Session. This is due to the first attempt to send the Alive packet failing, the NAS waits 10 seconds for a retry. During this ten seconds, the user disconnects, the NAS sends a stop record. The NAS then sends off the second attempt for the Alive packet. Consequently, the session is 'reopened' in my SessionTable, as the Alive packet triggers a delete/insert .. for all intensive purposes I see a dead session, which was actually already closed off. Thanks Martin -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 04, 2002 9:50 AM To: Martin Edge Cc: Radiator Subject: Re: (RADIATOR) Hacking around an upstream issue. Hello Martin - What exactly is the problem? If you just want special processing for Alives, do something like this: Handler Acct-Status-Type = Alive /Handler regards Hugh On Wednesday, September 4, 2002, at 09:23 AM, Martin Edge wrote: Hey Guys, Want to see if anyone has any ideas of how I should deal with this situation. We are currently getting the following for the 'occasional' user session from our Upstream RADIUS.. Order Amount Type - 1 1 Start 2 ManyAlive's (every 15 min) 3 1 Stop (0 sec, Acct-Delay-Time) 4 1 Alive (9 seconds afterwards, Acct-Delay-Time=10) We are told that what is happening, is the first attempt is made to send the first Alive packet. By coincendence, the user disconnects between these retries, and the Stop packet is fired off. The Retry Alive packet is sent after the Stop packet for that session has arrived. Until they can come up with a network-fix for the problem (to prevent Additional Packets for the Same Session to be sent before completely failing the current packet (until $x times tried), I'm going to have to develop a hack around to work out on what basis to ignore these extra Alives. I was thinking I have two options 1:- Make Radiator see whether the SessionID is still active for an Alive packet (could be costly on DB work each instance) 2:- Make Radiator store recent sessionIDs it has closed off in a DB or DBM file, and check incoming Alive packet -isn't- in the recently expired list. Which would be the best? Where should I start? :) Thanks, Martin === 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.
RE: (RADIATOR) Hacking around an upstream issue.
Kinda, it's a load issue. The policy from our upstream RADIUS is to pound the primary until it fails, and then failover. They have no RR or Load Balance functionality. We get enough load on that one server that you'd expect it to timeout occasionally.. I may just whack another proxy inbetween my supplier and myself and do RR or LB there.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ingvar Berg (EAB) Sent: Wednesday, September 04, 2002 10:09 PM To: Radiator Subject: RE: (RADIATOR) Hacking around an upstream issue. Sounds like a broken NAS, sending alive packets for a terminated session... /Ingvar The NAS's appear to be sending an Alive packet for a Session after we have received the Stop packet for the _same_ Session. This is due to the first attempt to send the Alive packet failing, the NAS waits 10 seconds for a retry. During this ten seconds, the user disconnects, the NAS sends a stop record. The NAS then sends off the second attempt for the Alive packet. Consequently, the session is 'reopened' in my SessionTable, as the Alive packet triggers a delete/insert .. for all intensive purposes I see a dead session, which was actually already closed off. Thanks Martin -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 04, 2002 9:50 AM To: Martin Edge Cc: Radiator Subject: Re: (RADIATOR) Hacking around an upstream issue. Hello Martin - What exactly is the problem? If you just want special processing for Alives, do something like this: Handler Acct-Status-Type = Alive /Handler regards Hugh On Wednesday, September 4, 2002, at 09:23 AM, Martin Edge wrote: Hey Guys, Want to see if anyone has any ideas of how I should deal with this situation. We are currently getting the following for the 'occasional' user session from our Upstream RADIUS.. Order Amount Type - 1 1 Start 2 ManyAlive's (every 15 min) 3 1 Stop (0 sec, Acct-Delay-Time) 4 1 Alive (9 seconds afterwards, Acct-Delay-Time=10) We are told that what is happening, is the first attempt is made to send the first Alive packet. By coincendence, the user disconnects between these retries, and the Stop packet is fired off. The Retry Alive packet is sent after the Stop packet for that session has arrived. Until they can come up with a network-fix for the problem (to prevent Additional Packets for the Same Session to be sent before completely failing the current packet (until $x times tried), I'm going to have to develop a hack around to work out on what basis to ignore these extra Alives. I was thinking I have two options 1:- Make Radiator see whether the SessionID is still active for an Alive packet (could be costly on DB work each instance) 2:- Make Radiator store recent sessionIDs it has closed off in a DB or DBM file, and check incoming Alive packet -isn't- in the recently expired list. Which would be the best? Where should I start? :) Thanks, Martin === 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. === 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.
Re: (RADIATOR) Hacking around an upstream issue.
Martin, perhaps it's possible to set up a handler to deal with packets with Acct-Delay-Time 0 and do the special handling just for those. Just an idea, I didn't give it a second thought, but at first it seems possible to me, doesn't it? regards cl. From: Hugh Irvine [EMAIL PROTECTED] To: Martin Edge [EMAIL PROTECTED] CC: Radiator [EMAIL PROTECTED] Subject: Re: (RADIATOR) Hacking around an upstream issue. Date: Wed, 4 Sep 2002 11:24:24 +1000 Hello Martin - Its a bit hard to see how Radiator could deal with this situation in any sensible fashion. I think I would still be inclined to use a seperate Handler for Alives and use a special AddQuery to check the existence of a session before trying to update it - although this will still be a problem if you have missed a Start record. I would also check how and why you are missing accounting records in the first place and fix whatever problem is causing this to happen (saturated links?). Keep in mind that the sanity of the session database depends directly on the sanity of the accounting records that are used to maintain it. Clearly what you describe is not sane. regards Hugh On Wednesday, September 4, 2002, at 10:18 AM, Martin Edge wrote: Hi Hugh, The normal processing of Alives is fine. The fact we get Alives ensures I can check the sanity of the SessionTable. Each time an Alive record comes in, it updates the SessionTable for each user's session The NAS's appear to be sending an Alive packet for a Session after we have received the Stop packet for the _same_ Session. This is due to the first attempt to send the Alive packet failing, the NAS waits 10 seconds for a retry. During this ten seconds, the user disconnects, the NAS sends a stop record. The NAS then sends off the second attempt for the Alive packet. Consequently, the session is 'reopened' in my SessionTable, as the Alive packet triggers a delete/insert .. for all intensive purposes I see a dead session, which was actually already closed off. Thanks Martin -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 04, 2002 9:50 AM To: Martin Edge Cc: Radiator Subject: Re: (RADIATOR) Hacking around an upstream issue. Hello Martin - What exactly is the problem? If you just want special processing for Alives, do something like this: Handler Acct-Status-Type = Alive /Handler regards Hugh On Wednesday, September 4, 2002, at 09:23 AM, Martin Edge wrote: Hey Guys, Want to see if anyone has any ideas of how I should deal with this situation. We are currently getting the following for the 'occasional' user session from our Upstream RADIUS.. OrderAmount Type - 11 Start 2ManyAlive's (every 15 min) 31 Stop (0 sec, Acct-Delay-Time) 41 Alive (9 seconds afterwards, Acct-Delay-Time=10) We are told that what is happening, is the first attempt is made to send the first Alive packet. By coincendence, the user disconnects between these retries, and the Stop packet is fired off. The Retry Alive packet is sent after the Stop packet for that session has arrived. Until they can come up with a network-fix for the problem (to prevent Additional Packets for the Same Session to be sent before completely failing the current packet (until $x times tried), I'm going to have to develop a hack around to work out on what basis to ignore these extra Alives. I was thinking I have two options 1:- Make Radiator see whether the SessionID is still active for an Alive packet (could be costly on DB work each instance) 2:- Make Radiator store recent sessionIDs it has closed off in a DB or DBM file, and check incoming Alive packet -isn't- in the recently expired list. Which would be the best? Where should I start? :) Thanks, Martin === 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. -- 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. _ Send and receive Hotmail on your mobile device: http://mobile.msn.com === Archive
Re: (RADIATOR) Hacking around an upstream issue.
Hello Martin - What exactly is the problem? If you just want special processing for Alives, do something like this: Handler Acct-Status-Type = Alive /Handler regards Hugh On Wednesday, September 4, 2002, at 09:23 AM, Martin Edge wrote: Hey Guys, Want to see if anyone has any ideas of how I should deal with this situation. We are currently getting the following for the 'occasional' user session from our Upstream RADIUS.. Order Amount Type - 1 1 Start 2 ManyAlive's (every 15 min) 3 1 Stop (0 sec, Acct-Delay-Time) 4 1 Alive (9 seconds afterwards, Acct-Delay-Time=10) We are told that what is happening, is the first attempt is made to send the first Alive packet. By coincendence, the user disconnects between these retries, and the Stop packet is fired off. The Retry Alive packet is sent after the Stop packet for that session has arrived. Until they can come up with a network-fix for the problem (to prevent Additional Packets for the Same Session to be sent before completely failing the current packet (until $x times tried), I'm going to have to develop a hack around to work out on what basis to ignore these extra Alives. I was thinking I have two options 1:- Make Radiator see whether the SessionID is still active for an Alive packet (could be costly on DB work each instance) 2:- Make Radiator store recent sessionIDs it has closed off in a DB or DBM file, and check incoming Alive packet -isn't- in the recently expired list. Which would be the best? Where should I start? :) Thanks, Martin === 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.
RE: (RADIATOR) Hacking around an upstream issue.
Hi Hugh, The normal processing of Alives is fine. The fact we get Alives ensures I can check the sanity of the SessionTable. Each time an Alive record comes in, it updates the SessionTable for each user's session The NAS's appear to be sending an Alive packet for a Session after we have received the Stop packet for the _same_ Session. This is due to the first attempt to send the Alive packet failing, the NAS waits 10 seconds for a retry. During this ten seconds, the user disconnects, the NAS sends a stop record. The NAS then sends off the second attempt for the Alive packet. Consequently, the session is 'reopened' in my SessionTable, as the Alive packet triggers a delete/insert .. for all intensive purposes I see a dead session, which was actually already closed off. Thanks Martin -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 04, 2002 9:50 AM To: Martin Edge Cc: Radiator Subject: Re: (RADIATOR) Hacking around an upstream issue. Hello Martin - What exactly is the problem? If you just want special processing for Alives, do something like this: Handler Acct-Status-Type = Alive /Handler regards Hugh On Wednesday, September 4, 2002, at 09:23 AM, Martin Edge wrote: Hey Guys, Want to see if anyone has any ideas of how I should deal with this situation. We are currently getting the following for the 'occasional' user session from our Upstream RADIUS.. Order Amount Type - 1 1 Start 2 ManyAlive's (every 15 min) 3 1 Stop (0 sec, Acct-Delay-Time) 4 1 Alive (9 seconds afterwards, Acct-Delay-Time=10) We are told that what is happening, is the first attempt is made to send the first Alive packet. By coincendence, the user disconnects between these retries, and the Stop packet is fired off. The Retry Alive packet is sent after the Stop packet for that session has arrived. Until they can come up with a network-fix for the problem (to prevent Additional Packets for the Same Session to be sent before completely failing the current packet (until $x times tried), I'm going to have to develop a hack around to work out on what basis to ignore these extra Alives. I was thinking I have two options 1:- Make Radiator see whether the SessionID is still active for an Alive packet (could be costly on DB work each instance) 2:- Make Radiator store recent sessionIDs it has closed off in a DB or DBM file, and check incoming Alive packet -isn't- in the recently expired list. Which would be the best? Where should I start? :) Thanks, Martin === 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.
Re: (RADIATOR) Hacking around an upstream issue.
Hello Martin - Its a bit hard to see how Radiator could deal with this situation in any sensible fashion. I think I would still be inclined to use a seperate Handler for Alives and use a special AddQuery to check the existence of a session before trying to update it - although this will still be a problem if you have missed a Start record. I would also check how and why you are missing accounting records in the first place and fix whatever problem is causing this to happen (saturated links?). Keep in mind that the sanity of the session database depends directly on the sanity of the accounting records that are used to maintain it. Clearly what you describe is not sane. regards Hugh On Wednesday, September 4, 2002, at 10:18 AM, Martin Edge wrote: Hi Hugh, The normal processing of Alives is fine. The fact we get Alives ensures I can check the sanity of the SessionTable. Each time an Alive record comes in, it updates the SessionTable for each user's session The NAS's appear to be sending an Alive packet for a Session after we have received the Stop packet for the _same_ Session. This is due to the first attempt to send the Alive packet failing, the NAS waits 10 seconds for a retry. During this ten seconds, the user disconnects, the NAS sends a stop record. The NAS then sends off the second attempt for the Alive packet. Consequently, the session is 'reopened' in my SessionTable, as the Alive packet triggers a delete/insert .. for all intensive purposes I see a dead session, which was actually already closed off. Thanks Martin -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 04, 2002 9:50 AM To: Martin Edge Cc: Radiator Subject: Re: (RADIATOR) Hacking around an upstream issue. Hello Martin - What exactly is the problem? If you just want special processing for Alives, do something like this: Handler Acct-Status-Type = Alive /Handler regards Hugh On Wednesday, September 4, 2002, at 09:23 AM, Martin Edge wrote: Hey Guys, Want to see if anyone has any ideas of how I should deal with this situation. We are currently getting the following for the 'occasional' user session from our Upstream RADIUS.. OrderAmount Type - 11 Start 2ManyAlive's (every 15 min) 31 Stop (0 sec, Acct-Delay-Time) 41 Alive (9 seconds afterwards, Acct-Delay-Time=10) We are told that what is happening, is the first attempt is made to send the first Alive packet. By coincendence, the user disconnects between these retries, and the Stop packet is fired off. The Retry Alive packet is sent after the Stop packet for that session has arrived. Until they can come up with a network-fix for the problem (to prevent Additional Packets for the Same Session to be sent before completely failing the current packet (until $x times tried), I'm going to have to develop a hack around to work out on what basis to ignore these extra Alives. I was thinking I have two options 1:- Make Radiator see whether the SessionID is still active for an Alive packet (could be costly on DB work each instance) 2:- Make Radiator store recent sessionIDs it has closed off in a DB or DBM file, and check incoming Alive packet -isn't- in the recently expired list. Which would be the best? Where should I start? :) Thanks, Martin === 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. -- 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.
