When the idle time is reached, B drops the link, decides it needs to send an
accounting record to A for which it needs to bring the link back up :(
Is this a common problem?
Do we need to run a RADIUS accounting server local for B (I hope not)?
Is it possible that pm B drops the accounting records for the location entry
itself (perhaps via a location option)?
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 :(
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
doesn't work: the portmaster seems to ignore it for these packets :(
Please don't tell me we need a default host on pm B's net...
In short: is it possible to manage a remote PoP on a dial-on-demand basis?
Thanks for any suggestions,
Richard Huveneers.
On another related note: since we don't run in.pmd, one of our users could
create a socket listening to port 1642 on our radius server.
Does this pose a security problem? Should we block port 1642 on the machine
running the radius server?