> This isn't a general case. There are no 'clean' solutions to the multiple
> login problem. It will take time to come up with a good solution that
> works on all supported platforms.
Yup, and there are people out there that want this to be higher up
on the priority pole.
> > > 1. You've got the source for radius, and can fix it yourself.
> > Not supported by Livingston.(and I wouldn't expect them to, beyond basic
> > functionality.)
>
> I can't expect them to support my local authentication policy. Its just
> not going to work. I'm sorry, but I think that radius isn't really very
> useful unless its modified to suit your own needs. I submit that while
> it might be nice for Livingston to have a radiusd that does everything I
> want, and their tech-support knows all about all the little features,
> there are other things that I'd rather they spent their time and effort
> on.
As it has been pointed out before, we are dealing with different
resources. The people that are working on OSPF are probably not the same
people that would be working on this issue. The engineers working on a
PRI solution are probably not the people that would be working on this issue.
>
> > > 2. There are 2 or 3 other radius implementations that will do what you're
> > > asking for.
> > Not supported by Livingston.(and I wouldn't expect them to, beyond basic
> > functionality.)
>
> Exactly, so why do we want them to support all of the various local
> authentication policies?
Because they can be an important part of the way a business functions.
As our company offers unmetered accounts, I can say that it is would be
much easier to disallow multiple logins rather than attempt to actually
get people to pay for multiple usage. Good luck.
You hacked your RADIUS to prevent multiples. We switched to Merit. But
none of this invalidates the request that Livingston offer support for
this function. It is a reasonable request, and given that the market is
moving more and more towards "unlimited" usage, it becomes more important
to the ISP market in general.
> > > 3. Its probably in the works anyway.
> > Possible, but what do you expect everyone to do, sit in a room and just
> > hope for it?
>
> No, they can code up something themselves if its so damned important to
> them. This is my point.
Which costs money.
> > And others would like *supported* additions to functionality. It could be
> > fixed *once* and *properly* as Livingston says they will do, or everyone
> > could continue to use what Gryphon, MZ(I forget which) say aren't the best
> > solutions.
>
> Again, how do you expect Livingston to SUPPORT local authentication
> policy? At this point, I don't think their support system is ready to
> deal with LUSER-ISP that calls up and fusses because he can't figure out
> the config file syntax for enabling GID based authentication restriction
> or selective multiple login denial or whatever. (Not to imply that
> Livingston Tech Support is inadequate, but they probably have enough to
> deal with right now.)
That is another matter altogether. Livingstons support should be such
that they can support their customer base. Period.
> > Not at all. However I think that *supported functionality* is important to
> > quite a few people.
>
> Yes, I'm sure it is, but there should be other irons in the fire...
Again, you are assuming that the same group is working on all the
different issues.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell (510) 943-5769 voice
Systems Administrator (510) 210-2000 modem
Value Net, Inc. (510) 943-1708 fax
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/