(ASCEND) Constant outgoing calls - solved

[Stephen Mulrine <skm@foremost.co.uk>]

I've solved what turned out to be the self-created problem of null
outgoing calls being placed every ten seconds and thought I would describe
what happened in case anybody encounters anything similar.

A few weeks back we made a business decision to cut down on support calls
by hacking the RADIUS server to accept any old rubbish as a username and
password (you'd probably only consider doing this if you have a revenue-
sharing deal with your telco).  We assign static IP addresses to some
customers and don't want people picking them up by accident, so we've left
a few entries in the password file for usernames which do actually require
a password.

The change to the RADIUS server was very simple: in the module unix_pass()
within radiusd.c, I changed the first mention of
    return UNIX_GETPWNAME_ERR;
to
    return 0;
and that did the trick.  Basically, if a username isn't contained within
the users file or the password file, access is granted.

A few days ago, our MAX was rebooted after an upgrade to 7.0.22 and
things started going horribly wrong.  A syslog message about a null
outgoing call showed up every ten seconds.  The RADIUS server was also
showing a higher load than normal.  It turned out that at boot time, the
MAX tries to authenticate several internal usernames through RADIUS.
These are (in 7.0.22 with load feik.m40):
    banner
    initial-banner-max4000
    dovbs-max4000-N
    permconn-max4000-N
    frdlink-max4000-N
    route-max4000-N
    bridge-max4000-N
where "max4000" is the unit's name and N is a number starting at 0.  My
hack to RADIUS meant that these names would be authenticated and the MAX
would (apparently) populate its internal tables with null data - hence the
null nailed frame relay connection it thought it had, and the stream of
null outgoing calls.  Also, if authentication of (e.g.) frdlink-max4000-0
succeeds, the unit will then request authentication of frdlink-max4000-1,
and so on - hence the load on the server.

A straightforward fix was to patch the code to return UNIX_GETPWNAME_ERR
where the "name" parameter to unix_pass is "banner" or begins with
"initial-", "dovbs-", etc.  The next time I rebooted the MAX, the problem
went away.

Thanks to Berend De Schouwer and Stanislav Galabov who both suggested I
had an active null connection profile, which was indeed the case.

Stephen
++ Ascend Users Mailing List ++
To unsubscribe:	send unsubscribe to ascend-users-request@bungi.com
To get FAQ'd:	<http://www.nealis.net/ascend/faq>