[Date Prev]   [Date Next] [Thread Prev]   [Thread Next] [Date Index]   [Thread Index]

 

     RE: [snips-users] Radiusmon

Joe,

I am using the same setup basically. I have Snips on a linux box, but my
radius is SBR and has been for a long time. I hate it, but I need cheap that
will query against a SQL database.

Suggestions:
Check the ports that SBR is running on vs what Snips is looking. Remember
there are two ports, accounting and authentication. Look in your radius log
file to see what ports it is listening on. There are two sets of ports that
radius is known to run on. They changed it since the first set was already
taken by another service, officially.

Also, check your radius logs to see if snips is trying to authenticate and
account. It looks like it may be connecting on the accounting but not the
authentication.

Finally, make sure SBR is running happily. Mine tends to abandon the DB
connection and quit responding, even though the service is still running.


Brian Andrus
Millenia Internet Services, Inc.

-----Original Message-----
From: owner-snips-users at navya com [mailto:owner-snips-users at navya com] On
Behalf Of Joe Warren-Meeks
Sent: Monday, July 28, 2003 6:21 AM
To: snips-users at navya com
Subject: [snips-users] Radiusmon


Hello guys,

(Long time Nocol/Snips user, first time poster, love the show)

I have been trying to get radiusmon working and have set up a test 
account to authenticate against, but radiusmon seems to report failure 
even on success. (SNIPS is running on a FreeBSD machine and the RADIUS 
machines are Steel Belted Radius on NT (but not for long))

Now, when I run it in debug mode I get the following:

Output from radiusmon -ddd (passwords in the output changed to protect 
the guilty)

(debug) set_polldevices_function to ptr addr 804d228
radiusmon- Reading global config file /usr/local/snips/etc/snips.conf
(radiusmon).. locked pid-file, started new process (pid=52993)
(debug) radiusmon:
          CONFIGFILE= '/usr/local/snips/etc/radiusmon-confg'
          DATAFILE= '/usr/local/snips/data/radiusmon-output'
          LOGHOST = 'localhost'
open_datafile(), mode = 436
Setting datafile format to version 1
readconfig(): RRD enabled
open_datafile(), mode = 436
read_dataversion() - version is 1
  PktHdr: code=1, id=1, vector=1059397904
  Hashing test, len=7, hashlen=16, test, 1059397904
(debug) radiusmon: llgrad02 radius down
  PktHdr: code=1, id=1, vector=1059397904
  Hashing test, len=7, hashlen=16, test, 1059397904
(debug) radiusmon: llgrad03 radius down

Tcpdump of exchange:

14:11:44.562784 10.1.1.100.4767 > 10.1.1.62.1645:  rad-access-req 61 
[id 1] Attr[  User{SNIPSTEST} Pass [|radius] (ttl 64, id 60738, len 89)
14:11:44.563862 10.1.1.62.1645 > 10.1.1.100.4767:  [udp sum ok] 
rad-access-accept 51 [id 1] Attr[  Class{SBR-CL DN="SNIPSTEST" AT="0".} 
] (ttl 128, id 5239, len 79)
14:11:44.587232 10.1.1.100.4768 > 10.1.1.61.1645:  rad-access-req 61 
[id 1] Attr[  User{SNIPSTEST} Pass [|radius] (ttl 64, id 60744, len 89)
14:11:44.588215 10.1.1.61.1645 > 10.1.1.100.4768:  [udp sum ok] 
rad-access-accept 51 [id 1] Attr[  Class{SBR-CL DN="SNIPSTEST" AT="0".} 
] (ttl 128, id 4291, len 79)


 From the tcpdump we can see that the RADIUS exchange works ok, but that 
radiusmon is still saying it is down. Now, I changed the 
radiusmon-confg to have a wrong password to see what happened if it 
really failed and got this:

radiusmon -ddd output:

read_dataversion() - version is 1
  PktHdr: code=1, id=149, vector=1059398226
  Hashing test1, len=8, hashlen=16, test, 1059398226
Password auth failed (returned 3)
(debug) radiusmon: llgrad02 radius down
  PktHdr: code=1, id=149, vector=1059398229
  Hashing test1, len=8, hashlen=16, test, 1059398229
Password auth failed (returned 3)
(debug) radiusmon: llgrad03 radius down

14:17:06.940120 10.1.1.100.2569 > 10.1.1.62.1645:  rad-access-req 61 
[id 149] Attr[  User{SNIPSTEST} Pass [|radius] (ttl 64, id 7735, len 89)
14:17:09.935948 10.1.1.62.1645 > 10.1.1.100.2569:  [udp sum ok] 
rad-access-reject 20 [id 149] (ttl 128, id 24699, len 48)
14:17:09.937232 10.1.1.100.2570 > 10.1.1.61.1645:  rad-access-req 61 
[id 149] Attr[  User{SNIPSTEST} Pass [|radius] (ttl 64, id 8619, len 89)
14:17:12.930334 10.1.1.61.1645 > 10.1.1.100.2570:  [udp sum ok] 
rad-access-reject 20 [id 149] (ttl 128, id 52171, len 48)

So, from this we can see that radiusmon knows it failed this time, and 
registers it as a failure, but I can't understand why in the first 
version it seems to succeed but (debug) says it fails it. And it 
updates noclogd, sorry snipslogd, as if it failed.

Clues?

Cheers!

  -- joe.

Joe Warren-Meeks
Technical Operations Director
Inspired Broadcast Networks & The Cloud
http://www.inspiredbroadcast.net/
Out of Home Pay to Play Networked Entertainment
1-7, Livonia Street, London W1F 8AD
Tel: +44 (0)20 7478 8282
Mob: +44 (0)7789 176078
Fax: +44 (0)20 7434 9166





Zyrion Traverse Network Monitoring & Network Management Software