More like the box crashes and DOES NOT reboot. We send the wakeup call
when we boot - but if we crash, or any NAS crashes, hard - no notice.
>during a crash, but you screw it up in one significant way - you send it on
>the RESET, not on the *RESTART*.
I had thought we sent it after every reboot... I'll have to look at that.
>Correct. This is a risk. But denying access for *two seconds* is not
But it isn't denying for 2 seconds. It is denied. The user gets a 'NO'
back. With an on demand dialer this might be ok, but it can also happen
with users manually connecting and they don't know it is ok immediately.
>generally a big deal. It will take longer on EVERY LOOKUP to verify via
>SNMP than the race condition exists. Also, if you keep track by *port*,
If you show the user is still connected - you do NOT reply. We have 30
seconds before the NAS times out. If it takes longer than 30 seconds
to query the NAS then there are other network problems. As long as we
reply before the NAS times out, it is valid.
>Yes, and now when a box "disappears" (ie: power cycle) you get a *boatload*
>of SNMP queries against it, all in real time, and possibly all in rapid
You make a query which says "who is on" - and take the opportunity to update
your DB. Optimization.
>Verification is a good thing *IF* you make the risk of needing to use it
>extremely low. Otherwise you're asking to bury the machine in question
That is the goal. Loopholes in RADIUS sending data are being tightened
down. That is a good thing anyway. So you only ask the box when the
possibility of a race is present, not every auth.
-MZ
-- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe portmaster-users' in the body of the message.