In article <[EMAIL PROTECTED]> you write:
>Don't know whether it is the right term but what would be
>desirable is a way to raise priority of certain protocols, and
>lower e.g. ftp, http and such.
>
>You know what I mean? You are fetching a big file, but wanna do
>an rlogin at the same time. I'm d
Hellmuth Michaelis writes:
> > to add a negraph interface to the B channels should be quite easy.
> > If you need help I can prbably almost do most of it..
>
> Its already in the development sources (Archie had a look at it already)
> and it works with mppd. It was really quite easy, although if
Juergen Lock writes:
> > when this is done the netgraph PPP nodes (which can support
> > these compression types will be usable.
>
> They could, but they don't yet, right? :)
>
> Maybe it still should be added to ijppp first cause debugging user
> processes is easier than the kernel... and at
In article <[EMAIL PROTECTED]>,
Archie Cobbs <[EMAIL PROTECTED]> wrote:
> I already have code for MPPC/MPPE, minus the proprietary STAC
> code and the patented RC4 algorithm,
I have read in several places that only the name "RC4" is trademarked,
and that the algorithm itself is not pa
John Polstra writes:
> > I already have code for MPPC/MPPE, minus the proprietary STAC
> > code and the patented RC4 algorithm,
>
> I have read in several places that only the name "RC4" is trademarked,
> and that the algorithm itself is not patented. Is that not the case?
Oops, my mi
John Polstra wrote:
>
> In article <[EMAIL PROTECTED]>,
> Archie Cobbs <[EMAIL PROTECTED]> wrote:
>
> > I already have code for MPPC/MPPE, minus the proprietary STAC
> > code and the patented RC4 algorithm,
>
> I have read in several places that only the name "RC4" is trademarked,
>
(CC: stripped)
>From the keyboard of Archie Cobbs:
> Here is my list of things that 'should be done' at some point:
>
> 1. Implement the various PPP compression types as netgraph nodes,
> starting with Deflate, then maybe predictor-1, STAC (if we can
> do it legally), and MPPC (sam
Hellmuth Michaelis writes:
> > 2. We should come up with a 'standard' netgraph control message
> > API for an ISDN basic rate interface, and have i4b implement
> > this interface. Then mpd/ppp/etc can "know" this interface
> > and therefore work automatically with any ISDN BRI de
> Juergen Lock writes:
> > > when this is done the netgraph PPP nodes (which can support
> > > these compression types will be usable.
> >
> > They could, but they don't yet, right? :)
> >
> > Maybe it still should be added to ijppp first cause debugging user
> > processes is easier than the k
> And the last thing, is anyone working on moving more of ppp back
> into the kernel, like, by using netgraph? (i hadn't really looked
> at this netgraph thing yet until i read the daemonnews article
> today... impressive stuff.) and is someone working on linking i4b
> and netgraph? that seems
>From the keyboard of Juergen Lock:
> And the other reason i'm looking at ijppp is ppp compression. It
> currently supports deflate (rfc1979) and predictor1 (rfc1978), which
> should at least help if the other end is running bsd or linux,
> but if your other end is something like an ascend or a
Hellmuth Michaelis wrote:
>
> >From the keyboard of Juergen Lock:
>
> > And the other reason i'm looking at ijppp is ppp compression. It
> > currently supports deflate (rfc1979) and predictor1 (rfc1978), which
> > should at least help if the other end is running bsd or linux,
> > but if your o
>From the keyboard of Julian Elischer:
> > > today... impressive stuff.) and is someone working on linking i4b
> > > and netgraph?
> >
> > There will be a netgraph node interface which will link an i4b B-channel
> > to netgraph. There are no plans from my side to netgraphify the D-channel
> >
[.]
> Currently i'm using ppp instead of mppd mostly just because it supports
> deflate compression. I had a look at both mppd and ppp to see how the
> mentioned free stac compression would be integrateable and found them
> both similar, given they both come from iijppp. It looks like if it we
On Sun, Mar 05, 2000 at 06:32:45AM +0100, Hellmuth Michaelis wrote:
> >From the keyboard of Juergen Lock:
>
> > And the other reason i'm looking at ijppp is ppp compression. It
> > currently supports deflate (rfc1979) and predictor1 (rfc1978), which
> > should at least help if the other end is
On Sun, Mar 05, 2000 at 12:31:30AM -0800, Julian Elischer wrote:
> Hellmuth Michaelis wrote:
> >
> > >From the keyboard of Juergen Lock:
> >
> > > And the other reason i'm looking at ijppp is ppp compression. It
> > > currently supports deflate (rfc1979) and predictor1 (rfc1978), which
> > > s
According to John Polstra:
> I have read in several places that only the name "RC4" is trademarked,
> and that the algorithm itself is not patented. Is that not the case?
That's right. RC4 (aka arcfour in SSH) was a trade secret (so it was not
patentable) till someone posted code implementing it
17 matches
Mail list logo
