I don't see this as a problem. To this point Livingston has done very
well being innovative and adding nifty features to their terminal servers.
If their radius supports these features out of box, many customers will be
much happier with the solution as a whole.
Cisco and the rest can't use Livingston's code without leaving the
copyrights in place, so wherever that code goes, its just screaming
Livingston's name. I'd think it was a bit odd that my cisco or USR was
depending on Livingston written software (ignoring the obvious here) that
didn't fully support their own native features.
> earlier posts the main reason for this agreement is the fact that
> other companies are ripping off radius code as a product for _their_
> customers. If I made something, I wouldn't want my competitors to
> run away with it either.
*shrug* Like I said, if any of Livingston's competitors use that code,
it only spreads the Livingston name around.
> >All well, I'm not switching to radius 2.0 anyway, and I'm using Ascends
> >for all of my dialup now so I don't have to deal with this.
>
> I don't think we'll be switching either, but that's mainly because our
> radius server is now almost completely rewritten. We had to be able to
> answer 100 packets a second, and the original livingston code wasn;t
> able to do that.
Yep. There is alot that 1.16 isn't able to do. Much subtle brokenness.
> >Anyone up for putting out a FreeRadius package derived from the 1.16
> >source tree? With Merit doing similar things with the licensing on
> >their LAS stuff it would almost be worth the effort. I'd bet we can match
> >Livingston feature for feature and do lots of other nifty stuff as well.
>
> We would do that if our code wasn't so extremely tailored to our needs.
> For instance, we directly read our NIS password database and keep it in
> memory, checking regularly to see if it changed, to update the incore
> copy of it.
*nod* I'm facing this too, but a package with a wide range of
flexability would be quite usefull.
> >In my bag I've got:
>
> >- Prefixed logins for unix auth'ed users. (SCP patches, and
> > adding something like user[#$%&]service wouldn't be hard either.
>
> Doesn't everyone? :)
True.
> >- PPP PAP autodetection (for prefixless PPP logins)
>
> Why do you need that? Doesn't user_service_type and framed_protocol tell you
> what you wanna know?
They do, which is the point.
> >- Livingston Portmaster, US Robotics Netserver, and Ascend compatibility.
> > (anyone have a Computone box I could get some detail files and -x output
> > from?)
>
> We've had major problems getting the Netserver to work. Their port of
> ComOS seems flaky at best. The latest version started blasting 60 packets
> a second at our server. Without even listening to answers. Our server
> survived, the original 1.16 didnt ;) Fork Fork Fork. One of the first
> things we fixed. Non-forking :)
Ah... *dig* *dig* *ponder*
I remember fixing something regarding the NetServer, but I can't remember
where it was. We started out using a Total Control, and have had it
working for a long time...
> Also, don't forget cisco :). Although their client code behaves differently
> with every release. Seems 11.1(5) behaves somewhat normal.
*nod* I'm not planning on using ciscos for dialup though. Someone else
will have to provide data on this one.
Have a good one.
| Matthew N. Dodd | winter@jurai.net | http://www.jurai.net/~winter |
| Technical Manager | mdodd@intersurf.net | http://www.intersurf.net |
| InterSurf Online | "Welcome to the net Sir, would you like a handbasket?"|