Re: (RADIATOR) Framed-IP of 0.0.0.0
Hello William -
Note that what you show below is an accounting request that does not have a
Framed-IP-Address in it at all.
Also note that your proposed PostAuthHook below would serve no purpose with
accounting requests.
regards
Hugh
On Thursday 13 September 2001 23:58, William Hernandez wrote:
Thanks everyone.
Given that we don't use FramedGroupBaseAddress in our Client
clauses, and given that the problem has been reported with
Radiator out of the picture, I'll conclude that this is a NAS
issue.
However, before I close this issue does it make sense to write a
PostAuthHook that would check FRAMEDIPADDRESS and if matches
0.0.0.0 change the Accept to a Reject and basically force the
user to reconnect and expect (hope) the NAS will generate a
correct IP the second time around.
Below is a trace 4. It seems that the 0.0.0.0 address occurs when
Framed-Protocol=MP or Framed-Protocol=MPP. But I'll have to check
more cases to say for sure.
Thanks in advance,
William
Mon Aug 27 14:22:24 2001: DEBUG: Packet dump:
*** Received from 208.249.78.9 port 1028
Code: Accounting-Request
Identifier: 18
Authentic:
(196208254x23924323522#196x16613818215
Attributes:
User-Name = horizonmm.com
NAS-IP-Address = 208.249.78.9
NAS-Port = 10207
Ascend-NAS-Port-Format = 3
NAS-Port-Type = Sync
Acct-Status-Type = Start
Acct-Delay-Time = 0
Acct-Session-Id = 364406391
Acct-Authentic = RADIUS
Ascend-Multilink-ID = 1309213583
Ascend-Num-In-Multilink = 2
Acct-Link-Count =
Acct-Multi-Session-Id = 4e09038f
Ascend-Modem-PortNo = 31
Ascend-Modem-SlotNo = 9
Calling-Station-Id = 7879778517
Called-Station-Id = 6419200
Framed-Protocol = MP
Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler
Realm=surfea.net should be use
d to handle this request
Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler
Realm=prwebtv.net should be us
ed to handle this request
Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler
Realm=holaplaneta.net should b
e used to handle this request
Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler
Realm=prdigital.com should be
used to handle this request
Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler
Called-Station-Id=/5050$/ shou
ld be used to handle this request
Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler should be used
to handle this
request
Mon Aug 27 14:22:24 2001: DEBUG: Handling request with Handler ''
Mon Aug 27 14:22:24 2001: DEBUG: prw-sessiondb Adding session for
horizonmm.com,
208.249.78.9, 10207
Mon Aug 27 14:22:24 2001: DEBUG: do query is: delete from
RADONLINE where NASIDE
NTIFIER='208.249.78.9' and NASPORT=010207
Mon Aug 27 14:22:24 2001: DEBUG: do query is: insert into
RADONLINE (USERNAME, N
ASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP,
FRAMEDIPADDRESS, NASPORTTYPE,
SERVICETYPE) values ('horizonmm.com', '208.249.78.9', 010207,
'364406391', 99893
6544, '0.0.0.0', 'Sync', '')
Mon Aug 27 14:22:24 2001: DEBUG: Handling with Radius::AuthFILE
Mon Aug 27 14:22:24 2001: DEBUG: Processing
PostAuthHook:setSessionTimeout
Mon Aug 27 14:22:24 2001: DEBUG: setSessionTimeout: username is:
horizonmm.com
Mon Aug 27 14:22:24 2001: DEBUG: setSessionTimeout:
Called-Station-Id is: 641920
0
Mon Aug 27 14:22:24 2001: DEBUG: Query is: select
USERNAME,TIMEBLOCK,CLASS,DISAB
LETIME,DISABLECLASS from XSTOP where USERNAME='horizonmm.com'
Mon Aug 27 14:22:24 2001: DEBUG: Accounting accepted
Mon Aug 27 14:22:24 2001: DEBUG: Packet dump:
*** Sending to 208.249.78.9 port 1028
Code: Accounting-Response
Identifier: 18
Authentic:
(196208254x23924323522#196x16613818215
Attributes:
-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 12, 2001 7:35 PM
To: William Hernandez; Radiator
Subject: Re: (RADIATOR) Framed-IP of 0.0.0.0
Hello William -
The only way to understand what is happening is to look at a
trace 4 debug
from Radiator to see in what circumstances this occurs. As it is
the NAS that
sends the accounting packets that are used to maintain the
session database,
it is highly likely that this is a NAS issue.
Note that we have seen similar behaviour occassionally when it is
Radiator
allocating the addresses, and one work-around is to send a copy
of the
address in a Class attribute and use a PreClientHook to restore
it.
Obviously if it is the NAS that is allocating the addresses, you
will need to
check with the NAS vendor if there is a fix for the problem.
regards
Hugh
On Thursday 13 September 2001 00:16, William Hernandez wrote:
Hello everyone,
We're using 2.18.2. Recently we started to see FRAMEDIPADDRESS
of
0.0.0.0 in RADONLINE. These records create a problem when
checking for Simultaneous-Use. Is this a problem with the
Ascend
NASes that we use?
Thanks in advance
RE: (RADIATOR) Framed-IP of 0.0.0.0
Thanks everyone.
Given that we don't use FramedGroupBaseAddress in our Client
clauses, and given that the problem has been reported with
Radiator out of the picture, I'll conclude that this is a NAS
issue.
However, before I close this issue does it make sense to write a
PostAuthHook that would check FRAMEDIPADDRESS and if matches
0.0.0.0 change the Accept to a Reject and basically force the
user to reconnect and expect (hope) the NAS will generate a
correct IP the second time around.
Below is a trace 4. It seems that the 0.0.0.0 address occurs when
Framed-Protocol=MP or Framed-Protocol=MPP. But I'll have to check
more cases to say for sure.
Thanks in advance,
William
Mon Aug 27 14:22:24 2001: DEBUG: Packet dump:
*** Received from 208.249.78.9 port 1028
Code: Accounting-Request
Identifier: 18
Authentic:
(196208254x23924323522#196x16613818215
Attributes:
User-Name = horizonmm.com
NAS-IP-Address = 208.249.78.9
NAS-Port = 10207
Ascend-NAS-Port-Format = 3
NAS-Port-Type = Sync
Acct-Status-Type = Start
Acct-Delay-Time = 0
Acct-Session-Id = 364406391
Acct-Authentic = RADIUS
Ascend-Multilink-ID = 1309213583
Ascend-Num-In-Multilink = 2
Acct-Link-Count =
Acct-Multi-Session-Id = 4e09038f
Ascend-Modem-PortNo = 31
Ascend-Modem-SlotNo = 9
Calling-Station-Id = 7879778517
Called-Station-Id = 6419200
Framed-Protocol = MP
Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler
Realm=surfea.net should be use
d to handle this request
Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler
Realm=prwebtv.net should be us
ed to handle this request
Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler
Realm=holaplaneta.net should b
e used to handle this request
Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler
Realm=prdigital.com should be
used to handle this request
Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler
Called-Station-Id=/5050$/ shou
ld be used to handle this request
Mon Aug 27 14:22:24 2001: DEBUG: Check if Handler should be used
to handle this
request
Mon Aug 27 14:22:24 2001: DEBUG: Handling request with Handler ''
Mon Aug 27 14:22:24 2001: DEBUG: prw-sessiondb Adding session for
horizonmm.com,
208.249.78.9, 10207
Mon Aug 27 14:22:24 2001: DEBUG: do query is: delete from
RADONLINE where NASIDE
NTIFIER='208.249.78.9' and NASPORT=010207
Mon Aug 27 14:22:24 2001: DEBUG: do query is: insert into
RADONLINE (USERNAME, N
ASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP,
FRAMEDIPADDRESS, NASPORTTYPE,
SERVICETYPE) values ('horizonmm.com', '208.249.78.9', 010207,
'364406391', 99893
6544, '0.0.0.0', 'Sync', '')
Mon Aug 27 14:22:24 2001: DEBUG: Handling with Radius::AuthFILE
Mon Aug 27 14:22:24 2001: DEBUG: Processing
PostAuthHook:setSessionTimeout
Mon Aug 27 14:22:24 2001: DEBUG: setSessionTimeout: username is:
horizonmm.com
Mon Aug 27 14:22:24 2001: DEBUG: setSessionTimeout:
Called-Station-Id is: 641920
0
Mon Aug 27 14:22:24 2001: DEBUG: Query is: select
USERNAME,TIMEBLOCK,CLASS,DISAB
LETIME,DISABLECLASS from XSTOP where USERNAME='horizonmm.com'
Mon Aug 27 14:22:24 2001: DEBUG: Accounting accepted
Mon Aug 27 14:22:24 2001: DEBUG: Packet dump:
*** Sending to 208.249.78.9 port 1028
Code: Accounting-Response
Identifier: 18
Authentic:
(196208254x23924323522#196x16613818215
Attributes:
-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 12, 2001 7:35 PM
To: William Hernandez; Radiator
Subject: Re: (RADIATOR) Framed-IP of 0.0.0.0
Hello William -
The only way to understand what is happening is to look at a
trace 4 debug
from Radiator to see in what circumstances this occurs. As it is
the NAS that
sends the accounting packets that are used to maintain the
session database,
it is highly likely that this is a NAS issue.
Note that we have seen similar behaviour occassionally when it is
Radiator
allocating the addresses, and one work-around is to send a copy
of the
address in a Class attribute and use a PreClientHook to restore
it.
Obviously if it is the NAS that is allocating the addresses, you
will need to
check with the NAS vendor if there is a fix for the problem.
regards
Hugh
On Thursday 13 September 2001 00:16, William Hernandez wrote:
Hello everyone,
We're using 2.18.2. Recently we started to see FRAMEDIPADDRESS
of
0.0.0.0 in RADONLINE. These records create a problem when
checking for Simultaneous-Use. Is this a problem with the
Ascend
NASes that we use?
Thanks in advance,
William
===
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
RE: (RADIATOR) Framed-IP of 0.0.0.0
Yes. I have seen this before prior to using Radiator in some of my NASes. We also have some Ascends. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of William Hernandez Sent: Wednesday, September 12, 2001 07:16 To: Radiator Subject: (RADIATOR) Framed-IP of 0.0.0.0 Hello everyone, We're using 2.18.2. Recently we started to see FRAMEDIPADDRESS of 0.0.0.0 in RADONLINE. These records create a problem when checking for Simultaneous-Use. Is this a problem with the Ascend NASes that we use? Thanks in advance, William === 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) Framed-IP of 0.0.0.0
I got this when someone connect in ISDN at two channels, the second record is showing this IP. Ascend Max TNT Hello everyone, We're using 2.18.2. Recently we started to see FRAMEDIPADDRESS of 0.0.0.0 in RADONLINE. These records create a problem when checking for Simultaneous-Use. Is this a problem with the Ascend NASes that we use? === 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) Framed-IP of 0.0.0.0
Exactly true for us as well, except that the NASes were Ciscos (5300s, I think). When we were using USR/3Com gear, we didn't have this problem :-\ Dave -Original Message- From: Pascal Robert [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 12, 2001 12:02 PM To: William Hernandez; Radiator Subject: Re: (RADIATOR) Framed-IP of 0.0.0.0 I got this when someone connect in ISDN at two channels, the second record is showing this IP. Ascend Max TNT Hello everyone, We're using 2.18.2. Recently we started to see FRAMEDIPADDRESS of 0.0.0.0 in RADONLINE. These records create a problem when checking for Simultaneous-Use. Is this a problem with the Ascend NASes that we use? === 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) Framed-IP of 0.0.0.0
Hello William - The only way to understand what is happening is to look at a trace 4 debug from Radiator to see in what circumstances this occurs. As it is the NAS that sends the accounting packets that are used to maintain the session database, it is highly likely that this is a NAS issue. Note that we have seen similar behaviour occassionally when it is Radiator allocating the addresses, and one work-around is to send a copy of the address in a Class attribute and use a PreClientHook to restore it. Obviously if it is the NAS that is allocating the addresses, you will need to check with the NAS vendor if there is a fix for the problem. regards Hugh On Thursday 13 September 2001 00:16, William Hernandez wrote: Hello everyone, We're using 2.18.2. Recently we started to see FRAMEDIPADDRESS of 0.0.0.0 in RADONLINE. These records create a problem when checking for Simultaneous-Use. Is this a problem with the Ascend NASes that we use? Thanks in advance, William === 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.
