Um, while I wouldn't use your exact wording:-), I certainly share your
sentiment...
>(1) no central database
>(2) new users require new locations in each PM
>(3) number of location limited to free FLASH space - no warning, just
>a big crash if FLASH is full
>
>I already asked for dynamic, RADIUS-based locations for Portmasters.
>It should also be possible to use DEFAULT locations and passing the
>phone number as a user parameter (Dialback-Framed-Location =
>"babelfish", Dialback-Number = "42").
I have submitted (through my vendor, 14 months ago) a formal RFE for the
ability to do exactly what the initial message asked for - simply
turning a Framed-User entry into dialback by prepending the "Dialback-"
and adding the Dialback-No item. That's how Dialback-Login-User works,
and I see no reason for Dialback-Framed-User to be different - in fact
I'd say that using locations for dialback is a rather convoluted idea...
All the info needed for the dialback is in the RADIUS entry, all of it
items that ComOS happily accepts per se - it just doesn't want to do the
right thing with them. As far as I can see, if you are only interested
in dialback (i.e. you don't need any fancy scripts), your two features
above could also be implemented through this comparatively minor
enhancement (bug fix?:-) - might need some modification to radiusd if
you don't want a big users file, but that's where it's easy to make
modifications.
Anyway, I'd like to encourage everybody that wants this functionality to
submit a formal RFE for it.
>Does the following work:
>
>(1) Define a normal login Dialback user in RADIUS with the supplied
>phone number
>(2) Define an additional PPP user for the above login (or use RADIUS
>2.0 prefix/suffix).
>(3) If the user logs in with account (1), the PortMasters dials back.
>After the connect, the PM asks for user/password again. Now enter the
>login (2).
>
>What do you think?
Hm, interesting idea - with the obvious drawback that you have to give a
password twice (especially for us that use one-time passwords:-) - but
that's also the case for Dialback-Login-User, so at least it's
consistent.:-) Had to try it of course, and it *almost* works - doing it
interactively, I get the usual PPP garbage after the second login -
however when doing it for real, my pppd (this is on FreeBSD) gives up,
complaining:
Nov 13 23:14:54 myhost pppd[492]: LCP: timeout sending Config-Requests
Nov 13 23:14:54 myhost pppd[492]: Connection terminated.
Nov 13 23:14:54 myhost pppd[492]: Serial link is not 8-bit clean:
Nov 13 23:14:54 myhost pppd[492]: All received characters had bit 7 set to 0
A very strange result, I think - my account (1) specified Login-Service
= PortMaster, which certainly gives me an 8-bit clean connection if
allowed to complete "normally" - and of course the account (2) would
also have produced an 8-bit clean connection normally.
I also routinely use different accounts for (1) and (2), with (1) being
a Dialback-Login-User and (2) the corresponding Login-User, as it is the
latter that is in the Unix passwd file and I thus can avoid the
additional Unix login - works fine. Seems like ComOS (version 3.3.1 if
it matters) gets confused in this particular case, but why? And why in
this strange way?
Regards
--Per Hedeland
per@erix.ericsson.se