Real Time Ascend Maling List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(ASCEND) Constant outgoing calls - solved
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>