On Wed, 29 Mar 2000, Mike wrote:
On Tue, 28 Mar 2000, Aaron Nabil wrote:
I'm banging my head against the wall on this SNMP disconnect problem. I want to be able to do a disconnect via a single "set" that is indexed via session-id or username and session-id.
Why are you so attached to the session ID? Why not use the port number to directly hang up the modem?
I am using the port number. We hang up _a lot_ (>10/hour, currently) of connections, I don't want to drop the wrong people because I lost an accounting stop. So it requires that I double-check to make sure that the user I want to zap is still on that port first. If I was using session-id, it wouldn't be necessary to make that check.
There are two good candidates. The best one is usrUserMan.usrUserManGroup.usrUserManActiveSessionTable.uumActiveSessionEntry.uumActiveSessionAction which works when you hand it the session ID it's looking for. Unfortunatly, the session-ID it's looking for is "off" by some, small, random, unpredicatable number compared to the Radius Session-ID, and you can only learn this bad sesion-ID by doing a "get" to discover it's corrupted value, which would be as slow as what I'm doing now.
How is this off?? Can you give an example?
An example would be the Radius Session-ID is 6637483 and the one in the table is 6637482, 6637483, 6637484, or 6637485. -- Aaron Nabil - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.