Yep. You either need to run RADIUS local to B, not run it at all, or use
a nailed up link, not dial on demand.
>Is it possible that pm B drops the accounting records for the location entry
>itself (perhaps via a location option)?
It isn't possible to do that currently.
>I am thinking of patching the RADIUS code to drop the accounting records
>for the location entry and then forward them to our real accounting server.
>Guess I'll need to do that for the syslog packets too :(
You'd have to be running a server local to B for this. The *PM* is what is
bringing the link up to send the packets. And that code is in ComOS.
>On a related note, pm B also tries to connect to TCP port 1642 of the
>default host constantly (in.pmd which we don't run). This default
>host is also on A's local net so this keeps the link up too. Is it possible
>to turn this off on pm B? Adding an out filter to the location entry on B
PM's ship with in.pmd on by default. If *any* port has
Login Service or Device Service as PortMaster, this happens.
something like:
'set all service_device rlogin'
'set all service_login rlogin'
'save all'
'reset all'
should to it.
>In short: is it possible to manage a remote PoP on a dial-on-demand basis?
It wasn't meant to be done this way...
>Does this pose a security problem? Should we block port 1642 on the machine
>running the radius server?
It'll try to connect to 1642 on the default hose, that isn't necessarily
your RADIUS host.
And in.pmd doesn't have anything to do with RADIUS.
-MZ
-- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 6920 Koll Center Parkway #220, Pleasanton, CA 94566