Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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 on USENET a few years ago... They didn't do that mistake again with RC5/RC6/... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #78: Sun Feb 27 15:32:39 CET 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
(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 (same thing). Sounds good. The link in the original mail points to a Linux (GPL) implementation of the STAC compression. Since i was under the impression that STAC is patented, i've contacted the author about this and it seems that STAC either did not notice his implementation, does not care about it, or that it is legal to reimplement it here in Germany or Europe. Perhaps it might be possible to use this somehow, or at least provide hooks to use it ... 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 device. Here is the interface that we use at Whistle: ftp://ftp.whistle.com/pub/archie/netgraph/ng_tn.h (note: the switch types are #defined in another file but include all of the usual suspects: ETSI, NI-1, ATT, DMS100, etc.) The problem here is, that the Whistle ISDN stack has a fundamentally different view of the world than i4b has :-) As far as i understood it, the Whistle ISDN stack is almost completely configurable by using netgraph messages whereas i4b is configured by its isdnd config file. I have made some experiments with mppd over the i4b netgraph b-channel interface and it works beautifully here without any additional configuration messages necessary. But i have no idea, if the real world demands some control messages, such as dial, dial a number, hangup etc. Any ideas how to proceed with this ? hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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 device. Here is the interface that we use at Whistle: ftp://ftp.whistle.com/pub/archie/netgraph/ng_tn.h (note: the switch types are #defined in another file but include all of the usual suspects: ETSI, NI-1, ATT, DMS100, etc.) The problem here is, that the Whistle ISDN stack has a fundamentally different view of the world than i4b has :-) As far as i understood it, the Whistle ISDN stack is almost completely configurable by using netgraph messages whereas i4b is configured by its isdnd config file. I have made some experiments with mppd over the i4b netgraph b-channel interface and it works beautifully here without any additional configuration messages necessary. But i have no idea, if the real world demands some control messages, such as dial, dial a number, hangup etc. Yes, our way of doing things was of course designed for our particular application. It depends on what you want to do with an 'ISDN node'. The /dev/i4b interface is actually pretty close to equivalent to our netgraph control message API. The main differences seem to be: - Our API is strictly limited to ISDN operation, e.g., there are no equivalents to I4B_TIMEOUT_UPD, I4B_UPDOWN_IND, or MSG_IDLE_TIMEOUT_IND and no connection to sppp(8) - Our API allows more ISDN-related configuration, e.g., changing switch type. - Our API is at a slightly higher level.. we don't have the CDID_REQ or PROCEEDING_IND messages; when rejecting a call, you don't get to specify the cause code, it's always set to 21 for you, etc. So the /dev/i4b and our netgraph API are actually quite similar. Of course, a major difference is that with /dev/i4b you don't get the B-channels exposed as netgraph node hooks, which is very useful... but as you've shown already this is easy to add. This gets you a "half netgraphified" ISDN node. One thing that would be easy to do is to simply convert all of the /dev/i4b ioctl's directly into netgraph control messages. This doesn't really buy you anything much though -- really just a different interface for the same thing. But if there were future plans to do all kinds of wacky things with an ISDN device that would benefit by having it fully netgraphified, maybe this would be worth doing. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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 the usual isdn bri
speeds a user process should still be pretty fast enough.
That makes perfect sense.. just be sure to write the code so that
it's easily ported to the kernel.. the main issues being mbuf's..
for that it's probably eassiest to just punt and copy each packet
into a contiguous buffer.
I've done a small amount of work on making ppp(8)-style mbufs look
more like real mbufs with this in mind. If I can bring the whole
interface in line, this problem will go away. Of course this'll
probably then introduce a compatibility problem with {Net,Open}BSD...
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
--
Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org
http://www.Awfulhak.org brian@[uk.]OpenBSD.org
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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 Archies daemonnews article had been available at that time i wrote it, it would have been even easier :-) when this is done the netgraph PPP nodes (which can support these compression types will be usable. In the mppd i worked with (looking ... mpd3.0b1/mpd3.0b2) deflate was not present, predictor was not usable, bsd was not present. There were just hooks for M$ and stac (which you can not release obviously). 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 were a good idea if Brian and Archie would merge both to get the best features from each one into a common product ;-) 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 (same thing). Once these exist, then mpd 'adapters' will have to be written for each one -- these are easy, they just decode the config-req's. I already have code for MPPC/MPPE, minus the proprietary STAC code and the patented RC4 algorithm, and am going to submit it after 4.0-REL as soon as somebody submits an RC4 implementation to /sys/crypto in the international repository. Mpd-3.x already has support for MPPC/MPPE. This is available on our ftp site.. ftp://ftp.whistle.com/pub/archie/netgraph/mppc.tgz 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 device. Here is the interface that we use at Whistle: ftp://ftp.whistle.com/pub/archie/netgraph/ng_tn.h (note: the switch types are #defined in another file but include all of the usual suspects: ETSI, NI-1, ATT, DMS100, etc.) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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 the usual isdn bri speeds a user process should still be pretty fast enough. That makes perfect sense.. just be sure to write the code so that it's easily ported to the kernel.. the main issues being mbuf's.. for that it's probably eassiest to just punt and copy each packet into a contiguous buffer. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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 patented. Is that not the case? John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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 mistake.. you are correct as far as I know. What I should have said was "the non-exportable RC4 algorithm" because (also AFAIK) it's not exportable so we can't check it into freefall. We *can* check it in to the international repository but I don't know if anyone has done that yet, or if so what the header file looks like. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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, and that the algorithm itself is not patented. Is that not the case? I thought RC4 was trademarked by Honda in the USA??? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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 other end is something like an ascend or an external router (zyxel, cisco(?), there are probably more that speak this protocol), you'd want stac lzs (rfc1974), or if its a wintendo box even you'd want M$' special version of that (yes of course they invented their own `standard' again.) So my question is, is anyone working on this? There is (alpha) code that does this on linux, http://www.ibh-dd.de/~beck/stuff/lzs4i4l/ I've looked at that. Its very Linux-centric and i gave up for the moment when i realized how much work it would be to port it. Brian's ppp over i4b does support deflate compression and i get very good results out of it - too good to put more work into the above URL. 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 part of i4b. 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.. (I did look at it already some time ago) when this is done the netgraph PPP nodes (which can support these compression types will be usable. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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 part of i4b. 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 Archies daemonnews article had been available at that time i wrote it, it would have been even easier :-) when this is done the netgraph PPP nodes (which can support these compression types will be usable. In the mppd i worked with (looking ... mpd3.0b1/mpd3.0b2) deflate was not present, predictor was not usable, bsd was not present. There were just hooks for M$ and stac (which you can not release obviously). 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 were a good idea if Brian and Archie would merge both to get the best features from each one into a common product ;-) hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
[.] 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 were a good idea if Brian and Archie would merge both to get the best features from each one into a common product ;-) The reason we haven't done this yet is my fault. I've been too busy with other things :-/ I hope this'll change soon. hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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 should at least help if the other end is running bsd or linux, but if your other end is something like an ascend or an external router (zyxel, cisco(?), there are probably more that speak this protocol), you'd want stac lzs (rfc1974), or if its a wintendo box even you'd want M$' special version of that (yes of course they invented their own `standard' again.) So my question is, is anyone working on this? There is (alpha) code that does this on linux, http://www.ibh-dd.de/~beck/stuff/lzs4i4l/ I've looked at that. Its very Linux-centric and i gave up for the moment when i realized how much work it would be to port it. Brian's ppp over i4b does support deflate compression and i get very good results out of it - too good to put more work into the above URL. 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 part of i4b. 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.. (I did look at it already some time ago) 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 the usual isdn bri speeds a user process should still be pretty fast enough. Regards, -- Juergen Lock [EMAIL PROTECTED] (remove dot foo from address to reply) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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 to be the logical way to do more complex stuff like this aodi thing that e.g. the german Telekom wants to use for their low-bandwidth 10 DEM/month isdn `flatrate' which they plan to introduce around the end of the year. (and _if_ this really works it sure will become pretty popular over here as long as all the other `real' flatrates are still in the 100 DEM or more range... :/ ) this seems to be the current draft: http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-pppext-aodi-02.txt I'm looking at pushing more stuff into the kernel using netgraph, but I haven't had much of a chance recently to work on it. Hellmuth has also created an i4b netgraph node, but again, I haven't had a chance to do much with it. Now that I've got a free-in-the-evenings ISDN connection, I have no excuses left though (except that it's showing up busy at the moment). Once the freeze is over, I'll be looking at getting things under way. Regards, -- Juergen Lock [EMAIL PROTECTED] (remove dot foo from address to reply) -- Brian [EMAIL PROTECTED]brian@[uk.]FreeBSD.org http://www.Awfulhak.org brian@[uk.]OpenBSD.org Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ijppp for isdn, ppp compression, and netgraph (also: load balancing)
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 an external router (zyxel, cisco(?), there are probably more that speak this protocol), you'd want stac lzs (rfc1974), or if its a wintendo box even you'd want M$' special version of that (yes of course they invented their own `standard' again.) So my question is, is anyone working on this? There is (alpha) code that does this on linux, http://www.ibh-dd.de/~beck/stuff/lzs4i4l/ I've looked at that. Its very Linux-centric and i gave up for the moment when i realized how much work it would be to port it. Brian's ppp over i4b does support deflate compression and i get very good results out of it - too good to put more work into the above URL. 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 part of i4b. that seems to be the logical way to do more complex stuff like this aodi thing that e.g. the german Telekom wants to use for their low-bandwidth 10 DEM/month isdn `flatrate' which they plan to introduce around the end of the year. (and _if_ this really works it sure will become pretty popular over here as long as all the other `real' flatrates are still in the 100 DEM or more range... :/ ) this seems to be the current draft: - this "flatrate" will only be available to T-Online customers. Since i'm not such a beast and will probably never become one its of not much use for me. - my usage of the internet is not much compatible with what this "flatrate" offers. - the Telecom does not give away anything for free. Check when, why and most important how you are using the internet: the savings you get using this "flatrate" does not pay even a fraction of the time and work needed to implement this - in my eyes. Anyway, i will happily accepting (clean) code which implements it :-) hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
