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