(RADIATOR) problems with some strange dialers

Thu Dec 19 21:43:17 CST 2002

Hello Bogdan -

I am not sure we have enough information here.

I would like to see a copy of your configuration file (no secrets) 
together with a trace 4 debug from Radiator showing a few successful 
requests and a few unsuccessful requests. I would also like to know if 
the same user that has a problem, *always* has a problem, or is it just 
sometimes? And do all the problems happen on the same NAS(s)?

The only reason I can think of is that some PC settings try to log on 
to the Windows network, which sometimes causes trouble.

regards

Hugh

On Thursday, Dec 19, 2002, at 20:27 Australia/Melbourne, Bogdan TARU 
wrote:

>
> 	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.
>
>

-- 
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 radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.