Beeing in new position where I have to manage, among other things, a
PM3, I'm faced with a
problem that seems to be a classic on this list. I did search the
archives, which helped in previous
ocasions, but didn't found nothing that applies. It's a long
description, so bear with me.
Radius is used for authenticating dial-in users. For some users,
dial-back is required and Radius
tells so to the PM3. On the client side, a DUN script is running
that connects, authenticates and
waits for the dialback connection from the PM3. When the PM3
disconnects, it imediatly tries
to dialback to the predefined location (the need to use locations
with Radius is another issue, but
let's not get out of subject too much); the client modem (analog
line) takes some time to sense
the carrier loss; in the mean time the PM3 (ISDN) tried to dial and
failed, generally due to User
Busy. On the test site, I can connect about 5% of the time, in a
remote site with a similar script
for Linux, I can connect 100% (my guess is because of the analog
operator switch in the remote
site, it takes more time for the dialback call to get established).
The problem is, so, the modem on
the client side not sensing the carrier drop fast enough. Curiosly
enough, with the exact same
DUN script, but using dialback users/locations on the PM3 instead of
Radius, I can get 100%
connects on the test site, as the modem carrier drop sensing is much
faster (isdn debug shows 2
S0: Sending Disconnect Request beeing issued against 1 with Radius
callback).
Attempting to solve this problem, I'm considering two options:
a) change all callback users from beeing authenticated with
Radius to beeing
authenticated/dialedback directly as PM3 dialback users; or
b) find a way to delay the attempt of PM3 dialing back.
Solution a) is straight forward, but implies dropping Radius, which
I was planning to use for
logging/accounting purposes, so I really don't want to do it.
Solution b) would be fine. I tried setting Callback-delay on a port
basis, but to no avail, as
Radius callback is implemented with dialout, not dialback (a subtle
difference, on PM3 viewpoint).
So, finally, the questions are:
a) Am I completely wrong about problem pin-pointing, or
misguided in something ?
b) If not, is there a simple solution to delay the dialback call
from the PM3 ?
c) If not, is there something I can do on the client side to
speed up carrier drop sensing ?
Thank you in advance for your answers/advices/opinions/flames,
Pedro Cavaca
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>