There appears to be a bug of sorts in the RewriteFunction call. Under high loads, radiator would stop answering Access-Requests. THe udp recv buffers would pin out. After further inspection, a level 4 trace actually says everything was OK (Access-Accept) but the NAS would never receive the packet. After weeks of troubleshooting we nailed it down to the Rewritefunction we were using.
<Handler Isp-Id=domain.com-CHAP> . . . # this line is wrapping RewriteFunction sub { my ($a) = shift; my ($n) = `/usr/local/bin/getvdomain-chap $a domain.com db1.gwtc.net db2.gwtc.net`; return $n;} . . . </Handler> During this "outage", sockstat (or lsof) would show that when /usr/local/bin/getvdomain-chap was running, it too was listening on udp 1645 and 1646. Keep in mind that during low traffic periods it would work like a charm... This happens on several different UNIX OS's. However, getvdomain actually is suppose to talk to a DB, pull an id out of the database, and authenticate based on the system password for that id. I shutoff all that functionality when we started having problems. So all it did was return the username and we authenticated off a flat users file. This did not resolve the problem. I finally had to use a RewriteUsername clause which fixed the problem temporarily: RewriteUsername s/^([^@]+).*/$1/ The funny thing is, it says it is actually working. The username is being rewritten properly, etc. It just stops working, radpwtst displays no reply during this time. As soon as traffic is shifted away, it recovers and starts working again. A packet dump on the wire reviels that some packets are getting back to the NAS...in the order of 2/50. Please advise as I can not find any documentation on RewriteFunction...did it get taken out of the documentation or something? Radiator version 2.18.4. Nick Rogness <[EMAIL PROTECTED]> - Don't mind me...I'm just sniffing your packets === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.