(RADIATOR) problems with some strange dialers

david.kramar at aliatel.cz david.kramar at aliatel.cz
Thu Dec 19 04:33:29 CST 2002


Hi Bogdan
Interesting problem:-)

What is IOS version?
Did you do some debug on cisco? try this (be careful on active AS)
deb radius
deb aaa authorization
deb aaa authentication
deb ppp authentication
deb ppp negotiation
deb ppp packet

so more investigation,

David


-----Původní zpráva-----
Od: Bogdan TARU [mailto:bgd at icomag.de]
Odesláno: 19. prosince 2002 10:28
Komu: radiator at open.com.au
Předmět: (RADIATOR) problems with some strange dialers



	hi guys,

 I have some strange problems, for a day or so, with some dialers which
are dialing our numbers by mistake (telecom call routing fuckup). We run
some cisco AS5300 with authentification on radiator 2.19. The problem is
that these dialers throw an "Access-Request" like:

Wed Dec 18 18:27:07 2002: DEBUG: Packet dump:
*** Received from 192.168.0.9 port 1645 ....
Code:       Access-Request
Identifier: 142
Authentic:  ?<179><232>$c<174><205><227><0>`<250>z>8<156><235>
Attributes:
        NAS-IP-Address = 192.168.0.9
        NAS-Port = 20028
        NAS-Port-Type = ISDN
        User-Name = "EMATECEssen"
        Called-Station-Id = "880430"
        Calling-Station-Id = "2018276617"
        CHAP-Password = <8>0Z2r<253><12><245><8>e<136>@<3>ar<182>$
        Service-Type = Framed-User
        Framed-Protocol = PPP


 To which we do these internal operations:

Wed Dec 18 18:27:07 2002: DEBUG: Handling request with Handler
'Realm=DEFAULT'
Wed Dec 18 18:27:07 2002: DEBUG: Rewrote user name to EMATECEssen
Wed Dec 18 18:27:07 2002: DEBUG: SessionsDSX Deleting session for
EMATECEssen, 1
92.168.0.9, 20028
Wed Dec 18 18:27:07 2002: DEBUG: do query is: delete from online where
NASID='19
2.168.0.9' and NASPort=020028

Wed Dec 18 18:27:07 2002: DEBUG: Handling with Radius::AuthSQL
Wed Dec 18 18:27:07 2002: DEBUG: Handling with Radius::AuthSQL:
Wed Dec 18 18:27:07 2002: DEBUG: Query is: select users.attribute from
users lef
t join users AS tmp on tmp.User='EMATECEssen' where (tmp.User IS NULL AND
users.
User='Default')

Wed Dec 18 18:27:07 2002: DEBUG: Radius::AuthSQL looks for match with
EMATECEsse
n
Wed Dec 18 18:27:07 2002: DEBUG: Radius::AuthSQL ACCEPT:
Wed Dec 18 18:27:07 2002: DEBUG: Handling with Radius::AuthDYNADDRESS
Wed Dec 18 18:27:07 2002: DEBUG: Query is: select Time, IPAddr from pools
where
Pool='192.168.0.9' and State=0 order by Time limit 1

Wed Dec 18 18:27:07 2002: DEBUG: do query is: update pools set
State=1,Time=1040
232427,Expiry=1040236027,User='EMATECEssen' where IPAddr='192.168.11.29'
and Tim
e =1040227767

Wed Dec 18 18:27:07 2002: DEBUG: Access accepted for EMATECEssen
Wed Dec 18 18:27:07 2002: DEBUG: Packet dump:


 And the radiator is sending the Cisco dialin machine the following
'Access-Accept' reply:

*** Sending to 192.168.0.9 port 1645 ....
Code:       Access-Accept
Identifier: 142
Authentic:  ?<179><232>$c<174><205><227><0>`<250>z>8<156><235>
Attributes:
        Service-Type = Framed-User
        Framed-Protocol = PPP
        Session-Timeout = 3600
        Framed-IP-Address = 192.168.11.29


 The problem is that the 'Access-Accept' is basically ignored, and a new
'Access-Request' is issued for the same user. This happens only for some
users -- usernames (I cannot say anything about them, I don't know what
kind of settings they have), the rest of them (our old dialers) work
perfectly.

 So, does anyone know what kind of settings on the client part could
determine such a behaviour? (maybe the dialer tries to get a certain IP
address, and just retries up until it gets that IP -- but shouldn't it
put the requested IP in the Access-Requeast packet?). I realize this isn't
exactly the best place to ask such a question, but it's the best I know.

 Secondly, there is still the problem that once I get an 'Access-Request'
I assign an IP, and send the reply with 'Access-Accept'. But if that is
ignored, it means the cisco machine will never send me an
'Accounting-Request', which means that that IP will be marked as busy
'forever', which leads to the fillup of the IP pool. How can one solve
such a problem? From within Radiator, I mean, I know I can build up a
daemon which can make a comparison between the 'online' and the 'pools'
tables, and reset the IPs which don't have online users to a non-busy
state.

 Thank you,
 bogdan

----------------------------
iCom Media AG
Kirchweg 36
Koln, 50858
Germany

Phone: +49-(0)221-485-689-16
Fax  : +49-(0)221-485-689-20
Mobile:+49-(0)173-906-46-01

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.


More information about the radiator mailing list