From owner-netdev@oss.sgi.com Thu Feb 3 15:51:42 2000 Received: by oss.sgi.com id ; Thu, 3 Feb 2000 15:51:22 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:45953 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Thu, 3 Feb 2000 15:50:51 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id KAA27922; Wed, 2 Feb 2000 10:43:53 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id KAA22894; Wed, 2 Feb 2000 10:42:47 -0500 (EST) Date: Wed, 2 Feb 2000 10:42:47 -0500 (EST) From: jamal To: netdev@oss.sgi.com cc: axboe@suse.de, Mark Spencer , mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: RFC: PPP over X Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Folks, This is not posted to l-k because i didnt see the need for it. If there is a good reason someone please forward it there. The people in the CC list are in "the know". If people think this should be taken off line and just privately discussed, then please yell. Hopefully, the result here is that we have a solution quickly decided so we can submit into 2.3 I apologize for the lengthy post; i thought it would be beneficial for those not "in the know" ;-> When you respond please continue CCing the Cc list ubecause some of them are not on the netdev list (other than probably Andi). -----------------------------START HERE ----------------- The issue as i see it: Too many "PPP over X" type protocols (PPPOE, L2TP, PPP over ATM, PPP over SONET etc) and there will be a lot more coming probably. All these type of protocols have a very similar protocol structure. You discover something and use that discovery information to start sending/receiving data using PPP framing. The discovery tends to be the rich part of the protocol (as well as the slower path). The problem IMO: Too many solutions; same end goal --> kernel cluttering. Example for ppp over ethernet (for 2.3): -------------------------------------------- Jamal: PPPd talks to a tty device (akin to a modem). Discovery in user space, data switching in kernel Code size in there kernel (At the moment about 20k) Contribution from the tty code: about 75% of this Advantage: -No changes required for any PPP/d (user/kernel) - small addition to ther kernel - Flexible enough to be used for _any_ PPP over X With Minimal code addition ( <10K in the kernel). -works in both 2.2 and 2.3 Disadvantage: -uses tty -- an asoteric interface -Does not use the channel interface (Claim: Trivial change to make) Michal: -has both the discovery and data switcing encap/decap into the kernel -PPPd talks to a brand new socket family (created for PPPOE). Code size in the kernel (At the moment about 60k) This includes also the server part. Contribution from the socket addition: about 30% of this Advantages: does not use the tty interface. Uses the channel interface; Disadvantage: -Bloats the kernel. (claim: Michal could remove the discovery phase out of the kernel reducing it by about 20K). -The socket use could become a maintainance nightmare (claim: it looks very clean at the moment). -Hard coded for PPPOE -Creating a whole socket family for just PPPOE is a bad idea (claim: Could make it for PPPOX with type PPPOE, L2TP etc). ----------------------------------------------------------- The flow of connection setup/teardown possibilities for connection setup: ----------------------------------- pppoxd refers to your favorite PPP over X daemon ONE: 1. pppoxd negotiates a connection and identifies parameters eg in PPPPOE the sid and remote MAC address for the connection. 2. pppoxd opens a connection to the pppox interface. to grab a fd which will be used by pppd. eg if the interface used was a socket then for pppoe, this determines the definition of sockaddr_pppoe. 3. pppoxd hands-off the fd to pppd. 4. PPPd grabs a new unit from the kernel (eg ppp1) 5. pppd performs a channel binding on the pppox interface by calling an ATTACH ioctl. TWO: 1. PPPd uses its "connect" interface to invoke a connection setup from the pppoxd. 2. pppoxd negotiates a connection and identifies parameters 3. pppoxd opens a connection to the pppox interface. to grab a fd which will be used by pppd. 4. pppoxd hands-off the fd to pppd. 5. PPPd grabs a new unit from the kernel (eg ppp1) 6. pppd performs a channel binding on the pppox interface by calling an ATTACH ioctl. The advantage of method 2 is that it maintains the goodies that pppd provides already (such as dial on demand etc) I prefer this method. Disconnection ------------- Could be issued from the user or could come from remote via a PADT >From Remote: 1. Kernel receives all PADTs 2. It detaches the channel whose SID is indicated by the PADT. 3. PPP tells pppd of the detachment. 4. pppd invokes the particular protocol's "disconnect" execution. >From user: 1. from pppoxd send a PADT to remote 2. From pppoxd send to kernel an ioctl to detach 3. pppd should inform you that there has been a detachment. WHAT Needs to be decided ------------------------ We are all curently in violent agreement that discovery should be in user space (includes Michal). The main decision to make is what interface should PPPd be talking to? For 2.2, the only viable solution is the tty one. There is no question that for 2.3 onwards the channel interface is the way to go. So what should be the device that pppd talks to? Is it a new socket family, tty device, a new char device etc.? End Goal: --------- -speed (a given with the channel stuff). However, we need some quick way of way to shunt the data to the correct transporter within the kernel (eg to UDP sockets for L2TP). -flexibility (IMO) make it easy in the future to just add encap/decap extensions. i.e i should be able to add todays_flavor_of_pppox by simple regiatration APIs, write a user space discovery, bind it to pppd and voila, it works (magic!). Note that we currently have a limitation in pppd in that it is very friendly to ttys. A small change will be required in the pppd daemon. No changes in the kernel PPP. I propose addition of a new syntax to the pppd options: "channelname " eg "channelname l2tp" The pppd code should check for this syntax (which is mutually exclusive with the devicename option). When this option is passed, any assumptions that pppd is talking to a tty device are nullified. This syntax could also be used to do other things in the future (i,e currently the name above eg l2tp is a meaningless artifact). I suggest that the current pppd "connect"/"disconnect" features be used for connection setup teardown. Some enhancement might be needed (although i dont see it myself). >From the kernel side, My proposal is that whatever interface chosen is, it should be able to very easily add new "PPP over X"s; so a registration API is a requirement. We should merge also the PPP over ATM already implemented using Michals idea. I might have missed other things. Michal? cheers, jamal From owner-netdev@oss.sgi.com Fri Feb 4 13:50:37 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 13:50:27 -0800 Received: from styx.uwaterloo.ca ([129.97.40.10]:13321 "EHLO styx.uwaterloo.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 13:50:08 -0800 Received: (from mostrows@localhost) by styx.uwaterloo.ca (8.9.3/8.9.3) id IAA26669; Thu, 3 Feb 2000 08:44:10 -0500 From: Michal Ostrowski MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14489.34346.789910.342715@styx.uwaterloo.ca> Date: Thu, 3 Feb 2000 08:44:10 -0500 (EST) To: jamal Cc: netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: RFC: PPP over X In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing jamal writes: > The advantage of method 2 is that it maintains the goodies that pppd > provides already (such as dial on demand etc) > I prefer this method. Me too. I take it that you meant to apply your "channelname" proposal to this? This would mean that pppoxd is some module inside pppd that does the negotiation. > > The main decision to make is what interface should PPPd be > talking to? For 2.2, the only viable solution is the tty one. > There is no question that for 2.3 onwards the channel > interface is the way to go. > > So what should be the device that pppd talks to? Is it a new socket > family, tty device, a new char device etc.? I think that for PPPoE at least sockets (of some form) are the way to go, because with a sockets approach we have code that maintains consistent semantics. What that means is that the code looks like network code all the way through (with no need to translate to tty semantics and vice-versa), and that's why I think it is a very "clean" solution (from a high-level perspective). Although this probably requires more code (infrastructure code to support a sockets interface) it's as efficient as anything else on a per-packet basis (using PPP-channels). I think that pretty well summarizes why I went with sockets in the first place... > > End Goal: > --------- > > -speed (a given with the channel stuff). However, we need some > quick way of way to shunt the data to the correct transporter > within the kernel (eg to UDP sockets for L2TP). > -flexibility (IMO) make it easy in the future to just add encap/decap > extensions. i.e i should be able to add todays_flavor_of_pppox > by simple regiatration APIs, write a user space discovery, bind it to > pppd and voila, it works (magic!). > > > Note that we currently have a limitation in pppd in that it is very > friendly to ttys. A small change will be required in the pppd daemon. > No changes in the kernel PPP. > I propose addition of a new syntax to the pppd options: > "channelname " eg "channelname l2tp" > The pppd code should check for this syntax (which is mutually > exclusive with the devicename option). When this option is passed, > any assumptions that pppd is talking to a tty device are nullified. > This syntax could also be used to do other things in the future > (i,e currently the name above eg l2tp is a meaningless artifact). I totally agree with this in general. I have a few concerns about some of the semantics though: I think that the "channelname" option should register a back-end channel module. This module would then provide a function which would try to interpret the "devicename" option. pppd would try the "devicename" recognizers for all registered channel modules --- the one that accepts is the channel that is used. By default a "tty" module is used; this module encapsulates existing tty control functionality. The reason for this is that you can then specify "channelname pppoe", and this works for PPPoE connections over eth0, eth1, etc. (the exact device being specified by the "devicename" options). > I suggest that the current pppd "connect"/"disconnect" features be used > for connection setup teardown. Some enhancement might be needed (although > i dont see it myself). Perhaps each channel module would provide it's own methods for "connect"/"disconnect". The "connect"/"disconnect" options as they are now would have to be recognized as options belonging to the "tty" module, though each module could support equivalents. This does raise the issue of how options are treated wrt modules; we could allow modules to register their own option namespace (e.g.: allow for channel specific options such as "pppoe.ac_name"). Thus we would allow for each channel module to register an options namespace and functions for connect, disconnect, and "devicename" recognition. With such an approach you could have one options file which would support PPPoE, tty and xxxx sessions simultaneously. > > We should merge also the PPP over ATM already implemented using Michals > idea. > I'd appreciate it if somebody would send me pointers to relevant code so I can see what things are like in PPPoATM land (and how they relate to PPPoE). Michal Ostrowski mostrows@styx.uwaterloo.ca From owner-netdev@oss.sgi.com Fri Feb 4 19:21:21 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 19:21:11 -0800 Received: from dhcp41.toaster.net ([199.108.84.41]:57617 "EHLO schmee.sfgoth.com") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 19:20:51 -0800 Received: (from mitch@localhost) by schmee.sfgoth.com (8.9.3/8.9.3) id LAA88167; Thu, 3 Feb 2000 11:15:17 -0800 (PST) Date: Thu, 3 Feb 2000 11:15:17 -0800 From: Mitchell Blank Jr To: Michal Ostrowski Cc: jamal , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X Message-ID: <20000203111517.I72648@sfgoth.com> References: <14489.34346.789910.342715@styx.uwaterloo.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <14489.34346.789910.342715@styx.uwaterloo.ca>; from mostrows@styx.uwaterloo.ca on Thu, Feb 03, 2000 at 08:44:10AM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing > I think that for PPPoE at least sockets (of some form) are the way to > go, because with a sockets approach we have code that maintains > consistent semantics. I agree, especially if you're running a PPPoE session server, where you need hundreds of simultaneous sessions demuxed. > This does raise the issue of how options are treated wrt modules; we > could allow modules to register their own option namespace (e.g.: > allow for channel specific options such as "pppoe.ac_name"). Uh, pppd modules can already register options. > Thus we would allow for each channel module to register an options > namespace and functions for connect, disconnect, and "devicename" > recognition. This has already been discussed among the PPPoA folks (i.e. mostly Jens and myself :-) Basically we need to add a few hooks to pppd-2.3.11 to allow all the tty-specific code to be worked around by a module. > > We should merge also the PPP over ATM already implemented using Michals > > idea. > > I'd appreciate it if somebody would send me pointers to relevant > code so I can see what things are like in PPPoATM land (and how they > relate to PPPoE). ftp://ftp.XX.kernel.org/pub/linux/kernel/people/jaxboe/PPPoATM/ It's a little rough (i.e. it currently takes the "big stick" approach to making pppd work instead of the module-style detailed above) The kernel-side stuff (which is my fault) shows how simple adding a protocol to the ppp_generic stuff can be. Ignore the ATTACH_ENCAPS ioctl - I was smoking something when I decided I needed that... really setting the encapsulation should be a seperate ioctl (like setting the tty options in ppp_async works) -Mitch From owner-netdev@oss.sgi.com Fri Feb 4 20:07:13 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 20:07:02 -0800 Received: from dhcp41.toaster.net ([199.108.84.41]:62724 "EHLO schmee.sfgoth.com") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 20:06:36 -0800 Received: (from mitch@localhost) by schmee.sfgoth.com (8.9.3/8.9.3) id MAA88918; Thu, 3 Feb 2000 12:01:27 -0800 (PST) Date: Thu, 3 Feb 2000 12:01:27 -0800 From: Mitchell Blank Jr To: jamal Cc: netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X Message-ID: <20000203120127.J72648@sfgoth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from hadi@cyberus.ca on Wed, Feb 02, 2000 at 10:42:47AM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing jamal wrote: > This is not posted to l-k because i didnt see the need for it. Probably a good idea. If it is going to happen on a vger list it should realy be linux-ppp > Hopefully, the result here is that we have a solution quickly decided so > we can submit into 2.3 I really don't see why the channels stuff in 2.3 shouldn't just stay as is - it's really very clean. The real work that needs to be done is to pppd to support plugins that deal with different channel types better. > The issue as i see it: > Too many "PPP over X" type protocols (PPPOE, L2TP, PPP over ATM, PPP > over SONET etc) and there will be a lot more coming probably. ...PPTP, ISDN-PPP (is that using the new ppp_generic code yet?), RFC 1598 (PPP-over-X25), RFC 1973 (PPP-over-Frame), RFC2363 (PPP-over-FUNI-ATM)... > The problem IMO: > > Too many solutions; same end goal --> kernel cluttering. The problem as I see it is just that more things need to convert to the channels stuff (ppp_generic and friends) > Advantage: > -No changes required for any PPP/d (user/kernel) I don't see this an advantage - recent pppd's have a plugin mechanism which could make these changes very clean (see the PLUGINS file in a recent pppd). All that is really needed is the tty-specific stuff in pppd to have hooks put around it so it can be supplanted easily by non-tty variants. Then each PPP-o-X can just have its own module. The only challenge is getting a firm enough grasp on all the pppd code that deals with ttys so the small surgical changes can be made without upsetting other ports. I haven't had time to divine this level of understanding of all those twisty little passages. > -has both the discovery and data switcing encap/decap into the kernel > -PPPd talks to a brand new socket family (created for PPPOE). > > Code size in the kernel (At the moment about 60k) > This includes also the server part. > Contribution from the socket addition: about 30% of this I think this is fine. PPPoE is a full-fledged protocol with all the mux/demux needs that implies. It's just going to be a little large if you want a flexible implementation. None of that has anything to do with the choice of ppp implementation. Look at the ppp-o-atm code - since the VCC mux/demux is handled by the higher layer (it's just over a standard PPP socket) the code to use the ppp_generic channel interface is almost trivial. If I had to rewrite it to emulate a tty interface not only would the performance suck eggs, but the code would be much larger. PPP is a packet-oriented interface and the current (2.3) ppp_generic stuff reflects that nicely. > Advantages: > does not use the tty interface. Uses the channel interface; > > Disadvantage: > -Bloats the kernel. Again, wrong. For a simple to implement protocol it bloats the kernel less than ppp_async does. > -The socket use could become a maintainance nightmare > (claim: it looks very clean at the moment). It's not a maintence nightmare. Quite the opposite - using a socket family gives you all the socket infastructure (like module auto-load) for free. > -Creating a whole socket family for just PPPOE is a bad idea I don't think so - it has its own addressing, so it needs its own address family. > 1. pppoxd negotiates a connection and identifies parameters > eg in PPPPOE the sid and remote MAC address for the connection. > > 2. pppoxd opens a connection to the pppox interface. > to grab a fd which will be used by pppd. > eg if the interface used was a socket then for pppoe, > this determines the definition of sockaddr_pppoe. > > 3. pppoxd hands-off the fd to pppd. Why make a new pppoxd? Wouldn't it be easier to just use a pppd plugin? > WHAT Needs to be decided > ------------------------ > > We are all curently in violent agreement that discovery should be in > user space (includes Michal). Then I'll be the violent dissenter, I guess. I don't think discovery is analagous to ARP (which also has a right to be in the kernel, IMO).. it's more analagous to TCP connect. Michal's code provides very clean socket semantics.. I think those should be preserved. When I looked at the code months ago there were a bunch of implementation problems (HZ=100 assumptions, needs a better hashed structure for holding connections (look at tcp code), didn't properly verify MAC on incoming data frames, etc) I spent a couple hours at a local diner with a printout of the pppoe code doing an audit and came up with a dozen or so suggested improvements.... then I managed to lose all my notes before doing anything with them :-( > The main decision to make is what interface should PPPd be > talking to? For 2.2, the only viable solution is the tty one. I think we should just write off 2.2 - 2.4 is on the way. If someone wants all these PPP-o-X things in 2.2 that badly then they should do a back-port of ppp_generic and friends. > So what should be the device that pppd talks to? Is it a new socket > family, tty device, a new char device etc.? Depends on the "X" in PPP-o-X! tty: can talk to a tty device just like now PPPoE: new socket family PPPoA: ATM_PVC socket etc > Note that we currently have a limitation in pppd in that it is very > friendly to ttys. A small change will be required in the pppd daemon. > No changes in the kernel PPP. OK, now you're talking sense. :-) > I propose addition of a new syntax to the pppd options: > "channelname " eg "channelname l2tp" > The pppd code should check for this syntax (which is mutually > exclusive with the devicename option). When this option is passed, > any assumptions that pppd is talking to a tty device are nullified. I think this can all be handled by the plugin architecture. We just need a hook installed to let us interpret the devicename ourselves. pppd plugin .../pppoe.so PPPoEoptions... eth0 pppd plugin .../pppoatm.so PPPoATMoptions... 0.0.101 > >From the kernel side, My proposal is that whatever interface chosen is, > it should be able to very easily add new "PPP over X"s; so a registration > API is a requirement. No, it isn't. The registration takes place at another level * tty: registers a new line discipline (register_ldisc) * PPPoE: registers a new socket family * PPPoA: registers a new atm "backend" (actually the way you register a backend in linux-atm is really gross... on my todo list for 2.5 is clean that up) All the register/unregister stuff (like autoloading) then gets dealt with at another level. -Mitch From owner-netdev@oss.sgi.com Fri Feb 4 20:21:21 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 20:21:12 -0800 Received: from styx.uwaterloo.ca ([129.97.40.10]:49677 "EHLO styx.uwaterloo.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 20:21:00 -0800 Received: (from mostrows@localhost) by styx.uwaterloo.ca (8.9.3/8.9.3) id PAA00873; Thu, 3 Feb 2000 15:15:01 -0500 From: Michal Ostrowski MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14489.57797.470801.438102@styx.uwaterloo.ca> Date: Thu, 3 Feb 2000 15:15:01 -0500 (EST) To: Mitchell Blank Jr Cc: Michal Ostrowski , jamal , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <20000203111517.I72648@sfgoth.com> References: <14489.34346.789910.342715@styx.uwaterloo.ca> <20000203111517.I72648@sfgoth.com> X-Mailer: VM 6.72 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Mitchell Blank Jr writes: > > I think that for PPPoE at least sockets (of some form) are the way to > > go, because with a sockets approach we have code that maintains > > consistent semantics. > > I agree, especially if you're running a PPPoE session server, where > you need hundreds of simultaneous sessions demuxed. > Serving up connections on such a scale brings up some issues. Most importantly, there should be a single process which negotiates all incoming connections. I deal with this in my most recent pppd patch by forking after having established a new connection; the child process then handles that connection and the parent continues to listen for more connections. This is an issue since a pppd daemon no longer has exclusive access to data over a particular "device". I don't know how this applies to PPPoATM, but I think it would be good to agree on what the correct behaviour should be in such situations, regardless of the back-end device/protocol. Michal Ostrowski mostrows@styx.uwaterloo.ca From owner-netdev@oss.sgi.com Fri Feb 4 20:29:31 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 20:29:22 -0800 Received: from dhcp41.toaster.net ([199.108.84.41]:46598 "EHLO schmee.sfgoth.com") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 20:29:11 -0800 Received: (from mitch@localhost) by schmee.sfgoth.com (8.9.3/8.9.3) id MAA89406; Thu, 3 Feb 2000 12:24:02 -0800 (PST) Date: Thu, 3 Feb 2000 12:24:02 -0800 From: Mitchell Blank Jr To: Michal Ostrowski Cc: jamal , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X Message-ID: <20000203122402.M72648@sfgoth.com> References: <14489.34346.789910.342715@styx.uwaterloo.ca> <20000203111517.I72648@sfgoth.com> <14489.57797.470801.438102@styx.uwaterloo.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <14489.57797.470801.438102@styx.uwaterloo.ca>; from mostrows@styx.uwaterloo.ca on Thu, Feb 03, 2000 at 03:15:01PM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing > Serving up connections on such a scale brings up some issues. Most > importantly, there should be a single process which negotiates all > incoming connections. That's true - ideally I'd like to see pppd look more like apache. Most of the gloabal varaiables could move to a "struct atm_instance" and each one would have its own ppp options, plugins, etc. Ideally there would be some way to add/delete/tweek these connections on a running pppd (so you could have a nice little GNOME configuration dialog giving you instant-gratification changes) I think this would be a really great approach for people running terminal-servers or PPPo{E,ATM} concentrators using linux. At some point the "thousands of pppd processes" model breaks down - it would be much cleaner just to have a single process that just needs to set a bunch of async-io signals on a bunch of {sockets,ttys} and watch /dev/ppp0. -Mitch From owner-netdev@oss.sgi.com Fri Feb 4 20:59:11 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 20:58:52 -0800 Received: from styx.uwaterloo.ca ([129.97.40.10]:62989 "EHLO styx.uwaterloo.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 20:58:33 -0800 Received: (from mostrows@localhost) by styx.uwaterloo.ca (8.9.3/8.9.3) id PAA01095; Thu, 3 Feb 2000 15:52:34 -0500 From: Michal Ostrowski MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14489.60049.954056.839117@styx.uwaterloo.ca> Date: Thu, 3 Feb 2000 15:52:33 -0500 (EST) To: Mitchell Blank Jr Cc: Michal Ostrowski , jamal , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <20000203122402.M72648@sfgoth.com> References: <14489.34346.789910.342715@styx.uwaterloo.ca> <20000203111517.I72648@sfgoth.com> <14489.57797.470801.438102@styx.uwaterloo.ca> <20000203122402.M72648@sfgoth.com> X-Mailer: VM 6.72 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Mitchell Blank Jr writes: > > Serving up connections on such a scale brings up some issues. Most > > importantly, there should be a single process which negotiates all > > incoming connections. > > That's true - ideally I'd like to see pppd look more like apache. > Most of the gloabal varaiables could move to a "struct atm_instance" > and each one would have its own ppp options, plugins, etc. > Ideally there would be some way to add/delete/tweek these > connections on a running pppd (so you could have a nice little > GNOME configuration dialog giving you instant-gratification > changes) I won't pretend to be an expert on pppd, but I think you'd want to replace "/dev/ppp" with something like a netlink socket. Using a socket would allow you to mux/demux data in a way that you can't do with a character device. > > I think this would be a really great approach for people > running terminal-servers or PPPo{E,ATM} concentrators using > linux. At some point the "thousands of pppd processes" model > breaks down - it would be much cleaner just to have a single > process that just needs to set a bunch of async-io signals > on a bunch of {sockets,ttys} and watch /dev/ppp0. > Good point. Michal Ostrowski mostrows@styx.uwaterloo.ca From owner-netdev@oss.sgi.com Fri Feb 4 21:14:02 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 21:13:52 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:10136 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 21:13:33 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id QAA16190; Thu, 3 Feb 2000 16:07:59 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id QAA26526; Thu, 3 Feb 2000 16:07:59 -0500 (EST) Date: Thu, 3 Feb 2000 16:07:58 -0500 (EST) From: jamal To: Mitchell Blank Jr , Michal Ostrowski cc: netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <20000203111517.I72648@sfgoth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Good to see this discussion is happening./ michal>I take it that you meant to apply your "channelname" proposal to this? michal> This would mean that pppoxd is some module inside pppd that does michal>negotiation. yes michal>I think that for PPPoE at least sockets (of some form) are the way michal>to go, because with a sockets approach we have code that maintains michal>consistent semantics. What that means is that the code looks like michal>network code all the way through (with no need to translate to tty michal>semantics and vice-versa), and that's why I think it is a very michal>"clean" solution (from a high-level perspective). Although this michal>probably requires more code (infrastructure code to support a michal> socketsinterface) it's as efficient as anything else on a michal> per-packet basis (using PPP-channels). michal> No the "network-like" skb code is provided by the channel interface. If you use the channel interface, you get skbs. I ma not totaly against using sockets, but you need a more convincing arguement (eg look at the netlink interface; it is a char device and yet it is used in networking abstraction) Try to be more convincing; if you say that the socket domain will be something like "pppox" and the type "pppoe" then it becomes a little more sellable. michal>I totally agree with this in general. I have a few concerns about michal>some of the semantics though: I think that the "channelname" option michal>should register a back-end channel module. This module would then michal>provide a function which would try to interpret the "devicename" michal>option. pppd would try the "devicename" recognizers for all michal>registered channel modules --- the one that accepts is the channel michal>that is used. By default a "tty" module is used; this module michal>encapsulates existing tty control functionality. The reason for this michal> this is that you can then specify "channelname pppoe", and this michal> works PPPoE connections over eth0, eth1, etc. (the exact device michal> being specified by the "devicename" options). pppd currently has "connect" and "disconnect" features. You can attach scripts to it or even executables. So this is the backend you might be refering to? This way pppd doesnt have to know anything about the PPPoX semantics. You are right, we might need to have to pass something like a channelnumber; so maybe extend the syntax to be something along the lines "channel " eg "channel l2tp 0" in the ppp passed to pppd in its options. michal>Perhaps each channel module would provide it's own methods for michal>"connect"/"disconnect". The "connect"/"disconnect" options as they This is there today (as mentioned above). but maybe we need a connect_plugin if you think the current "connect" is not good enough. 2.3.11 has a neat plugins feature (which seems a little limited) but allows you to extend the functionality of pppd. michal>This does raise the issue of how options are treated wrt michal> modules; we michal>could allow modules to register their own option namespace (e.g.: michal>allow for channel specific options such as "pppoe.ac_name"). michal> michal>Thus we would allow for each channel module to register an options michal>namespace and functions for connect, disconnect, and "devicename" michal>recognition. With such an approach you could have one options file michal>which would support PPPoE, tty and xxxx sessions simultaneously. This sounds like a lot of work to me, no? Why not just have the passing of the "channel" syntax to mean that this is not a tty? And then you can add whatever options you want (and maybe ignore most that dont affect you). cheers, jamal From owner-netdev@oss.sgi.com Fri Feb 4 21:21:21 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 21:21:12 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:7837 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 21:21:01 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id QAA21087; Thu, 3 Feb 2000 16:15:50 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id QAA26544; Thu, 3 Feb 2000 16:15:50 -0500 (EST) Date: Thu, 3 Feb 2000 16:15:50 -0500 (EST) From: jamal To: Mitchell Blank Jr cc: Michal Ostrowski , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <20000203111517.I72648@sfgoth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing mitch> I agree, especially if you're running a PPPoE session server, where mitch> you need hundreds of simultaneous sessions demuxed. mitch> You just need to be able to select and/or poll; you dont necessarily need sockets for that mitch> a protocol to the ppp_generic stuff can be. Ignore the mitch> ATTACH_ENCAPS mitch> ioctl - I was smoking something when I decided I needed that... mitch> really setting the encapsulation should be a seperate ioctl (like mitch> setting the tty options in ppp_async works) mitch> I think it looks bad because you were trying to do this on pppd. It should be OK if you did it in say a pppoatmd; cheers jamal From owner-netdev@oss.sgi.com Fri Feb 4 21:32:52 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 21:32:42 -0800 Received: from styx.uwaterloo.ca ([129.97.40.10]:19470 "EHLO styx.uwaterloo.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 21:32:22 -0800 Received: (from mostrows@localhost) by styx.uwaterloo.ca (8.9.3/8.9.3) id QAA01611; Thu, 3 Feb 2000 16:26:27 -0500 From: Michal Ostrowski MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14489.62083.60474.357786@styx.uwaterloo.ca> Date: Thu, 3 Feb 2000 16:26:27 -0500 (EST) To: jamal Cc: Mitchell Blank Jr , Michal Ostrowski , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: References: <20000203111517.I72648@sfgoth.com> X-Mailer: VM 6.72 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing > > No the "network-like" skb code is provided by the channel interface. > If you use the channel interface, you get skbs. I ma not totaly against > using sockets, but you need a more convincing arguement > (eg look at the netlink interface; it is a char device and yet it > is used in networking abstraction) > Try to be more convincing; if you say that the socket domain will be > something like "pppox" and the type "pppoe" then it becomes a little more > sellable. Which interface are you referring to? Netlink sockets or "/dev/ppp" or something else entirely? I'm a bit confused... > > michal>Perhaps each channel module would provide it's own methods for > michal>"connect"/"disconnect". The "connect"/"disconnect" options as they > > This is there today (as mentioned above). > but maybe we need a connect_plugin if you think the current "connect" > is not good enough. 2.3.11 has a neat plugins feature (which seems > a little limited) but allows you to extend the functionality of pppd. Adding in more hooks to support plugins would appear to be the way to go. As implied in Mitchell's thread we'd want a device name recognition hook as well as "connect" and "disconnect" hooks. Extending the functionality of plugins, and perhaps isolating the tty code into a default plugin would give us the functionality and flexibility we want. > > michal>This does raise the issue of how options are treated wrt > michal> modules; we > michal>could allow modules to register their own option namespace (e.g.: > michal>allow for channel specific options such as "pppoe.ac_name"). > michal> > michal>Thus we would allow for each channel module to register an options > michal>namespace and functions for connect, disconnect, and "devicename" > michal>recognition. With such an approach you could have one options file > michal>which would support PPPoE, tty and xxxx sessions simultaneously. > > This sounds like a lot of work to me, no? Why not just have the passing > of the "channel" syntax to mean that this is not a tty? > And then you can add whatever options you want (and maybe ignore most that > dont affect you). > As Mitch pointed out most of what I mentioned is already there with plugins, though we need to add more hooks. It appears that the "channelname" semantics you propose are equivalent to plugins with support for a device name recognition hook. Quite frankly I think it's pretty nifty to be able to do "pppd eth0". Michal Ostrowski mostrows@styx.uwaterloo.ca From owner-netdev@oss.sgi.com Fri Feb 4 21:41:52 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 21:41:42 -0800 Received: from styx.uwaterloo.ca ([129.97.40.10]:28686 "EHLO styx.uwaterloo.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 21:41:36 -0800 Received: (from mostrows@localhost) by styx.uwaterloo.ca (8.9.3/8.9.3) id QAA01809; Thu, 3 Feb 2000 16:35:19 -0500 From: Michal Ostrowski MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14489.62615.212216.191320@styx.uwaterloo.ca> Date: Thu, 3 Feb 2000 16:35:19 -0500 (EST) To: jamal Cc: Mitchell Blank Jr , Michal Ostrowski , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: References: <20000203111517.I72648@sfgoth.com> X-Mailer: VM 6.72 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing jamal writes: > > mitch> I agree, especially if you're running a PPPoE session server, where > mitch> you need hundreds of simultaneous sessions demuxed. > mitch> > > You just need to be able to select and/or poll; you dont necessarily need > sockets for that I think the bigger issue there is that in such a situation it may not be feasible to maintain a unique character device for each connection. If you've got connections going up and down constantly it could be a real hassle to try to match and bind them to character devices. Socket's are ideal for this kind of thing since you don't need to translate from the network-level naming (stuff that can be done with a sockaddr) and character device naming in the file system. Since any sort of PPPoX code must be able to keep track of multiple connections using an addressing/naming scheme unique to "X", using sockets with an appropriately defined sockaddr derivative appears to be the natural thing to do. Michal Ostrowski mostrows@styx.uwaterloo.ca From owner-netdev@oss.sgi.com Fri Feb 4 21:49:42 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 21:49:32 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:2480 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 21:49:21 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id QAA07241; Thu, 3 Feb 2000 16:41:48 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id QAA26591; Thu, 3 Feb 2000 16:41:47 -0500 (EST) Date: Thu, 3 Feb 2000 16:41:47 -0500 (EST) From: jamal To: Mitchell Blank Jr cc: netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <20000203120127.J72648@sfgoth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Thu, 3 Feb 2000, Mitchell Blank Jr wrote: > jamal wrote: > mitch >I really don't see why the channels stuff in 2.3 shouldn't just mitch >stay as is - it's really very clean. The real work that needs mitch >to be done is to pppd to support plugins that deal with different mitch >channel types better. mitch > Nobody is suggesting to touch the generic stuff mitch > mitch >...PPTP, ISDN-PPP (is that using the new ppp_generic code yet?), mitch >RFC 1598 (PPP-over-X25), RFC 1973 (PPP-over-Frame), RFC2363 mitch >(PPP-over-FUNI-ATM)... mitch > You made my point. mitch >> The problem IMO: mitch >> mitch >> Too many solutions; same end goal --> kernel cluttering. mitch > mitch >The problem as I see it is just that more things need to mitch >convert to the channels stuff (ppp_generic and friends) Nobody is arguing about that. In 2.2 it is out of question. tty is the only answer. mitch >> -No changes required for any PPP/d (user/kernel) mitch > mitch >I don't see this an advantage - recent pppd's have a plugin mitch > mechanism mitch >which could make these changes very clean (see the PLUGINS mitch >file in a recent pppd). All that is really needed is the mitch > tty-specific mitch >stuff in pppd to have hooks put around it so it can be supplanted mitch >easily by non-tty variants. Then each PPP-o-X can just have mitch >its own module. I am in agreement. mitch > mitch >The only challenge is getting a firm enough grasp on all the mitch >pppd code that deals with ttys so the small surgical changes mitch >can be made without upsetting other ports. I haven't had mitch >time to divine this level of understanding of all those mitch >twisty little passages. nod. mitch > mitch >> Code size in the kernel (At the moment about 60k) mitch >> This includes also the server part. mitch >> Contribution from the socket addition: about 30% of this mitch > mitch >I think this is fine. PPPoE is a full-fledged protocol with all mitch >the mux/demux needs that implies. It's just going to be a mitch >little large if you want a flexible implementation. None of mitch >that has anything to do with the choice of ppp implementation. Did you really read the whole thing before posting ;->? Nobody is saying anything about touching the ppp implementation;-> And just because some protocol needs a mux/demux interface does not equate it to sockets; have you thought of using netfilter modules? And why not, since they can provide you with nice mux/demux interface? mitch > mitch >Look at the ppp-o-atm code - since the VCC mux/demux is handled mitch >by the higher layer (it's just over a standard PPP socket) mitch >the code to use the ppp_generic channel interface is almost mitch >trivial. If I had to rewrite it to emulate a tty interface mitch >not only would the performance suck eggs, but the code would mitch >be much larger. mitch > For PPP over ATM it might actually make sense to do the VCC mux/demux socket(AF_ATMPVC, SOCK_DGRAM, 0) as you do because you already have the VCC being mapped to the socket by design. i.e you did not create the AF_ATMPVC just so that you can do PPP over it unless i am totaly misunderstading the reasoning behind the AAL5 semantics. mitch >> Advantages: mitch >> does not use the tty interface. Uses the channel interface; mitch >> mitch >> Disadvantage: mitch >> -Bloats the kernel. mitch > mitch >Again, wrong. For a simple to implement protocol it bloats mitch >the kernel less than ppp_async does. mitch > I dont think so. But thats a moot point. The point is: Add stuff in the kernel only when it will make sense for more people to use it; If you can do it in user space -- do it there! If you can improve performance by moving pieces into the kernel, then that is a good justification. mitch >> -The socket use could become a maintainance nightmare mitch >> (claim: it looks very clean at the moment). mitch > mitch >It's not a maintence nightmare. Quite the opposite - using mitch >a socket family gives you all the socket infastructure (like mitch >module auto-load) for free. mitch > So iam saying that because it is a lot of code. You might have a point -- i still havent seen it. mitch >> -Creating a whole socket family for just PPPOE is a bad idea mitch > mitch >I don't think so - it has its own addressing, so it needs mitch >its own address family. mitch > Bad reason. mitch >Why make a new pppoxd? Wouldn't it be easier to just use a pppd mitch > plugin? mitch > I think thats what we are saying. I.e just another plugin or a thing that talks to pppd. mitch > mitch >> mitch >> We are all curently in violent agreement that discovery should be mitch > in mitch >> user space (includes Michal). mitch > mitch >Then I'll be the violent dissenter, I guess. I don't think mitch> discovery mitch >is analagous to ARP (which also has a right to be in the kernel, IMO).. mitch >it's more analagous to TCP connect. So why dont you move OSPF to the kernel? It has its own addressing, it does its own demuxing/muxing etc.. mitch >> The main decision to make is what interface should PPPd be mitch >> talking to? For 2.2, the only viable solution is the tty one. mitch > mitch >I think we should just write off 2.2 - 2.4 is on the way. mitch >If someone wants all these PPP-o-X things in 2.2 that badly mitch >then they should do a back-port of ppp_generic and friends. You can use the generic tty interface i provided for 2.2. mitch > mitch >> So what should be the device that pppd talks to? Is it a new socket mitch >> family, tty device, a new char device etc.? mitch > mitch >Depends on the "X" in PPP-o-X! mitch > mitch > tty: can talk to a tty device just like now mitch > PPPoE: new socket family mitch > PPPoA: ATM_PVC socket And what about PPP-over-Frame, PPP over UDP ;-> Create a new socket family for each? mitch >etc mitch > mitch >I think this can all be handled by the plugin architecture. We just mitch >need a hook installed to let us interpret the devicename ourselves. mitch > mitch > pppd plugin .../pppoe.so PPPoEoptions... eth0 mitch > pppd plugin .../pppoatm.so PPPoATMoptions... 0.0.101 mitch > You need to have both a connect and disconnect; It could be via plugins or the already provided features of "connect" or "disconnect" mitch >No, it isn't. The registration takes place at another level mitch > * tty: registers a new line discipline (register_ldisc) mitch > * PPPoE: registers a new socket family mitch > * PPPoA: registers a new atm "backend" (actually the way you register mitch > a backend in linux-atm is really gross... on my todo list for 2.5 mitch > is clean that up) mitch > mitch >All the register/unregister stuff (like autoloading) then gets mitch >dealt with at another level. mitch > I didnt quiet follow -- but i'd like to understand what you are saying. cheers, jamal From owner-netdev@oss.sgi.com Fri Feb 4 21:50:31 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 21:50:12 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:25008 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 21:50:06 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id QAA08788; Thu, 3 Feb 2000 16:44:47 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id QAA26610; Thu, 3 Feb 2000 16:44:46 -0500 (EST) Date: Thu, 3 Feb 2000 16:44:46 -0500 (EST) From: jamal To: Michal Ostrowski cc: Mitchell Blank Jr , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <14489.57797.470801.438102@styx.uwaterloo.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Thu, 3 Feb 2000, Michal Ostrowski wrote: > Serving up connections on such a scale brings up some issues. Most > importantly, there should be a single process which negotiates all > by forking after having established a new connection; the child > process then handles that connection and the parent continues to > listen for more connections. This is an issue since a pppd daemon no > longer has exclusive access to data over a particular "device". I > don't know how this applies to PPPoATM, but I think it would be good > to agree on what the correct behaviour should be in such situations, > regardless of the back-end device/protocol. Its probably a very specific design issue; off the top of my head -- you could have pppd "connect" invoke you via some IPC eg unix domain sockets; How you handle what happens after is your decision; mutithreading etc is one example; avoid forks (just my choice). cheers jamal From owner-netdev@oss.sgi.com Fri Feb 4 22:07:22 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 22:07:02 -0800 Received: from styx.uwaterloo.ca ([129.97.40.10]:46862 "EHLO styx.uwaterloo.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 22:06:46 -0800 Received: (from mostrows@localhost) by styx.uwaterloo.ca (8.9.3/8.9.3) id RAA02492; Thu, 3 Feb 2000 17:00:36 -0500 From: Michal Ostrowski MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14489.64132.865545.368327@styx.uwaterloo.ca> Date: Thu, 3 Feb 2000 17:00:36 -0500 (EST) To: jamal Cc: Mitchell Blank Jr , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: References: <20000203120127.J72648@sfgoth.com> X-Mailer: VM 6.72 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing jamal writes: > > So iam saying that because it is a lot of code. > You might have a point -- i still havent seen it. > > mitch >> -Creating a whole socket family for just PPPOE is a bad idea > mitch > > mitch >I don't think so - it has its own addressing, so it needs > mitch >its own address family. > mitch > > > Bad reason. > What's the difference between adding a new socket family and adding a new tty-device type? Yes, a tty-device will probably require less infrastructure code (since sockets have a richer interface to support). Aside from lines of code what's the difference? > > And what about PPP-over-Frame, PPP over UDP ;-> > Create a new socket family for each? Just off-the top of my head, you may be able to support PPP over UDP simply by adding the appropriate ioctls into the UDP socket code. You may have a good point about PPPoATM --- there may be enough similarities between PPPoE and PPPoATM to justify code sharing. (Though I'm just speculating here because I haven't had a chance to go through the code thoroughly yet.) > > You need to have both a connect and disconnect; It could be via plugins > or the already provided features of "connect" or "disconnect" > Perhaps the existing "connect"/"disconnect" options should be integrated into the plugin/hook mechanism. (That is, recognizing one of these options registers an appropriate hook.) One may be able to do all of the options parsing upon starting up pppd , use the options to set hooks and then just rely on the hooks instead of checking whether or not a given option is set. (It's amazing just how little one can accomplish in an afternoon when there's e-mail to read/write.) Michal Ostrowski mostrows@styx.uwaterloo.ca From owner-netdev@oss.sgi.com Fri Feb 4 22:30:31 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 22:30:22 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:1483 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 22:30:14 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id RAA03031; Thu, 3 Feb 2000 17:25:02 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id RAA26693; Thu, 3 Feb 2000 17:25:02 -0500 (EST) Date: Thu, 3 Feb 2000 17:25:02 -0500 (EST) From: jamal To: Michal Ostrowski cc: Mitchell Blank Jr , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <14489.64132.865545.368327@styx.uwaterloo.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Thu, 3 Feb 2000, Michal Ostrowski wrote: > jamal writes: > > mitch >> -Creating a whole socket family for just PPPOE is a bad idea > > mitch > > > mitch >I don't think so - it has its own addressing, so it needs > > mitch >its own address family. > > mitch > > > > > Bad reason. > > > > What's the difference between adding a new socket family and adding a > new tty-device type? Yes, a tty-device will probably require less > infrastructure code (since sockets have a richer interface to > support). Aside from lines of code what's the difference? > >From a semantical point of view there is *none*. If i was managing the code, i would say it would be easier to manage something that is smaller (especially when it is more than half the size). And the rate at which Linux kernel code is growing, it safer to give a lot of merit to code that provides less bloat to the kernel especially if they provide the same functionality. Now if you look at the tty code, you'll see there is still a lot of unnecesary crap that is not really being used, but is there because the tty interface needs it. I dont like that either. Again it seems there is a consensus that maybe tty is not the way to go., > > > > > And what about PPP-over-Frame, PPP over UDP ;-> > > Create a new socket family for each? > > Just off-the top of my head, you may be able to support PPP over UDP > simply by adding the appropriate ioctls into the UDP socket code. > You will still have to register callbacks for the encap/decap Which the general population using UDP sockets might not be very excited about. And if you do add the callbacks then it doesnt make much of a difference in the end performancewise if you use a generic socket_pppox interface to do it instead and pipe the data to an open udp socket. > You may have a good point about PPPoATM --- there may be enough > similarities between PPPoE and PPPoATM to justify code > sharing. (Though I'm just speculating here because I haven't had a > chance to go through the code thoroughly yet.) I just browsed through it myself. > > > > > > You need to have both a connect and disconnect; It could be via plugins > > or the already provided features of "connect" or "disconnect" > > > > Perhaps the existing "connect"/"disconnect" options should be > integrated into the plugin/hook mechanism. (That is, recognizing one > of these options registers an appropriate hook.) One may be able to > do all of the options parsing upon starting up pppd , use the options > to set hooks and then just rely on the hooks instead of checking > whether or not a given option is set. > Good point. We might have to revisit it later again once the kernel level issue is settled. > > (It's amazing just how little one can accomplish in an afternoon when > there's e-mail to read/write.) hehe. Same here. Havent heard from Mark Spencer or Paul Mackerras. It would be nice to hear from them. cheers, jamal From owner-netdev@oss.sgi.com Fri Feb 4 22:57:42 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 22:57:23 -0800 Received: from kogge.hanse.de ([192.76.134.17]:42513 "EHLO kogge.Hanse.DE") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 22:57:16 -0800 Received: (from uucp@localhost) by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id XAA15842; Thu, 3 Feb 2000 23:51:12 +0100 (CET) (envelope-from eis@baty.hanse.de) Received: (from eis@localhost) by baty.hanse.de (8.9.3/8.9.3) id XAA17504; Thu, 3 Feb 2000 23:03:17 +0100 To: jamal Cc: netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X References: From: Henner Eisen Date: 03 Feb 2000 23:03:17 +0100 In-Reply-To: jamal's message of "Wed, 2 Feb 2000 10:42:47 -0500 (EST)" Message-ID: Lines: 59 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >>>>> "jamal" == jamal writes: jamal> -Hard coded for PPPOE -Creating a whole socket family for jamal> just PPPOE is a bad idea (claim: Could make it for PPPOX jamal> with type PPPOE, L2TP etc). What about a generic ´ppp over socket´ paradigm which would eliminate the need of special protocol families for each ppp carrier? I´was thinking about it like this: - Connection is controlled via usual socket system calls (bind(), connect(), accept(), setsockopt(), ...) - a special ioctl() allows for attaching a ppp channel to a socket is provided. After successful completion of that ioctl(), a struct ppp_channel will have been created. The socket´s protocol stack will pass incoming data upstream by calling ppp_input() instead of appending the frame to sk->receive_queue. The ppp_channel_ops´ queue_xmit() method will pass the frame to the protocol engine´s output method. I think that for SOCK_PACKET and SOCK_SEQ_PACKET sockets, this could be implemented rather generically by providing some standard hook functions for the struct sock callbacks (e.g. ppp_input() might be called from sk->data_ready()). (However, a certain amount of protocol specific code will be necessary because different ppp carrier protocols use different methods to encapsulate ppp frames). ppp connections would be set up like this: - pppd creates socket corresponding to ppp carrier, e.g. PPP over ethernet: s = socket(PF_PACKET,SOCK_PACKET,ETH_P_PPPOE); PPP over X.25: s = socket(PF_X25,SOCK_SEQ_PACKET,0); PPP over YOUR_FAVOURITE_CARRIER_PROTOCOL: s = socket(PF_YOUR_FAVORITE_FAMILY,SOCK[_SEQ]_PACKET,?); (please forgive me that i don´t know the paramters for YOUR_FAVOURITE_CARRIER by heart, but the above should extend easily to things like PPP over ATM, PPP over IRDA or PPP over UDP) - pppd directly (by means of connect() or accept()) or indirectly (by means of protocol family specific utility programs) establishes carrier connection of desired type. - When carrier connection is established, pppd executes ioctl(s,SIOCATTPPP,&pppchan); which attaches the data path of the socket to a ppp channel. - after that, pppd continues to process the ppp protocol proper. - pppd might perform further socket connection control triggerd by local events or remote events. E.g. additional channels might be set up or closed when MPPP negotiation is indicationg this. Henner From owner-netdev@oss.sgi.com Fri Feb 4 22:59:01 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 22:58:42 -0800 Received: from lrcsun15.epfl.ch ([128.178.156.77]:60551 "EHLO lrcsun15.epfl.ch") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 22:58:28 -0800 Received: (from almesber@localhost) by lrcsun15.epfl.ch (8.8.X/EPFL-8.1a) id XAA23391; Thu, 3 Feb 2000 23:42:47 +0100 (MET) From: Werner Almesberger Message-Id: <200002032242.XAA23391@lrcsun15.epfl.ch> Subject: Re: RFC: PPP over X To: hadi@cyberus.ca (jamal) Date: Thu, 3 Feb 2000 23:42:46 +0100 (MET) Cc: mitch@sfgoth.com (Mitchell Blank Jr), mostrows@styx.uwaterloo.ca (Michal Ostrowski), netdev@oss.sgi.com, axboe@suse.de, markster@marko.net (Mark Spencer), ak@suse.de (Andi Kleen), marc@mbsi.ca (Marc Boucher), paulus@linuxcare.com, bcrl@redhat.com (Ben LaHaise) In-Reply-To: from "jamal" at Feb 03, 2000 04:07:58 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing jamal wrote: > (eg look at the netlink interface; it is a char device and yet it > is used in networking abstraction) Minor correction, assuming you means what you get with CONFIG_NETLINK_DEV: the "right" way to use netlink is as a protocol family, not as a device. - Werner -- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/ From owner-netdev@oss.sgi.com Fri Feb 4 23:10:31 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 23:10:21 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:34278 "EHLO cyberus.ca") convert rfc822-to-8bit bulk by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 23:10:11 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id SAA26584; Thu, 3 Feb 2000 18:04:33 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id SAA26759; Thu, 3 Feb 2000 18:04:33 -0500 (EST) Date: Thu, 3 Feb 2000 18:04:33 -0500 (EST) From: jamal To: Henner Eisen cc: netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8BIT Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On 3 Feb 2000, Henner Eisen wrote: > >>>>> "jamal" == jamal writes: > > jamal> -Hard coded for PPPOE -Creating a whole socket family for > jamal> just PPPOE is a bad idea (claim: Could make it for PPPOX > jamal> with type PPPOE, L2TP etc). > > What about a generic ´ppp over socket´ paradigm which would eliminate > the need of special protocol families for each ppp carrier? > > I´was thinking about it like this: > Other than the weird syntax you provided for the socket connect this sounds quiet reasonable to me; domain=pppox, type=pppoe, protocol=0x8864 as an example ... This is what i was saying to Michal (but not in so many words ;->). In addition i think what is needed is a registration API at the kernel so that all the common code is shared other than the encapsulation/send recieve/decapsulation which is specific to the particular "PPP over X" This way every new PPPOX doesnt have a new socket family and it adds only the code specific to itself. cheers, jamal From owner-netdev@oss.sgi.com Fri Feb 4 23:12:11 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 23:12:02 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:35304 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 23:11:56 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id SAA28253; Thu, 3 Feb 2000 18:06:40 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id SAA26764; Thu, 3 Feb 2000 18:06:40 -0500 (EST) Date: Thu, 3 Feb 2000 18:06:39 -0500 (EST) From: jamal To: Werner Almesberger cc: Mitchell Blank Jr , Michal Ostrowski , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <200002032242.XAA23391@lrcsun15.epfl.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Thu, 3 Feb 2000, Werner Almesberger wrote: > jamal wrote: > > (eg look at the netlink interface; it is a char device and yet it > > is used in networking abstraction) > > Minor correction, assuming you means what you get with CONFIG_NETLINK_DEV: > the "right" way to use netlink is as a protocol family, not as a device. Thanks Werner ;-> And for the netfilter device i meant the one used to send packets to user space (not sure if it works or is still around); Solaris box, tty terminal, no code to double check. cheers, jamal From owner-netdev@oss.sgi.com Fri Feb 4 23:18:02 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 23:17:53 -0800 Received: from styx.uwaterloo.ca ([129.97.40.10]:3087 "EHLO styx.uwaterloo.ca") convert rfc822-to-8bitQBCWVC1 by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 23:17:49 -0800 Received: (from mostrows@localhost) by styx.uwaterloo.ca (8.9.3/8.9.3) id SAA03334; Thu, 3 Feb 2000 18:12:02 -0500 From: Michal Ostrowski MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Message-ID: <14490.2881.979155.516130@styx.uwaterloo.ca> Date: Thu, 3 Feb 2000 18:12:01 -0500 (EST) To: Henner Eisen Cc: jamal , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Henner Eisen writes: > >>>>> "jamal" == jamal writes: > > jamal> -Hard coded for PPPOE -Creating a whole socket family for > jamal> just PPPOE is a bad idea (claim: Could make it for PPPOX > jamal> with type PPPOE, L2TP etc). > > What about a generic ´ppp over socket´ paradigm which would eliminate > the need of special protocol families for each ppp carrier? > > I´was thinking about it like this: > Your outline is almost identical to the code I've got right now. Feel free to take a look: http://www.math.uwaterloo.ca/~mostrows > > ppp connections would be set up like this: > > - pppd creates socket corresponding to ppp carrier, e.g. > PPP over ethernet: s = socket(PF_PACKET,SOCK_PACKET,ETH_P_PPPOE); The problem here is that you need to use bind and/or connect (regardless of where negotiation is performed), and you need to do with a sockaddr that is not compatible with PF_PACKET. It is this need for an addressing scheme which is unique to PPPoE that made me go with PF_PPPOE. Modifying PF_PACKET to make exceptions and support "protocols" that have different addressing schemes would be rather grotesque. To do PPPoE you must bind sockets to addresses that consist of an ethernet MAC address and a PPPoE session id (and implicitly an ethernet data type of 0x8864). I don't think there's any way of doing this cleanly inside another address family such as PF_PACKET. Things get a bit more complicated when you want to do in-kernel connection negotiation, since you may then have to bind sockets to an additional address component: the access-concentrator name. Michal Ostrowski mostrows@styx.uwaterloo.ca From owner-netdev@oss.sgi.com Fri Feb 4 16:40:26 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 16:39:53 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:32961 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 07:10:57 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id KAA11332; Fri, 4 Feb 2000 10:10:57 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id KAA27851; Fri, 4 Feb 2000 10:10:55 -0500 (EST) Date: Fri, 4 Feb 2000 10:10:55 -0500 (EST) From: jamal To: Michal Ostrowski cc: netdev@oss.sgi.com Subject: Re: RFC: PPP over X In-Reply-To: <14490.57346.128709.747580@styx.uwaterloo.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Fri, 4 Feb 2000, Michal Ostrowski wrote: > jamal writes: > > > > So lets try to identify what the other concerns are. > > Michal, i think this is a very good compromise if you can pull it. > > Maybe it will start with just PPPOE; and i suspect L2TP to follow > > it needs something similar. > > I think we'd need to examine L2TP and see just how well it can > co-exist with PPPoE/PPPoATM. Doing PPPoE is easy... figuring out how > to do it in a manner which can co-exist with PPPoX is hard. > Not really. I'll take a look at L2TP and (i hate promising this because i am overloaded) do a port of Mark Spencers user space l2tp > > I think the socket solution is acceptable if you can make it to be > > for more than just pppoe. This is my opinion however. > > I am afraid some of the people that i know to be concerned of this whole > > socket idea havent spoken yet ;-> The words "maintainance nightmare" were > > not really mine. > > Yes... I'm really looking forward to hearing Andi's, Paul's and Dave's > comments (if they ever manage to read through all of the stuff we sent > around yesterday). > I am afraid these are some of the people who were staing that. They probably want to see if we reach an agreement or not ;-> I am also scared that someone is gonna shout "SOCK_PACKET extensions" (as did the last poster -- thats why i didnt respond). > > > > sid should be enough for pppoe, no? > > 99.99999% of the time sid alone suffices. However, you have a problem > if you have multiple connections --- because the remote access > concentrator's may all assign you the same sid, in which case you must > identify them by MAC address as well. My view is that you can think > of sid's as analogous to TCP/UDP ports --- they're useless without an > IP address. > true. > Let's not be quick to jump to conclusions as to how PPPoE will be > used. I've heard a rumour that PPPoE is being considered for use here > at the University of Waterloo to provided authenticated ethernet > access at public ethernet access points. Such a solution makes some > sense since one could leverage the existing RADIUS/PPP infrastructure > used to provide dial-up access. The point here is is that we may see > PPPoE being used beyond the traditional ADSL context (funny how ADSL > is already "traditional"). > I think i have a very good feel to where PPPOE is going. It is about services -- currently the only service is really access; and i think that you might end up seeing the discovery part being extended for some things. I would like to extend it myself and i dont think the "proprietary tag" they have there already is good enough. > > > > There is always a unique way to identify a flow regardless of the > > protocol. Look at the way UDP does it (because it is simple). > > > > I don't understand what you mean by this, please elaborate (or refer > to a specific code fragment). > I was refering to the hashing used. Sorry dont have access to code right now; A TCPI/IP flow could be uniquely hashed by the five tuples: src/dst port, src/dst IP and protocol. > My concern is that you need to know something about the protocol to be > able to identify the flow, since you need to be able to parse the > packet header and extract those bits that identify the stream. And i think every of the PPPOXs will have something unique; so the hashing is not shareable. > Is it possible to find some sort of abstract addressing scheme which > can be used by PPPoE, PPPoATM, L2TP, etc...? (Essentially is it > possible to come up with a sockaddr_pppox which is appropriate for all > of them?) The answer to that IMO will determine whether or not you > can make AF_PPPOX work. I don't know the answer to that. I'll take a look at L2TP sometime this evening or sometime tommorow. You can easily figure the ATM one (or i could look at that too). > > As a side note... I've been informed that our favorite PPPoE-using > ADSL provider's network architecture (Bell Nexxia) includes PPPoE, > L2TP, and PPPoUDP. By that I mean that it is actually possible for > you to send a packet which is carried by all of these protocols before > it reaches your ISP's IP network (in the case that your ISP is not > Sympatico). If your ISP is Sympatico, then you get to skip the > PPPoUDP step. > Hmm... I know someone who is doing PPPTP over PPPOE ;-> I do tunnel over IPSEC to work via PPPOE myself;-> I think you'll see a lot of these VPNish types offered as services; You discover them, you select based on pricing, QoS paramaters etc; doesnt matter what the "ISP today" is. I split my user space code into some sort of libraries -- still in very primitive stages so that i can easily stash GUIs etc in anticipation of this. So in the very near future this will start happening, if the CRTC gets its rulings imposed. You ask for access service, 10 ISPs respond with their AC names and a few other parameters. You select one. Dont ask me about the billing ;-> In the future ADSL will part of your phone bill and the people resonding to you will not be offering you access but rather some other value add service. You will get a feel that Access is free since it is bundled in your phone bill ;-> I hear cable modem is moving to this path as well ;-> It makes a lot of sense if you think about the future. cheers jamal From owner-netdev@oss.sgi.com Fri Feb 4 16:40:27 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 16:39:52 -0800 Received: from styx.uwaterloo.ca ([129.97.40.10]:25105 "EHLO styx.uwaterloo.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 06:19:59 -0800 Received: (from mostrows@localhost) by styx.uwaterloo.ca (8.9.3/8.9.3) id JAA05794; Fri, 4 Feb 2000 09:19:46 -0500 From: Michal Ostrowski MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14490.57346.128709.747580@styx.uwaterloo.ca> Date: Fri, 4 Feb 2000 09:19:46 -0500 (EST) To: jamal Cc: netdev@oss.sgi.com Subject: Re: RFC: PPP over X In-Reply-To: References: <14490.3532.627594.667133@styx.uwaterloo.ca> X-Mailer: VM 6.72 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing jamal writes: > > So lets try to identify what the other concerns are. > Michal, i think this is a very good compromise if you can pull it. > Maybe it will start with just PPPOE; and i suspect L2TP to follow > it needs something similar. I think we'd need to examine L2TP and see just how well it can co-exist with PPPoE/PPPoATM. Doing PPPoE is easy... figuring out how to do it in a manner which can co-exist with PPPoX is hard. > I think the socket solution is acceptable if you can make it to be > for more than just pppoe. This is my opinion however. > I am afraid some of the people that i know to be concerned of this whole > socket idea havent spoken yet ;-> The words "maintainance nightmare" were > not really mine. Yes... I'm really looking forward to hearing Andi's, Paul's and Dave's comments (if they ever manage to read through all of the stuff we sent around yesterday). > > sid should be enough for pppoe, no? 99.99999% of the time sid alone suffices. However, you have a problem if you have multiple connections --- because the remote access concentrator's may all assign you the same sid, in which case you must identify them by MAC address as well. My view is that you can think of sid's as analogous to TCP/UDP ports --- they're useless without an IP address. Let's not be quick to jump to conclusions as to how PPPoE will be used. I've heard a rumour that PPPoE is being considered for use here at the University of Waterloo to provided authenticated ethernet access at public ethernet access points. Such a solution makes some sense since one could leverage the existing RADIUS/PPP infrastructure used to provide dial-up access. The point here is is that we may see PPPoE being used beyond the traditional ADSL context (funny how ADSL is already "traditional"). > > There is always a unique way to identify a flow regardless of the > protocol. Look at the way UDP does it (because it is simple). > I don't understand what you mean by this, please elaborate (or refer to a specific code fragment). My concern is that you need to know something about the protocol to be able to identify the flow, since you need to be able to parse the packet header and extract those bits that identify the stream. Is it possible to find some sort of abstract addressing scheme which can be used by PPPoE, PPPoATM, L2TP, etc...? (Essentially is it possible to come up with a sockaddr_pppox which is appropriate for all of them?) The answer to that IMO will determine whether or not you can make AF_PPPOX work. I don't know the answer to that. As a side note... I've been informed that our favorite PPPoE-using ADSL provider's network architecture (Bell Nexxia) includes PPPoE, L2TP, and PPPoUDP. By that I mean that it is actually possible for you to send a packet which is carried by all of these protocols before it reaches your ISP's IP network (in the case that your ISP is not Sympatico). If your ISP is Sympatico, then you get to skip the PPPoUDP step. Michal Ostrowski mostrows@styx.uwaterloo.ca From owner-netdev@oss.sgi.com Fri Feb 4 16:40:27 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 16:39:53 -0800 Received: from styx.uwaterloo.ca ([129.97.40.10]:60177 "EHLO styx.uwaterloo.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 07:57:48 -0800 Received: (from mostrows@localhost) by styx.uwaterloo.ca (8.9.3/8.9.3) id KAA06835; Fri, 4 Feb 2000 10:56:48 -0500 From: Michal Ostrowski MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14490.63167.969929.894420@styx.uwaterloo.ca> Date: Fri, 4 Feb 2000 10:56:47 -0500 (EST) To: Mark Spencer Cc: jamal , Henner Eisen , netdev@oss.sgi.com, axboe@suse.de, mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Mark Spencer writes: > I've been following your discussion for some time now. The way I did PPP > generically when I implemented it long ago was with a character device. I Do you mean that the PPP daemon always negotiated PPP over a character device? I think we've reached a consensus that pppd should not assume what kind of device it is negotiating over --- and leave that instead to one of the plugins that knows all of the details (e.g.: setting up PPP line discipline for modem connections). Michal Ostrowski mostrows@styx.uwaterloo.ca From owner-netdev@oss.sgi.com Fri Feb 4 16:40:28 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 16:39:53 -0800 Received: from marko.marko.net ([207.13.5.3]:27212 "EHLO marko.marko.net") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 07:15:39 -0800 Received: from localhost (markster@localhost) by marko.marko.net (8.8.7/8.8.7) with ESMTP id KAA13909; Fri, 4 Feb 2000 10:16:45 -0600 Date: Fri, 4 Feb 2000 10:16:45 -0600 (EST) From: Mark Spencer To: jamal cc: Henner Eisen , netdev@oss.sgi.com, axboe@suse.de, mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing I've been following your discussion for some time now. The way I did PPP generically when I implemented it long ago was with a character device. I then used ioctl's on the other technologies to attach their sockets to the PPP devices. An actual channel just implemented a few routines from the PPP layer (like sending and hanging up the PPP channel). In writing the API, I also built up some linkage between channels to standardize how multilink PPP would work, and I would suggest you do the same in your design. Mark From owner-netdev@oss.sgi.com Fri Feb 4 16:40:46 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 16:39:54 -0800 Received: from dhcp41.toaster.net ([199.108.84.41]:24078 "EHLO schmee.sfgoth.com") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 16:11:30 -0800 Received: (from mitch@localhost) by schmee.sfgoth.com (8.9.3/8.9.3) id QAA07614; Fri, 4 Feb 2000 16:11:18 -0800 (PST) Date: Fri, 4 Feb 2000 16:11:18 -0800 From: Mitchell Blank Jr To: jamal Cc: netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X Message-ID: <20000204161118.H6052@sfgoth.com> References: <20000203120127.J72648@sfgoth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from hadi@cyberus.ca on Thu, Feb 03, 2000 at 04:41:47PM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing jamal wrote: > Nobody is suggesting to touch the generic stuff Ok, it wasn't clear to me what was being proposed for 2.3. > Nobody is arguing about that. In 2.2 it is out of question. tty > is the only answer. Why? Instead of going through the effort of individually converting all the PPPoX modules to use tty, why not just backport the channels stuff? Or maybe implement the kernel-land channel API on top of ttys? (ick!) > And just because some protocol needs a mux/demux interface does > not equate it to sockets; have you thought of using netfilter > modules? And why not, since they can provide you with nice mux/demux > interface? Maybe I'm not familiar with netfilter enough, but isn't it just a rules-based engine for matching packets? So if I had, say, 500 PPPoE sessions going we'd have a painful O(n) search through the rules list trying to match the right one. > For PPP over ATM it might actually make sense to do the VCC mux/demux > socket(AF_ATMPVC, SOCK_DGRAM, 0) as you do because you already have the > VCC being mapped to the socket by design. i.e you did not create the > AF_ATMPVC just so that you can do PPP over it unless i am totaly > misunderstading the reasoning behind the AAL5 semantics. That's correct. > mitch >> We are all curently in violent agreement that discovery should be > mitch > in > mitch >> user space (includes Michal). > mitch > > mitch >Then I'll be the violent dissenter, I guess. I don't think > mitch> discovery > mitch >is analagous to ARP (which also has a right to be in the kernel, > IMO).. > mitch >it's more analagous to TCP connect. > > So why dont you move OSPF to the kernel? It has its own addressing, Does it? If it does then I've _never_ seen multiple OSPF sessions coexisting on the same physical network (and I doubt that gated even would support such a thing). OSPF is just a multicast IP protocol, so it makes sense to use generic IP sockets. > mitch >> family, tty device, a new char device etc.? > mitch > > mitch >Depends on the "X" in PPP-o-X! > mitch > > mitch > tty: can talk to a tty device just like now > mitch > PPPoE: new socket family > mitch > PPPoA: ATM_PVC socket > > And what about PPP-over-Frame, PPP over UDP ;-> > Create a new socket family for each? PPP-over-Frame: I'm not familiar with the frame relay support, but I think a reasonable implementation would be a socket family to open a DLCI (analagous to ATM's SOCK_ATMPVC) PPP-over-UDP: Turns out UDP already has its own socket family. Bonus. It's true that L2TP and PPTP might need special-purpose socket family. -Mitch From owner-netdev@oss.sgi.com Fri Feb 4 16:40:46 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 16:39:54 -0800 Received: from marko.marko.net ([207.13.5.3]:65353 "EHLO marko.marko.net") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 15:33:08 -0800 Received: from localhost (markster@localhost) by marko.marko.net (8.8.7/8.8.7) with ESMTP id SAA15344; Fri, 4 Feb 2000 18:34:12 -0600 Date: Fri, 4 Feb 2000 18:34:11 -0600 (EST) From: Mark Spencer To: Michal Ostrowski cc: jamal , Henner Eisen , netdev@oss.sgi.com, axboe@suse.de, mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <14490.63167.969929.894420@styx.uwaterloo.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing > Do you mean that the PPP daemon always negotiated PPP over a character > device? I think we've reached a consensus that pppd should not assume > what kind of device it is negotiating over --- and leave that instead > to one of the plugins that knows all of the details (e.g.: setting up > PPP line discipline for modem connections). pppd would run on /dev/ppp and would negotiate the PPP using that file descriptor. What would actually supply the PPP frames to the kernel (and thus eventually to /dev/ppp) is up to the kernel driver. That's just how I did it. Mark From owner-netdev@oss.sgi.com Fri Feb 4 16:40:47 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 16:39:54 -0800 Received: from styx.uwaterloo.ca ([129.97.40.10]:61713 "EHLO styx.uwaterloo.ca") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 08:03:37 -0800 Received: (from mostrows@localhost) by styx.uwaterloo.ca (8.9.3/8.9.3) id LAA06931; Fri, 4 Feb 2000 11:03:18 -0500 From: Michal Ostrowski MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14490.63558.799600.744802@styx.uwaterloo.ca> Date: Fri, 4 Feb 2000 11:03:18 -0500 (EST) To: jamal Cc: Michal Ostrowski , netdev@oss.sgi.com Subject: Re: RFC: PPP over X In-Reply-To: References: <14490.57346.128709.747580@styx.uwaterloo.ca> X-Mailer: VM 6.72 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing jamal writes: > > I am afraid these are some of the people who were staing that. They > probably want to see if we reach an agreement or not ;-> I am also I hope that they do comment soon, there's some bigger issue involved here than a piddly little protocol. In particular I would like to hear Andi's comments on the maintenance/semantics issues. Regardless of the kernel support, I think we know what needs to be done to pppd (more hooks, wrapping the tty code up as a plugin). Once this is done it's almost trivial to write plugins to support any kind of kernel support for PPPo*. > > I think i have a very good feel to where PPPOE is going. > It is about services -- currently the only service is really access; and i > think that you might end up seeing the discovery part being extended for > some things. I would like to extend it myself and i dont think the > "proprietary tag" they have there already is good enough. > It's disappointing to see that what is really a pretty neat idea has been given such a bad rap by Access Manager (a rather "quirky" windows client). > > > > I don't understand what you mean by this, please elaborate (or refer > > to a specific code fragment). > > > > I was refering to the hashing used. Sorry dont have access to code right > now; > A TCPI/IP flow could be uniquely hashed by the five tuples: src/dst port, > src/dst IP and protocol. > > > My concern is that you need to know something about the protocol to be > > able to identify the flow, since you need to be able to parse the > > packet header and extract those bits that identify the stream. > > And i think every of the PPPOXs will have something unique; so the hashing > is not shareable. That's a huge chunk of the code. I was going through my code trying to identify the PPPoE specific stuff and the somewhat more generic stuff and unfortunately I'm having a very tough time identifying any sizeable portion of the code that could be made generic. Essentially, every time I refer to a pppoe_hdr struct, that's code that's PPPoE specific-- and there's very little code that doesn't do that. I'd like to refer you to my pppoe_bind function -- this is very similar to what a pppoe_connect would look like if the discovery is removed. The primary point of this code is to create a hash-table entry, and thus all of this code is pppoe specific. Hence, if you did have AF_PPPOX, pppox_bind would essentially look something like: pppox_bind(...){ ... return sk->sock_ops->bind(...) } In this case I'm worried that the PPPoX code would simply be there to provide another level of indirection --- and note that the only common code you could have is the code from the system-call side of things. So, here's what I suggest we consider: 1. Rename AF_PPPOE to AF_PPPOX. 2. Define a protocol number PPPOX_ETH for PPPoE --- require that this be used to identifty PPPOE sockets. 3. Define a sockaddr_pppox to be something like: struct sockaddr_pppox { sa_family_t sa_family; /* address family, AF_PPPOX */ unsigned int sa_proto; /* protocol identifier */ union { struct pppoe_addr pppoe; } sa_proto_data; /* protocol data */ } 4. Add appropriate checks to the AF_PPPOE code to ensure that it is being used with AF_PPPOX semantics (that is check that the user is correctly specifying the protocol where applicable). What this will do is create an AF_PPPOX interface that is flexible --- when we want to define other protocols we simply add stuff to the union. This way we get to keep binary compatibility with code that was compiled to use PPPOE, and we get to add protocols as appropriate. Each protocol gets to use whatever addressing scheme it requires. When it comes time to actually implement these other protocols, that's when we start working on seperating out protocol specific code (as is done with AF_INET). The point of this is that we won't know exactly how that is to be done until we have other protocols to work with. > > I'll take a look at L2TP sometime this evening or sometime tommorow. > You can easily figure the ATM one (or i could look at that too). > I'll take a peek at the ATM code (or perhaps some of the PPPoATM guys would care to comment). > > > Hmm... I know someone who is doing PPPTP over PPPOE ;-> > I do tunnel over IPSEC to work via PPPOE myself;-> > I think you'll see a lot of these VPNish types offered as services; > You discover them, you select based on pricing, QoS paramaters etc; doesnt > matter what the "ISP today" is. I split my user space code into some sort > of libraries -- still in very primitive stages so that i can easily stash > GUIs etc in anticipation of this. So in the very near future this will > start happening, if the CRTC gets its rulings imposed. You ask for access > service, 10 ISPs respond with their AC names and a few other parameters. Mitch: That's the perfect example of why it's very hard to do proper negotiation in kernel-space. We'd like to be able to present the user with a funky GUI plugin which they can use to select their ISP. This would mean that we'd probably have to break out of the middle of a "connect" syscall in some way. Michal Ostrowski mostrows@styx.uwaterloo.ca From owner-netdev@oss.sgi.com Fri Feb 4 17:21:47 2000 Received: by oss.sgi.com id ; Fri, 4 Feb 2000 17:21:27 -0800 Received: from internal.nci.com.au ([203.38.215.137]:6168 "EHLO ncigw.nci.com.au") by oss.sgi.com with ESMTP id ; Fri, 4 Feb 2000 17:21:05 -0800 Received: from w95vmware.ns.com (ppp2.nci.com.au [172.30.0.162]) by ncigw.nci.com.au (8.8.7/8.8.7) with SMTP id LAA11070 for ; Sat, 5 Feb 2000 11:52:29 +1030 Message-Id: <3.0.6.32.20000205020902.008ce5a0@203.16.214.248> X-Sender: ns@203.16.214.248 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Sat, 05 Feb 2000 02:09:02 +1000 To: netdev@oss.sgi.com From: Richard Sharpe Subject: Re: RFC: PPP over X In-Reply-To: <20000204161118.H6052@sfgoth.com> References: <20000203120127.J72648@sfgoth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi, my remarks here nodoubt come out of left field, and are not related to any of the original discussion, but in the Ethereal Team, we have a problem with PPP over serial ports. The problem is that we do not get to see any of the PPP 'frames', we only see IP datagrams. If there is a rewrite or big changes coming for 2.3, has any thought been given to providing a way to inject raw frames into the appropriate places in the kernel so libpcap can capture them, and thus we can see them in ethereal. I hope that this is not too far off from your interests. Regards ------- Richard Sharpe, sharpe@ns.aus.com, Master Linux Administrator :-), Samba (Team member, www.samba.org), Ethereal (Team member, www.zing.org) Co-author, SAMS Teach Yourself Samba in 24 Hours Author: First Australian 5-day, intensive, hands-on Linux SysAdmin course From owner-netdev@oss.sgi.com Sat Feb 5 13:37:13 2000 Received: by oss.sgi.com id ; Sat, 5 Feb 2000 13:36:54 -0800 Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:17162 "EHLO grok.myip.org") by oss.sgi.com with ESMTP id ; Sat, 5 Feb 2000 13:36:39 -0800 Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1]) by grok.myip.org (8.9.3/8.9.3) with ESMTP id OAA00711 for ; Sat, 5 Feb 2000 14:58:52 -0700 Message-ID: <389C9D1C.9280AA96@candelatech.com> Date: Sat, 05 Feb 2000 14:58:52 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: "netdev@oss.sgi.com" Subject: Question on SOCK_PACKET Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing I'm building a test protocol that will write directly to the ethernet driver using the SOCK_PACKET socket type. However, I'm seeing something a little wierd. I write a pkt of 1036 bytes, but when I read off of the receiving port (on the other machine), I read 1040 bytes. All bytes seem to be the same, except that there are 4 extra ones tacked onto the end. I'm suspicious that they might be an ethernet checksum. Can anyone confirm this, or provide any other ideas? Thanks, Ben -- Ben Greear (greearb@candelatech.com) http://scry.wanfear.com/~greear Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL) http://scry.wanfear.com From owner-netdev@oss.sgi.com Sat Feb 5 22:01:10 2000 Received: by oss.sgi.com id ; Sat, 5 Feb 2000 22:01:01 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:23568 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Sat, 5 Feb 2000 22:00:47 -0800 Received: (from paulus@localhost) by front.linuxcare.com.au (8.9.3/8.9.3/Debian/GNU) id QAA29863; Sun, 6 Feb 2000 16:59:55 +1100 From: Paul Mackerras Organization: Linuxcare, Inc. To: jamal , Michal Ostrowski , Mitchell Blank Jr , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Ben LaHaise Subject: Re: RFC: PPP over X Date: Sun, 6 Feb 2000 16:39:09 +1100 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain References: MIME-Version: 1.0 Message-Id: <00020616582804.06510@argo.linuxcare.com.au> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Fri, 04 Feb 2000, jamal wrote: > hehe. Same here. Havent heard from Mark Spencer or Paul Mackerras. It > would be nice to hear from them. Yes, sorry I haven't jumped in earlier. Here's what I think: - Forget the old (2.2) ppp driver, we'll backport the 2.3 driver to 2.2 rather than doing major surgery to the 2.2 driver. - At the moment, with the channels stuff, pppd needs to be able to have a fd to each channel which it can do read/write/poll/ioctl on, and the channel has to specify which ppp unit it is to be attached to when it is registered. I now think that we should do it a bit differently in order to minimize the amount of duplicated code in each channel. In order to be able to do multilink, pppd needs to be able to talk to each channel separately as well as to the ppp unit (which represents a bundle), and this is why pppd needs to be able to do read/write/poll on the channel. I plan to rearrange the code so that it will instead talk to the channel through an open instance of /dev/ppp. We'll make it so that when a channel registers itself, it gets given a channel number which can be passed to pppd. Pppd will open /dev/ppp and use an ioctl to connect that instance to the channel. It can then use another ioctl to connect that channel to a ppp unit. This way, pppd doesn't have to know how to get hold of a file descriptor for talking directly to a channel, it just needs to know the channel number. We can then either have a separate program for the discovery or have a plugin to do the discovery. If we have a separate program, it just needs to tell pppd the channel number (there are several ways we can do this, e.g. via connect/disconnect scripts, or the discovery program invoking pppd, or the discovery program can talk to pppd through a pair of pipes or a socket). Probably there should be a UID associated with the channel to make sure I can't steal the channel you just set up. - I plan to pull out the async encapsulation stuff into a library so that other channels can use it too. Thus ppp_async.c should end up with very little in it other than stuff for implementing the line discipline and talking to the serial driver. - I am not so keen on the idea of having one process handling thousands of connections - don't poll and select get very inefficient if you have thousands of file descriptors? With that many fds, not only does the setup cost rise, but the poll/select will wait for a shorter time on average, so you pay the setup cost more often. On the other hand, having a thousand daemons means 8MB of kernel space gone just for the kernel stacks and process structures. We should maybe ask Alan Cox what the best compromise is. Certainly for moderate numbers of connections the process-per-connection model is good - if the daemon dies, you only lose one connection, and if you want to kill a connection, there is an identifiable process to send a signal to. I hope to spend a fair bit of the coming week on ppp hacking. :-) Paul. -- Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax paulus@linuxcare.com.au, http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. From owner-netdev@oss.sgi.com Sun Feb 6 05:39:40 2000 Received: by oss.sgi.com id ; Sun, 6 Feb 2000 05:39:30 -0800 Received: from dhcp41.toaster.net ([199.108.84.41]:55556 "EHLO schmee.sfgoth.com") by oss.sgi.com with ESMTP id ; Sun, 6 Feb 2000 05:39:06 -0800 Received: (from mitch@localhost) by schmee.sfgoth.com (8.9.3/8.9.3) id FAA27617; Sun, 6 Feb 2000 05:38:20 -0800 (PST) Date: Sun, 6 Feb 2000 05:38:20 -0800 From: Mitchell Blank Jr To: Paul Mackerras Cc: jamal , Michal Ostrowski , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Ben LaHaise Subject: Re: RFC: PPP over X Message-ID: <20000206053819.X9170@sfgoth.com> References: <00020616582804.06510@argo.linuxcare.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <00020616582804.06510@argo.linuxcare.com.au>; from paulus@linuxcare.com on Sun, Feb 06, 2000 at 04:39:09PM +1100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Paul Mackerras wrote: > In order to be able to do multilink, pppd needs to be able to talk to each > channel separately as well as to the ppp unit (which represents a bundle), Could a single connection to the ppp unit represent multiple unrelated bundles? > This way, pppd doesn't have to know how to get hold of a file descriptor > for talking directly to a channel, it just needs to know the channel > number. I don't think this is a big deal - for many potential transports, its perfectly natural to operate on them as a file descriptor. Making the kernel grab it (instead of going through the normal open(2) path) will only complicate matters. Then again, I'm of the opinion that adding new socket families for new pure-PPP transports (PPPoE being the obvious one) is No Big Deal(tm), which doesn't seem to be the common viewpoint around here. As for teaching pppd to "get hold of a file descriptor" I worked a lot today at making that stuff modular... I've still got a little work to do, but I'll share a patch with the rest of the class tommorrow. Hopefully you'll find it fit for inclusion with the next pppd, which will make PPPoATM and PPPoE at least a lot easier to install. > Probably there should be a UID associated with the > channel to make sure I can't steal the channel you just set up. Its things like this that make me really like the socket-family model. When you have a file descriptor you have a nice automatically reference- counted token that you can pass among user-space programs. > - I plan to pull out the async encapsulation stuff into a library so that > other channels can use it too. What of the async encapsulation stuff is needed by other channel types? Most of the obvious ones (PPPoATM, PPPoE, PPTP, L2TP) are packet-based and won't need any of that code at all. I can't think of any other encapsulations that would need control-character escaping and the like. > - I am not so keen on the idea of having one process handling thousands of > connections - don't poll and select get very inefficient if you have > thousands of file descriptors? Yes, but an async-signal+poll method can deal with tens of thousands of fds quite comfortably. > With that many fds, not only does the > setup cost rise, No per-loop setup costs with a signal-based model. The only time you need to fall back on a poll is in the unlikely event that you've overflowed the signal queue - in that case you probably have loads of fds that need servicing, so poll is actually rather efficient. > On the other hand, having > a thousand daemons means 8MB of kernel space gone just for the kernel > stacks and process structures. Exactly. Plus managing shared resources like dyanmic IP pools is tricker. -Mitch From owner-netdev@oss.sgi.com Sun Feb 6 08:41:11 2000 Received: by oss.sgi.com id ; Sun, 6 Feb 2000 08:41:01 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:30132 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Sun, 6 Feb 2000 08:40:51 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id LAA19588; Sun, 6 Feb 2000 11:40:50 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id LAA01055; Sun, 6 Feb 2000 11:40:49 -0500 (EST) Date: Sun, 6 Feb 2000 11:40:49 -0500 (EST) From: jamal To: Michal Ostrowski cc: netdev@oss.sgi.com Subject: Re: RFC: PPP over X In-Reply-To: <14490.63558.799600.744802@styx.uwaterloo.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Fri, 4 Feb 2000, Michal Ostrowski wrote: > I hope that they do comment soon, there's some bigger issue involved > here than a piddly little protocol. In particular I would like to I think we are almost reaching a consensus. And no news means good news ;-> > Regardless of the kernel support, I think we know what needs to be > done to pppd (more hooks, wrapping the tty code up as a plugin). Once > this is done it's almost trivial to write plugins to support any kind > of kernel support for PPPo*. > Nod > That's a huge chunk of the code. I was going through my code trying > to identify the PPPoE specific stuff and the somewhat more generic > stuff and unfortunately I'm having a very tough time identifying any > sizeable portion of the code that could be made generic. Essentially, > every time I refer to a pppoe_hdr struct, that's code that's PPPoE > specific-- and there's very little code that doesn't do that. > Thats because you were thinking PPPOE when you wrote that code; think PPPOX now ;-> > I'd like to refer you to my pppoe_bind function -- this is very > similar to what a pppoe_connect would look like if the discovery is > removed. The primary point of this code is to create a hash-table > entry, and thus all of this code is pppoe specific. Hence, if you did > have AF_PPPOX, pppox_bind would essentially look something like: > > pppox_bind(...){ > ... > return sk->sock_ops->bind(...) > } > > In this case I'm worried that the PPPoX code would simply be there to > provide another level of indirection --- and note that the only common You can call it indirection or a wrapper; the point is you dont have to right that particular piece of code for every one of them, I dont think you'll be loosing any speed (or if you do it wont be that much). > code you could have is the code from the system-call side of things. > > So, here's what I suggest we consider: > > 1. Rename AF_PPPOE to AF_PPPOX. > > 2. Define a protocol number PPPOX_ETH for PPPoE --- require that this be > used to identifty PPPOE sockets. > > 3. Define a sockaddr_pppox to be something like: > > struct sockaddr_pppox { > sa_family_t sa_family; /* address family, AF_PPPOX */ > unsigned int sa_proto; /* protocol identifier */ > union { > struct pppoe_addr pppoe; > } sa_proto_data; /* protocol data */ > } > > 4. Add appropriate checks to the AF_PPPOE code to ensure that it is > being used with AF_PPPOX semantics (that is check that the user is > correctly specifying the protocol where applicable). > Sounds like a plan to me. > What this will do is create an AF_PPPOX interface that is flexible --- > when we want to define other protocols we simply add stuff to the union. > Yes. > This way we get to keep binary compatibility with code that was > compiled to use PPPOE, and we get to add protocols as appropriate. > Each protocol gets to use whatever addressing scheme it requires. > You are thinking PPPOX ;-> > When it comes time to actually implement these other protocols, that's > when we start working on seperating out protocol specific code (as is > done with AF_INET). The point of this is that we won't know exactly > how that is to be done until we have other protocols to work with. > true. But we should provide as much genericity with the current code as we can. We can always rip it off in 2.5 when we learn more from this experience. > Mitch: > > That's the perfect example of why it's very hard to do proper > negotiation in kernel-space. We'd like to be able to present the user > with a funky GUI plugin which they can use to select their ISP. This > would mean that we'd probably have to break out of the middle of a > "connect" syscall in some way. > Thanks for pointing this out. cheers jamal From owner-netdev@oss.sgi.com Sun Feb 6 08:44:22 2000 Received: by oss.sgi.com id ; Sun, 6 Feb 2000 08:44:12 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:18613 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Sun, 6 Feb 2000 08:44:03 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id LAA20345; Sun, 6 Feb 2000 11:43:55 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id LAA01068; Sun, 6 Feb 2000 11:43:54 -0500 (EST) Date: Sun, 6 Feb 2000 11:43:53 -0500 (EST) From: jamal To: Mark Spencer cc: Michal Ostrowski , Henner Eisen , netdev@oss.sgi.com, axboe@suse.de, mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Mark, I know you said that this is just the way "you did it"; Is there a good reason as to why you did it this way (other than probably the code being smaller)? In particular with the Multi-PPP, how does it provide an advantage? You mention some relationship between the channels for MPPP; i just dont think that exists today; Mind to comment please (and whether moving to the socket interface will screw this grand scheme of things) cheers jamal On Fri, 4 Feb 2000, Mark Spencer wrote: > > Do you mean that the PPP daemon always negotiated PPP over a character > > device? I think we've reached a consensus that pppd should not assume > > what kind of device it is negotiating over --- and leave that instead > > to one of the plugins that knows all of the details (e.g.: setting up > > PPP line discipline for modem connections). > > pppd would run on /dev/ppp and would negotiate the PPP using that file > descriptor. What would actually supply the PPP frames to the kernel (and > thus eventually to /dev/ppp) is up to the kernel driver. > > That's just how I did it. > > Mark > From owner-netdev@oss.sgi.com Sun Feb 6 09:06:22 2000 Received: by oss.sgi.com id ; Sun, 6 Feb 2000 09:06:12 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:27841 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Sun, 6 Feb 2000 09:05:53 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id MAA29173; Sun, 6 Feb 2000 12:05:37 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id MAA01099; Sun, 6 Feb 2000 12:05:38 -0500 (EST) Date: Sun, 6 Feb 2000 12:05:37 -0500 (EST) From: jamal To: Mitchell Blank Jr cc: netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <20000204161118.H6052@sfgoth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Fri, 4 Feb 2000, Mitchell Blank Jr wrote: > jamal wrote: > Ok, it wasn't clear to me what was being proposed for 2.3. > > > Nobody is arguing about that. In 2.2 it is out of question. tty > > is the only answer. > > Why? Instead of going through the effort of individually converting > all the PPPoX modules to use tty, why not just backport the > channels stuff? Or maybe implement the kernel-land channel API > on top of ttys? (ick!) > Backporting sounds like a huge pain to me. And would this be a separate patch or part of the kernel proper? 2.2 is considered to be a stable release. > > Maybe I'm not familiar with netfilter enough, but isn't it just > a rules-based engine for matching packets? So if I had, say, 500 > PPPoE sessions going we'd have a painful O(n) search through the > rules list trying to match the right one. I am not sure about the exact details of the implementation, but O(n) or not -- this is another way it could be done. It is not very smart, but it is an alternative; thats the point i was trying to make. (BTW, I think this is the way the BSDs did it ;-> ) > > mitch >> We are all curently in violent agreement that discovery should be > > mitch > in > > mitch >> user space (includes Michal). > > So why dont you move OSPF to the kernel? It has its own addressing, > > Does it? If it does then I've _never_ seen multiple OSPF sessions > coexisting on the same physical network (and I doubt that gated even > would support such a thing). OSPF is just a multicast IP protocol, > so it makes sense to use generic IP sockets. TCP is another IP protocol; so is OSPF. And sure OSPF can have unicast addressing -- Point to point circuits use unicast; look at the specs, and maybe look again at gated. Even if it was just multicast alone, you could create a sockaddr struct and put OSPF in the kernel. I think that signalling/discovery protocols tend to be very rich and sometimes dynamically changing; they dont affect the fast path of the data flow therefore they dont need to be in the kernel -- they'll bloat it for no good reason. TCP is the most used protocol. When you have that many people using the protocol, it is fair to move it down. Mass use however, by itself is not a good reason either. Moving a protocol to kernel sometimes could have its consequences (look at the khttp dicussions in l-k archives). You have to weigh a lot of options before making such a choice. cheers, jamal From owner-netdev@oss.sgi.com Sun Feb 6 09:28:22 2000 Received: by oss.sgi.com id ; Sun, 6 Feb 2000 09:28:13 -0800 Received: from marko.marko.net ([207.13.5.3]:50244 "EHLO marko.marko.net") by oss.sgi.com with ESMTP id ; Sun, 6 Feb 2000 09:27:55 -0800 Received: from localhost (markster@localhost) by marko.marko.net (8.8.7/8.8.7) with ESMTP id MAA14946; Sun, 6 Feb 2000 12:28:43 -0600 Date: Sun, 6 Feb 2000 12:28:42 -0600 (EST) From: Mark Spencer To: jamal cc: Michal Ostrowski , Henner Eisen , netdev@oss.sgi.com, axboe@suse.de, mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing > Is there a good reason as to why you did it this way (other than probably > the code being smaller)? It fit in well with the current pppd model. > In particular with the Multi-PPP, how does it provide an advantage? I put some mechanisms in the kernel to use the two parameters provided by the MPPP spec to decide which should bundle, and provided an override capability for pppd, if so desired. I really don't think that the userspace programs should have to confer with one another to decide who should go in an MP bundle. My method allowed any pppd to know whether it was a master or a slave channel and the kernel could dynamically add and drop channels to/from a bundle. > You mention some relationship between the channels for MPPP; i just dont > think that exists today; My patches were accepted but never applied, and (being a novice) I did not continue to submit them beyond the first time. > Mind to comment please (and whether moving to the socket interface > will screw this grand scheme of things) I really just don't see the socket advantage. What's missing here is a clear description for just what it is we're looking to accomplish, and a good model for designing such a system. For example, consider L2TP... As an LNS, I want to read PPP frames from a network socket (with l2tp encapsulation) and then send them to the network layer or a pppd. The most likely scenario I can see for that is to create a socket, then call some ioctl()'s to make the kernel aware of new connections and such. Then I need a way to apply those to PPP channels, and launch a pppd to handle the negotiations. We want the datapath within the kernel to be fast (no copies). Now, if I'm a LAC, I want to copy PPP frames from a device (say, a tty or ISDN driver, or even another pppd) to my L2TP socket... Can this also be done with a kernel datapath? My API didn't really have a mechanism for doing so, but it would be nice if the new one did. Mark p.s. Would you like me to setup a mailing list for this? I've got majordomo and it wouldn't take me but a few minutes to do so. From owner-netdev@oss.sgi.com Sun Feb 6 09:30:21 2000 Received: by oss.sgi.com id ; Sun, 6 Feb 2000 09:30:11 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:3021 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Sun, 6 Feb 2000 09:29:57 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id MAA08443; Sun, 6 Feb 2000 12:29:45 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id MAA01124; Sun, 6 Feb 2000 12:29:46 -0500 (EST) Date: Sun, 6 Feb 2000 12:29:46 -0500 (EST) From: jamal To: Paul Mackerras cc: Michal Ostrowski , Mitchell Blank Jr , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <00020616582804.06510@argo.linuxcare.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Sun, 6 Feb 2000, Paul Mackerras wrote: > - Forget the old (2.2) ppp driver, we'll backport the 2.3 driver to 2.2 > rather than doing major surgery to the 2.2 driver. > This looks like a lot of work to me. And doing this kind of thing on a stable release might not be a very good idea either. In a few months (less than 4?) we'll probably be moving to 2.4 > - At the moment, with the channels stuff, pppd needs to be able to have a > fd to each channel which it can do read/write/poll/ioctl on, and the > channel has to specify which ppp unit it is to be attached to when it is > registered. I now think that we should do it a bit differently in order > to minimize the amount of duplicated code in each channel. > > In order to be able to do multilink, pppd needs to be able to talk to each > channel separately as well as to the ppp unit (which represents a bundle), > and this is why pppd needs to be able to do read/write/poll on the channel. > I plan to rearrange the code so that it will instead talk to the channel > through an open instance of /dev/ppp. We'll make it so that when a channel > registers itself, it gets given a channel number which can be passed to > pppd. Pppd will open /dev/ppp and use an ioctl to connect that instance > to the channel. It can then use another ioctl to connect that channel to > a ppp unit. > Sounds like a good plan but quiet involved. Mark would you please comment? > This way, pppd doesn't have to know how to get hold of a file descriptor > for talking directly to a channel, it just needs to know the channel > number. We can then either have a separate program for the discovery or > have a plugin to do the discovery. If we have a separate program, it > just needs to tell pppd the channel number (there are several ways we can > do this, e.g. via connect/disconnect scripts, or the discovery program > invoking pppd, or the discovery program can talk to pppd through a pair of > pipes or a socket). Probably there should be a UID associated with the > channel to make sure I can't steal the channel you just set up. Locking inside the kernel will help instead of UID i.e make the channel grabbing atomic; if the channel is grabbed its state changes to "grabbed"; this could be also interpreted as a refcount; on close or detach it goes back to "available" state. > - I plan to pull out the async encapsulation stuff into a library so that > other channels can use it too. Thus ppp_async.c should end up with very > little in it other than stuff for implementing the line discipline and > talking to the serial driver. fantastic. I thought it was already a module by itself. > - I am not so keen on the idea of having one process handling thousands of > connections - don't poll and select get very inefficient if you have > thousands of file descriptors? With that many fds, not only does the > setup cost rise, but the poll/select will wait for a shorter time on > average, so you pay the setup cost more often. On the other hand, having > a thousand daemons means 8MB of kernel space gone just for the kernel > stacks and process structures. We should maybe ask Alan Cox what the best > compromise is. > I take it you are refering about the way the new pppd should handle this increase in fds (you shouldnt have to worry about the pppoxs). Wouldnt that be a single daemon? For PPPOE running in server mode i see a lot of connections; so the usual "scalable server" techniques apply. I would expect one pppoed to handle all of them i.e pppd will only have to worry about the connection setup and teardown and not any other event. Select is probably good enough; poll will most likely be an overkill. Just off the top of my head. > Certainly for moderate numbers of connections the process-per-connection > model is good - if the daemon dies, you only lose one connection, and if > you want to kill a connection, there is an identifiable process to send a > signal to. > > I hope to spend a fair bit of the coming week on ppp hacking. :-) > I think other than the back porting i agree with everything you say. My opinion is that we should have pppd separate from the pppoxds; in the beggining until they stabilise, the pppoxds should be maintained separately; i am agnostic to the fact it could be a plugin or connect/disconnect. cheers jamal From owner-netdev@oss.sgi.com Sun Feb 6 09:38:42 2000 Received: by oss.sgi.com id ; Sun, 6 Feb 2000 09:38:32 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:24784 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Sun, 6 Feb 2000 09:38:29 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id MAA11150; Sun, 6 Feb 2000 12:38:17 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id MAA01133; Sun, 6 Feb 2000 12:38:18 -0500 (EST) Date: Sun, 6 Feb 2000 12:38:18 -0500 (EST) From: jamal To: Mitchell Blank Jr cc: Paul Mackerras , Michal Ostrowski , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <20000206053819.X9170@sfgoth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Sun, 6 Feb 2000, Mitchell Blank Jr wrote: > As for teaching pppd to "get hold of a file descriptor" I worked a lot > today at making that stuff modular... I've still got a little work > to do, but I'll share a patch with the rest of the class tommorrow. > Hopefully you'll find it fit for inclusion with the next pppd, which > will make PPPoATM and PPPoE at least a lot easier to install. While this is generally a good idea, maybe we should agree on the flow/semantics first? > > Probably there should be a UID associated with the > > channel to make sure I can't steal the channel you just set up. > > Its things like this that make me really like the socket-family model. > When you have a file descriptor you have a nice automatically reference- > counted token that you can pass among user-space programs. > socket ref counts dont protect you from someone else grabbing the ppp channel from underneath you ;-> It should be trivial to add refcounting to the chanels. cheers, jamal From owner-netdev@oss.sgi.com Sun Feb 6 11:03:13 2000 Received: by oss.sgi.com id ; Sun, 6 Feb 2000 11:03:03 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:12781 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Sun, 6 Feb 2000 11:02:48 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id OAA06267; Sun, 6 Feb 2000 14:02:40 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id OAA01168; Sun, 6 Feb 2000 14:02:41 -0500 (EST) Date: Sun, 6 Feb 2000 14:02:41 -0500 (EST) From: jamal To: Mark Spencer cc: Michal Ostrowski , Henner Eisen , netdev@oss.sgi.com, axboe@suse.de, mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Sun, 6 Feb 2000, Mark Spencer wrote: > > Is there a good reason as to why you did it this way (other than probably > > the code being smaller)? > > It fit in well with the current pppd model. > Ok. > > In particular with the Multi-PPP, how does it provide an advantage? > > I put some mechanisms in the kernel to use the two parameters provided by > the MPPP spec to decide which should bundle, and provided an override > capability for pppd, if so desired. I really don't think that the > userspace programs should have to confer with one another to decide who > should go in an MP bundle. > > My method allowed any pppd to know whether it was a master or a slave > channel and the kernel could dynamically add and drop channels to/from a > bundle. > I think Paul is the best person to respond to this; my knowledge of MPPP is rather basic. > > Mind to comment please (and whether moving to the socket interface > > will screw this grand scheme of things) > > I really just don't see the socket advantage. What's missing here is a > clear description for just what it is we're looking to accomplish, and a > good model for designing such a system. For example, consider L2TP... As > an LNS, I want to read PPP frames from a network socket (with l2tp > encapsulation) and then send them to the network layer or a pppd. The > most likely scenario I can see for that is to create a socket, then call > some ioctl()'s to make the kernel aware of new connections and such. Then > I need a way to apply those to PPP channels, and launch a pppd to handle > the negotiations. We want the datapath within the kernel to be fast (no > copies). It can be done in the kernel. The control should be downloadble via the PPPOX interface (whether sockets or character devices) e.g. mapping of the ppp channels etc. You should be able to add a local_in netfilter hook to grab incoming UDP packets and filter them for L2TP headers; massage them for the next output interface (eg remove L2TP headers and stash PPP headers or FR headers etc ) and then shove them out that interface. > Now, if I'm a LAC, I want to copy PPP frames from a device (say, a tty or > ISDN driver, or even another pppd) to my L2TP socket... Can this also be > done with a kernel datapath? My API didn't really have a mechanism for > doing so, but it would be nice if the new one did. Yes. Assuming of course that the devices you are reading from are network devices. Otherwise it becomes a little more complex. Currently the add_pack API is for layer 2 protocols only eg PPPOE fits fine there for incoming packets since it reads from ethernet L2TP over PPP, FR, ATM etc i believe should work the same way. If not via add_pack then maybe over something else similar for ATM or FR etc. You will have to write the data-shunting interface to UDP; i.e open and close sockets from within the kernel and then bind them to a channel (Michal had a good example os the sock->bind() interface established during the "call connect"). So in essence via the generic interface (pppox) you should be able to send control information to select LNS vs LAC and what API to register for receive and transmit which also do the encode/decode; and all these could be modules. > Mark > > p.s. Would you like me to setup a mailing list for this? I've got > majordomo and it wouldn't take me but a few minutes to do so. > I dont know what others think. If people in netdev are getting upset maybe we should move. cheers, jamal From owner-netdev@oss.sgi.com Mon Feb 7 03:53:03 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 03:52:54 -0800 Received: from iabgfw.iabg.de ([194.139.245.2]:12453 "EHLO iabgfw.iabg.de") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 03:52:34 -0800 Received: by iabgfw.iabg.de; id MAA18993; Mon, 7 Feb 2000 12:52:25 +0100 (MET) Received: from iabgmh.iabg.de(10.255.255.2) by iabgfw.iabg.de via smap (V4.2) id xma018907; Mon, 7 Feb 00 12:52:14 +0100 Received: from iabgvw.iabg.de ([10.255.255.8]) by iabgmh.iabg.de (Post.Office MTA v3.5.1 release 219 ID# 127-59214U1600L300S0V35) with ESMTP id de; Mon, 7 Feb 2000 12:52:13 +0100 Received: from iabgdns.iabg.de (localhost [127.0.0.1]) by iabgvw.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id MAA14998; Mon, 7 Feb 2000 12:52:13 +0100 (MET) Received: from iabg.de (cc31pc12.iabg.de [10.3.0.20]) by iabgdns.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id MAA09985; Mon, 7 Feb 2000 12:52:12 +0100 (MET) Message-ID: <389EB1EC.600FEA6A@iabg.de> Date: Mon, 07 Feb 2000 12:52:12 +0100 From: Gerhard Gessler Organization: IABG mbH X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: netfilter@samba.org, netdev@oss.sgi.com Subject: IPv6 + AH + ESP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi all, I would like to know whether somebody is working on integrating AH and ESP into the IPv6 networking part of Linux. Is this possible via a netfilter module? Are there already plans / actions to do this? Thank you in advance, Gerhard From owner-netdev@oss.sgi.com Mon Feb 7 05:17:56 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 05:17:35 -0800 Received: from alcove.wittsend.com ([130.205.0.20]:11533 "EHLO alcove.wittsend.com") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 05:17:17 -0800 Received: (from mhw@localhost) by alcove.wittsend.com (8.9.3/8.9.3) id IAA10907; Mon, 7 Feb 2000 08:17:04 -0500 Date: Mon, 7 Feb 2000 08:17:03 -0500 From: "Michael H. Warfield" To: Gerhard Gessler Cc: netfilter@samba.org, netdev@oss.sgi.com Subject: Re: IPv6 + AH + ESP Message-ID: <20000207081703.K20611@alcove.wittsend.com> References: <389EB1EC.600FEA6A@iabg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <389EB1EC.600FEA6A@iabg.de>; from gessler@iabg.de on Mon, Feb 07, 2000 at 12:52:12PM +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Mon, Feb 07, 2000 at 12:52:12PM +0100, Gerhard Gessler wrote: > Hi all, > I would like to know whether somebody is working on integrating AH and > ESP into the IPv6 networking part of Linux. Is this possible via a > netfilter module? Are there already plans / actions to do this? Could you refine that question a bit? Are you asking if someone is doing IPSec (AH and ESP) on IPv6? Then the answer is definitely yes. This is being done as part of the FreeSwan project . As far as doing it via the netfilter module... It's not being done that way at this time. I believe, however, that they are intending to migrate the KLIPS (Kernel Level IPSec code) to using some of the netfilter hooks in the future. If you are asking if netfilter is going to support filtering based on AH and ESP headers, I would think that it could already do that. If you are asking if netfilter will filter something like tcp that is encapsulated by ESP and AH the answer would be "it depends". Netfilter can't get at the ESP encrypted payload so it can't filter based on the tcp port unless the IPSec tunnel terminals and is decrypted on the netfilter system. If the ESP encryption is ESPNULL or it only contains AH headers, then this is possible and is no different than any other non-encrypted tunnel (other than the option headers). > Thank you in advance, > Gerhard Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-netdev@oss.sgi.com Mon Feb 7 13:09:49 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 13:09:29 -0800 Received: from kogge.hanse.de ([192.76.134.17]:61190 "EHLO kogge.Hanse.DE") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 13:09:18 -0800 Received: (from uucp@localhost) by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id WAA53730; Mon, 7 Feb 2000 22:08:34 +0100 (CET) (envelope-from eis@baty.hanse.de) Received: (from eis@localhost) by baty.hanse.de (8.9.3/8.9.3) id UAA31408; Mon, 7 Feb 2000 20:06:17 +0100 To: Mitchell Blank Jr Cc: Paul Mackerras , jamal , Michal Ostrowski , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Ben LaHaise Subject: Re: RFC: PPP over X References: <00020616582804.06510@argo.linuxcare.com.au> <20000206053819.X9170@sfgoth.com> From: Henner Eisen Date: 07 Feb 2000 20:06:17 +0100 In-Reply-To: Mitchell Blank Jr's message of "Sun, 6 Feb 2000 05:38:20 -0800" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >>>>> "Mitchell" == Mitchell Blank writes: Mitchell> Could a single connection to the ppp unit represent Mitchell> multiple unrelated bundles? Don't know whether this is already implemented in the generic ppp code. But isdn ppp (doesn't use the generic ppp yet) has allways done it like this and I'm not aware of any problem reports related to this. That might be the best proof that the concept is correct. Henner From owner-netdev@oss.sgi.com Mon Feb 7 13:12:48 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 13:12:28 -0800 Received: from kogge.hanse.de ([192.76.134.17]:64262 "EHLO kogge.Hanse.DE") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 13:12:19 -0800 Received: (from uucp@localhost) by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id WAA53862; Mon, 7 Feb 2000 22:12:01 +0100 (CET) (envelope-from eis@baty.hanse.de) Received: (from eis@localhost) by baty.hanse.de (8.9.3/8.9.3) id TAA31340; Mon, 7 Feb 2000 19:25:04 +0100 To: Michal Ostrowski Cc: jamal , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X References: <14490.2881.979155.516130@styx.uwaterloo.ca> From: Henner Eisen Date: 07 Feb 2000 19:25:04 +0100 In-Reply-To: Michal Ostrowski's message of "Thu, 3 Feb 2000 18:12:01 -0500 (EST)" Message-ID: Lines: 118 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >>>>> "Michal" == Michal Ostrowski writes: Michal> Henner Eisen writes: >> ppp connections would be set up like this: >> >> - pppd creates socket corresponding to ppp carrier, e.g. PPP >> over ethernet: s = socket(PF_PACKET,SOCK_PACKET,ETH_P_PPPOE); Michal> The problem here is that you need to use bind and/or Michal> connect (regardless of where negotiation is performed), Michal> and you need to do with a sockaddr that is not compatible Michal> with PF_PACKET. It is this need for an addressing scheme Michal> which is unique to PPPoE that made me go with PF_PPPOE. Michal> Modifying PF_PACKET to make exceptions and support Michal> "protocols" that have different addressing schemes would Michal> be rather grotesque. Yes, I agree. I think I have to clarify my arguments, because I never wanted to suggest hacking PF_PACKET in such a way: The design in mind was the following: : user space : : : +------+ : +-------+ ppp protocol | pppd | - /dev/ppp - | ppp | proper +------+ : +-------+ | : | | : | socket | : +-----------+ ppp over X ...interface =========== .....: | encap X | frame encapsulation | +-----------+ protocol | | +----------+------------+ | | +-----------------+ | carrier | | protocol | | PF_X | +-----------------+ kernel space `Carrier protocol' denotes the protocol that carries the (encapsulated) ppp packets (not some low/physical layer stuff). With the generic ppp module in 2.3.x, we've got already the ppp protocol module. With the various PF_X as implemented in /usr/src/linux/net/* we've also got the implementation of several carrier protocols as well. What's missing is a generic method of processing the ppp frame encapsulation protocol contents and a generic mechanism to connect such an encapsulation protocol engine to the upper layer of the carrier protocol. For all socket of type SOCK_PACKET and SOCK_SEQ_PACKET, the latter can probably be implementeted in a generic manner. (Most SOCK_PACKET and SOCK_SEQPACKET implementations share a single poll method, and it seems that all sockets which use /usr/src/linux/net/core/datagram.c::datagram_poll() could be attached to a ppp frame encapsulation protocol generically as well). There is nothing special about PF_PACKET. PF_PACKET would be treated in the same (generic) manner as any other carrier protocol family. Now my PF_PACKET socket example was not a request for hacking into PF_PACKET for supporting a protocol which SOCK_PACKET was not designed for. All the PPPoE specific stuff would reside in the ppp frame encpasulation protocol. It was really an example that even PPPoE fits the 'ppp over socket' paradigm very well by using the low layer PF_PACKET protocol family. Of course, as PPPoE uses a more complex encapsulation then most other ppp flavors. But this only implies that implementing the PPPoE frame encapsulation requires more work. It does not require any dirty hacks to PF_PACKET. Michal> with PF_PACKET. It is this need for an addressing scheme Michal> which is unique to PPPoE that made me go with PF_PPPOE. Yes, good point, you've conviced me! (But only as far as PPPeE is concerned :-). As PPPoE frame encapsulation requires session-id-based [de]multiplexing, it is rasonnable to create a new protocol family. Providing different sockets for different sessions also preserves the point-to-point sematics which ppp assumes. Note that this still fits in the generic 'ppp over socket' paradigm. The only difference is where the ppp frame encapsulation is processed. With PF_PACKET, PPPoE requires to implement a non-zero ppp frame encapsulation protocol engine, but can use an existing protocol family. With PF_PPPOE, it requires implementing that new protocol family which does the encapsulation stuff by itsself. The 'encap X' box becomes a zero layer in that case. I'm still very uncomforatable with the idea of creating a new protocol family for every existing protocol serving as a carrier connection. The frame encapsulation is essentially a zero layer for most protocols. It does not provide any service to the ppp layer proper. The reason why they exist at all was to maintain compatibility with other (non-ppp) protocols. E.g. sync ppp (async as well) encapsulation prepends an HDLC address and UI control field to the ppp frame. This allows to use existing transmission hardware (and to re-use software) which relies on the presence of HDLC headers. From ppp's point of view, this frame encapsulation protocol is logically a zero layer. Thus, ppp peers ususally negotiate to compress (remove) those headers if they know that the headers are not needed for reasons outside the scope of ppp (and the logical zero layer layer becomes a physical one). My summary: PF_PPPOE: o.k. PF_PPPOx: not o.k. (only o.k. if multiplexing above an existing carrier protocol is needed. Maybe the latter case could be handled by a generic PF_PPPOX for every such protocol). Henner From owner-netdev@oss.sgi.com Mon Feb 7 13:15:18 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 13:14:59 -0800 Received: from kogge.hanse.de ([192.76.134.17]:1799 "EHLO kogge.Hanse.DE") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 13:14:43 -0800 Received: (from uucp@localhost) by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id WAA53921; Mon, 7 Feb 2000 22:14:34 +0100 (CET) (envelope-from eis@baty.hanse.de) Received: (from eis@localhost) by baty.hanse.de (8.9.3/8.9.3) id TAA31363; Mon, 7 Feb 2000 19:37:26 +0100 To: Mitchell Blank Jr Cc: jamal , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X References: <20000203120127.J72648@sfgoth.com> From: Henner Eisen Date: 07 Feb 2000 19:37:26 +0100 In-Reply-To: Mitchell Blank Jr's message of "Thu, 3 Feb 2000 12:01:27 -0800" Message-ID: Lines: 8 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >>>>> "Mitchell" == Mitchell Blank writes: Mitchell> ...PPTP, ISDN-PPP (is that using the new ppp_generic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ No, isdn_ppp is the second oldest ppp implementation in the linux kernel (since 1.3.x, don't know x by heart). That was long before ppp_generic was available (2.3.x). Henner From owner-netdev@oss.sgi.com Mon Feb 7 13:15:38 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 13:15:29 -0800 Received: from kogge.hanse.de ([192.76.134.17]:2567 "EHLO kogge.Hanse.DE") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 13:15:19 -0800 Received: (from uucp@localhost) by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id WAA53960; Mon, 7 Feb 2000 22:16:56 +0100 (CET) (envelope-from eis@baty.hanse.de) Received: (from eis@localhost) by baty.hanse.de (8.9.3/8.9.3) id UAA31452; Mon, 7 Feb 2000 20:36:15 +0100 To: Mark Spencer cc: netdev@oss.sgi.com Subject: Re: RFC: PPP over X References: From: Henner Eisen Date: 07 Feb 2000 20:36:15 +0100 In-Reply-To: Mark Spencer's message of "Sun, 6 Feb 2000 12:28:42 -0600 (EST)" Message-ID: Lines: 25 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >>>>> "Mark" == Mark Spencer writes: Mark> p.s. Would you like me to setup a mailing list for this? Mark> I've got majordomo and it wouldn't take me but a few minutes Mark> to do so. I'd prefer to keep the discussion on this list. ppp-over-X design is strongly related to the linux network design. And that's exactly what netdev is for. It's also very important (you know, the peer review issue) that linux network experts can observe the discussion even if they (currently) don't participate. Although there is sufficient documentation availabe which allows for writing a standard (e.g. ethernet) network driver, there is almost no documentation of the linux network core. Experience shows that there are several traps where people step in when trying to program stuff not addressed by the network driver documentation. Henner From owner-netdev@oss.sgi.com Mon Feb 7 14:30:59 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 14:30:50 -0800 Received: from dhcp41.toaster.net ([199.108.84.41]:29451 "EHLO schmee.sfgoth.com") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 14:30:37 -0800 Received: (from mitch@localhost) by schmee.sfgoth.com (8.9.3/8.9.3) id OAA44201; Mon, 7 Feb 2000 14:30:07 -0800 (PST) Date: Mon, 7 Feb 2000 14:30:07 -0800 From: Mitchell Blank Jr To: Henner Eisen Cc: jamal , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X Message-ID: <20000207143007.O31166@sfgoth.com> References: <20000203120127.J72648@sfgoth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from eis@baty.hanse.de on Mon, Feb 07, 2000 at 07:37:26PM +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Henner Eisen wrote: > >>>>> "Mitchell" == Mitchell Blank writes: > Mitchell> ...PPTP, ISDN-PPP (is that using the new ppp_generic > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > No, isdn_ppp is the second oldest ppp implementation in the linux kernel > (since 1.3.x, don't know x by heart). That was long before ppp_generic > was available (2.3.x). Yes, but I was wondering if it had been updated to the ppp_generic regime. After all async PPP is older still and it uses ppp_generic now :-) BTW, sorry I didn't get around to posting patches to pppd yesterday. Every time I thought I nailed the "last thing" in pppd a couple more would pop up. I think I'm nearing the end of the tunnel though, so stay tuned. -Mitch From owner-netdev@oss.sgi.com Mon Feb 7 17:04:39 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 17:04:29 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:9226 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 17:04:17 -0800 Received: (from paulus@localhost) by front.linuxcare.com.au (8.9.3/8.9.3/Debian/GNU) id LAA19430; Tue, 8 Feb 2000 11:59:43 +1100 From: Paul Mackerras Organization: Linuxcare, Inc. To: Mark Spencer , jamal Subject: Re: RFC: PPP over X Date: Tue, 8 Feb 2000 11:51:52 +1100 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain Cc: Michal Ostrowski , Henner Eisen , netdev@oss.sgi.com, axboe@suse.de, mitch@sfgoth.com, Andi Kleen , Marc Boucher , Ben LaHaise References: MIME-Version: 1.0 Message-Id: <0002081158160A.09952@argo.linuxcare.com.au> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Mon, 07 Feb 2000, Mark Spencer wrote: > I put some mechanisms in the kernel to use the two parameters provided by > the MPPP spec to decide which should bundle, and provided an override > capability for pppd, if so desired. I really don't think that the > userspace programs should have to confer with one another to decide who > should go in an MP bundle. I have to disagree here. Deciding which links go in which bundle is something that can easily be done in userspace and has a large element of policy about it. Therefore it should be done in userspace. The userspace stuff (pppd or whatever) then just tells the kernel "attach this link to this bundle". This keeps the kernel code simple and clean. > Now, if I'm a LAC, I want to copy PPP frames from a device (say, a tty or > ISDN driver, or even another pppd) to my L2TP socket... Can this also be > done with a kernel datapath? My API didn't really have a mechanism for > doing so, but it would be nice if the new one did. For a tty you could make a line discipline which would shunt the packets down the l2tp socket. Alternatively you could have a kernel thread doing reads and writes on the device and your l2tp socket. That might actually turn out cleaner. -- Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax paulus@linuxcare.com.au, http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. From owner-netdev@oss.sgi.com Mon Feb 7 17:31:00 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 17:30:49 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:9739 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 17:30:24 -0800 Received: (from paulus@localhost) by front.linuxcare.com.au (8.9.3/8.9.3/Debian/GNU) id MAA20532; Tue, 8 Feb 2000 12:29:43 +1100 From: Paul Mackerras Organization: Linuxcare, Inc. To: Mitchell Blank Jr Subject: Re: RFC: PPP over X Date: Tue, 8 Feb 2000 11:58:24 +1100 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain Cc: jamal , Michal Ostrowski , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Ben LaHaise References: <20000206053819.X9170@sfgoth.com> MIME-Version: 1.0 Message-Id: <0002081228350B.09952@argo.linuxcare.com.au> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Mon, 07 Feb 2000, Mitchell Blank Jr wrote: > Paul Mackerras wrote: > > In order to be able to do multilink, pppd needs to be able to talk to each > > channel separately as well as to the ppp unit (which represents a bundle), > > Could a single connection to the ppp unit represent multiple unrelated > bundles? No, I don't see any point in allowing this and it would complicate things. If you want to control multiple bundles you open /dev/ppp several times and attach the individual fds to the individual bundles. > > This way, pppd doesn't have to know how to get hold of a file descriptor > > for talking directly to a channel, it just needs to know the channel > > number. > > I don't think this is a big deal - for many potential transports, its > perfectly natural to operate on them as a file descriptor. Making the Sure. I think my point was more that if there are some transports where we don't have a fd, we can accommodate them too. There's also the point that my design relieves each channel from having to provide read() and write() methods for sending and receiving PPP frames on that channel. Instead that code is there once in ppp_generic.c. > kernel grab it (instead of going through the normal open(2) path) Maybe we have a misunderstanding here. The way I see it that the discovery stuff will use open or socket or whatever to get hold of an fd, then do an ioctl to say "become a PPP channel" and get back a channel number. This channel number gets passed to pppd which then does the ppp stuff over it. Most likely the original fd needs to be kept open while we are doing ppp over the channel. > Its things like this that make me really like the socket-family model. > When you have a file descriptor you have a nice automatically reference- > counted token that you can pass among user-space programs. Using unix-domain sockets and the control message stuff, you mean? I must admit I've never actually used that. I could cheerfully have that in a pppd plugin but I would be hesitant about using it in pppd proper unless I can be sure it is supported on all the unices that pppd runs on. > What of the async encapsulation stuff is needed by other channel types? > Most of the obvious ones (PPPoATM, PPPoE, PPTP, L2TP) are packet-based > and won't need any of that code at all. I can't think of any other > encapsulations that would need control-character escaping and the like. If it's a library, you don't have to use it but you can if you want to. Anything that wants to make a stream where it doesn't need to preserve packet boundaries would probably want to use the async encapsulation, at least to the extent of escaping ~ and }, and putting in ~ to mark the packet boundaries. -- Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax paulus@linuxcare.com.au, http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. From owner-netdev@oss.sgi.com Mon Feb 7 17:35:40 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 17:35:30 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:13323 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 17:35:22 -0800 Received: (from paulus@localhost) by front.linuxcare.com.au (8.9.3/8.9.3/Debian/GNU) id MAA20589; Tue, 8 Feb 2000 12:34:43 +1100 From: Paul Mackerras Organization: Linuxcare, Inc. To: jamal Subject: Re: RFC: PPP over X Date: Tue, 8 Feb 2000 12:29:07 +1100 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain Cc: Michal Ostrowski , Mitchell Blank Jr , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Ben LaHaise References: MIME-Version: 1.0 Message-Id: <0002081230340C.09952@argo.linuxcare.com.au> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Mon, 07 Feb 2000, jamal wrote: > Locking inside the kernel will help instead of UID i.e make the channel > grabbing atomic; if the channel is grabbed its state changes to "grabbed"; > this could be also interpreted as a refcount; on close or detach it goes > back to "available" state. That still leaves a race where I can grab your channel. Actually it would probably be better to say that only root can grab a channel. -- Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax paulus@linuxcare.com.au, http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. From owner-netdev@oss.sgi.com Mon Feb 7 17:36:19 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 17:35:59 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:14603 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 17:35:43 -0800 Received: (from paulus@localhost) by front.linuxcare.com.au (8.9.3/8.9.3/Debian/GNU) id MAA20593; Tue, 8 Feb 2000 12:34:43 +1100 From: Paul Mackerras Organization: Linuxcare, Inc. To: jamal , Mitchell Blank Jr Subject: Re: RFC: PPP over X Date: Tue, 8 Feb 2000 12:30:46 +1100 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain Cc: netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , paulus@linuxcare.com, Michal Ostrowski , Ben LaHaise References: MIME-Version: 1.0 Message-Id: <0002081231480D.09952@argo.linuxcare.com.au> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Mon, 07 Feb 2000, jamal wrote: > Backporting sounds like a huge pain to me. And would this be a separate > patch or part of the kernel proper? 2.2 is considered to be a stable > release. It wouldn't be that much of a pain, I actually developed it under 2.2 for a while before 2.3 came along. -- Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax paulus@linuxcare.com.au, http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. From owner-netdev@oss.sgi.com Mon Feb 7 20:58:53 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 20:58:42 -0800 Received: from dibbler.ne.mediaone.net ([24.218.56.247]:20751 "EHLO dibbler.ne.mediaone.net") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 20:58:22 -0800 Received: (from rodrigc@localhost) by dibbler.ne.mediaone.net (8.9.3/8.9.3) id AAA21716 for netdev@oss.sgi.com; Tue, 8 Feb 2000 00:04:09 -0500 Date: Tue, 8 Feb 2000 00:04:09 -0500 From: Craig Rodrigues To: netdev@oss.sgi.com Subject: Does the Linux kernel support RFC 2292 Advanced Socket API? Message-ID: <20000208000409.A21682@mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi, Does the Linux kernel and header files support the RFC 2292 Advanced Socket API? I posted the same question to the glibc mailing list, because the header files involved were and which seem to be under the control of the glibc project, and not the Linux kernel project. The glibc folks told me to post here, hence I post. :) I couldn't find the following things on my glibc 2.1.2 system: IPV6_RTHDR IPV6_RTHDR_LOOSE IPV6_RTHDR_STRICT IPV6_RTHDR_TYPE_0 struct ip6_hdr{}; struct ip6_rthdr{}; struct ip6_rthdr0{}; A lot of the functions in Section 8 of RFC 2292, "Routing Header Options" do not seem to be implemented. Do these functions have to be implemented in the IPv6 kernel implementation, or in libc? RFC 2292 is at: ftp://ftp.isi.edu/in-notes/rfc2292.txt and an updated draft version which adds more stuff is at: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ipngwg-rfc2292bis-01.txt Thanks. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From owner-netdev@oss.sgi.com Mon Feb 7 22:23:04 2000 Received: by oss.sgi.com id ; Mon, 7 Feb 2000 22:22:55 -0800 Received: from [155.33.140.250] ([155.33.140.250]:4629 "EHLO nofear.sweet.com") by oss.sgi.com with ESMTP id ; Mon, 7 Feb 2000 22:22:49 -0800 Received: from localhost (gws@localhost) by nofear.sweet.com (8.9.2/8.9.2) with SMTP id BAA23954 for ; Tue, 8 Feb 2000 01:22:47 -0500 (EST) Date: Tue, 8 Feb 2000 01:22:46 -0500 (EST) From: Greg Simpson To: netdev@oss.sgi.com Subject: routing tricks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Alright, here's a non-development thought-provoking hack idea for you.. [sorry, but I looked and decided everywhere else was filled with 'my ne2k doesn't work! help!' type-questions =)].. I have an 'application' that accepts udp packets, and responds likewise with udp.. it, however, cannot accept packets from any network larger than a class C [bad coding]. The network I am on is > /24! [mask 255.255.252.0]. Thus, this application is inaccessible to my local network [lame]. My goal is to be able to access that application from the localnet, without renumbering to a class C. Ideally.. if I could do something like.. ipchains -A input -p udp -s x.x.0.0/255.255.252.0 -d 0/0 -j MASQ that'd rock my world. Linux doesn't seem to like having MASQ applied to anything other than the forward chain though!! :) :) how would i go about writing/finding a userspace chain that i could make inbound packets jump to, to masq ? or any hacks you think i could try? I'm using pptp to connect from local windows boxen to the linux application; a series of /32's work fine. PPTP is messy though, and that setup breaks other things [and shouldn't be necessary]. conversations look like: x.x.0.2->255.255.255.255 udp is this app listening on the net? x.x.0.1->x.x.0.2 udp yes, i am here x.x.0.2->x.x.0.255 udp hello class c, what clients are here? [nobody answers] x.x.0.2->x.x.0.1 udp connect x.x.0.1->x.x.0.2 udp sorry, you're not on the same class C as me. One of my thoughts to provide basic functionality would be to have another linux box on the same net, masq'ing connections to the linux app box, and route through that... I'm more certain I could get that to work, but I'd rather find an elegant hack first =) -g From owner-netdev@oss.sgi.com Tue Feb 8 01:18:15 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 01:18:06 -0800 Received: from dhcp41.toaster.net ([199.108.84.41]:8199 "EHLO schmee.sfgoth.com") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 01:17:41 -0800 Received: (from mitch@localhost) by schmee.sfgoth.com (8.9.3/8.9.3) id BAA53916; Tue, 8 Feb 2000 01:17:36 -0800 (PST) Date: Tue, 8 Feb 2000 01:17:36 -0800 From: Mitchell Blank Jr To: Paul Mackerras Cc: jamal , Michal Ostrowski , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Ben LaHaise Subject: Re: RFC: PPP over X Message-ID: <20000208011736.A53038@sfgoth.com> References: <20000206053819.X9170@sfgoth.com> <0002081228350B.09952@argo.linuxcare.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <0002081228350B.09952@argo.linuxcare.com.au>; from paulus@linuxcare.com on Tue, Feb 08, 2000 at 11:58:24AM +1100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Paul Mackerras wrote: > > Could a single connection to the ppp unit represent multiple unrelated > > bundles? > > No, I don't see any point in allowing this and it would complicate things. > If you want to control multiple bundles you open /dev/ppp several times > and attach the individual fds to the individual bundles. Fair enough. I just thought it might make for nice multiplexing of information back to userland, but its certainly not critical. Thinking about it a bit more I agree that its probably a can of worms. > > I don't think this is a big deal - for many potential transports, its > > perfectly natural to operate on them as a file descriptor. Making the > > Sure. I think my point was more that if there are some transports where > we don't have a fd, we can accommodate them too. OK, I thought you were talking about having the ppp_generic layer do some magic kernel-land open() or something. That would be gross. I'm still unconvinced that supporting transports for which we can't get an fd is needed at all.. adding socket families is really very cheap. > There's also the point > that my design relieves each channel from having to provide read() and > write() methods for sending and receiving PPP frames on that channel. > Instead that code is there once in ppp_generic.c. Yes, that would be a good thing. > The way I see it that the > discovery stuff will use open or socket or whatever to get hold of an fd, > then do an ioctl to say "become a PPP channel" and get back a channel > number. This channel number gets passed to pppd which then does the ppp > stuff over it. Most likely the original fd needs to be kept open while we > are doing ppp over the channel. Then why not pass back the fd to pppd? In UNIX the basic userland token representing an object in the kernel is an open file descriptor. What you're really suggesting is adding a new type of token (the PPP channel number) which gets passed around much like a file descriptor. While this isn't impossible, I just don't see the real benefit. It just is going to add code. I think the current token could be described as "a file descriptor willing to perform an ioctl(PPPIOCATTACH)" An improvement would be to make that ioctl's argument was a file descriptor for the /dev/ppp we have open. Then we could completely banish the idea of "channel number" and the code would be considerably cleaner. What do you think? > Using unix-domain sockets and the control message stuff, you mean? I must > admit I've never actually used that. I could cheerfully have that in a > pppd plugin but I would be hesitant about using it in pppd proper unless I > can be sure it is supported on all the unices that pppd runs on. I can't speak for ultrix or next off the top of my head, but all the rest definately do. NeXT should also be no problem since BSD4.3 had it. Ultrix may be an issue since it had a lot of BSD 4.1c code in it, but is it really _that_ important to keep support for things that old? I've been accused of being a raving DEC fan, and even _I_ stopped giving Ultrix the time of day years ago. > If it's a library, you don't have to use it but you can if you want to. > Anything that wants to make a stream where it doesn't need to preserve > packet boundaries would probably want to use the async encapsulation, at > least to the extent of escaping ~ and }, and putting in ~ to mark the > packet boundaries. I'm just curious where you're anticipating the code re-use coming from. I'm aware of many protocols built on PPP but PPP-on-async is the only one I'm aware of that uses those algorithms. Maybe PPP-on-X25? (haven't read that RFC yet) I think most any hardware device that needs much of the ppp_async code to speak PPP would probably be implemented as a tty anyway. -Mitch From owner-netdev@oss.sgi.com Tue Feb 8 02:05:25 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 02:05:06 -0800 Received: from dhcp41.toaster.net ([199.108.84.41]:15879 "EHLO schmee.sfgoth.com") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 02:04:36 -0800 Received: (from mitch@localhost) by schmee.sfgoth.com (8.9.3/8.9.3) id CAA54238; Tue, 8 Feb 2000 02:04:27 -0800 (PST) Date: Tue, 8 Feb 2000 02:04:25 -0800 From: Mitchell Blank Jr To: Paul Mackerras Cc: Mark Spencer , jamal , Michal Ostrowski , Henner Eisen , netdev@oss.sgi.com, axboe@suse.de, Andi Kleen , Marc Boucher , Ben LaHaise Subject: Re: RFC: PPP over X Message-ID: <20000208020423.B53038@sfgoth.com> References: <0002081158160A.09952@argo.linuxcare.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <0002081158160A.09952@argo.linuxcare.com.au>; from paulus@linuxcare.com on Tue, Feb 08, 2000 at 11:51:52AM +1100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing > > Now, if I'm a LAC, I want to copy PPP frames from a device (say, a tty or > > ISDN driver, or even another pppd) to my L2TP socket... Can this also be > > done with a kernel datapath? My API didn't really have a mechanism for > > doing so, but it would be nice if the new one did. > > For a tty you could make a line discipline which would shunt the packets > down the l2tp socket. Alternatively you could have a kernel thread doing > reads and writes on the device and your l2tp socket. That might actually > turn out cleaner. We definately want whatever the next PPP rewrite looks like to include some mechanism for this (which is probably best described as PPP bridging). I don't think we need a kernel thread to do it, either- you just need to wire ppp_input() on one channel to ops->start_xmit() on the other, perhaps with a small skb queue in the middle. This capability has many uses... for instance some companies sell devices that turn PPP-over-async and PPP-over-DS1 sessions into PPP-over-ATM so you can backhaul those customers accross your ATM network and terminate the PPP session on your big-iron router. We could give linux the capability to do this quite easily. If implemented intellegently this could also be used as a basis for implementing multi-chassis MPPP (i.e. supporting bonding multiple incoming calls into one bundle even if the calls landed on different machines) To do this, you need a way to get the PPP frames that landed on the slave box(es) back to the master box (which is actually handling the routing for the channel). One easy way to do this would be to just have the slaves bridge the PPP packets over some other transport (L2TP for instance) and have the master put that transport in the bundle with the others. Note that the "master" actually can be bundling nothing but channels from slaves - it could be a box that only handles routing for PPP bundles bridged over from a set of slave boxes... Cisco's large-scale dialin solution is architected that way. -Mitch From owner-netdev@oss.sgi.com Tue Feb 8 03:32:17 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 03:31:57 -0800 Received: from firewall.i-data.com ([195.24.22.194]:9741 "HELO firewall.i-data.com") by oss.sgi.com with SMTP id ; Tue, 8 Feb 2000 03:31:34 -0800 Received: (qmail 3549 invoked from network); 8 Feb 2000 10:36:06 -0000 Received: from unknown (HELO idaHUB2000.i-data.com) (172.16.1.8) by firewall.i-data.com with SMTP; 8 Feb 2000 10:36:06 -0000 Received: by idaHUB2000.i-data.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 4125687F.003F594E ; Tue, 8 Feb 2000 12:31:56 +0100 X-Lotus-FromDomain: I-DATA From: thomas.horsten@lasat.com To: netdev@oss.sgi.com Message-ID: <4125687F.003F57C0.00@idaHUB2000.i-data.com> Date: Tue, 8 Feb 2000 12:29:22 +0100 Subject: portfw for 2.0.x Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi, I have done a port of Linux 2.0.38 for LASAT networks' MIPS based platform. I've patched in autofw but I can't seem to find the source for the userspace tool to configure this (for 2.2.x and above, ipmasqadm does that job). There's supposed to be a stand-alone utility on ftp.netis.com, but it has apparantly been deleted from there. Does anyone have a pointer to where I can find this? Regards, Thomas Horsten Thomas@Horsten.com From owner-netdev@oss.sgi.com Tue Feb 8 07:25:10 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 07:25:00 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:15110 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Tue, 8 Feb 2000 07:24:42 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id SAA02675; Tue, 8 Feb 2000 18:24:22 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002081524.SAA02675@ms2.inr.ac.ru> Subject: Re: Does the Linux kernel support RFC 2292 Advanced Socket API? To: rodrigc@mediaone.NET (Craig Rodrigues) Date: Tue, 8 Feb 2000 18:24:22 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: <20000208000409.A21682@mediaone.net> from "Craig Rodrigues" at Feb 8, 0 08:13:07 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 519 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > Does the Linux kernel and header files support the RFC 2292 Advanced > Socket API? What's about kernel --- the answer is yes. > I posted the same question to the glibc mailing list, > because the header files involved were and > which seem to be under the control of the glibc project, and not the Linux > kernel project. The glibc folks told me to post here, hence I post. :) What glibc folk did say your this? Kernel header files are in full order. Alexey Kuznetsov From owner-netdev@oss.sgi.com Tue Feb 8 07:49:10 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 07:49:01 -0800 Received: from mainframe.dgrc.crc.ca ([142.92.38.206]:63909 "EHLO mainframe.dgrc.crc.ca") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 07:48:42 -0800 Received: from crc.ca (curly [142.92.38.251]) by mainframe.dgrc.crc.ca (8.9.3/8.9.3) with ESMTP id KAA06929; Tue, 8 Feb 2000 10:43:26 -0500 (EST) Message-ID: <38A03A8D.AA3868C0@crc.ca> Date: Tue, 08 Feb 2000 10:47:25 -0500 From: Guilhem Tardy Organization: CRC X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Craig Rodrigues CC: netdev@oss.sgi.com Subject: Re: Does the Linux kernel support RFC 2292 Advanced Socket API? References: <20000208000409.A21682@mediaone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing > > IPV6_RTHDR > IPV6_RTHDR_LOOSE > IPV6_RTHDR_STRICT > IPV6_RTHDR_TYPE_0 > > struct ip6_hdr{}; > struct ip6_rthdr{}; > struct ip6_rthdr0{}; You'll find some of those in include/linux/ipv6.h : IPV6_SRCRT_TYPE_0 struct ipv6_rt_hdr {}; struct rt0_hdr {}; struct ipv6hdr{}; -- Guilhem Tardy phone: (613) 993-8232 Network Systems and Technologies fax: (613) 998-9648 Communications Research Center email: Guilhem.Tardy@crc.ca 3701 Carling Ave. #28/2B web: http://www.crc.ca/ Ottawa (Ontario) K2H 8S2 From owner-netdev@oss.sgi.com Tue Feb 8 14:15:12 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 14:15:02 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:28061 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 14:14:44 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id RAA21770; Tue, 8 Feb 2000 17:14:06 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id RAA07251; Tue, 8 Feb 2000 17:14:01 -0500 (EST) Date: Tue, 8 Feb 2000 17:14:00 -0500 (EST) From: jamal To: Henner Eisen cc: Michal Ostrowski , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On 7 Feb 2000, Henner Eisen wrote: [Very nice diagram and description deleted] > My summary: > > PF_PPPOE: o.k. > PF_PPPOx: not o.k. (only o.k. if multiplexing above an existing carrier > protocol is needed. Maybe the latter case could be > handled by a generic PF_PPPOX for every such protocol). > My thinking is that the protocol family/domain is really just for management reasons i.e what you describe as 'carrier' i see to be really the encap/decap part. For example it might come in through one encap interface, gets decaped and encaped again to another one (the LAC example fits well in this scenario). Another scenario: The packet comes in, it goes through the decap then up the stack to the approriate socket interface to the user space server for example. We should leave the control of what happens to the implementation of the specific PPPOX; For this reason i am supporting the PF_PPPOX as a family and the type to be one PPPOXs eg SOCK_PPPOE and we dont need to implement the traditional SOCK_STREAM etc. I am saying this without looking at the code so i could be off tangent. cheers, jamal From owner-netdev@oss.sgi.com Tue Feb 8 14:20:23 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 14:20:03 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:63647 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 14:19:55 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id RAA24869; Tue, 8 Feb 2000 17:19:45 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id RAA07295; Tue, 8 Feb 2000 17:19:44 -0500 (EST) Date: Tue, 8 Feb 2000 17:19:44 -0500 (EST) From: jamal To: Paul Mackerras cc: Michal Ostrowski , Mitchell Blank Jr , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <0002081230340C.09952@argo.linuxcare.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Tue, 8 Feb 2000, Paul Mackerras wrote: > On Mon, 07 Feb 2000, jamal wrote: > > That still leaves a race where I can grab your channel. Actually it would > probably be better to say that only root can grab a channel. Would there still be a race if multiple root processes tried to grab the channel? >> Backporting sounds like a huge pain to me. And would this be a separate >> patch or part of the kernel proper? 2.2 is considered to be a stable >> release. >It wouldn't be that much of a pain, I actually developed it under 2.2 for >a while before 2.3 came along. Ok, but then do we want this to be part of 2.2? cheers jamal From owner-netdev@oss.sgi.com Tue Feb 8 14:27:52 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 14:27:32 -0800 Received: from styx.uwaterloo.ca ([129.97.40.10]:61706 "EHLO styx.uwaterloo.ca") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 14:27:17 -0800 Received: (from mostrows@localhost) by styx.uwaterloo.ca (8.9.3/8.9.3) id RAA26135; Tue, 8 Feb 2000 17:26:24 -0500 From: Michal Ostrowski MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14496.38928.23657.403216@styx.uwaterloo.ca> Date: Tue, 8 Feb 2000 17:26:24 -0500 (EST) To: jamal Cc: Henner Eisen , Michal Ostrowski , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing jamal writes: > > > On 7 Feb 2000, Henner Eisen wrote: > > [Very nice diagram and description deleted] > > > My summary: > > > > PF_PPPOE: o.k. > > PF_PPPOx: not o.k. (only o.k. if multiplexing above an existing carrier > > protocol is needed. Maybe the latter case could be > > handled by a generic PF_PPPOX for every such protocol). > > > > My thinking is that the protocol family/domain is really just for > management reasons i.e what you describe as 'carrier' i see to be really > the encap/decap part. For example it might come in through one encap > interface, gets decaped and encaped again to another one (the LAC example > fits well in this scenario). > Another scenario: The packet comes in, it goes through the decap then up > the stack to the approriate socket interface to the user space server for > example. > We should leave the control of what happens to the implementation > of the specific PPPOX; > For this reason i am supporting the PF_PPPOX as a family and the > type to be one PPPOXs eg SOCK_PPPOE and we dont need to implement the > traditional SOCK_STREAM etc. I am saying this without looking at the code > so i could be off tangent. Going off a bit on a tangent myself, perhaps we should give some thought to playing around with the socket "type". From the "socket" man page: int socket(int domain, int type, int protocol); ... The socket has the indicated type, which specifies the semantics of communication. Currently defined types are: So if you want to do PPP/UDP: socket(AF_INET,SOCK_PPP,IPPROTO_UDP); As the "type" suggests, you get PPP semantics. This wouldn't solve the problem for PPPoE, where we need a unique addressing scheme, but it might be a nice way of dealing with things for those transport schemes where we can re-use the existing infrastructure. (Under such a scheme it may be feasible/easy to do PPP/TCP .) Michal Ostrowski mostrows@styx.uwaterloo.ca From owner-netdev@oss.sgi.com Tue Feb 8 14:31:53 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 14:31:43 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:59559 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 14:31:37 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id RAA02013; Tue, 8 Feb 2000 17:31:25 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id RAA07312; Tue, 8 Feb 2000 17:31:25 -0500 (EST) Date: Tue, 8 Feb 2000 17:31:24 -0500 (EST) From: jamal To: Mitchell Blank Jr cc: Paul Mackerras , Mark Spencer , Michal Ostrowski , Henner Eisen , netdev@oss.sgi.com, axboe@suse.de, Andi Kleen , Marc Boucher , Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <20000208020423.B53038@sfgoth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Tue, 8 Feb 2000, Mitchell Blank Jr wrote: > > For a tty you could make a line discipline which would shunt the packets > > down the l2tp socket. Alternatively you could have a kernel thread doing > > reads and writes on the device and your l2tp socket. That might actually > > turn out cleaner. > > We definately want whatever the next PPP rewrite looks like to include some > mechanism for this (which is probably best described as PPP bridging). > I don't think we need a kernel thread to do it, either- you just need > to wire ppp_input() on one channel to ops->start_xmit() on the other, > perhaps with a small skb queue in the middle. > > > If implemented intellegently this could also be used as a basis for > implementing multi-chassis MPPP (i.e. supporting bonding multiple > incoming calls into one bundle even if the calls landed on different > machines) To do this, you need a way to get the PPP frames that > landed on the slave box(es) back to the master box (which is actually > handling the routing for the channel). One easy way to do this > would be to just have the slaves bridge the PPP packets over > some other transport (L2TP for instance) and have the master put > that transport in the bundle with the others. Note that the "master" > actually can be bundling nothing but channels from slaves - it could > be a box that only handles routing for PPP bundles bridged over from a > set of slave boxes... Cisco's large-scale dialin solution is > architected that way. And this could all be setup via ioctls onto the generic PPPOX setup; look at my suggestions to Mark Spencer on the LAC/LNS. cheers jamal From owner-netdev@oss.sgi.com Tue Feb 8 14:50:22 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 14:50:03 -0800 Received: from 207-168-200-20.gw.eni.net ([207.168.200.20]:32243 "EHLO nt_excha_server.atlantic1.com") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 14:49:47 -0800 Received: from onsyd.com (naiad.atlantic1.com [172.16.1.200]) by nt_excha_server.atlantic1.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 12FPSSR8; Tue, 8 Feb 2000 17:49:42 -0500 Message-ID: <38A09D83.FCA814B@onsyd.com> Date: Tue, 08 Feb 2000 17:49:39 -0500 From: Syd X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Admin address Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing I've been on this list for so long I seem to have lost the admin address. Would someone send it along when you have a moment. Thanks Syd From owner-netdev@oss.sgi.com Tue Feb 8 14:53:53 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 14:53:33 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:60080 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 14:53:26 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id RAA11862; Tue, 8 Feb 2000 17:53:17 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id RAA07357; Tue, 8 Feb 2000 17:53:16 -0500 (EST) Date: Tue, 8 Feb 2000 17:53:15 -0500 (EST) From: jamal To: Michal Ostrowski cc: Henner Eisen , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , mitch@sfgoth.com, Andi Kleen , Marc Boucher , paulus@linuxcare.com, Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <14496.38928.23657.403216@styx.uwaterloo.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Tue, 8 Feb 2000, Michal Ostrowski wrote: > So if you want to do PPP/UDP: > > socket(AF_INET,SOCK_PPP,IPPROTO_UDP); > > As the "type" suggests, you get PPP semantics. > There is a catch with this: You now have to muck with the UDP kernel code to add L2TP semantics; most other people would probably only want to use UDP as it is. cheers jamal From owner-netdev@oss.sgi.com Tue Feb 8 17:12:16 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 17:11:57 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:57099 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 17:11:36 -0800 Received: (from paulus@localhost) by front.linuxcare.com.au (8.9.3/8.9.3/Debian/GNU) id MAA10999; Wed, 9 Feb 2000 12:09:45 +1100 From: Paul Mackerras Organization: Linuxcare, Inc. To: jamal Subject: Re: RFC: PPP over X Date: Wed, 9 Feb 2000 12:08:14 +1100 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain Cc: Michal Ostrowski , Mitchell Blank Jr , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Ben LaHaise References: MIME-Version: 1.0 Message-Id: <00020912100001.24880@argo.linuxcare.com.au> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Wed, 09 Feb 2000, jamal wrote: > Would there still be a race if multiple root processes tried to grab the > channel? Yes, but then you can implement access controls at user level, in pppd or whatever, to make sure the race doesn't happen. > Ok, but then do we want this to be part of 2.2? Potentially, it would be up to Alan Cox and Linus. -- Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax paulus@linuxcare.com.au, http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. From owner-netdev@oss.sgi.com Tue Feb 8 17:16:57 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 17:16:47 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:524 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 17:16:28 -0800 Received: (from paulus@localhost) by front.linuxcare.com.au (8.9.3/8.9.3/Debian/GNU) id MAA11775; Wed, 9 Feb 2000 12:14:45 +1100 From: Paul Mackerras Organization: Linuxcare, Inc. To: Mitchell Blank Jr Subject: Re: RFC: PPP over X Date: Wed, 9 Feb 2000 12:13:04 +1100 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain Cc: Mark Spencer , jamal , Michal Ostrowski , Henner Eisen , netdev@oss.sgi.com, axboe@suse.de, Andi Kleen , Marc Boucher , Ben LaHaise References: <20000208020423.B53038@sfgoth.com> MIME-Version: 1.0 Message-Id: <00020912141802.24880@argo.linuxcare.com.au> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Tue, 08 Feb 2000, Mitchell Blank Jr wrote: > We definately want whatever the next PPP rewrite looks like to include some > mechanism for this (which is probably best described as PPP bridging). > I don't think we need a kernel thread to do it, either- you just need > to wire ppp_input() on one channel to ops->start_xmit() on the other, > perhaps with a small skb queue in the middle. So we have two ppp channels and an ioctl or something that says "connect these two channels to each other"? That wouldn't be too hard to do at all. -- Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax paulus@linuxcare.com.au, http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. From owner-netdev@oss.sgi.com Tue Feb 8 18:04:08 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 18:03:47 -0800 Received: from mail.cyberus.ca ([209.195.95.1]:5769 "EHLO cyberus.ca") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 18:03:38 -0800 Received: from shell.cyberus.ca (shell [209.195.95.7]) by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id VAA04577; Tue, 8 Feb 2000 21:03:17 -0500 (EST) Received: from localhost (hadi@localhost) by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id VAA07542; Tue, 8 Feb 2000 21:03:18 -0500 (EST) Date: Tue, 8 Feb 2000 21:03:18 -0500 (EST) From: jamal To: Paul Mackerras cc: Michal Ostrowski , Mitchell Blank Jr , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Ben LaHaise Subject: Re: RFC: PPP over X In-Reply-To: <00020912100001.24880@argo.linuxcare.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Wed, 9 Feb 2000, Paul Mackerras wrote: > On Wed, 09 Feb 2000, jamal wrote: > > > Ok, but then do we want this to be part of 2.2? > > Potentially, it would be up to Alan Cox and Linus. > My only concern is in stability -- You are sort of changing the interface; Are there any other product vendors who are using these kernel PPP features or expecting some esoteric features? Maybe not ... just a thought. cheers, jamal From owner-netdev@oss.sgi.com Tue Feb 8 20:39:11 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 20:38:51 -0800 Received: from tnt.isi.edu ([128.9.128.128]:2476 "EHLO tnt.isi.edu") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 20:38:24 -0800 Received: from orb.isi.edu (orb-e.isi.edu [128.9.160.66]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id UAA16110; Tue, 8 Feb 2000 20:38:18 -0800 (PST) Received: from orb.isi.edu (LOCALHOST [127.0.0.1]) by orb.isi.edu (8.8.7/8.8.6) with ESMTP id UAA08340; Tue, 8 Feb 2000 20:38:17 -0800 (PST) Date: Tue, 08 Feb 2000 20:38:16 -0800 Message-ID: From: Yuji Sekiya To: Guilhem.Tardy@crc.ca Cc: rodrigc@mediaone.net, netdev@oss.sgi.com Subject: Re: Does the Linux kernel support RFC 2292 Advanced Socket API? In-Reply-To: In your message of "Tue, 08 Feb 2000 10:47:25 -0500" <38A03A8D.AA3868C0@crc.ca> References: <20000208000409.A21682@mediaone.net> <38A03A8D.AA3868C0@crc.ca> User-Agent: Wanderlust/2.2.15 (More Than Words) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 8) (Bryce Canyon) (sparc-sun-solaris2.7) Organization: Information Sciences Institute MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing At Tue, 08 Feb 2000 10:47:25 -0500, Guilhem Tardy wrote: Hello, > You'll find some of those in include/linux/ipv6.h : > > IPV6_SRCRT_TYPE_0 > > struct ipv6_rt_hdr {}; > struct rt0_hdr {}; > struct ipv6hdr{}; Usually, Userland applications don't include directry. AFAIK, glibc doesn't have such definitions. As Alexey said, Linux kernel implement RFC2292, but glibc doesn't yet. -- SEKIYA Yuji USC/ISI Computer Networks Division 7 From owner-netdev@oss.sgi.com Tue Feb 8 21:18:32 2000 Received: by oss.sgi.com id ; Tue, 8 Feb 2000 21:18:11 -0800 Received: from tnt.isi.edu ([128.9.128.128]:57015 "EHLO tnt.isi.edu") by oss.sgi.com with ESMTP id ; Tue, 8 Feb 2000 21:17:42 -0800 Received: from orb.isi.edu (orb-e.isi.edu [128.9.160.66]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id VAA18212; Tue, 8 Feb 2000 21:17:34 -0800 (PST) Received: from orb.isi.edu (LOCALHOST [127.0.0.1]) by orb.isi.edu (8.8.7/8.8.6) with ESMTP id VAA08357; Tue, 8 Feb 2000 21:17:33 -0800 (PST) Date: Tue, 08 Feb 2000 21:17:33 -0800 Message-ID: From: Yuji Sekiya To: kuznet@ms2.inr.ac.ru Cc: Hideaki YOSHIFUJI , netdev@oss.sgi.com Subject: sin6_scope_id patch for Linux kernel User-Agent: Wanderlust/2.2.15 (More Than Words) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 8) (Bryce Canyon) (sparc-sun-solaris2.7) Organization: Information Sciences Institute MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello Alexey and members, Yoshfuji made sin6_scope_id patch for Linux kernel before and informed you and members. We are looking forward to your reply, but we don't still receive any reply from you. To be honest, what do you think about the patch ? 1. You can't adopt the patch into linux-2.3 kernel because of just before the release of linux-2.4 kernel, 2. you can't eat the patch because the patch is not what you intend or 3. others. Regards. -- SEKIYA Yuji USC/ISI Computer Networks Division 7 From owner-netdev@oss.sgi.com Wed Feb 9 08:18:16 2000 Received: by oss.sgi.com id ; Wed, 9 Feb 2000 08:18:07 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:22532 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Wed, 9 Feb 2000 08:17:53 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA09068; Wed, 9 Feb 2000 19:17:08 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002091617.TAA09068@ms2.inr.ac.ru> Subject: Re: sin6_scope_id patch for Linux kernel To: sekiya@ISI.EDU (Yuji Sekiya) Date: Wed, 9 Feb 2000 19:17:08 +0300 (MSK) Cc: yoshfuji@ecei.tohoku.ac.jp, netdev@oss.sgi.com In-Reply-To: from "Yuji Sekiya" at Feb 8, 0 09:17:33 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 445 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > Yoshfuji made sin6_scope_id patch for Linux kernel before and > informed you and members. We are looking forward to your reply, > but we don't still receive any reply from you. I simply did not receieve this patch. Please, retransmit! > 1. You can't adopt the patch into linux-2.3 kernel > because of just before the release of linux-2.4 > kernel, I see no reasons not to accept it, once the work is really done. Alexey From owner-netdev@oss.sgi.com Wed Feb 9 08:52:37 2000 Received: by oss.sgi.com id ; Wed, 9 Feb 2000 08:52:27 -0800 Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:41733 "EHLO cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP id ; Wed, 9 Feb 2000 08:52:02 -0800 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id BAA29143; Thu, 10 Feb 2000 01:51:01 +0900 To: kuznet@ms2.inr.ac.ru Cc: sekiya@ISI.EDU, netdev@oss.sgi.com Subject: Re: sin6_scope_id patch for Linux kernel From: Hideaki YOSHIFUJI In-Reply-To: <200002091617.TAA09068@ms2.inr.ac.ru> References: <200002091617.TAA09068@ms2.inr.ac.ru> X-Mailer: Mew version 1.94 on XEmacs 20.4 (Emerald) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000210015100Y.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Thu, 10 Feb 2000 01:51:00 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 24 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi, Alexey! In article <200002091617.TAA09068@ms2.inr.ac.ru> (at Wed, 9 Feb 2000 19:17:08 +0300 (MSK)), kuznet@ms2.inr.ac.ru says: > > Yoshfuji made sin6_scope_id patch for Linux kernel before and > > informed you and members. We are looking forward to your reply, > > but we don't still receive any reply from you. > > I simply did not receieve this patch. Please, retransmit! For linux-2.3.39 and 2.3.40, the following patch is available and it seems ok: For linux-2.3.41, is available, but not well-tested. At this moment, we don't have patch for the latest kernel (2.3.42). I will work on it in this weekend. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 From owner-netdev@oss.sgi.com Wed Feb 9 10:50:27 2000 Received: by oss.sgi.com id ; Wed, 9 Feb 2000 10:50:17 -0800 Received: from salisbury.futuretv.com ([194.216.164.17]:62982 "EHLO salisbury.labs.futuretv.com") by oss.sgi.com with ESMTP id ; Wed, 9 Feb 2000 10:50:04 -0800 Received: from zebra.labs.futuretv.com ([192.0.0.67] ident=mail) by salisbury.labs.futuretv.com with esmtp (Exim 3.03 #1) id 12IcD5-0004Ua-00 for netdev@oss.sgi.com; Wed, 09 Feb 2000 18:51:31 +0000 Received: from [192.0.0.21] (helo=fountain.labs.futuretv.com ident=mail) by zebra.labs.futuretv.com with esmtp (Exim 3.03 #1) id 12IcBc-0002zG-00; Wed, 09 Feb 2000 18:50:00 +0000 Received: from [127.0.0.1] (helo=fountain ident=pb) by fountain.labs.futuretv.com with esmtp (Exim 3.03 #1) id 12IcBb-00042K-00; Wed, 09 Feb 2000 18:49:59 +0000 X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: kuznet@ms2.inr.ac.ru cc: rodrigc@mediaone.NET (Craig Rodrigues), netdev@oss.sgi.com Subject: Re: Does the Linux kernel support RFC 2292 Advanced Socket API? In-Reply-To: Message from kuznet@ms2.inr.ac.ru of "Tue, 08 Feb 2000 18:24:22 +0300." <200002081524.SAA02675@ms2.inr.ac.ru> References: <200002081524.SAA02675@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Feb 2000 18:49:59 +0000 From: Philip Blundell Message-Id: Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >> because the header files involved were and >> which seem to be under the control of the glibc project, and not the Linux >> kernel project. The glibc folks told me to post here, hence I post. :) > >What glibc folk did say your this? Kernel header files are in full order. It was me. I looked for IPV6_RTHDR_LOOSE, struct ip6_rthdr and friends and couldn't find them. Perhaps I just didn't look carefully enough. Sorry. p. From owner-netdev@oss.sgi.com Wed Feb 9 11:02:47 2000 Received: by oss.sgi.com id ; Wed, 9 Feb 2000 11:02:37 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:8201 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Wed, 9 Feb 2000 11:02:18 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA11316; Wed, 9 Feb 2000 22:02:00 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002091902.WAA11316@ms2.inr.ac.ru> Subject: Re: Does the Linux kernel support RFC 2292 Advanced Socket API? To: pb@labs.futuretv.com (Philip Blundell) Date: Wed, 9 Feb 2000 22:02:00 +0300 (MSK) Cc: rodrigc@mediaone.NET, netdev@oss.sgi.com In-Reply-To: from "Philip Blundell" at Feb 9, 0 06:49:59 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 462 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > It was me. I looked for IPV6_RTHDR_LOOSE, struct ip6_rthdr and friends and > couldn't find them. Perhaps I just didn't look carefully enough. Sorry. Like all other structures. You searched in wrong place, cut-n-paste them from rfc, rather than from kernel source. BTW loose and strict rthdr flags do not exist. Adv. API rfc is older than IPv6 rfc literally by week... You can just omit this place. All the rest is pure cut-n-paste work. Alexey From owner-netdev@oss.sgi.com Wed Feb 9 11:25:37 2000 Received: by oss.sgi.com id ; Wed, 9 Feb 2000 11:25:27 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:28681 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Wed, 9 Feb 2000 11:25:15 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA11516; Wed, 9 Feb 2000 22:24:44 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002091924.WAA11516@ms2.inr.ac.ru> Subject: Re: sin6_scope_id patch for Linux kernel To: yoshfuji@ecei.tohoku.ac.jp (Hideaki YOSHIFUJI) Date: Wed, 9 Feb 2000 22:24:44 +0300 (MSK) Cc: sekiya@ISI.EDU, netdev@oss.sgi.com In-Reply-To: <20000210015100Y.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> from "Hideaki YOSHIFUJI" at Feb 10, 0 01:51:00 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 165 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > Khm... $ host apps.v6.linux.or.jp Host not found. Alexey From owner-netdev@oss.sgi.com Wed Feb 9 11:29:57 2000 Received: by oss.sgi.com id ; Wed, 9 Feb 2000 11:29:37 -0800 Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:49925 "EHLO cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP id ; Wed, 9 Feb 2000 11:29:21 -0800 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id EAA30752; Thu, 10 Feb 2000 04:28:13 +0900 To: kuznet@ms2.inr.ac.ru Cc: sekiya@ISI.EDU, netdev@oss.sgi.com Subject: Re: sin6_scope_id patch for Linux kernel From: Hideaki YOSHIFUJI In-Reply-To: <200002091924.WAA11516@ms2.inr.ac.ru> References: <20000210015100Y.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <200002091924.WAA11516@ms2.inr.ac.ru> X-Mailer: Mew version 1.94 on XEmacs 20.4 (Emerald) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000210042813B.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Thu, 10 Feb 2000 04:28:13 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 15 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing In article <200002091924.WAA11516@ms2.inr.ac.ru> (at Wed, 9 Feb 2000 22:24:44 +0300 (MSK)), kuznet@ms2.inr.ac.ru says: > $ host apps.v6.linux.or.jp > Host not found. Strange... % host apps.v6.linux.or.jp apps.v6.linux.or.jp CNAME chiharu.v6.linux.or.jp chiharu.v6.linux.or.jp A 210.157.158.25 -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 From owner-netdev@oss.sgi.com Wed Feb 9 11:31:06 2000 Received: by oss.sgi.com id ; Wed, 9 Feb 2000 11:30:56 -0800 Received: from gwu.ericy.com ([208.196.3.162]:16258 "EHLO gwu.ericy.com") by oss.sgi.com with ESMTP id ; Wed, 9 Feb 2000 11:30:43 -0800 Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id NAA24501; Wed, 9 Feb 2000 13:30:35 -0600 (CST) Received: from SMTP (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with SMTP id NAA26212; Wed, 9 Feb 2000 13:30:35 -0600 (CST) Received: from eamrcnt740.exu.ericsson.se ([138.85.224.211]) by 138.85.133.38 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 09 Feb 2000 19:30:34 0000 (GMT) Received: by eamrcnt740.exu.ericsson.se with Internet Mail Service (5.5.2448.0) id <1RTCFLB6>; Wed, 9 Feb 2000 13:30:32 -0600 Message-ID: From: "Sean Schneyer (EUS)" To: "'kuznet@ms2.inr.ac.ru'" , yoshfuji@ecei.tohoku.ac.jp Cc: sekiya@ISI.EDU, netdev@oss.sgi.com Subject: RE: sin6_scope_id patch for Linux kernel Date: Wed, 9 Feb 2000 13:30:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Works fine for me and I'm even behind a corporate firewall. Regards, Sean Sean Kendall Schneyer Operative Product Manager, Standardization ERICSSON 740 East Campbell Road MS M-03 Richardson, TX 75081 USA Phone +1 (972) 583 8329 Fax +1 (972) 644 3036 E-mail sean.schneyer@ericsson.com -----Original Message----- From: kuznet@ms2.inr.ac.ru [mailto:kuznet@ms2.inr.ac.ru] Sent: Wednesday, February 09, 2000 1:25 PM To: yoshfuji@ecei.tohoku.ac.jp Cc: sekiya@ISI.EDU; netdev@oss.sgi.com Subject: Re: sin6_scope_id patch for Linux kernel Hello! > Khm... $ host apps.v6.linux.or.jp Host not found. Alexey From owner-netdev@oss.sgi.com Wed Feb 9 11:50:27 2000 Received: by oss.sgi.com id ; Wed, 9 Feb 2000 11:50:07 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:58377 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Wed, 9 Feb 2000 11:49:38 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA12739; Wed, 9 Feb 2000 22:49:15 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002091949.WAA12739@ms2.inr.ac.ru> Subject: Re: sin6_scope_id patch for Linux kernel To: yoshfuji@ecei.tohoku.ac.jp (Hideaki YOSHIFUJI) Date: Wed, 9 Feb 2000 22:49:15 +0300 (MSK) Cc: sekiya@ISI.EDU, netdev@oss.sgi.com In-Reply-To: <20000210042813B.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> from "Hideaki YOSHIFUJI" at Feb 10, 0 04:28:13 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 2601 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > > $ host apps.v6.linux.or.jp > > Host not found. > > Strange... > > % host apps.v6.linux.or.jp > apps.v6.linux.or.jp CNAME chiharu.v6.linux.or.jp > chiharu.v6.linux.or.jp A 210.157.158.25 Yes. It is strange. Even more: $ dig @chiharu.v6.linux.or.jp v6.linux.or.jp axfr any ; <<>> DiG 2.2 <<>> @chiharu.v6.linux.or.jp. v6.linux.or.jp. axfr any ; (1 server found) v6.linux.or.jp. 192800 SOA chiharu.v6.linux.or.jp. sekiya.sfc.wide.ad.jp. ( 99120810 ; serial 172800 ; refresh (2 days) 3600 ; retry (1 hour) 1728000 ; expire (20 days) 192800 ) ; minimum (2 days 5 hours 33 mins 20 secs) v6.linux.or.jp. 192800 NS chiharu.v6.linux.or.jp. v6.linux.or.jp. 192800 NS bono.v6.linux.or.jp. v6.linux.or.jp. 192800 MX 3 chiharu.v6.linux.or.jp. v6.linux.or.jp. 192800 MX 5 bono.v6.linux.or.jp. v6.linux.or.jp. 192800 AAAA 3ffe:505:d::1 v6.linux.or.jp. 192800 A 203.178.140.36 ring.v6.linux.or.jp. 192800 MX 5 ring.v6.linux.or.jp. ring.v6.linux.or.jp. 192800 AAAA 3ffe:505:d:1000:260:52ff:fe04:bcb7 ring.v6.linux.or.jp. 192800 A 203.178.140.36 chiharu.not.v6.linux.or.jp. 192800 A 210.157.158.25 monster.v6.linux.or.jp. 192800 CNAME monster.kyushu.v6.linux.or.jp. sendai.v6.linux.or.jp. 192800 AAAA 3ffe:505:e:200::1 chiharu.v6.linux.or.jp. 192800 AAAA 3ffe:505:d:3000::1 chiharu.v6.linux.or.jp. 192800 A 210.157.158.25 localhost.v6.linux.or.jp. 192800 CNAME localhost. mail.v6.linux.or.jp. 192800 CNAME chiharu.v6.linux.or.jp. ipsmg.v6.linux.or.jp. 192800 AAAA 3ffe:505:d:4000::1 tamon.v6.linux.or.jp. 192800 CNAME tamon.kyushu.v6.linux.or.jp. www.v6.linux.or.jp. 192800 CNAME ring.v6.linux.or.jp. kyoto.v6.linux.or.jp. 192800 CNAME mulgarita.kyoto.v6.linux.or.jp. mulgarita.kyoto.v6.linux.or.jp. 192800 AAAA 3ffe:505:d:2000::1 kyushu.v6.linux.or.jp. 192800 NS tamon.v6.ec.kyushu-u.ac.jp. ur.v6.linux.or.jp. 192800 NS 133.13.27.120.v6.linux.or.jp. debian.v6.linux.or.jp. 192800 AAAA 3ffe:505:d:6000::1 bono.v6.linux.or.jp. 192800 MX 5 bono.v6.linux.or.jp. bono.v6.linux.or.jp. 192800 AAAA 3ffe:505:d::1 bono.v6.linux.or.jp. 192800 A 203.178.140.36 ftp.v6.linux.or.jp. 192800 CNAME ring.v6.linux.or.jp. ftp2.v6.linux.or.jp. 192800 CNAME chiharu.v6.linux.or.jp. v6.linux.or.jp. 192800 SOA chiharu.v6.linux.or.jp. sekiya.sfc.wide.ad.jp. ( 99120810 ; serial 172800 ; refresh (2 days) 3600 ; retry (1 hour) 1728000 ; expire (20 days) 192800 ) ; minimum (2 days 5 hours 33 mins 20 secs) ;; Received 31 answers (31 records). ;; FROM: minus to SERVER: 210.157.158.25 ;; WHEN: Wed Feb 9 22:46:30 2000 So, it does not matter. You told me what is apps 8) Alexey From owner-netdev@oss.sgi.com Wed Feb 9 15:44:41 2000 Received: by oss.sgi.com id ; Wed, 9 Feb 2000 15:44:20 -0800 Received: from kogge.hanse.de ([192.76.134.17]:32522 "EHLO kogge.Hanse.DE") by oss.sgi.com with ESMTP id ; Wed, 9 Feb 2000 15:44:16 -0800 Received: (from uucp@localhost) by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id AAA35415; Thu, 10 Feb 2000 00:42:59 +0100 (CET) (envelope-from eis@baty.hanse.de) Received: (from eis@localhost) by baty.hanse.de (8.9.3/8.9.3) id XAA05004; Wed, 9 Feb 2000 23:25:43 +0100 Date: Wed, 9 Feb 2000 23:25:43 +0100 From: Henner Eisen Message-Id: <200002092225.XAA05004@baty.hanse.de> To: mitch@sfgoth.com CC: hadi@cyberus.ca, netdev@oss.sgi.com, axboe@suse.de, markster@marko.net, ak@suse.de, marc@mbsi.ca, paulus@linuxcare.com, mostrows@styx.uwaterloo.ca, bcrl@redhat.com In-reply-to: <20000207143007.O31166@sfgoth.com> (message from Mitchell Blank Jr on Mon, 7 Feb 2000 14:30:07 -0800) Subject: Re: RFC: PPP over X References: <20000203120127.J72648@sfgoth.com> <20000207143007.O31166@sfgoth.com> Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >>>>> "Mitchell" == Mitchell Blank writes: >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ No, isdn_ppp is the second >> oldest ppp implementation in the linux kernel (since 1.3.x, >> don't know x by heart). That was long before ppp_generic was >> available (2.3.x). Mitchell> Yes, but I was wondering if it had been updated to the Mitchell> ppp_generic regime. After all async PPP is older still Mitchell> and it uses ppp_generic now :-) Yes, but ppp_generic and the corresponding async ppp was implemented simultaneously, making async ppp the first prototype implementation for ppp_generic. Now, as we have a very clean generic ppp modules which is already tested on top of an async driver, we can start to migrate other ppps to the generic paradigm. However, with isdn, I don't think this can be done quickly. First, isdn ppp relies on special stuff of the isdn driver (e.g. the demand dialing which is implemented in the kernel). Next, isdn ppp has been enhanced independently from async ppp, development was driven by other goals. Thus, the ioctl interface is not compatible any more, and there is a certain amount of non-overlapping functionality. And as the isdn link layer is somewhat messy, it might be even more diffcult. I could imagine that writing a new isdn link layer from scratch (which would of course use the generic ppp) will be even faster. Henner From owner-netdev@oss.sgi.com Wed Feb 9 15:47:10 2000 Received: by oss.sgi.com id ; Wed, 9 Feb 2000 15:46:51 -0800 Received: from kogge.hanse.de ([192.76.134.17]:35082 "EHLO kogge.Hanse.DE") by oss.sgi.com with ESMTP id ; Wed, 9 Feb 2000 15:46:36 -0800 Received: (from uucp@localhost) by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id AAA35426; Thu, 10 Feb 2000 00:46:32 +0100 (CET) (envelope-from eis@baty.hanse.de) Received: (from eis@localhost) by baty.hanse.de (8.9.3/8.9.3) id XAA05050; Wed, 9 Feb 2000 23:50:05 +0100 Date: Wed, 9 Feb 2000 23:50:05 +0100 From: Henner Eisen Message-Id: <200002092250.XAA05050@baty.hanse.de> To: hadi@cyberus.ca CC: mostrows@styx.uwaterloo.ca, netdev@oss.sgi.com, axboe@suse.de, markster@marko.net, mitch@sfgoth.com, ak@suse.de, marc@mbsi.ca, paulus@linuxcare.com, bcrl@redhat.com In-reply-to: (message from jamal on Tue, 8 Feb 2000 17:53:15 -0500 (EST)) Subject: Re: RFC: PPP over X References: Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >>>>> "jamal" == jamal writes: jamal> On Tue, 8 Feb 2000, Michal Ostrowski wrote: >> So if you want to do PPP/UDP: >> >> >> >> As the "type" suggests, you get PPP semantics. >> jamal> There is a catch with this: You now have to muck with the jamal> UDP kernel code to add L2TP semantics; most other people jamal> would probably only want to use UDP as it is. If done by new parameters to the socket() call, I think the last (protocol) parameter would be more appropriate. e.g. socket(AF_INET,SOCK_DGRAM,IPPROTO_PPP_UDP); That would allow for running ppp over any reasonable protocol in the AF_INET family (just need to add a IPP_PROTO_* for every reasonnable protocol). On the other hand, I don't see what introducing new parameter values would gain at all. An ioctl, which attaches the socket's data path to the ppp channel would serve the same thing. It is even more flexible as it would allow to delay connecting the ppp channel. After a succesful connect() or accept(), the user space program could communicate some none-ppp related data with the peer before it attaches the socket to the ppp channel. This could be useful for different things, e.g. - performing additional authentification - negotiating some enryption for the channel - if it is not known a-priori that the peer really wants to speak ppp, some heuristic algorithm might be able to analyse the first data received from the peer and switch to an alternative protocol when detected so. Henner From owner-netdev@oss.sgi.com Wed Feb 9 15:49:21 2000 Received: by oss.sgi.com id ; Wed, 9 Feb 2000 15:49:12 -0800 Received: from kogge.hanse.de ([192.76.134.17]:37642 "EHLO kogge.Hanse.DE") by oss.sgi.com with ESMTP id ; Wed, 9 Feb 2000 15:48:57 -0800 Received: (from uucp@localhost) by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id AAA35440; Thu, 10 Feb 2000 00:48:51 +0100 (CET) (envelope-from eis@baty.hanse.de) Received: (from eis@localhost) by baty.hanse.de (8.9.3/8.9.3) id AAA05339; Thu, 10 Feb 2000 00:33:54 +0100 Date: Thu, 10 Feb 2000 00:33:54 +0100 From: Henner Eisen Message-Id: <200002092333.AAA05339@baty.hanse.de> To: hadi@cyberus.ca CC: mostrows@styx.uwaterloo.ca, netdev@oss.sgi.com, axboe@suse.de, markster@marko.net, mitch@sfgoth.com, ak@suse.de, marc@mbsi.ca, paulus@linuxcare.com, bcrl@redhat.com In-reply-to: (message from jamal on Tue, 8 Feb 2000 17:53:15 -0500 (EST)) Subject: Re: RFC: PPP over X References: Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Yet another idea: Why not generalizing (essentially, it is just renaming) the paradigm 'attaching ppp channel to connected socket' to 'attaching/tunneling arbitray protocol over connected socket' ? The channel API, although there is 'ppp' in the name prefixes, is very generic and not exclusivly useful to ppp_generic.c. It would be possible to write software net_device drivers (e.g. one for each encapsulation protocol) which communicate the downstream data by means of the channel API. (The only difference seems that the channel is not registered for ppp but somewehere else). Then, as the generic socket code will use the ppp_channel API anyway, attaching the socket to a real ppp channel will not be any different from attaching it to some other software net_device driver. We Henner From owner-netdev@oss.sgi.com Wed Feb 9 16:51:32 2000 Received: by oss.sgi.com id ; Wed, 9 Feb 2000 16:51:12 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:12302 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Wed, 9 Feb 2000 16:50:52 -0800 Received: (from paulus@localhost) by front.linuxcare.com.au (8.9.3/8.9.3/Debian 8.9.3-6) id LAA01376; Thu, 10 Feb 2000 11:49:47 +1100 From: Paul Mackerras Organization: Linuxcare, Inc. To: Henner Eisen , hadi@cyberus.ca Subject: Re: RFC: PPP over X Date: Thu, 10 Feb 2000 11:41:10 +1100 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain Cc: mostrows@styx.uwaterloo.ca, netdev@oss.sgi.com, axboe@suse.de, markster@marko.net, mitch@sfgoth.com, ak@suse.de, marc@mbsi.ca, bcrl@redhat.com References: <200002092333.AAA05339@baty.hanse.de> MIME-Version: 1.0 Message-Id: <00021011490500.01926@argo.linuxcare.com.au> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Thu, 10 Feb 2000, Henner Eisen wrote: > Why not generalizing (essentially, it is just renaming) the paradigm > > 'attaching ppp channel to connected socket' > > to > > 'attaching/tunneling arbitray protocol over connected socket' Anyone for STREAMS??? Seriously, if you want any chance of Linus/Alan/DaveM etc. being interested, you have to show some specific actual thing that this would be good for. Just saying `this is a nice abstraction' will get you nowhere. -- Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax paulus@linuxcare.com.au, http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. From owner-netdev@oss.sgi.com Thu Feb 10 04:48:02 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 04:47:52 -0800 Received: from p413-019.ppp.get2net.dk ([195.82.218.19]:4357 "EHLO osh.sparre.dk") by oss.sgi.com with ESMTP id ; Thu, 10 Feb 2000 04:47:34 -0800 Received: from sparre.dk (osh@localhost [127.0.0.1]) by osh.sparre.dk (8.8.7/8.8.7) with ESMTP id NAA23670; Thu, 10 Feb 2000 13:47:04 +0100 Message-ID: <38A2B348.B07A7398@sparre.dk> Date: Thu, 10 Feb 2000 13:47:04 +0100 From: Ole Husgaard Organization: Sparre Software X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.2.12 i586) MIME-Version: 1.0 To: Paul Mackerras CC: Henner Eisen , hadi@cyberus.ca, mostrows@styx.uwaterloo.ca, netdev@oss.sgi.com, axboe@suse.de, markster@marko.net, mitch@sfgoth.com, ak@suse.de, marc@mbsi.ca, bcrl@redhat.com, Linux STREAMS Subject: Re: RFC: PPP over X References: <200002092333.AAA05339@baty.hanse.de> <00021011490500.01926@argo.linuxcare.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Paul Mackerras wrote: > > On Thu, 10 Feb 2000, Henner Eisen wrote: > > > Why not generalizing (essentially, it is just renaming) the paradigm > > > > 'attaching ppp channel to connected socket' > > > > to > > > > 'attaching/tunneling arbitray protocol over connected socket' > > Anyone for STREAMS??? > > Seriously, if you want any chance of Linus/Alan/DaveM etc. being > interested, you have to show some specific actual thing that this would be > good for. Just saying `this is a nice abstraction' will get you nowhere. Actually the modularity and configurability of STREAMS would be really good for this kind of problem: The various pieces of protocol code would be STREAMS modules and drivers running in the kernel, and userspace programs could assemble them as needed by the particular application. Interfacing with the existing Linux drivers and protocols at the datalink layer is no problem: We have had code for this for years in the Linux STREAMS project at http://www.gcom.com/LiS/. There seems to be a few false assumptions about STREAMS in Linux floating around, and I'll like to kill the most important: Adding STREAMS to Linux does _not_ mean that existing network code would have to be changed in any way, and the existing network code would _not_ become slower. In fact, Linux STREAMS runs as a module in a completely unpatched 2.2 kernel. Please note that I don't want to start a flame war about STREAMS or advocate that the network code be all changed to STREAMS. But it would be nice if kernel developers could use STREAMS when it has an advantage. Regards, Ole Husgaard osh@sparre.dk PS: Some of you PPP guys might be interested in the QoS anomalies I've observed when running PPP over async: Take a look at http://www.sparre.dk/pub/linux/congestion/QoSproblem.html From owner-netdev@oss.sgi.com Thu Feb 10 06:37:53 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 06:37:43 -0800 Received: from email.gcom.com ([199.97.226.1]:60425 "EHLO gcom.com") by oss.sgi.com with ESMTP id ; Thu, 10 Feb 2000 06:37:32 -0800 Received: from gcom.com (dave@dave-pc.gcom1.com [192.168.1.76]) by gcom.com (8.9.3/8.9.3) with ESMTP id IAA03862; Thu, 10 Feb 2000 08:39:53 -0600 Message-ID: <38A2CCDD.3F9FACAE@gcom.com> Date: Thu, 10 Feb 2000 08:36:13 -0600 From: Dave Grothe Organization: Gcom, Inc X-Mailer: Mozilla 4.7C-CCK-MCD Caldera Systems OpenLinux [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: en MIME-Version: 1.0 To: Ole Husgaard CC: Paul Mackerras , Henner Eisen , hadi@cyberus.ca, mostrows@styx.uwaterloo.ca, netdev@oss.sgi.com, axboe@suse.de, markster@marko.net, mitch@sfgoth.com, ak@suse.de, marc@mbsi.ca, bcrl@redhat.com, Linux STREAMS Subject: Re: RFC: PPP over X References: <200002092333.AAA05339@baty.hanse.de> <00021011490500.01926@argo.linuxcare.com.au> <38A2B348.B07A7398@sparre.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing To amplify a bit on what Ole said: The Linux STREAMS code (LiS) does a good job in being able to interpose complex and flexible protocol stacks below IP -- the _standard_ Linux IP. What it _cannot_ do, and would require some assistance from the kernel networking folks, is to run protocol stacks _above_ TCP or _above_ UDP. Every once in awhile I get a question from a potential customer about tunneling our SNA over a TCP connection in Linux. Without making a trip up to user space the answer always has to be "can't be done." The reason being that we can't configure our SNA code (STREAMS based) above TCP while keeping the messages in the kernel. (Having contributed this two-cents worth to this discussion, I feel somewhat embarassed in that I am leaving for a two-week vacation on Saturday and will not have an opportunity to read responses or comment further.) -- Dave (author of LiS) From owner-netdev@oss.sgi.com Thu Feb 10 07:05:43 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 07:05:33 -0800 Received: from mea.tmt.tele.fi ([194.252.70.162]:52749 "EHLO mea.tmt.tele.fi") by oss.sgi.com with ESMTP id ; Thu, 10 Feb 2000 07:05:16 -0800 Received: by mea.tmt.tele.fi id ; Thu, 10 Feb 2000 17:04:59 +0200 Date: Thu, 10 Feb 2000 17:04:59 +0200 From: Matti Aarnio To: Dave Grothe Cc: Ole Husgaard , Paul Mackerras , Henner Eisen , hadi@cyberus.ca, mostrows@styx.uwaterloo.ca, netdev@oss.sgi.com, axboe@suse.de, markster@marko.net, mitch@sfgoth.com, ak@suse.de, marc@mbsi.ca, bcrl@redhat.com, Linux STREAMS Subject: Re: RFC: PPP over X Message-ID: <20000210170459.Y26018@mea.tmt.tele.fi> References: <200002092333.AAA05339@baty.hanse.de> <00021011490500.01926@argo.linuxcare.com.au> <38A2B348.B07A7398@sparre.dk> <38A2CCDD.3F9FACAE@gcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <38A2CCDD.3F9FACAE@gcom.com>; from Dave Grothe on Thu, Feb 10, 2000 at 08:36:13AM -0600 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Thu, Feb 10, 2000 at 08:36:13AM -0600, Dave Grothe wrote: > To amplify a bit on what Ole said: The Linux STREAMS code (LiS) does a > good job in being able to interpose complex and flexible protocol > stacks below IP -- the _standard_ Linux IP. > > What it _cannot_ do, and would require some assistance from the kernel > networking folks, is to run protocol stacks _above_ TCP or _above_ UDP. > Every once in awhile I get a question from a potential customer about > tunneling our SNA over a TCP connection in Linux. Without making a > trip up to user space the answer always has to be "can't be done." The > reason being that we can't configure our SNA code (STREAMS based) above > TCP while keeping the messages in the kernel. Yes you can. You can "simulate" user dataspace in kernel by doing: (from mm/filemap.c) static int file_send_actor(read_descriptor_t * desc, struct page *page, unsigned long offset , unsigned long size) { unsigned long kaddr; ssize_t written; unsigned long count = desc->count; struct file *file = (struct file *) desc->buf; mm_segment_t old_fs; if (size > count) size = count; old_fs = get_fs(); set_fs(KERNEL_DS); kaddr = kmap(page); written = file->f_op->write(file, (char *)kaddr + offset, size, &file->f_pos); kunmap(page); set_fs(old_fs); if (written < 0) { desc->error = written; written = 0; } desc->count = count - written; desc->written += written; return written; } Sure it isn't too pretty, but it does work quite well. (And "worst" of all, it involves data copy...) > (Having contributed this two-cents worth to this discussion, I feel somewhat > embarassed in that I am leaving for a two-week vacation on Saturday and will not > have an opportunity to read responses or comment further.) > > -- Dave (author of LiS) /Matti Aarnio From owner-netdev@oss.sgi.com Thu Feb 10 07:28:13 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 07:28:04 -0800 Received: from email.gcom.com ([199.97.226.1]:44042 "EHLO gcom.com") by oss.sgi.com with ESMTP id ; Thu, 10 Feb 2000 07:27:43 -0800 Received: from gcom.com (dave@dave-pc.gcom1.com [192.168.1.76]) by gcom.com (8.9.3/8.9.3) with ESMTP id JAA04125; Thu, 10 Feb 2000 09:30:09 -0600 Message-ID: <38A2D8A4.6E1EBE52@gcom.com> Date: Thu, 10 Feb 2000 09:26:28 -0600 From: Dave Grothe Organization: Gcom, Inc X-Mailer: Mozilla 4.7C-CCK-MCD Caldera Systems OpenLinux [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: en MIME-Version: 1.0 To: Matti Aarnio CC: Ole Husgaard , Paul Mackerras , Henner Eisen , hadi@cyberus.ca, mostrows@styx.uwaterloo.ca, netdev@oss.sgi.com, axboe@suse.de, markster@marko.net, mitch@sfgoth.com, ak@suse.de, marc@mbsi.ca, bcrl@redhat.com, Linux STREAMS Subject: Re: RFC: PPP over X References: <200002092333.AAA05339@baty.hanse.de> <00021011490500.01926@argo.linuxcare.com.au> <38A2B348.B07A7398@sparre.dk> <38A2CCDD.3F9FACAE@gcom.com> <20000210170459.Y26018@mea.tmt.tele.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Matti Aarnio wrote: > On Thu, Feb 10, 2000 at 08:36:13AM -0600, Dave Grothe wrote: > Without making a > > trip up to user space the answer always has to be "can't be done." The > > reason being that we can't configure our SNA code (STREAMS based) above > > TCP while keeping the messages in the kernel. > > Yes you can. You can "simulate" user dataspace in kernel > by doing: > > (from mm/filemap.c) This looks like a technique for writing to any old file system from inside the kernel. What about the other direction. Do you have to set up a kernel thread per data stream and use a similar technique to "read" from the file system? Or maybe one could concoct an inside-the-kernel kludge to use poll(). -- Dave From owner-netdev@oss.sgi.com Thu Feb 10 08:26:43 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 08:26:34 -0800 Received: from Cantor.suse.de ([194.112.123.193]:13580 "HELO Cantor.suse.de") by oss.sgi.com with SMTP id ; Thu, 10 Feb 2000 08:26:20 -0800 Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136]) by Cantor.suse.de (Postfix) with ESMTP id 823781E0A9; Thu, 10 Feb 2000 17:26:18 +0100 (MET) Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2]) by Hermes.suse.de (Postfix) with ESMTP id 08F0C10A02B; Thu, 10 Feb 2000 17:26:18 +0100 (MET) Received: by gruyere.muc.suse.de (Postfix, from userid 14446) id 5F2702F36C; Thu, 10 Feb 2000 17:26:09 +0100 (MET) Date: Thu, 10 Feb 2000 17:26:09 +0100 From: "Andi Kleen" To: Dave Grothe Cc: Matti Aarnio , Ole Husgaard , Paul Mackerras , Henner Eisen , hadi@cyberus.ca, mostrows@styx.uwaterloo.ca, netdev@oss.sgi.com, axboe@suse.de, markster@marko.net, mitch@sfgoth.com, ak@suse.de, marc@mbsi.ca, bcrl@redhat.com, Linux STREAMS Subject: Re: RFC: PPP over X Message-ID: <20000210172609.A8685@gruyere.muc.suse.de> References: <200002092333.AAA05339@baty.hanse.de> <00021011490500.01926@argo.linuxcare.com.au> <38A2B348.B07A7398@sparre.dk> <38A2CCDD.3F9FACAE@gcom.com> <20000210170459.Y26018@mea.tmt.tele.fi> <38A2D8A4.6E1EBE52@gcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <38A2D8A4.6E1EBE52@gcom.com>; from dave@gcom.com on Thu, Feb 10, 2000 at 09:26:28AM -0600 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Thu, Feb 10, 2000 at 09:26:28AM -0600, Dave Grothe wrote: > Matti Aarnio wrote: > > > On Thu, Feb 10, 2000 at 08:36:13AM -0600, Dave Grothe wrote: > > Without making a > > > trip up to user space the answer always has to be "can't be done." The > > > reason being that we can't configure our SNA code (STREAMS based) above > > > TCP while keeping the messages in the kernel. > > > > Yes you can. You can "simulate" user dataspace in kernel > > by doing: > > > > (from mm/filemap.c) > > This looks like a technique for writing to any old file system from inside the > kernel. What about the other direction. Do you have to set up a kernel thread per > data stream and use a similar technique to "read" from the file system? Or maybe one > could concoct an inside-the-kernel kludge to use poll(). You need a kernel thread to read/write TCP or UDP, because their socket layer requires process context. e.g. sunrpc does it this way for asynchronous NFS. Have a nice vacation, -Andi From owner-netdev@oss.sgi.com Thu Feb 10 14:57:36 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 14:57:16 -0800 Received: from tango.SoftHome.net ([204.144.231.49]:30943 "HELO convert rfc822-to-8bit tango.SoftHome.net") by oss.sgi.com with SMTP id ; Thu, 10 Feb 2000 14:57:04 -0800 Received: (qmail 19553 invoked by uid 417); 10 Feb 2000 21:11:02 -0000 Received: from unknown (HELO localhost.localdomain) (212.4.96.133) by smtpb.softhome.net with SMTP; 10 Feb 2000 21:11:02 -0000 From: magicboiz@softhome.net Date: Thu, 10 Feb 2000 21:12:20 GMT Message-ID: <20000210.21122000@localhost.localdomain> Subject: Question on i2.2 kernel ipv4 stack code To: netdev@oss.sgi.com X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello all, I know people here works on next kernel version, but perhaps some of you can help me. In file ip_input.c, function ip_rcv, how can I know if a received skb is for our machine if no sock (and no transport protocol) is waitting that packet(skb)?, Is there an easy way to determine if skb->nh.iph.daddr is our ip addr?. I hope you can understand me :) Thanks in advance. From owner-netdev@oss.sgi.com Thu Feb 10 14:58:46 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 14:58:36 -0800 Received: from hill-b-039.resnet.purdue.edu ([128.211.205.39]:27140 "EHLO hill-b-039.resnet.purdue.edu") by oss.sgi.com with ESMTP id ; Thu, 10 Feb 2000 14:58:27 -0800 Received: from hill-b-039.resnet.purdue.edu (coronach@hill-b-039.resnet.purdue.edu [128.211.205.39]) by hill-b-039.resnet.purdue.edu (8.9.3/8.9.3/Debian 8.9.3-6) with SMTP id NAA00914 for ; Thu, 10 Feb 2000 13:43:48 -0500 Date: Thu, 10 Feb 2000 13:43:48 -0500 (EST) From: "Michael A. Lemler" X-Sender: coronach@hill-b-039.resnet.purdue.edu Reply-To: "Michael A. Lemler" To: netdev@oss.sgi.com Subject: IPv6 LANs with Linux 2.2.14 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing I am having some basic connectivity problems and I am curious if someone could point out my error or if there is a problem in the 2.2.14 associated with what I am trying to do. All interfaces respond to pings while on console of the appropriate box and Node A is connected to the 6bone and will respond to pings on eth0 and eth1. So, with that, I assume the basic IPv6 configuration tasks are complete. Before I explain the problem, here are the configurations, all IPv6 options are compiled into the kernels. Node A: eth1 Link encap:Ethernet HWaddr 00:60:08:1B:5D:13 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::60:81b:5d13/10 Scope:Link inet6 addr: 3ffe:1ceb:0:2:10:1:0:1/112 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:672 errors:0 dropped:0 overruns:0 frame:0 TX packets:1198 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:5 Base address:0x280 This is the inside interface to my gateway, this box is also doing the tunneling. Here is the routing information for this box relating to eth1. 3ffe:1ceb:0:2:10:1::/112 fe80::60:81b:5d13 UG 1 17 0 eth1 3ffe:1ceb:0:2:10:1::/112 :: UA 256 0 0 eth1 I added the gateway route as a testing procedure to see if it needed it, but it didn't work. Currently, I have left it in there but I have tested it without and it still doesn't work. Node B: eth0 Link encap:Ethernet HWaddr 08:00:20:0C:FD:4F inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::a00:20ff:fe0c:fd4f/10 Scope:Link inet6 addr: 3ffe:1ceb:0:2:10:1:0:2/112 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4530 errors:0 dropped:0 overruns:0 frame:0 TX packets:2386 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:5 Base address:0xd400 As you can see, they are on the same subnet. Here is the routing information: 3ffe:1ceb:0:2:10:1::/112 fe80::a00:20ff:fe0c:fd4f UG 1 111 0 eth0 3ffe:1ceb:0:2:10:1:0:2/112 :: UA 256 0 0 eth0 Here, there a few differences, but I seem not to be able to get the first node to add the route for 3ffe:1ceb:0:2:10:1:0:1/112 and I can't delete 3ffe:1ceb:0:2:10:1::/112 (no gateway address) without removing the identifier from the interface. When I add the identifier, the route returns. During a ping test (pinging from Node 2 to Node 1), Node 1's in packets increase, but never sends a reply back. (information from /proc/net/snmp6) Suggestions? Corrections? Thanks. coronach@succubus.dhis.org From owner-netdev@oss.sgi.com Thu Feb 10 15:16:26 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 15:16:07 -0800 Received: from kogge.hanse.de ([192.76.134.17]:63499 "EHLO kogge.Hanse.DE") by oss.sgi.com with ESMTP id ; Thu, 10 Feb 2000 15:15:56 -0800 Received: (from uucp@localhost) by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id AAA73341; Fri, 11 Feb 2000 00:11:55 +0100 (CET) (envelope-from eis@baty.hanse.de) Received: (from eis@localhost) by baty.hanse.de (8.9.3/8.9.3) id AAA07912; Fri, 11 Feb 2000 00:00:29 +0100 Date: Fri, 11 Feb 2000 00:00:29 +0100 From: Henner Eisen Message-Id: <200002102300.AAA07912@baty.hanse.de> To: osh@sparre.dk CC: paulus@linuxcare.com, hadi@cyberus.ca, mostrows@styx.uwaterloo.ca, netdev@oss.sgi.com, axboe@suse.de, markster@marko.net, mitch@sfgoth.com, ak@suse.de, marc@mbsi.ca, bcrl@redhat.com, linux-streams@gsyc.escet.urjc.es In-reply-to: <38A2B348.B07A7398@sparre.dk> (message from Ole Husgaard on Thu, 10 Feb 2000 13:47:04 +0100) Subject: Re: RFC: PPP over X References: <200002092333.AAA05339@baty.hanse.de> <00021011490500.01926@argo.linuxcare.com.au> <38A2B348.B07A7398@sparre.dk> Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing DISCLAIMER: This is not a pro or contra streams article :-) >>>>> "Ole" == Ole Husgaard writes: Ole> Paul Mackerras wrote: >> On Thu, 10 Feb 2000, Henner Eisen wrote: >> >> > Why not generalizing (essentially, it is just renaming) the >> paradigm >> > >> > 'attaching ppp channel to connected socket' >> > >> > to >> > >> > 'attaching/tunneling arbitray protocol over connected socket' >> >> Anyone for STREAMS??? >> When I posted my message, I was almost sure to see a reply with this magic word in it :-) >> Seriously, if you want any chance of Linus/Alan/DaveM >> etc. being interested, you have to show some specific actual >> thing that this would be good for. Just saying `this is a nice >> abstraction' will get you nowhere. Yes, but the 'abstraction' is merily just a renaming, as the mechanism needed to attach a ppp_channel to a socket will require exactly the same functionality from the socket code. Ole> Actually the modularity and configurability of STREAMS would Ole> be really good for this kind of problem: The various pieces Ole> of protocol code would be STREAMS modules and drivers running Ole> in the kernel, and userspace programs could assemble them as Anyway, I'd like to say that the proposed mechanism is different from STREAMS. Just because it allows for tunneling a protocol over another protocol does not make it STREAMS: - Communication between the socket and upper layer protocol would be via a function call interface similar to any other internal communication between socket layers. - No message passing with message queues or message dispatcher is involved - The interface does not provide for controlling the connection. For controlling the carrier connection, a user space program which creates and controls the socket is permanently necessary. Only the data input and output is linked to the upper layer of the tunnel. As the control operations for the socket (connect/accept/ioctl/setsockopt) are not needed to be called from kernel, there is no need make them working from bh or interrupt context. Only the data input/output path needs to be callable from kernel. And even if the protocol implementation requires a process context for this, we don't need an artificial process for this, because the process which controls the socket is already there. Henner From owner-netdev@oss.sgi.com Thu Feb 10 15:44:26 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 15:44:06 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:50958 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Thu, 10 Feb 2000 15:43:56 -0800 Received: from box.linuxcare.com.au (penicillin.linuxcare.com.au [10.61.2.27]) by front.linuxcare.com.au (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id KAA04052; Fri, 11 Feb 2000 10:43:39 +1100 Received: from linuxcare.com (localhost [127.0.0.1]) by box.linuxcare.com.au (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id KAA29635; Fri, 11 Feb 2000 10:43:37 +1100 Message-Id: <200002102343.KAA29635@box.linuxcare.com.au> X-Authentication-Warning: box.linuxcare.com.au: Host localhost [127.0.0.1] claimed to be linuxcare.com From: Rusty Russell To: netdev@oss.sgi.com Cc: Willem Konynenberg Subject: (FORWARD) Willem Konynenberg: Re: Code cleanup (Was: Port) Date: Fri, 11 Feb 2000 10:43:37 +1100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi Dave, Please apply Willem's perfectly obvious patch, works v 2.3.43 as well. Rusty. --- v2.3.42/include/net/ip.h Tue Feb 1 02:13:06 2000 +++ linux/include/net/ip.h Tue Feb 8 00:01:33 2000 @@ -41,7 +41,6 @@ struct inet_skb_parm { struct ip_options opt; /* Compiled IP options */ - u16 redirport; /* Redirect port */ unsigned char flags; #define IPSKB_MASQUERADED 1 From owner-netdev@oss.sgi.com Thu Feb 10 16:41:28 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 16:41:18 -0800 Received: from laurin.munich.netsurf.de ([194.64.166.1]:55255 "EHLO laurin.munich.netsurf.de") by oss.sgi.com with ESMTP id ; Thu, 10 Feb 2000 16:40:52 -0800 Received: from fred.muc.de (none@ns1031.munich.netsurf.de [195.180.235.31]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id BAA24697; Fri, 11 Feb 2000 01:40:45 +0100 (MET) Received: from andi by fred.muc.de with local (Exim 2.05 #1) id 12J4AJ-0000iU-00; Fri, 11 Feb 2000 01:42:31 +0100 Date: Fri, 11 Feb 2000 01:42:31 +0100 From: Andi Kleen To: magicboiz@softhome.net Cc: netdev@oss.sgi.com Subject: Re: Question on i2.2 kernel ipv4 stack code Message-ID: <20000211014231.A2750@fred.muc.de> References: <20000210.21122000@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <20000210.21122000@localhost.localdomain>; from magicboiz@softhome.net on Thu, Feb 10, 2000 at 11:58:52PM +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Thu, Feb 10, 2000 at 11:58:52PM +0100, magicboiz@softhome.net wrote: > Hello all, > > I know people here works on next kernel version, but perhaps some of > you can > help me. > > In file ip_input.c, function ip_rcv, how can I know if a received skb > is for our machine > if no sock (and no transport protocol) is waitting that packet(skb)?, > Is there an easy way to > determine if skb->nh.iph.daddr is our ip addr?. I hope you can > understand me :) Check ((struct rtable *) skb->dst)->rt_flags & RTCF_LOCAL -Andi -- This is like TV. I don't like TV. From owner-netdev@oss.sgi.com Thu Feb 10 18:19:39 2000 Received: by oss.sgi.com id ; Thu, 10 Feb 2000 18:19:19 -0800 Received: from pizda.ninka.net ([216.101.162.242]:15232 "EHLO pizda.ninka.net") by oss.sgi.com with ESMTP id ; Thu, 10 Feb 2000 18:18:58 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id SAA03287; Thu, 10 Feb 2000 18:15:18 -0800 Date: Thu, 10 Feb 2000 18:15:18 -0800 Message-Id: <200002110215.SAA03287@pizda.ninka.net> X-Authentication-Warning: pizda.ninka.net: davem set sender to davem@redhat.com using -f From: "David S. Miller" To: rusty@linuxcare.com.au CC: netdev@oss.sgi.com, wfk@xos.nl In-reply-to: <200002102343.KAA29635@box.linuxcare.com.au> (message from Rusty Russell on Fri, 11 Feb 2000 10:43:37 +1100) Subject: Re: (FORWARD) Willem Konynenberg: Re: Code cleanup (Was: Port) References: <200002102343.KAA29635@box.linuxcare.com.au> Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing From: Rusty Russell Date: Fri, 11 Feb 2000 10:43:37 +1100 Please apply Willem's perfectly obvious patch, works v 2.3.43 as well. Patch applied, will go to Linus tonight. Thanks. Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Fri Feb 11 01:07:39 2000 Received: by oss.sgi.com id ; Fri, 11 Feb 2000 01:07:29 -0800 Received: from mail0.u-aizu.ac.jp ([163.143.1.43]:7878 "EHLO mail0.u-aizu.ac.jp") by oss.sgi.com with ESMTP id ; Fri, 11 Feb 2000 01:07:08 -0800 Received: from ccultra2.u-aizu.ac.jp (ccultra2.u-aizu.ac.jp [163.143.99.104]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id SAA05721; Fri, 11 Feb 2000 18:07:02 +0900 (JST) Received: from ccultra2.u-aizu.ac.jp ([163.143.99.156]) by ccultra2.u-aizu.ac.jp (8.9.1b+Sun/8.8.8) with ESMTP id SAA21232; Fri, 11 Feb 2000 18:03:42 +0900 (JST) Message-ID: <38A3D170.EBA92D8B@ccultra2.u-aizu.ac.jp> Date: Fri, 11 Feb 2000 18:08:01 +0900 From: Behcet Sarikaya X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: netdev@nuclecu.unam.mx CC: coronach@succubus.dhis.org, netdev@oss.sgi.com, sekiya@isi.edu Subject: sit configuration question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello, I have a question on how to configure sit on a Linux host (IPv4 address is 163.143.99.101) for v6. I have a working sit (sit1) to 6bone-jp, now I need to configure another sit (sit2) for a local host on a different subnet. Using the following script I can configure sit1 to Tokyo (203.178.136.188): $ifconfig sit0 tunnel ::203.178.136.188 $ifconfig sit1 inet6 add 3ffe:501:427::163.143.99.101/64 $ifconfig sit1 mtu 1280 $ifconfig sit1 up $route -A inet6 add 3ffe::0/16 gw fe80::203.178.136.188 dev sit1 $route -A inet6 add 3ffe::0/16 gw ::203.178.136.188 dev sit0 To configure sit2 to a local host (163.143.180.107) I did ifconfig sit0 tunnel ::163.143.180.107 ifconfig sit2 mtu 1280 ifconfig sit2 up This is OK but I can not communicate with the host 163.143.180.107 on ipv6. Should sit2 have a global address? What are the route add commands that I need? Thanks in advance, Behcet Sarikaya University of Aizu From owner-netdev@oss.sgi.com Fri Feb 11 07:43:27 2000 Received: by oss.sgi.com id ; Fri, 11 Feb 2000 07:43:17 -0800 Received: from hill-b-039.resnet.purdue.edu ([128.211.205.39]:55044 "EHLO hill-b-039.resnet.purdue.edu") by oss.sgi.com with ESMTP id ; Fri, 11 Feb 2000 07:42:52 -0800 Received: from tremere (tremere.succubus.ml.org [192.168.1.10]) by hill-b-039.resnet.purdue.edu (8.9.3/8.9.3/Debian 8.9.3-6) with SMTP id KAA04305; Fri, 11 Feb 2000 10:43:06 -0500 X-Authentication-Warning: hill-b-039.resnet.purdue.edu: Host tremere.succubus.ml.org [192.168.1.10] claimed to be tremere From: "Michael A. Lemler" To: "Behcet Sarikaya" Cc: Subject: RE: sit configuration question Date: Fri, 11 Feb 2000 10:42:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38A3D170.EBA92D8B@ccultra2.u-aizu.ac.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hopefully this will help you. You do not need the extra MTU setting. 1280 is the min for IPv6 if you do not have an underlying layer 2 technology that will handle the fragmentation. So, if you are going across Ethernet or have not messed with default settings, you can leave the MTU at 1500. Second of all, you need to something on the order of this: Another_IPv4_Tunnel = 123.142.102.101 # The destination IP here Another_IPv6_subnet = 3ffe:501:427:1 # IPv6 Subnet to Route /sbin/ifconfig sit0 tunnel ::$Another_IPv4_Tunnel /sbin/ifconfig sit2 up /sbin/route -A inet6 add $Another_IPv6_subnet::0/64 gw fe80::$Another_IPv4_Tunnel dev sit2 Now, you can get rid of this line also "$route -A inet6 add 3ffe::0/16 gw ::203.178.136.188 dev sit0" as it is also not needed. Sit1 is your default gateway and gateway for the 6bone. Note, please make sure you have a "echo 1 > /proc/sys/net/ipv6/conf/all/forwarding" some where to enable IPv6 forwarding. That takes care of the tunnel provider. You need to then configure the tunnel end point much like the first. Here is a snippet from the scripts I have made. Most of the variables are self explanatory, but IPv6_PROVIDER_TUNNEL is the IPv4 address of machine you are tunneling to. /sbin/ifconfig eth0 add $IPv6_PREFIX::$IPv6_ADDR/$IPv6_ADDRMASK /sbin/route -A inet6 add $IPv6_PREFIX::0/$IPv6_ADDRMASK dev eth0 /sbin/ifconfig sit0 up tunnel ::$IPv6_PROVIDER_TUNNEL /sbin/ifconfig sit1 up /sbin/route -A inet6 add 3ffe::0/16 gw fe80::$IPv6_PROVIDER_TUNNEL dev sit1 If that doesn't work, let me know. Michael A. Lemler Undergrad, University Of Purdue -----Original Message----- From: Behcet Sarikaya [mailto:sarikaya@ccultra2.u-aizu.ac.jp] Sent: Friday, February 11, 2000 4:08 AM To: netdev@nuclecu.unam.mx Cc: coronach@succubus.dhis.org; netdev@oss.sgi.com; sekiya@isi.edu Subject: sit configuration question Hello, I have a question on how to configure sit on a Linux host (IPv4 address is 163.143.99.101) for v6. I have a working sit (sit1) to 6bone-jp, now I need to configure another sit (sit2) for a local host on a different subnet. Using the following script I can configure sit1 to Tokyo (203.178.136.188): $ifconfig sit0 tunnel ::203.178.136.188 $ifconfig sit1 inet6 add 3ffe:501:427::163.143.99.101/64 $ifconfig sit1 mtu 1280 $ifconfig sit1 up $route -A inet6 add 3ffe::0/16 gw fe80::203.178.136.188 dev sit1 $route -A inet6 add 3ffe::0/16 gw ::203.178.136.188 dev sit0 To configure sit2 to a local host (163.143.180.107) I did ifconfig sit0 tunnel ::163.143.180.107 ifconfig sit2 mtu 1280 ifconfig sit2 up This is OK but I can not communicate with the host 163.143.180.107 on ipv6. Should sit2 have a global address? What are the route add commands that I need? Thanks in advance, Behcet Sarikaya University of Aizu From owner-netdev@oss.sgi.com Fri Feb 11 07:55:57 2000 Received: by oss.sgi.com id ; Fri, 11 Feb 2000 07:55:37 -0800 Received: from quechua.inka.de ([212.227.14.2]:27242 "EHLO mail.inka.de") by oss.sgi.com with ESMTP id ; Fri, 11 Feb 2000 07:55:15 -0800 Received: from dungeon.inka.de by mail.inka.de with uucp (rmailwrap 0.4) id 12JIPW-0003vE-00; Fri, 11 Feb 2000 16:55:10 +0100 Received: by dungeon.inka.de (Postfix, from userid 1000) id C0576B781F; Fri, 11 Feb 2000 16:48:38 +0100 (CET) Date: Fri, 11 Feb 2000 16:48:38 +0100 From: Andreas Jellinghaus To: "Michael A. Lemler" Cc: Behcet Sarikaya , netdev@oss.sgi.com Subject: Re: sit configuration question Message-ID: <20000211164838.A12915@dungeon.inka.de> References: <38A3D170.EBA92D8B@ccultra2.u-aizu.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Michael A. Lemler on Fri, Feb 11, 2000 at 10:42:45AM -0500 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing i wonder what the idea behind the network interface "sit0" is. i created my tunnels without it, and it works fine. andreas *** sit tunnel config with ip *** ip tunnel add sit1 mode sit remote 129.13.35.16 local 129.13.126.154 ip link set sit1 up ip route add 3ffe:400:20:0::0/64 dev sit1 metric 256 ip -f inet6 route add default dev sit1 metric 512 From owner-netdev@oss.sgi.com Fri Feb 11 08:08:47 2000 Received: by oss.sgi.com id ; Fri, 11 Feb 2000 08:08:37 -0800 Received: from hill-b-039.resnet.purdue.edu ([128.211.205.39]:57348 "EHLO hill-b-039.resnet.purdue.edu") by oss.sgi.com with ESMTP id ; Fri, 11 Feb 2000 08:08:20 -0800 Received: from tremere (tremere.succubus.ml.org [192.168.1.10]) by hill-b-039.resnet.purdue.edu (8.9.3/8.9.3/Debian 8.9.3-6) with SMTP id LAA04379; Fri, 11 Feb 2000 11:08:33 -0500 X-Authentication-Warning: hill-b-039.resnet.purdue.edu: Host tremere.succubus.ml.org [192.168.1.10] claimed to be tremere From: "Michael A. Lemler" To: "Andreas Jellinghaus" Cc: "Behcet Sarikaya" , Subject: RE: sit configuration question Date: Fri, 11 Feb 2000 11:08:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20000211164838.A12915@dungeon.inka.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Any devices that are sit[1..n] are for the client side of the connection. sit0 is reserved for the server side of the tunnel. So, if you just have one machine tunneling into an existing host and do not need to serve another tunnel from it, you do not need sit0. --Mike -----Original Message----- From: Andreas Jellinghaus [mailto:aj@dungeon.inka.de] Sent: Friday, February 11, 2000 10:49 AM To: Michael A. Lemler Cc: Behcet Sarikaya; netdev@oss.sgi.com Subject: Re: sit configuration question i wonder what the idea behind the network interface "sit0" is. i created my tunnels without it, and it works fine. andreas *** sit tunnel config with ip *** ip tunnel add sit1 mode sit remote 129.13.35.16 local 129.13.126.154 ip link set sit1 up ip route add 3ffe:400:20:0::0/64 dev sit1 metric 256 ip -f inet6 route add default dev sit1 metric 512 From owner-netdev@oss.sgi.com Fri Feb 11 10:20:18 2000 Received: by oss.sgi.com id ; Fri, 11 Feb 2000 10:20:10 -0800 Received: from mainframe.dgrc.crc.ca ([142.92.38.206]:38544 "EHLO mainframe.dgrc.crc.ca") by oss.sgi.com with ESMTP id ; Fri, 11 Feb 2000 10:19:50 -0800 Received: from crc.ca (curly [142.92.38.251]) by mainframe.dgrc.crc.ca (8.9.3/8.9.3) with ESMTP id NAA14147; Fri, 11 Feb 2000 13:14:58 -0500 (EST) Message-ID: <38A45295.DC68319C@crc.ca> Date: Fri, 11 Feb 2000 13:19:01 -0500 From: Guilhem Tardy Organization: CRC X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ak@muc.de CC: netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Same question on i2.2 kernel, but for ipv6 stack code References: <20000210.21122000@localhost.localdomain> <20000211014231.A2750@fred.muc.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Andi Kleen wrote: > > > > > In file ip_input.c, function ip_rcv, how can I know if a received skb > > is for our machine > > if no sock (and no transport protocol) is waitting that packet(skb)?, > > Is there an easy way to > > determine if skb->nh.iph.daddr is our ip addr?. I hope you can > > understand me :) > > Check ((struct rtable *) skb->dst)->rt_flags & RTCF_LOCAL > > -Andi > How would you do that for an skb with a IPv6 packet? I want to know if an arbitrary IPv6 address is an on-link address for the receiving node, and I need to check the prefix length of the subnet corresponding to this link. Finally, how does a node know if it is a router itself? (probably a #define) PS Alexey: Sorry for asking the same question again, it is just to let you know that my usual email system is back to normal (at last). -- Guilhem Tardy phone: (613) 993-8232 Network Systems and Technologies fax: (613) 998-9648 Communications Research Center email: Guilhem.Tardy@crc.ca 3701 Carling Ave. #28/2B web: http://www.crc.ca/ Ottawa (Ontario) K2H 8S2 From owner-netdev@oss.sgi.com Fri Feb 11 21:28:53 2000 Received: by oss.sgi.com id ; Fri, 11 Feb 2000 21:28:44 -0800 Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:60680 "EHLO grok.myip.org") by oss.sgi.com with ESMTP id ; Fri, 11 Feb 2000 21:28:23 -0800 Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1]) by grok.myip.org (8.9.3/8.9.3) with ESMTP id WAA02443; Fri, 11 Feb 2000 22:51:09 -0700 Message-ID: <38A4F4CD.4C15E15C@candelatech.com> Date: Fri, 11 Feb 2000 22:51:09 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: VLAN Mailing List , "netdev@oss.sgi.com" Subject: Question on porting to 2.3 kernel: __initfunc Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Seems we no longer use __initfunc in 2.3, eh? Anyone care to clue me in to what takes its place? This is in context of the VLAN device code, btw. Thanks, Ben -- Ben Greear (greearb@candelatech.com) http://scry.wanfear.com/~greear Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL) http://scry.wanfear.com From owner-netdev@oss.sgi.com Fri Feb 11 21:36:54 2000 Received: by oss.sgi.com id ; Fri, 11 Feb 2000 21:36:44 -0800 Received: from pizda.ninka.net ([216.101.162.242]:27776 "EHLO pizda.ninka.net") by oss.sgi.com with ESMTP id ; Fri, 11 Feb 2000 21:36:43 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA02560; Fri, 11 Feb 2000 21:33:10 -0800 Date: Fri, 11 Feb 2000 21:33:10 -0800 Message-Id: <200002120533.VAA02560@pizda.ninka.net> X-Authentication-Warning: pizda.ninka.net: davem set sender to davem@redhat.com using -f From: "David S. Miller" To: greearb@candelatech.com CC: vlan@Scry.WANfear.com, netdev@oss.sgi.com In-reply-to: <38A4F4CD.4C15E15C@candelatech.com> (message from Ben Greear on Fri, 11 Feb 2000 22:51:09 -0700) Subject: Re: Question on porting to 2.3 kernel: __initfunc References: <38A4F4CD.4C15E15C@candelatech.com> Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Date: Fri, 11 Feb 2000 22:51:09 -0700 From: Ben Greear Seems we no longer use __initfunc in 2.3, eh? Anyone care to clue me in to what takes its place? "__init" Later, David S. Miller davem@redhat.com From owner-netdev@oss.sgi.com Sat Feb 12 00:20:55 2000 Received: by oss.sgi.com id ; Sat, 12 Feb 2000 00:20:36 -0800 Received: from mail0.u-aizu.ac.jp ([163.143.1.43]:56565 "EHLO mail0.u-aizu.ac.jp") by oss.sgi.com with ESMTP id ; Sat, 12 Feb 2000 00:20:15 -0800 Received: from ccultra2.u-aizu.ac.jp (ccultra2.u-aizu.ac.jp [163.143.99.104]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id RAA23286; Sat, 12 Feb 2000 17:20:12 +0900 (JST) Received: from ccultra2.u-aizu.ac.jp (ccss1051 [163.143.180.107]) by ccultra2.u-aizu.ac.jp (8.9.1b+Sun/8.8.8) with ESMTP id RAA22050; Sat, 12 Feb 2000 17:16:53 +0900 (JST) Message-ID: <38A51BD7.39093438@ccultra2.u-aizu.ac.jp> Date: Sat, 12 Feb 2000 17:37:43 +0900 From: Behcet Sarikaya Organization: University of Aizu X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.14 ppc) X-Accept-Language: en MIME-Version: 1.0 To: coronach@succubus.dhis.org, netdev@oss.sgi.com, sarikaya@ccultra2.u-aizu.ac.jp Subject: sit configuration Content-Type: multipart/mixed; boundary="------------4DF31DFBEE0E7A6B44F2D0E3" Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing This is a multi-part message in MIME format. --------------4DF31DFBEE0E7A6B44F2D0E3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Michael, I did like you said but it did not work! Firstly, 1280 is required for tunnels to 6bone-jp, so I kept it at 1280. I am attaching the v6 startup shell on tunnel endpoint machine (163.143.180.107) which has two interfaces, so I create two prefixes 3ffe:501:427:1002 and 3ffe:501:427:1102 and I run mrtd, I am attaching mrtd.conf as well. On the tunnel provider host, I ran a script to create sit2 and I include this script (ipv6.sh.tun2). On this host too I ahve two interface and I am running mrtd with a similar conf file (with network sit2 added on ripng). Thanks in advance, -- Behcet Sarikaya Computer Communications Lab. --------------4DF31DFBEE0E7A6B44F2D0E3 Content-Type: application/x-sh; name="ipv6.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipv6.sh" #!/bin/bash ifconfig=/sbin/ifconfig route=/sbin/route ## Initial MTU setting. $ifconfig sit0 mtu 1280 ## local IP address # Your IPv6 prefix PREFIX=3ffe:501:427 ADDRESS1=163.143.180.107 ADDRESS2=163.143.180.100 #PREFIX_LEN=48 PREFIX_LEN=64 ## gateway IP address TUNNEL_IPV4=163.143.99.101 echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra echo 1 > /proc/sys/net/ipv6/conf/all/accept_redirects echo 1 > /proc/sys/net/ipv6/conf/all/forwarding # local interface $ifconfig sit0 up $ifconfig eth0 add $PREFIX:1002::$ADDRESS1/$PREFIX_LEN $ifconfig eth1 add $PREFIX:1102::$ADDRESS2/$PREFIX_LEN $route -A inet6 add $PREFIX::0/48 dev eth0 #$route -A inet6 add $PREFIX:1100:0/64 dev eth1 # tunnel $ifconfig sit0 tunnel ::$TUNNEL_IPV4 $ifconfig sit1 up $ifconfig sit1 inet6 add $PREFIX::$ADDRESS1 $ifconfig sit1 mtu 1280 $route -A inet6 add 3ffe::0/16 gw fe80::$TUNNEL_IPV4 dev sit1 #$route -A inet6 add 3ffe::0/16 gw ::$TUNNEL_IPV4 dev sit0 # Boot MRTd and radvd /usr/local/sbin/mrtd /usr/local/sbin/radvd --------------4DF31DFBEE0E7A6B44F2D0E3 Content-Type: text/plain; charset=us-ascii; name="mrtd.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mrtd.conf" !#################################################################### ! MRTd -- MRT version 1.4.9 Alpha [09/04/98] !#################################################################### ! password merit debug all /tmp/MRTd.log 100000 ! access-list 1 permit 3ffe:501:427::/48 access-list 1 deny all ! ! router rip network eth0 network eth1 redistribute direct redistribute connected ! router ripng network eth0 network eth1 redistribute direct redistribute connected ! router ripng network sit1 redistribute connected redistribute static redistribute direct distribute-list 1 out sit1 ! ip route 0.0.0.0/0 163.143.180.1 --------------4DF31DFBEE0E7A6B44F2D0E3 Content-Type: text/plain; charset=us-ascii; name="ipv6.sh.tun2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipv6.sh.tun2" #!/bin/bash ifconfig=/sbin/ifconfig route=/sbin/route ## Initial MTU setting. #$ifconfig sit0 ## local IP address # Your IPv6 prefix PREFIX=3ffe:501:427 ADDRESS1=163.143.99.101 ADDRESS2=163.143.226.100 #PREFIX_LEN=48 PREFIX_LEN=64 ## gateway IP address TUNNEL_IPV4=203.178.136.188 Another_IPv6_Tunnel=163.143.180.107 Another_IPv6_Subnet=3ffe:501:427:1002 # tunnel #Another tunnel $ifconfig sit0 tunnel ::$Another_IPv6_Tunnel $ifconfig sit2 mtu 1280 $ifconfig sit2 up $route -A inet6 add $Another_IPv6_Subnet::0/64 gw fe80::$Another_IPv6_Tunnel dev sit2 --------------4DF31DFBEE0E7A6B44F2D0E3-- From owner-netdev@oss.sgi.com Sat Feb 12 01:03:16 2000 Received: by oss.sgi.com id ; Sat, 12 Feb 2000 01:03:06 -0800 Received: from hill-b-039.resnet.purdue.edu ([128.211.205.39]:19973 "EHLO hill-b-039.resnet.purdue.edu") by oss.sgi.com with ESMTP id ; Sat, 12 Feb 2000 01:02:45 -0800 Received: from tremere (tremere.succubus.ml.org [192.168.1.10]) by hill-b-039.resnet.purdue.edu (8.9.3/8.9.3/Debian 8.9.3-6) with SMTP id EAA08198; Sat, 12 Feb 2000 04:03:01 -0500 X-Authentication-Warning: hill-b-039.resnet.purdue.edu: Host tremere.succubus.ml.org [192.168.1.10] claimed to be tremere From: "Michael A. Lemler" To: , Subject: RE: sit configuration Date: Sat, 12 Feb 2000 04:02:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38A51BD7.39093438@ccultra2.u-aizu.ac.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing OK, let's go through this and correct as needed: >echo 1 > /proc/sys/net/ipv6/conf/all/accept_redirects Do you really want redirects? >$route -A inet6 add $PREFIX::0/48 dev eth0 Why 48 bits? >$ifconfig sit1 inet6 add $PREFIX::$ADDRESS1 Remove the above line Eliminate mrtd and radvd from the config until you get the basic tunnel working... process of elimination, simplify I _think_ everything else looks ok and I hope I have not missed anything. The important thing now is to test connectivity. First, try your basic ping6 ::1, then move to a ping6 ::ipv4addr where the addr is the other side of the tunnel. Do any of those fail? If not, where do you see connectivity fail? When attempting to ping6 other devices on the 6bone? You can, if you'd like, reference the scripts I have placed online for use. http://succubus.dhis.org/~coronach/ipv6 will have two scripts and a config file. The first script is real rough and the second is an improvement but hopefully it will help. These scripts are being used right now to connect several machines to the 6bone here at Purdue. If you have suggestions about the script, problems, etc, please e-mail the address in the header. --Mike -----Original Message----- From: sarikaya@ccultra2.u-aizu.ac.jp [mailto:sarikaya@ccultra2.u-aizu.ac.jp] Sent: Saturday, February 12, 2000 3:38 AM To: coronach@succubus.dhis.org; netdev@oss.sgi.com; sarikaya@ccultra2.u-aizu.ac.jp Subject: sit configuration Hello Michael, I did like you said but it did not work! Firstly, 1280 is required for tunnels to 6bone-jp, so I kept it at 1280. I am attaching the v6 startup shell on tunnel endpoint machine (163.143.180.107) which has two interfaces, so I create two prefixes 3ffe:501:427:1002 and 3ffe:501:427:1102 and I run mrtd, I am attaching mrtd.conf as well. On the tunnel provider host, I ran a script to create sit2 and I include this script (ipv6.sh.tun2). On this host too I ahve two interface and I am running mrtd with a similar conf file (with network sit2 added on ripng). Thanks in advance, -- Behcet Sarikaya Computer Communications Lab. From owner-netdev@oss.sgi.com Sat Feb 12 10:32:08 2000 Received: by oss.sgi.com id ; Sat, 12 Feb 2000 10:31:59 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:46610 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Sat, 12 Feb 2000 10:31:37 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA14925; Sat, 12 Feb 2000 21:31:23 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002121831.VAA14925@ms2.inr.ac.ru> Subject: Re: Same question on i2.2 kernel, but for ipv6 stack code To: Guilhem.Tardy@crc.ca (Guilhem Tardy) Date: Sat, 12 Feb 2000 21:31:23 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: <38A45295.DC68319C@crc.ca> from "Guilhem Tardy" at Feb 11, 0 01:19:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 1050 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > How would you do that for an skb with a IPv6 packet? Currently there is no simple way to get this. Simply it is not required, because it is controlled not by flags but by input method. One receipt is !dst->error && dst->dev == loopback, another one is dst->input == ip6_input. > I want to know if an arbitrary IPv6 address is an on-link address for > the receiving node, > and I need to check the prefix length of the subnet corresponding to > this link. What is problem? Scan address list and check this. Kernel never needs to know such information (actually, it is not well-defined in IPv6), so that such routine is missing. I have strong impression that if some protocol needs to ask questions sort of "A is on-link or not?", it is the first candidate to be moved to user space. It is pure policy issue in IPv6. F.e. redirected address is on-link or not on-link? For kernel it is simply meaningless. > Finally, how does a node know if it is a router itself? (probably a > #define) It is variable ipv6_devconf.forwarding. Alexey From owner-netdev@oss.sgi.com Sat Feb 12 11:05:19 2000 Received: by oss.sgi.com id ; Sat, 12 Feb 2000 11:04:59 -0800 Received: from [206.171.92.89] ([206.171.92.89]:57610 "HELO penguin.filetron.com") by oss.sgi.com with SMTP id ; Sat, 12 Feb 2000 11:04:41 -0800 Received: (qmail 2147 invoked from network); 12 Feb 2000 19:00:09 -0000 Received: from ns1.filetron.com (httpd@206.171.92.1) by 206.171.92.89 with SMTP; 12 Feb 2000 19:00:09 -0000 Received: (from httpd@localhost) by ns1.filetron.com (8.8.7/8.8.7) id LAA11990; Sat, 12 Feb 2000 11:04:30 -0800 Date: Sat, 12 Feb 2000 11:04:30 -0800 Message-Id: <200002121904.LAA11990@ns1.filetron.com> Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.103 (Entity 4.115) From: David Jeffery To: netdev@oss.sgi.com Subject: ip6 udp panic from accept Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing It appears that the strange non-fatal udp panic I have been able to produce is caused by socktest illegally trying to call accept() on an ip6 udp socket. ip4 correctly returns an error while ip6 panics. illegally calling listen() though correctly returns an error under ip6. So somewhere in the ip6 code accept is failing to check that the socket is a tcp socket. To exploit it, just bind a udp port, and then call accept on it. The program segfaults and the port becomes "stuck" and can't be successfully bound to again. If someone wants a sample program that does this, or a panic trace, let me know. David "LordBeatnik" Jeffery ---------------------- Do you do Linux? :) Get your FREE @linuxstart.com email address at: http://www.linuxstart.com From owner-netdev@oss.sgi.com Sat Feb 12 17:20:00 2000 Received: by oss.sgi.com id ; Sat, 12 Feb 2000 17:19:50 -0800 Received: from [206.171.92.89] ([206.171.92.89]:41483 "HELO penguin.filetron.com") by oss.sgi.com with SMTP id ; Sat, 12 Feb 2000 17:19:29 -0800 Received: (qmail 16077 invoked from network); 13 Feb 2000 01:14:54 -0000 Received: from ns1.filetron.com (httpd@206.171.92.1) by 206.171.92.89 with SMTP; 13 Feb 2000 01:14:54 -0000 Received: (from httpd@localhost) by ns1.filetron.com (8.8.7/8.8.7) id RAA03133; Sat, 12 Feb 2000 17:19:14 -0800 Date: Sat, 12 Feb 2000 17:19:14 -0800 Message-Id: <200002130119.RAA03133@ns1.filetron.com> Mime-Version: 1.0 X-Mailer: MIME-tools 4.103 (Entity 4.115) From: David Jeffery To: netdev@oss.sgi.com Subject: [patch] nf6 for 2.3.44 Content-Type: multipart/mixed; boundary="----------=_950404754-3131-0" Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing This is a multi-part message in MIME format... ------------=_950404754-3131-0 Content-Type: text/plain Content-Disposition: inline Here's an updated patch for adding netfilter hooks to ipv6. This is an important bug fix release. Earlier versions were missing an error return that could've allowed a null pointer to be dereferenced in ip6_maybe_reroute. Alexey, any chance of this sneaking in before 2.4? David Jeffery ---------------------- Do you do Linux? :) Get your FREE @linuxstart.com email address at: http://www.linuxstart.com ------------=_950404754-3131-0 Content-Type: application/octet-stream; name="nf6-2.3.44.patch" Content-Disposition: inline; filename="nf6-2.3.44.patch" Content-Transfer-Encoding: base64 ZGlmZiAtdSAtciAtTiBsaW51eC0yLjMuNDQvaW5jbHVkZS9saW51eC9uZXRm aWx0ZXJfaXB2Ni5oIGxpbnV4L2luY2x1ZGUvbGludXgvbmV0ZmlsdGVyX2lw djYuaAotLS0gbGludXgtMi4zLjQ0L2luY2x1ZGUvbGludXgvbmV0ZmlsdGVy X2lwdjYuaAlXZWQgRGVjIDMxIDE5OjAwOjAwIDE5NjkKKysrIGxpbnV4L2lu Y2x1ZGUvbGludXgvbmV0ZmlsdGVyX2lwdjYuaAlTYXQgRmViIDEyIDE3OjI0 OjA2IDIwMDAKQEAgLTAsMCArMSw1OCBAQAorI2lmbmRlZiBfX0xJTlVYX0lQ Nl9ORVRGSUxURVJfSAorI2RlZmluZSBfX0xJTlVYX0lQNl9ORVRGSUxURVJf SAorCisvKiBJUHY2LXNwZWNpZmljIGRlZmluZXMgZm9yIG5ldGZpbHRlci4g CisgKiAoQykxOTk4IFJ1c3R5IFJ1c3NlbGwgLS0gVGhpcyBjb2RlIGlzIEdQ TC4KKyAqIChDKTE5OTkgRGF2aWQgSmVmZmVyeQorICogICB0aGlzIGhlYWRl ciB3YXMgYmxhdGFudGx5IHJpcHBlZCBmcm9tIG5ldGZpbHRlcl9pcHY0Lmgg CisgKiAgIGl0J3MgYW1hemluZyB3aGF0IGFkZGluZyBhIGJ1bmNoIG9mIDZz IGNhbiBkbyA9OF4pCisgKi8KKworI2luY2x1ZGUgPGxpbnV4L2NvbmZpZy5o PgorI2luY2x1ZGUgPGxpbnV4L25ldGZpbHRlci5oPgorCisvKiBJUCBDYWNo ZSBiaXRzLiAqLworLyogU3JjIElQIGFkZHJlc3MuICovCisjZGVmaW5lIE5G Q19JUDZfU1JDICAgICAgICAgICAgICAweDAwMDEKKy8qIERlc3QgSVAgYWRk cmVzcy4gKi8KKyNkZWZpbmUgTkZDX0lQNl9EU1QgICAgICAgICAgICAgIDB4 MDAwMgorLyogSW5wdXQgZGV2aWNlLiAqLworI2RlZmluZSBORkNfSVA2X0lG X0lOICAgICAgICAgICAgMHgwMDA0CisvKiBPdXRwdXQgZGV2aWNlLiAqLwor I2RlZmluZSBORkNfSVA2X0lGX09VVCAgICAgICAgICAgMHgwMDA4CisvKiBU T1MuICovCisjZGVmaW5lIE5GQ19JUDZfVE9TICAgICAgICAgICAgICAweDAw MTAKKy8qIFByb3RvY29sLiAqLworI2RlZmluZSBORkNfSVA2X1BST1RPICAg ICAgICAgICAgMHgwMDIwCisvKiBJUCBvcHRpb25zLiAqLworI2RlZmluZSBO RkNfSVA2X09QVElPTlMgICAgICAgICAgMHgwMDQwCisvKiBGcmFnICYgZmxh Z3MuICovCisjZGVmaW5lIE5GQ19JUDZfRlJBRyAgICAgICAgICAgICAweDAw ODAKKworCisvKiBQZXItcHJvdG9jb2wgaW5mb3JtYXRpb246IG9ubHkgbWF0 dGVycyBpZiBwcm90byBtYXRjaC4gKi8KKy8qIFRDUCBmbGFncy4gKi8KKyNk ZWZpbmUgTkZDX0lQNl9UQ1BGTEFHUyAgICAgICAgIDB4MDEwMAorLyogU291 cmNlIHBvcnQuICovCisjZGVmaW5lIE5GQ19JUDZfU1JDX1BUICAgICAgICAg ICAweDAyMDAKKy8qIERlc3QgcG9ydC4gKi8KKyNkZWZpbmUgTkZDX0lQNl9E U1RfUFQgICAgICAgICAgIDB4MDQwMAorLyogU29tZXRoaW5nIGVsc2UgYWJv dXQgdGhlIHByb3RvICovCisjZGVmaW5lIE5GQ19JUDZfUFJPVE9fVU5LTk9X TiAgICAweDIwMDAKKworCisvKiBJUDYgSG9va3MgKi8KKy8qIEFmdGVyIHBy b21pc2MgZHJvcHMsIGNoZWNrc3VtIGNoZWNrcy4gKi8KKyNkZWZpbmUgTkZf SVA2X1BSRV9ST1VUSU5HCTAKKy8qIElmIHRoZSBwYWNrZXQgaXMgZGVzdGlu ZWQgZm9yIHRoaXMgYm94LiAqLworI2RlZmluZSBORl9JUDZfTE9DQUxfSU4J CTEKKy8qIElmIHRoZSBwYWNrZXQgaXMgZGVzdGluZWQgZm9yIGFub3RoZXIg aW50ZXJmYWNlLiAqLworI2RlZmluZSBORl9JUDZfRk9SV0FSRAkJMgorLyog UGFja2V0cyBjb21pbmcgZnJvbSBhIGxvY2FsIHByb2Nlc3MuICovCisjZGVm aW5lIE5GX0lQNl9MT0NBTF9PVVQJCTMKKy8qIFBhY2tldHMgYWJvdXQgdG8g aGl0IHRoZSB3aXJlLiAqLworI2RlZmluZSBORl9JUDZfUE9TVF9ST1VUSU5H CTQKKyNkZWZpbmUgTkZfSVA2X05VTUhPT0tTCQk1CisKKworI2VuZGlmIC8q X19MSU5VWF9JUDZfTkVURklMVEVSX0gqLwpkaWZmIC11IC1yIC1OIGxpbnV4 LTIuMy40NC9uZXQvaXB2Ni9pcDZfaW5wdXQuYyBsaW51eC9uZXQvaXB2Ni9p cDZfaW5wdXQuYwotLS0gbGludXgtMi4zLjQ0L25ldC9pcHY2L2lwNl9pbnB1 dC5jCVR1ZSBKYW4gMTEgMTk6MDI6MTcgMjAwMAorKysgbGludXgvbmV0L2lw djYvaXA2X2lucHV0LmMJU2F0IEZlYiAxMiAxNzoyNDowNiAyMDAwCkBAIC0y Niw2ICsyNiw5IEBACiAjaW5jbHVkZSA8bGludXgvaW42Lmg+CiAjaW5jbHVk ZSA8bGludXgvaWNtcHY2Lmg+CiAKKyNpbmNsdWRlIDxsaW51eC9uZXRmaWx0 ZXIuaD4KKyNpbmNsdWRlIDxsaW51eC9uZXRmaWx0ZXJfaXB2Ni5oPgorCiAj aW5jbHVkZSA8bmV0L3NvY2suaD4KICNpbmNsdWRlIDxuZXQvc25tcC5oPgog CkBAIC0zOCw2ICs0MSwxNiBAQAogI2luY2x1ZGUgPG5ldC9hZGRyY29uZi5o PgogCiAKKworc3RhdGljIGludCBpcDZfcmN2X2ZpbmlzaCggc3RydWN0IHNr X2J1ZmYgKnNrYikgCit7CisKKwlpZiAoc2tiLT5kc3QgPT0gTlVMTCkKKwkJ aXA2X3JvdXRlX2lucHV0KHNrYik7CisKKwlyZXR1cm4gc2tiLT5kc3QtPmlu cHV0KHNrYik7Cit9CisKIGludCBpcHY2X3JjdihzdHJ1Y3Qgc2tfYnVmZiAq c2tiLCBzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgcGFja2V0X3R5 cGUgKnB0KQogewogCXN0cnVjdCBpcHY2aGRyICpoZHI7CkBAIC03NywxMiAr OTAsNyBAQAogCQkJcmV0dXJuIDA7CiAJCX0KIAl9Ci0KLQlpZiAoc2tiLT5k c3QgPT0gTlVMTCkKLQkJaXA2X3JvdXRlX2lucHV0KHNrYik7Ci0KLQlyZXR1 cm4gc2tiLT5kc3QtPmlucHV0KHNrYik7Ci0KKwlyZXR1cm4gTkZfSE9PSyhQ Rl9JTkVUNixORl9JUDZfUFJFX1JPVVRJTkcsIHNrYiwgZGV2LCBOVUxMLCBp cDZfcmN2X2ZpbmlzaCk7CiB0cnVuY2F0ZWQ6CiAJSVA2X0lOQ19TVEFUU19C SChJcDZJblRydW5jYXRlZFBrdHMpOwogZXJyOgpAQCAtOTcsNyArMTA1LDgg QEAKICAqCURlbGl2ZXIgdGhlIHBhY2tldCB0byB0aGUgaG9zdAogICovCiAK LWludCBpcDZfaW5wdXQoc3RydWN0IHNrX2J1ZmYgKnNrYikKKworc3RhdGlj IGlubGluZSBpbnQgaXA2X2lucHV0X2ZpbmlzaChzdHJ1Y3Qgc2tfYnVmZiAq c2tiKQogewogCXN0cnVjdCBpcHY2aGRyICpoZHIgPSBza2ItPm5oLmlwdjZo OwogCXN0cnVjdCBpbmV0Nl9wcm90b2NvbCAqaXBwcm90OwpAQCAtMTgwLDYg KzE4OSwxMiBAQAogCX0KIAogCXJldHVybiAwOworfQorCisKK2ludCBpcDZf aW5wdXQoc3RydWN0IHNrX2J1ZmYgKnNrYikKK3sKKwlyZXR1cm4gTkZfSE9P SyhQRl9JTkVUNixORl9JUDZfTE9DQUxfSU4sIHNrYiwgc2tiLT5kZXYsIE5V TEwsIGlwNl9pbnB1dF9maW5pc2gpOwogfQogCiBpbnQgaXA2X21jX2lucHV0 KHN0cnVjdCBza19idWZmICpza2IpCmRpZmYgLXUgLXIgLU4gbGludXgtMi4z LjQ0L25ldC9pcHY2L2lwNl9vdXRwdXQuYyBsaW51eC9uZXQvaXB2Ni9pcDZf b3V0cHV0LmMKLS0tIGxpbnV4LTIuMy40NC9uZXQvaXB2Ni9pcDZfb3V0cHV0 LmMJVHVlIEphbiAxMSAxOTowMjoxNyAyMDAwCisrKyBsaW51eC9uZXQvaXB2 Ni9pcDZfb3V0cHV0LmMJU2F0IEZlYiAxMiAxNzo0NTowNiAyMDAwCkBAIC0z NCw2ICszNCw5IEBACiAjaW5jbHVkZSA8bGludXgvaW42Lmg+CiAjaW5jbHVk ZSA8bGludXgvcm91dGUuaD4KIAorI2luY2x1ZGUgPGxpbnV4L25ldGZpbHRl ci5oPgorI2luY2x1ZGUgPGxpbnV4L25ldGZpbHRlcl9pcHY2Lmg+CisKICNp bmNsdWRlIDxuZXQvc29jay5oPgogI2luY2x1ZGUgPG5ldC9zbm1wLmg+CiAK QEAgLTU3LDYgKzYwLDI2IEBACiAJc3Bpbl91bmxvY2tfYmgoJmlwNl9pZF9s b2NrKTsKIH0KIAorc3RhdGljIGlubGluZSBpbnQgaXA2X291dHB1dF9maW5p c2goc3RydWN0IHNrX2J1ZmYgKnNrYikKK3sKKworCXN0cnVjdCBkc3RfZW50 cnkgKmRzdCA9IHNrYi0+ZHN0OworCXN0cnVjdCBoaF9jYWNoZSAqaGggPSBk c3QtPmhoOworCisJaWYgKGhoKSB7CisJCXJlYWRfbG9ja19iaCgmaGgtPmho X2xvY2spOworCQltZW1jcHkoc2tiLT5kYXRhIC0gMTYsIGhoLT5oaF9kYXRh LCAxNik7CisJCXJlYWRfdW5sb2NrX2JoKCZoaC0+aGhfbG9jayk7CisJICAg ICAgICBza2JfcHVzaChza2IsIGhoLT5oaF9sZW4pOworCQlyZXR1cm4gaGgt PmhoX291dHB1dChza2IpOworCX0gZWxzZSBpZiAoZHN0LT5uZWlnaGJvdXIp CisJCXJldHVybiBkc3QtPm5laWdoYm91ci0+b3V0cHV0KHNrYik7CisKKwlr ZnJlZV9za2Ioc2tiKTsKKwlyZXR1cm4gLUVJTlZBTDsKKworfQorCiBpbnQg aXA2X291dHB1dChzdHJ1Y3Qgc2tfYnVmZiAqc2tiKQogewogCXN0cnVjdCBk c3RfZW50cnkgKmRzdCA9IHNrYi0+ZHN0OwpAQCAtODQsMTcgKzEwNyw0MCBA QAogCQlJUDZfSU5DX1NUQVRTKElwNk91dE1jYXN0UGt0cyk7CiAJfQogCi0J aWYgKGhoKSB7Ci0JCXJlYWRfbG9ja19iaCgmaGgtPmhoX2xvY2spOwotCQlt ZW1jcHkoc2tiLT5kYXRhIC0gMTYsIGhoLT5oaF9kYXRhLCAxNik7Ci0JCXJl YWRfdW5sb2NrX2JoKCZoaC0+aGhfbG9jayk7Ci0JICAgICAgICBza2JfcHVz aChza2IsIGhoLT5oaF9sZW4pOwotCQlyZXR1cm4gaGgtPmhoX291dHB1dChz a2IpOwotCX0gZWxzZSBpZiAoZHN0LT5uZWlnaGJvdXIpCi0JCXJldHVybiBk c3QtPm5laWdoYm91ci0+b3V0cHV0KHNrYik7CisJcmV0dXJuIE5GX0hPT0so UEZfSU5FVDYsIE5GX0lQNl9QT1NUX1JPVVRJTkcsIHNrYixOVUxMLCBza2It PmRldixpcDZfb3V0cHV0X2ZpbmlzaCk7CiAKLQlrZnJlZV9za2Ioc2tiKTsK LQlyZXR1cm4gLUVJTlZBTDsKK30KKworI2lmZGVmIENPTkZJR19ORVRGSUxU RVIKK3N0YXRpYyBpbnQgcm91dGU2X21lX2hhcmRlcihzdHJ1Y3Qgc2tfYnVm ZiAqc2tiKQoreworCXN0cnVjdCBpcHY2aGRyICppcDZoID0gc2tiLT5uaC5p cHY2aDsKKwlzdHJ1Y3QgcnQ2X2luZm8gKnJ0NjsKKy8qIGlzIHRoaXMgcmln aHQ/IGlzIHRoaXMgdXNlIG9mIHJ0Nl9sb29rdXAgb24gdGhlc2UgTE9DQUxf T1VUIHBhY2tldHMKK2EgZ29vZCB3YXkgdG8gcmVyb3V0ZSBjaGFuZ2VkIHBh Y2tldHM/IERKCisgRklYTUUqLworCXJ0NiA9IHJ0Nl9sb29rdXAoJmlwNmgt PmRhZGRyLCAmaXA2aC0+c2FkZHIsIDAsIDApOworCisJaWYocnQ2ID09IE5V TEwpeworCQlwcmludGsoS0VSTl9ERUJVRyAicm91dGU2X21lX2hhcmRlciBm YWlsdXJlIFxuIik7CisJCXJldHVybiAtRUlOVkFMOworCX0KKwlza2ItPmRz dCA9ICZydDYtPnUuZHN0OworCXJldHVybiAwOworfQorI2VuZGlmIC8qIENP TkZJR19ORVRGSUxURVIgKi8KKworc3RhdGljIGlubGluZSBpbnQgaXA2X21h eWJlX3Jlcm91dGUoc3RydWN0IHNrX2J1ZmYgKnNrYikKK3sKKyNpZmRlZiBD T05GSUdfTkVURklMVEVSCisJaWYgKHNrYi0+bmZjYWNoZSAmIE5GQ19BTFRF UkVEKXsKKwkJaWYgKHJvdXRlNl9tZV9oYXJkZXIoc2tiKSAhPSAwKXsKKwkJ CWtmcmVlX3NrYihza2IpOworCQkJcmV0dXJuIC1FSU5WQUw7CisJCX0KKwl9 CisjZW5kaWYgLyogQ09ORklHX05FVEZJTFRFUiAqLworCXJldHVybiBza2It PmRzdC0+b3V0cHV0KHNrYik7CiB9CiAKIC8qCkBAIC0xNTksNyArMjA1LDcg QEAKIAogCWlmIChza2ItPmxlbiA8PSBkc3QtPnBtdHUpIHsKIAkJSVA2X0lO Q19TVEFUUyhJcDZPdXRSZXF1ZXN0cyk7Ci0JCXJldHVybiBkc3QtPm91dHB1 dChza2IpOworCQlyZXR1cm4gTkZfSE9PSyhQRl9JTkVUNiwgTkZfSVA2X0xP Q0FMX09VVCwgc2tiLCBOVUxMLCBkc3QtPmRldiwgaXA2X21heWJlX3Jlcm91 dGUpOwogCX0KIAogCXByaW50ayhLRVJOX0RFQlVHICJJUHY2OiBzZW5kaW5n IHBrdF90b29fYmlnIHRvIHNlbGZcbiIpOwpAQCAtMzg4LDcgKzQzNCw3IEBA CiAKIAkJCUlQNl9JTkNfU1RBVFMoSXA2RnJhZ0NyZWF0ZXMpOwogCQkJSVA2 X0lOQ19TVEFUUyhJcDZPdXRSZXF1ZXN0cyk7Ci0JCQllcnIgPSBkc3QtPm91 dHB1dChza2IpOworCQkJZXJyID0gTkZfSE9PSyhQRl9JTkVUNixORl9JUDZf TE9DQUxfT1VULCBza2IsIE5VTEwsIGRzdC0+ZGV2LCBpcDZfbWF5YmVfcmVy b3V0ZSk7CiAJCQlpZiAoZXJyKSB7CiAJCQkJa2ZyZWVfc2tiKGxhc3Rfc2ti KTsKIAkJCQlyZXR1cm4gZXJyOwpAQCAtNDE0LDcgKzQ2MCw3IEBACiAJSVA2 X0lOQ19TVEFUUyhJcDZGcmFnQ3JlYXRlcyk7CiAJSVA2X0lOQ19TVEFUUyhJ cDZGcmFnT0tzKTsKIAlJUDZfSU5DX1NUQVRTKElwNk91dFJlcXVlc3RzKTsK LQlyZXR1cm4gZHN0LT5vdXRwdXQobGFzdF9za2IpOworCXJldHVybiBORl9I T09LKFBGX0lORVQ2LCBORl9JUDZfTE9DQUxfT1VULCBsYXN0X3NrYiwgTlVM TCxkc3QtPmRldiwgaXA2X21heWJlX3Jlcm91dGUpOwogfQogCiBpbnQgaXA2 X2J1aWxkX3htaXQoc3RydWN0IHNvY2sgKnNrLCBpbmV0X2dldGZyYWdfdCBn ZXRmcmFnLCBjb25zdCB2b2lkICpkYXRhLApAQCAtNTgyLDcgKzYyOCw3IEBA CiAKIAkJaWYgKCFlcnIpIHsKIAkJCUlQNl9JTkNfU1RBVFMoSXA2T3V0UmVx dWVzdHMpOwotCQkJZXJyID0gZHN0LT5vdXRwdXQoc2tiKTsKKwkJCWVyciA9 IE5GX0hPT0soUEZfSU5FVDYsIE5GX0lQNl9MT0NBTF9PVVQsIHNrYiwgTlVM TCwgZHN0LT5kZXYsIGlwNl9tYXliZV9yZXJvdXRlKTsKIAkJfSBlbHNlIHsK IAkJCWVyciA9IC1FRkFVTFQ7CiAJCQlrZnJlZV9za2Ioc2tiKTsKQEAgLTYz Niw2ICs2ODIsMTEgQEAKIAlyZXR1cm4gMDsKIH0KIAorc3RhdGljIGlubGlu ZSBpbnQgaXA2X2ZvcndhcmRfZmluaXNoKHN0cnVjdCBza19idWZmICpza2Ip Cit7CisJcmV0dXJuIHNrYi0+ZHN0LT5vdXRwdXQoc2tiKTsKK30KKwogaW50 IGlwNl9mb3J3YXJkKHN0cnVjdCBza19idWZmICpza2IpCiB7CiAJc3RydWN0 IGRzdF9lbnRyeSAqZHN0ID0gc2tiLT5kc3Q7CkBAIC03MjYsNyArNzc3LDcg QEAKIAloZHItPmhvcF9saW1pdC0tOwogCiAJSVA2X0lOQ19TVEFUU19CSChJ cDZPdXRGb3J3RGF0YWdyYW1zKTsKLQlyZXR1cm4gZHN0LT5vdXRwdXQoc2ti KTsKKwlyZXR1cm4gTkZfSE9PSyhQRl9JTkVUNixORl9JUDZfRk9SV0FSRCwg c2tiLCBza2ItPmRldiwgZHN0LT5kZXYsIGlwNl9mb3J3YXJkX2ZpbmlzaCk7 CiAKIGRyb3A6CiAJSVA2X0lOQ19TVEFUU19CSChJcDZJbkFkZHJFcnJvcnMp OwpkaWZmIC11IC1yIC1OIGxpbnV4LTIuMy40NC9uZXQvaXB2Ni9pcHY2X3Nv Y2tnbHVlLmMgbGludXgvbmV0L2lwdjYvaXB2Nl9zb2NrZ2x1ZS5jCi0tLSBs aW51eC0yLjMuNDQvbmV0L2lwdjYvaXB2Nl9zb2NrZ2x1ZS5jCVdlZCBGZWIg IDIgMTk6MDM6MDAgMjAwMAorKysgbGludXgvbmV0L2lwdjYvaXB2Nl9zb2Nr Z2x1ZS5jCVNhdCBGZWIgMTIgMTc6MjQ6MDYgMjAwMApAQCAtMzUsNiArMzUs NyBAQAogI2luY2x1ZGUgPGxpbnV4L2lmX2FycC5oPgogI2luY2x1ZGUgPGxp bnV4L2luaXQuaD4KICNpbmNsdWRlIDxsaW51eC9zeXNjdGwuaD4KKyNpbmNs dWRlIDxsaW51eC9uZXRmaWx0ZXIuaD4KIAogI2luY2x1ZGUgPG5ldC9zb2Nr Lmg+CiAjaW5jbHVkZSA8bmV0L3NubXAuaD4KQEAgLTM3MSw2ICszNzIsMTQg QEAKIAljYXNlIElQVjZfRkxPV0xBQkVMX01HUjoKIAkJcmV0diA9IGlwdjZf Zmxvd2xhYmVsX29wdChzaywgb3B0dmFsLCBvcHRsZW4pOwogCQlicmVhazsK KworI2lmZGVmIENPTkZJR19ORVRGSUxURVIKKwlkZWZhdWx0OgorCQlyZXR2 ID0gbmZfc2V0c29ja29wdChzaywgUEZfSU5FVDYsIG9wdG5hbWUsIG9wdHZh bCwgCisJCQkJCSAgICBvcHRsZW4pOworCQlicmVhazsKKyNlbmRpZgorCiAJ fQogCXJlbGVhc2Vfc29jayhzayk7CiAKQEAgLTQ1MCw3ICs0NTksMTcgQEAK IAkJYnJlYWs7CiAJfQogCWRlZmF1bHQ6CisjaWZkZWYgQ09ORklHX05FVEZJ TFRFUgorCQlsb2NrX3NvY2soc2spOworCQl2YWwgPSBuZl9nZXRzb2Nrb3B0 KHNrLCBQRl9JTkVUNiwgb3B0bmFtZSwgb3B0dmFsLCAKKwkJCQkgICAgJmxl bik7CisJCXJlbGVhc2Vfc29jayhzayk7CisJCWlmICh2YWwgPj0gMCkKKwkJ CXZhbCA9IHB1dF91c2VyKGxlbiwgb3B0bGVuKTsKKwkJcmV0dXJuIHZhbDsK KyNlbHNlCiAJCXJldHVybiAtRUlOVkFMOworI2VuZGlmCiAJfQogCWxlbj1t aW4oc2l6ZW9mKGludCksbGVuKTsKIAlpZihwdXRfdXNlcihsZW4sIG9wdGxl bikpCg== ------------=_950404754-3131-0-- From owner-netdev@oss.sgi.com Sat Feb 12 18:52:23 2000 Received: by oss.sgi.com id ; Sat, 12 Feb 2000 18:52:14 -0800 Received: from mail0.u-aizu.ac.jp ([163.143.1.43]:33178 "EHLO mail0.u-aizu.ac.jp") by oss.sgi.com with ESMTP id ; Sat, 12 Feb 2000 18:51:52 -0800 Received: from ccultra2.u-aizu.ac.jp (ccultra2.u-aizu.ac.jp [163.143.99.104]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id LAA08032; Sun, 13 Feb 2000 11:51:44 +0900 (JST) Received: from ccultra2.u-aizu.ac.jp (ccpro2 [163.143.99.101]) by ccultra2.u-aizu.ac.jp (8.9.1b+Sun/8.8.8) with ESMTP id LAA22489; Sun, 13 Feb 2000 11:48:25 +0900 (JST) Message-ID: <38A61C40.55E39573@ccultra2.u-aizu.ac.jp> Date: Sun, 13 Feb 2000 11:51:45 +0900 From: Behcet Sarikaya Organization: University of Aizu X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: coronach@succubus.dhis.org, netdev@oss.sgi.com, sarikaya@ccultra2.u-aizu.ac.jp Subject: sit configuration Content-Type: multipart/alternative; boundary="------------472C848D3D69E86A12273B61" Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing --------------472C848D3D69E86A12273B61 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Micheal, Thanks for your email. Yes I did your changes. I do get ping6 ::1 and ping6 ::163.143.99.101 and to all other v6 hosts on 99 subnet. But I do not get ping6 3ffe:501:427:1000::163.143.99.101 and others. For ping6 www.6bone.net (external 6bone host) it gives network is unreachable, but for local hosts no reply. I tried to ping6 from the tunnel provider , the same result (I checked with tcpdump6, icmp v6 messages are transmitted on eth0), ping6 ::163.143.180.107 works but not the global address. Thanks in advance, -- Behcet Sarikaya Computer Communications Lab. --------------472C848D3D69E86A12273B61 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Micheal,
  Thanks for your email. Yes I did your changes. I do get
ping6 ::1 and
ping6 ::163.143.99.101 and to all other v6 hosts on 99 subnet. But I do not get
ping6 3ffe:501:427:1000::163.143.99.101 and others.
For ping6 www.6bone.net (external 6bone host) it gives network is unreachable, but for local hosts no reply.
I tried to ping6 from the tunnel provider , the same result (I checked with tcpdump6, icmp v6 messages are transmitted on eth0),
ping6 ::163.143.180.107 works but not the global address.
  Thanks in advance, 
-- 
Behcet Sarikaya
Computer Communications Lab.
  --------------472C848D3D69E86A12273B61-- From owner-netdev@oss.sgi.com Sat Feb 12 19:26:14 2000 Received: by oss.sgi.com id ; Sat, 12 Feb 2000 19:25:54 -0800 Received: from hill-b-039.resnet.purdue.edu ([128.211.205.39]:25860 "EHLO hill-b-039.resnet.purdue.edu") by oss.sgi.com with ESMTP id ; Sat, 12 Feb 2000 19:25:48 -0800 Received: from tremere (tremere.succubus.ml.org [192.168.1.10]) by hill-b-039.resnet.purdue.edu (8.9.3/8.9.3/Debian 8.9.3-6) with SMTP id WAA03580; Sat, 12 Feb 2000 22:26:01 -0500 X-Authentication-Warning: hill-b-039.resnet.purdue.edu: Host tremere.succubus.ml.org [192.168.1.10] claimed to be tremere From: "Michael A. Lemler" To: , Subject: RE: sit configuration Date: Sat, 12 Feb 2000 22:25:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38A61C40.55E39573@ccultra2.u-aizu.ac.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Well, in that case, it might not be your fault. I double checked your default route and that looks fine. Do a traceroute6 and see if that gives you anything worthwhile. See what hop traffic will not route past and then go from there. --Mike -----Original Message----- From: sarikaya@ccultra2.u-aizu.ac.jp [mailto:sarikaya@ccultra2.u-aizu.ac.jp] Sent: Saturday, February 12, 2000 9:52 PM To: coronach@succubus.dhis.org; netdev@oss.sgi.com; sarikaya@ccultra2.u-aizu.ac.jp Subject: sit configuration Hi Micheal, Thanks for your email. Yes I did your changes. I do get ping6 ::1 and ping6 ::163.143.99.101 and to all other v6 hosts on 99 subnet. But I do not get ping6 3ffe:501:427:1000::163.143.99.101 and others. For ping6 www.6bone.net (external 6bone host) it gives network is unreachable, but for local hosts no reply. I tried to ping6 from the tunnel provider , the same result (I checked with tcpdump6, icmp v6 messages are transmitted on eth0), ping6 ::163.143.180.107 works but not the global address. Thanks in advance, -- Behcet Sarikaya Computer Communications Lab. From owner-netdev@oss.sgi.com Sat Feb 12 19:36:14 2000 Received: by oss.sgi.com id ; Sat, 12 Feb 2000 19:35:54 -0800 Received: from pizda.ninka.net ([216.101.162.242]:2945 "EHLO pizda.ninka.net") by oss.sgi.com with ESMTP id ; Sat, 12 Feb 2000 19:35:37 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA13856; Sat, 12 Feb 2000 19:31:54 -0800 Date: Sat, 12 Feb 2000 19:31:54 -0800 Message-Id: <200002130331.TAA13856@pizda.ninka.net> X-Authentication-Warning: pizda.ninka.net: davem set sender to davem@redhat.com using -f From: "David S. Miller" To: lordbeatnik@linuxstart.com CC: netdev@oss.sgi.com In-reply-to: <200002121904.LAA11990@ns1.filetron.com> (message from David Jeffery on Sat, 12 Feb 2000 11:04:30 -0800) Subject: Re: ip6 udp panic from accept References: <200002121904.LAA11990@ns1.filetron.com> Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing This should fix it: --- net/ipv6/af_inet6.c.~1~ Fri Feb 4 13:04:08 2000 +++ net/ipv6/af_inet6.c Sat Feb 12 19:31:24 2000 @@ -451,7 +451,7 @@ inet6_bind, inet_dgram_connect, /* ok */ sock_no_socketpair, /* a do nothing */ - inet_accept, /* ok */ + sock_no_accept, /* a do nothing */ inet6_getname, datagram_poll, /* ok */ inet6_ioctl, /* must change */ From owner-netdev@oss.sgi.com Sat Feb 12 22:13:07 2000 Received: by oss.sgi.com id ; Sat, 12 Feb 2000 22:12:48 -0800 Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:31492 "EHLO grok.myip.org") by oss.sgi.com with ESMTP id ; Sat, 12 Feb 2000 22:12:26 -0800 Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1]) by grok.myip.org (8.9.3/8.9.3) with ESMTP id XAA10313 for ; Sat, 12 Feb 2000 23:34:59 -0700 Message-ID: <38A65093.FF75B285@candelatech.com> Date: Sat, 12 Feb 2000 23:34:59 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: "netdev@oss.sgi.com" Subject: Question on net_device->refcnt && unregister_netdevice. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing When I try to delete a VLAN device, it seems to work, but I get this error: unregister_netdevice: Old style device vlan0004 leaked(refcnt=1). Wait for crash. (I especially like the last part!!) I'm working with the 2.3.42 snapshot, plus the VLAN code.. Is this problem something that my code could be responsible for, or is it something else in the stack? I memset the net_device struct to zero before I start filling it in, so the refcnt starts out as zero. I never actively (that I know of) mess with the refcnt one way or another... What kinds of things (calls?) affect the refcnt? Any hints as to what might have this refcnt will be appreciated! Thanks, Ben -- Ben Greear (greearb@candelatech.com) http://scry.wanfear.com/~greear Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL) http://scry.wanfear.com From owner-netdev@oss.sgi.com Sun Feb 13 08:16:21 2000 Received: by oss.sgi.com id ; Sun, 13 Feb 2000 08:16:10 -0800 Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:22792 "EHLO cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP id ; Sun, 13 Feb 2000 08:15:48 -0800 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id BAA21893; Mon, 14 Feb 2000 01:14:55 +0900 To: kuznet@ms2.inr.ac.ru CC: netdev@oss.sgi.com Subject: sin6_scope_id patch for linux-2.3.44 From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) X-Mailer: Mew version 1.94 on Emacs 20.5 / Mule 4.1 =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000214011455I.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Mon, 14 Feb 2000 01:14:55 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 13 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi, I've worked on linux-2.3.44 and now, sin6_scope_id patch is available at: Thanks. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 From owner-netdev@oss.sgi.com Sun Feb 13 08:38:40 2000 Received: by oss.sgi.com id ; Sun, 13 Feb 2000 08:38:30 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:52754 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Sun, 13 Feb 2000 08:38:13 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA21062; Sun, 13 Feb 2000 19:37:59 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002131637.TAA21062@ms2.inr.ac.ru> Subject: Re: Question on net_device->refcnt && unregister_netdevice. To: greearb@candelatech.COM (Ben Greear) Date: Sun, 13 Feb 2000 19:37:59 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: <38A65093.FF75B285@candelatech.com> from "Ben Greear" at Feb 13, 0 10:13:07 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 994 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > unregister_netdevice: Old style device vlan0004 leaked(refcnt=1). Wait for crash. > (I especially like the last part!!) It does not lie. If that guy who holds refcnt will remember about this device finally, it will be oops in the best case or even memory corruption. If you allocate device struct via kmalloc(), it is better to convert it to "new style". F.e. look into tunnels or to ppp. > Is this problem something that my code could be responsible for, > or is it something else in the stack? It can be everywhere, where the device is referenced. Debug! > I memset the net_device struct to zero before I start filling it in, > so the refcnt starts out as zero. I never actively (that I know of) > mess with the refcnt one way or another... It is correct. > What kinds of things (calls?) affect the refcnt? Any place, which gets this device to use it later. skbs, routes, arp entries etc. etc. Where is the code? Probably, I will be able to see hole. Alexey Kuznetsov From owner-netdev@oss.sgi.com Sun Feb 13 10:50:41 2000 Received: by oss.sgi.com id ; Sun, 13 Feb 2000 10:50:30 -0800 Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:15624 "EHLO grok.myip.org") by oss.sgi.com with ESMTP id ; Sun, 13 Feb 2000 10:50:16 -0800 Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1]) by grok.myip.org (8.9.3/8.9.3) with ESMTP id MAA13941; Sun, 13 Feb 2000 12:12:28 -0700 Message-ID: <38A7021B.B8EF42AF@candelatech.com> Date: Sun, 13 Feb 2000 12:12:28 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: kuznet@ms2.inr.ac.ru CC: netdev@oss.sgi.com Subject: Re: Question on net_device->refcnt && unregister_netdevice. References: <200002131637.TAA21062@ms2.inr.ac.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing kuznet@ms2.inr.ac.ru wrote: > > Hello! > > > unregister_netdevice: Old style device vlan0004 leaked(refcnt=1). Wait for crash. > > (I especially like the last part!!) > > It does not lie. If that guy who holds refcnt will remember about this > device finally, it will be oops in the best case or even memory corruption. I think I found most of them. The problem was that I found devices by their name quite often: dev_get_by_name(), and never explicitly released them. Does this also cause problems in the 2.2 kernels? > > If you allocate device struct via kmalloc(), it is better to convert > it to "new style". F.e. look into tunnels or to ppp. I'll do that... > > Is this problem something that my code could be responsible for, > > or is it something else in the stack? > > It can be everywhere, where the device is referenced. Debug! I think we should put some comments in the net_device struct to explain what kinds of calls increment/decrement the refcnt. I eventually figured out it was the dev_put/dev_get* methods, but only lots of poking and grepping yielded that... Ben -- Ben Greear (greearb@candelatech.com) http://scry.wanfear.com/~greear Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL) http://scry.wanfear.com From owner-netdev@oss.sgi.com Sun Feb 13 10:56:21 2000 Received: by oss.sgi.com id ; Sun, 13 Feb 2000 10:56:10 -0800 Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:18952 "EHLO grok.myip.org") by oss.sgi.com with ESMTP id ; Sun, 13 Feb 2000 10:56:03 -0800 Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1]) by grok.myip.org (8.9.3/8.9.3) with ESMTP id MAA13960 for ; Sun, 13 Feb 2000 12:18:59 -0700 Message-ID: <38A703A3.58CCA4B9@candelatech.com> Date: Sun, 13 Feb 2000 12:18:59 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: "netdev@oss.sgi.com" Subject: Why is the tulip.c in the 2.3 kernels older than the 2.2.14? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing I am able to pass large ethernet vlan packets with my tulip.c compatible ethernet card in 2.2.13/14. However, in the 2.3.42 kernel, I get frame_errors (because the frame is 4 bytes larger when the pkt is MTU sized.) Same hardware.... I noticed that the tulip.c in the 2.3.42 kernel is older than the 2.2.14 version. Does anyone have a newer tulip.c that is ported to the 2.3 kernel? I downloaded the "tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov\n"; version, but it won't compile cleanly... Thanks, Ben -- Ben Greear (greearb@candelatech.com) http://scry.wanfear.com/~greear Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL) http://scry.wanfear.com From owner-netdev@oss.sgi.com Sun Feb 13 10:58:40 2000 Received: by oss.sgi.com id ; Sun, 13 Feb 2000 10:58:31 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:19463 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Sun, 13 Feb 2000 10:58:27 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA23188; Sun, 13 Feb 2000 21:58:20 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002131858.VAA23188@ms2.inr.ac.ru> Subject: Re: Question on net_device->refcnt && unregister_netdevice. To: greearb@candelatech.com (Ben Greear) Date: Sun, 13 Feb 2000 21:58:20 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: <38A7021B.B8EF42AF@candelatech.com> from "Ben Greear" at Feb 13, 0 12:12:28 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 709 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > I think I found most of them. The problem was that I found devices > by their name quite often: dev_get_by_name(), and never explicitly > released them. OK! Actually, it you make this from dev->ioctl, dev->open or dev->close and do not save pointer to device, you may use __dev_get_by_*(), it does not increase refcnt. (device list is not protected by semaphore, while you sit in these routines). > Does this also cause problems in the 2.2 kernels? No. 2.2 did not have refcnt. The problem really existed, but it was masked, because probability of reference to already killed device is very low. In 2.3 it is real problem, because accounting itself needs reference to dead memory area. Alexey From owner-netdev@oss.sgi.com Mon Feb 14 16:44:02 2000 Received: by oss.sgi.com id ; Mon, 14 Feb 2000 16:43:52 -0800 Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:8979 "EHLO grok.myip.org") by oss.sgi.com with ESMTP id ; Mon, 14 Feb 2000 16:43:31 -0800 Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1]) by grok.myip.org (8.9.3/8.9.3) with ESMTP id SAA22239 for ; Mon, 14 Feb 2000 18:06:26 -0700 Message-ID: <38A8A692.E69907CA@candelatech.com> Date: Mon, 14 Feb 2000 18:06:26 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: "netdev@oss.sgi.com" Subject: Resend: Updated tulip.c driver available for 2.3.42+ kernels. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing (Appologies if you've already seen this, I believe it didn't get sent correctly last time, or maybe the attachment was too big..) ----------------------------------------------------------------- While trying to get my tulip (mostly?) compatible card to allow jumbo (4 bytes larger) frames for VLAN, I attempted to get the "tulip.c:v0.91g 7/16/99 becker@cesdis.gsfc.nasa.gov\n"; driver to run on 2.3.42. I have no idea if what I did was reasonable, but it does seem to work on my system at least (it didn't fix my frame_error problem, but regular traffic seems to work ok).... At any rate, it would probably be a good idea to get a newer tulip.c into the kernel soon. If you'd like this driver, or to put it in the kernel proper (AC, Becker?) then please download it from my web page: http://scry.wanfear.com/~greear/tulip.c.gz If anyone can figure out how (if it's even possible) to get the driver/card to accept larger pkts (current max + 4), please let me know.. Thanks, Ben -- Ben Greear (greearb@candelatech.com) http://scry.wanfear.com/~greear Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL) http://scry.wanfear.com From owner-netdev@oss.sgi.com Wed Feb 16 06:20:01 2000 Received: by oss.sgi.com id ; Wed, 16 Feb 2000 06:19:51 -0800 Received: from dhcp41.toaster.net ([199.108.84.41]:58382 "EHLO schmee.sfgoth.com") by oss.sgi.com with ESMTP id ; Wed, 16 Feb 2000 06:19:32 -0800 Received: (from mitch@localhost) by schmee.sfgoth.com (8.9.3/8.9.3) id GAA83669; Wed, 16 Feb 2000 06:18:53 -0800 (PST) Date: Wed, 16 Feb 2000 06:18:53 -0800 From: Mitchell Blank Jr To: paulus@linuxcare.com Cc: jamal , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Henner Eisen , Michal Ostrowski , Ben LaHaise Subject: Re: RFC: PPP over X Message-ID: <20000216061853.A83604@sfgoth.com> References: <20000203120127.J72648@sfgoth.com> <20000207143007.O31166@sfgoth.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" X-Mailer: Mutt 1.0i In-Reply-To: <20000207143007.O31166@sfgoth.com>; from mitch on Mon, Feb 07, 2000 at 02:30:07PM -0800 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Mitchell Blank Jr wrote: > BTW, sorry I didn't get around to posting patches to pppd yesterday. > Every time I thought I nailed the "last thing" in pppd a couple more would > pop up. I think I'm nearing the end of the tunnel though, so stay > tuned. Sorry for taking so long to deliver my promised pppd patches, but at long last here they are. These aren't tested (since I have no PPP line right now to test them with :-), so if interested parties could give them a whirl and make sure that I haven't broken too many things, I'd appreciate it. This patch to pppd-2.3.11 makes it possible to implement non-tty backends (PPPoATM, PPPoE, etc, etc) using the existing pppd plugin mechanism. Specifically... First, I changed plugin_init so that they are loaded (and plugin_init called) during option-pre-parsing time. This was a bug in the past - before plugin's add_option's weren't processed until later option parsing, which meant that plugin-added options and their arguments could get confused with speeds and device names. This change also means that plugins can have deeper impacts on the parsing process. I also added an (optional) plugin entry point "plugin_init_later" which is called at the time that plugin_init used to be called in case any future plugins need that (for instance if they do something at init-time that requires that "devnam" has been determined) Second, I added twelve new hooks which can be used to override most all of the tty-specific behavior in the default pppd. This provides enough control to implement things like PPPoATM and PPPoE as plugins. These additional hooks are documented in the PLUGINS file (I also took the liberty of documenting the ip_{up,down}_hook hooks which weren't mentioned there. I'm also including an example PPPoATM plugin. *NOTE*: this is for a new version of the in-kernel PPPoATM driver which I am working on, not the one that Jens Axboe is distributing (which in turn is based on my original version). Therefore this plugin will neither compile nor work, but is only meant as an example showing how a non-async discipline would be implemented using the new hooks. One aspect of pppd which does NOT work with non-tty backends is demand dialing - the current implementation is heavily reliant on substituting a pseudo-tty for the real device and that just won't work for a non-tty device. Paul - can demand-dialing be redesigned? I think it would be easiest if the kernel considered "waiting to dial" as another ppp_channel which just queues skb's and notifies userland somehow. That way you could demand-dial PPPoATM or PPPoE using the same mechanism for ppp_async. I hope that these patches look good.. Paul, if you don't like anything let me know. I'm going back to working on the PPPoATM kernel-side now. -Mitch --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pppd-2.3.11mnb1.patch" diff -ur ppp-2.3.11/pppd/demand.c ppp-2.3.11mnb1/pppd/demand.c --- ppp-2.3.11/pppd/demand.c Thu Aug 12 23:46:12 1999 +++ ppp-2.3.11mnb1/pppd/demand.c Tue Sep 6 16:08:35 1904 @@ -85,8 +85,8 @@ flush_flag = 0; fcs = PPP_INITFCS; - ppp_send_config(0, PPP_MRU, (u_int32_t) 0, 0, 0); - ppp_recv_config(0, PPP_MRU, (u_int32_t) 0, 0, 0); + send_config_hook(0, PPP_MRU, (u_int32_t) 0, 0, 0); + recv_config_hook(0, PPP_MRU, (u_int32_t) 0, 0, 0); #ifdef PPP_FILTER set_filters(&pass_filter, &active_filter); diff -ur ppp-2.3.11/pppd/lcp.c ppp-2.3.11mnb1/pppd/lcp.c --- ppp-2.3.11/pppd/lcp.c Wed Dec 22 17:27:28 1999 +++ ppp-2.3.11mnb1/pppd/lcp.c Tue Sep 6 16:07:59 1904 @@ -82,6 +82,8 @@ { "nopcomp", o_bool, &lcp_wantoptions[0].neg_pcompression, "Disable protocol field compression", OPT_A2COPY, &lcp_allowoptions[0].neg_pcompression }, + { "pcomp", o_bool, &lcp_wantoptions[0].neg_pcompression, + "Enable protocol field compression (default)", 1 }, { "-pc", o_bool, &lcp_wantoptions[0].neg_pcompression, "Disable protocol field compression", OPT_A2COPY, &lcp_allowoptions[0].neg_pcompression }, @@ -172,6 +174,13 @@ }; /* + * Hooks we use which can be overridden by protocol plugins + */ +void (*recv_config_hook) __P((int, int, u_int32_t, int, int)) = ppp_recv_config; +void (*send_config_hook) __P((int, int, u_int32_t, int, int)) = ppp_send_config; +void (*set_xaccm_hook) __P((int, ext_accm)) = ppp_set_xaccm; + +/* * Protocol entry points. * Some of these are called directly. */ @@ -366,9 +375,9 @@ * but accept A/C and protocol compressed packets * if we are going to ask for A/C and protocol compression. */ - ppp_set_xaccm(unit, xmit_accm[unit]); - ppp_send_config(unit, PPP_MRU, 0xffffffff, 0, 0); - ppp_recv_config(unit, PPP_MRU, (lax_recv? 0: 0xffffffff), + set_xaccm_hook(unit, xmit_accm[unit]); + send_config_hook(unit, PPP_MRU, 0xffffffff, 0, 0); + recv_config_hook(unit, PPP_MRU, (lax_recv? 0: 0xffffffff), wo->neg_pcompression, wo->neg_accompression); peer_mru[unit] = PPP_MRU; lcp_allowoptions[unit].asyncmap = xmit_accm[unit][0]; @@ -1557,10 +1566,10 @@ * set our MRU to the larger of value we wanted and * the value we got in the negotiation. */ - ppp_send_config(f->unit, MIN(ao->mru, (ho->neg_mru? ho->mru: PPP_MRU)), + send_config_hook(f->unit, MIN(ao->mru, (ho->neg_mru? ho->mru: PPP_MRU)), (ho->neg_asyncmap? ho->asyncmap: 0xffffffff), ho->neg_pcompression, ho->neg_accompression); - ppp_recv_config(f->unit, (go->neg_mru? MAX(wo->mru, go->mru): PPP_MRU), + recv_config_hook(f->unit, (go->neg_mru? MAX(wo->mru, go->mru): PPP_MRU), (lax_recv? 0: go->neg_asyncmap? go->asyncmap: 0xffffffff), go->neg_pcompression, go->neg_accompression); @@ -1588,8 +1597,8 @@ link_down(f->unit); - ppp_send_config(f->unit, PPP_MRU, 0xffffffff, 0, 0); - ppp_recv_config(f->unit, PPP_MRU, + send_config_hook(f->unit, PPP_MRU, 0xffffffff, 0, 0); + recv_config_hook(f->unit, PPP_MRU, (go->neg_asyncmap? go->asyncmap: 0xffffffff), go->neg_pcompression, go->neg_accompression); peer_mru[f->unit] = PPP_MRU; diff -ur ppp-2.3.11/pppd/main.c ppp-2.3.11mnb1/pppd/main.c --- ppp-2.3.11/pppd/main.c Wed Dec 22 18:12:31 1999 +++ ppp-2.3.11mnb1/pppd/main.c Wed Sep 7 14:33:36 1904 @@ -118,6 +118,10 @@ u_char outpacket_buf[PPP_MRU+PPP_HDRLEN]; /* buffer for outgoing packet */ u_char inpacket_buf[PPP_MRU+PPP_HDRLEN]; /* buffer for incoming packet */ +void (*set_line_discipline_hook) __P((int)) = NULL; /* TIOCSETD(N_PPP) */ +void (*reset_line_discipline_hook) __P((int)) = NULL; /* TIOCSETD(N_TTY) */ + + static int n_children; /* # child processes still running */ static int got_sigchld; /* set if we have received a SIGCHLD */ @@ -216,6 +220,86 @@ NULL }; +static int +open_device_async(void) +{ + return open(devnam, O_NONBLOCK | O_RDWR, 0); +} + +/* Open "devname", return an fd */ +int (*open_device_hook) __P((void)) = open_device_async; + +static char *connector; + +/* post-open tty setup */ +static void +post_open_setup_tty(fd) + int fd; +{ + struct stat statbuf; + int fdflags; + if ((fdflags = fcntl(ttyfd, F_GETFL)) == -1 || + fcntl(ttyfd, F_SETFL, fdflags & ~O_NONBLOCK) < 0) + warn("Couldn't reset non-blocking mode on device: %m"); + /* + * Do the equivalent of `mesg n' to stop broadcast messages. + */ + if (fstat(ttyfd, &statbuf) < 0 || + fchmod(ttyfd, statbuf.st_mode & ~(S_IWGRP | S_IWOTH)) < 0) { + warn("Couldn't restrict write permissions to %s: %m", devnam); + } else + tty_mode = statbuf.st_mode; + /* + * Set line speed, flow control, etc. + * If we have a non-null connection or initializer script, + * on most systems we set CLOCAL for now so that we can talk + * to the modem before carrier comes up. But this has the + * side effect that we might miss it if CD drops before we + * get to clear CLOCAL below. On systems where we can talk + * successfully to the modem with CLOCAL clear and CD down, + * we could clear CLOCAL at this point. + */ + set_up_tty(ttyfd, + ((connector != NULL && connector[0] != 0) || initializer != NULL)); +} + +void (*post_open_setup_hook) __P((int)) = post_open_setup_tty; + +static void +pre_close_restore_tty(fd) + int fd; +{ + restore_tty(fd); + + if (tty_mode != (mode_t) -1) { + if (fchmod(fd, tty_mode) != 0) { + /* XXX if devnam is a symlink, this will change the link */ + chmod(devnam, tty_mode); + } + } +} + +void (*pre_close_restore_hook) __P((int)) = pre_close_restore_tty; + +static void +no_device_given_async(void) +{ + char *p; + if (!isatty(0) || (p = ttyname(0)) == NULL) { + option_error("no device specified and stdin is not a tty"); + exit(EXIT_OPTION_ERROR); + } + strlcpy(devnam, p, sizeof(devnam)); + if (stat(devnam, &devstat) < 0) + fatal("Couldn't stat default device %s: %m", devnam); +} + +/* + * No device was specified in the options - open a default if + * available. Must fill in devnam and devstat + */ +void (*no_device_given_hook) __P((void)) = no_device_given_async; + int main(argc, argv) int argc; @@ -223,7 +307,7 @@ { int i, fdflags, t; struct sigaction sa; - char *p, *connector; + char *p; struct passwd *pw; struct timeval timo; sigset_t mask; @@ -296,16 +380,8 @@ * Work out the device name, if it hasn't already been specified. */ using_pty = notty || ptycommand != NULL; - if (!using_pty && default_device) { - char *p; - if (!isatty(0) || (p = ttyname(0)) == NULL) { - option_error("no device specified and stdin is not a tty"); - exit(EXIT_OPTION_ERROR); - } - strlcpy(devnam, p, sizeof(devnam)); - if (stat(devnam, &devstat) < 0) - fatal("Couldn't stat default device %s: %m", devnam); - } + if (!using_pty && default_device) + no_device_given_hook(); /* * Parse the tty options file and the command line. @@ -314,7 +390,7 @@ */ devnam_fixed = 1; if (!using_pty) { - if (!options_for_tty()) + if (!options_for_device_hook()) exit(EXIT_OPTION_ERROR); } @@ -375,8 +451,9 @@ * If the device is already open read/write on stdin, * we assume we don't need to lock it, and we can open it as root. */ - if (fstat(0, &statbuf) >= 0 && S_ISCHR(statbuf.st_mode) - && statbuf.st_rdev == devstat.st_rdev) { + if (S_ISCHR(devstat.st_mode) && + fstat(0, &statbuf) >= 0 && S_ISCHR(statbuf.st_mode) && + statbuf.st_rdev == devstat.st_rdev) { default_device = 1; fdflags = fcntl(0, F_GETFL); if (fdflags != -1 && (fdflags & O_ACCMODE) == O_RDWR) @@ -618,7 +695,7 @@ int err; if (!devnam_info.priv && !privopen) seteuid(uid); - ttyfd = open(devnam, O_NONBLOCK | O_RDWR, 0); + ttyfd = open_device_hook(); err = errno; if (!devnam_info.priv && !privopen) seteuid(0); @@ -632,31 +709,7 @@ if (!persist || err != EINTR) goto fail; } - if ((fdflags = fcntl(ttyfd, F_GETFL)) == -1 - || fcntl(ttyfd, F_SETFL, fdflags & ~O_NONBLOCK) < 0) - warn("Couldn't reset non-blocking mode on device: %m"); - - /* - * Do the equivalent of `mesg n' to stop broadcast messages. - */ - if (fstat(ttyfd, &statbuf) < 0 - || fchmod(ttyfd, statbuf.st_mode & ~(S_IWGRP | S_IWOTH)) < 0) { - warn("Couldn't restrict write permissions to %s: %m", devnam); - } else - tty_mode = statbuf.st_mode; - - /* - * Set line speed, flow control, etc. - * If we have a non-null connection or initializer script, - * on most systems we set CLOCAL for now so that we can talk - * to the modem before carrier comes up. But this has the - * side effect that we might miss it if CD drops before we - * get to clear CLOCAL below. On systems where we can talk - * successfully to the modem with CLOCAL clear and CD down, - * we could clear CLOCAL at this point. - */ - set_up_tty(ttyfd, ((connector != NULL && connector[0] != 0) - || initializer != NULL)); + post_open_setup_hook(ttyfd); real_ttyfd = ttyfd; } @@ -664,36 +717,38 @@ * If the notty and/or record option was specified, * start up the character shunt now. */ - status = EXIT_PTYCMD_FAILED; - if (ptycommand != NULL) { - if (record_file != NULL) { - int ipipe[2], opipe[2], ok; - - if (pipe(ipipe) < 0 || pipe(opipe) < 0) - fatal("Couldn't create pipes for record option: %m"); - ok = device_script(ptycommand, opipe[0], ipipe[1], 1) == 0 - && start_charshunt(ipipe[0], opipe[1]); - close(ipipe[0]); - close(ipipe[1]); - close(opipe[0]); - close(opipe[1]); - if (!ok) + if (S_ISCHR(devstat.st_mode)) { + status = EXIT_PTYCMD_FAILED; + if (ptycommand != NULL) { + if (record_file != NULL) { + int ipipe[2], opipe[2], ok; + + if (pipe(ipipe) < 0 || pipe(opipe) < 0) + fatal("Couldn't create pipes for record option: %m"); + ok = device_script(ptycommand, opipe[0], ipipe[1], 1) == 0 + && start_charshunt(ipipe[0], opipe[1]); + close(ipipe[0]); + close(ipipe[1]); + close(opipe[0]); + close(opipe[1]); + if (!ok) + goto fail; + } else { + if (device_script(ptycommand, pty_master, + pty_master, 1) < 0) + goto fail; + ttyfd = pty_slave; + close(pty_master); + pty_master = -1; + } + } else if (notty) { + if (!start_charshunt(0, 1)) goto fail; - } else { - if (device_script(ptycommand, pty_master, pty_master, 1) < 0) + } else if (record_file != NULL) { + if (!start_charshunt(ttyfd, ttyfd)) goto fail; - ttyfd = pty_slave; - close(pty_master); - pty_master = -1; } - } else if (notty) { - if (!start_charshunt(0, 1)) - goto fail; - } else if (record_file != NULL) { - if (!start_charshunt(ttyfd, ttyfd)) - goto fail; } - /* run connection script */ if ((connector && connector[0]) || initializer) { if (real_ttyfd != -1) { @@ -731,7 +786,7 @@ /* set line speed, flow control, etc.; clear CLOCAL if modem option */ - if (real_ttyfd != -1) + if (S_ISCHR(devstat.st_mode) && real_ttyfd != -1) set_up_tty(real_ttyfd, 0); if (doing_callback == CALLBACK_DIALIN) @@ -753,8 +808,12 @@ close(i); } - slprintf(numbuf, sizeof(numbuf), "%d", baud_rate); - script_setenv("SPEED", numbuf); + if (S_ISCHR(devstat.st_mode) && real_ttyfd != -1) { + slprintf(numbuf, sizeof(numbuf), "%d", baud_rate); + script_setenv("SPEED", numbuf); + } + else + script_setenv("SPEED","na"); /* run welcome script, if any */ if (welcomer && welcomer[0]) { @@ -864,7 +923,8 @@ * real serial device back to its normal mode of operation. */ remove_fd(fd_ppp); - clean_check(); + if (S_ISCHR(devstat.st_mode)) + clean_check(); if (demand) restore_loop(); disestablish_ppp(ttyfd); @@ -879,7 +939,7 @@ disconnect: if (disconnect_script && !hungup) { new_phase(PHASE_DISCONNECT); - if (real_ttyfd >= 0) + if (S_ISCHR(devstat.st_mode) && real_ttyfd >= 0) set_up_tty(real_ttyfd, 1); if (device_script(disconnect_script, ttyfd, ttyfd, 0) < 0) { warn("disconnect script failed"); @@ -1296,15 +1356,7 @@ sleep(1); } - restore_tty(real_ttyfd); - - if (tty_mode != (mode_t) -1) { - if (fchmod(real_ttyfd, tty_mode) != 0) { - /* XXX if devnam is a symlink, this will change the link */ - chmod(devnam, tty_mode); - } - } - + pre_close_restore_hook(real_ttyfd); close(real_ttyfd); real_ttyfd = -1; } diff -ur ppp-2.3.11/pppd/options.c ppp-2.3.11mnb1/pppd/options.c --- ppp-2.3.11/pppd/options.c Wed Dec 22 17:28:52 1999 +++ ppp-2.3.11mnb1/pppd/options.c Wed Sep 7 13:51:11 1904 @@ -127,9 +127,8 @@ /* * Prototypes */ -static int setdevname __P((char *)); +static int setdevname __P((const char *)); static int setipaddr __P((char *)); -static int setspeed __P((char *)); static int noopt __P((char **)); static int setdomain __P((char **)); static int setnetmask __P((char **)); @@ -272,7 +271,7 @@ "Maximum time (in ms) to wait after connect script finishes" }, #ifdef PLUGIN { "plugin", o_special, loadplugin, - "Load a plug-in module into pppd", OPT_PRIV }, + "Load a plug-in module into pppd", OPT_PRIV|OPT_PREPASS }, #endif #ifdef PPP_FILTER @@ -351,7 +350,7 @@ * Maybe a tty name, speed or IP address? */ if ((ret = setdevname(arg)) == 0 - && (ret = setspeed(arg)) == 0 + && (ret = setspeed_hook(arg)) == 0 && (ret = setipaddr(arg)) == 0 && !prepass) { option_error("unrecognized option '%s'", arg); @@ -472,7 +471,7 @@ * Maybe a tty name, speed or IP address? */ if ((i = setdevname(cmd)) == 0 - && (i = setspeed(cmd)) == 0 + && (i = setspeed_hook(cmd)) == 0 && (i = setipaddr(cmd)) == 0) { option_error("In file %s: unrecognized option '%s'", filename, cmd); @@ -517,28 +516,23 @@ } /* - * options_for_tty - See if an options file exists for the serial - * device, and if so, interpret options from it. + * options_from_devfile - Generic handler for getting options from + * device-specific file */ int -options_for_tty() +options_from_devfile(prefix, dev) +const char *prefix, *dev; { - char *dev, *path, *p; - int ret; size_t pl; - - dev = devnam; - if (strncmp(dev, "/dev/", 5) == 0) - dev += 5; - if (dev[0] == 0 || strcmp(dev, "tty") == 0) - return 1; /* don't look for /etc/ppp/options.tty */ - pl = strlen(_PATH_TTYOPT) + strlen(dev) + 1; + char *path, *p; + int ret; + pl = strlen(prefix) + strlen(dev) + 1; path = malloc(pl); if (path == NULL) - novm("tty init file name"); - slprintf(path, pl, "%s%s", _PATH_TTYOPT, dev); - /* Turn slashes into dots, for Solaris case (e.g. /dev/term/a) */ - for (p = path + strlen(_PATH_TTYOPT); *p != 0; ++p) + novm("per-device init file name"); + slprintf(path, pl, "%s%s", prefix, dev); + /* Turn slashes into dots */ + for (p = path + strlen(prefix); *p != 0; ++p) if (*p == '/') *p = '.'; ret = options_from_file(path, 0, 0, 1); @@ -547,6 +541,28 @@ } /* + * options_for_tty - See if an options file exists for the serial + * device, and if so, interpret options from it. + */ +static int +options_for_tty() +{ + char *dev = devnam; + + if (strncmp(dev, "/dev/", 5) == 0) + dev += 5; + if (dev[0] == 0 || strcmp(dev, "tty") == 0) + return 1; /* don't look for /etc/ppp/options.tty */ + return options_from_devfile(_PATH_TTYOPT, dev); +} + +/* + * options_for_device_hook - read the per-device options. This should + * usually just be a wrapper around options_from_devfile + */ +int (*options_for_device_hook) __P((void)) = options_for_tty; + +/* * options_from_list - process a string of options in a wordlist. */ int @@ -589,7 +605,7 @@ * Maybe a tty name, speed or IP address? */ if ((i = setdevname(w->word)) == 0 - && (i = setspeed(w->word)) == 0 + && (i = setspeed_hook(w->word)) == 0 && (i = setipaddr(w->word)) == 0) { option_error("In secrets file: unrecognized option '%s'", w->word); @@ -617,6 +633,8 @@ struct option_list *list; int i; + if (*name == '\0') + return NULL; for (list = extra_options; list != NULL; list = list->next) for (opt = list->options; opt->name != NULL; ++opt) if (strcmp(name, opt->name) == 0) @@ -636,6 +654,23 @@ } /* + * remove_option - permanently remove an option from consideration... + * for use by modules to remove choices which no longer make sense. + * returns true if found an option + */ +int +remove_option(name) + char *name; +{ + option_t *o; + o = find_option(name); + if (o == NULL) + return 0; + o->name = ""; + return 1; +} + +/* * process_option - process one new-style option. */ static int @@ -1319,8 +1354,8 @@ * setspeed - Set the speed. */ static int -setspeed(arg) - char *arg; +setspeed_async(arg) + const char *arg; { char *ptr; int spd; @@ -1334,13 +1369,34 @@ return 1; } +int (*setspeed_hook) __P((const char *)) = setspeed_async; + +/* + * dev_set_ok - Is it ok to specify new a device now? + */ +int +dev_set_ok(void) +{ + if (phase != PHASE_INITIALIZE) { + option_error("device name cannot be changed after initialization"); + return 0; + } else if (devnam_fixed) { + option_error("per-tty options file may not specify device name"); + return 0; + } + if (devnam_info.priv && !privileged_option) { + option_error("device name cannot be overridden"); + return 0; + } + return 1; +} /* - * setdevname - Set the device name. + * setdevname_async - Set the device name (for the default async behavior) */ static int -setdevname(cp) - char *cp; +setdevname_async(cp) + const char *cp; { struct stat statbuf; char dev[MAXPATHLEN]; @@ -1368,28 +1424,33 @@ return -1; } - if (phase != PHASE_INITIALIZE) { - option_error("device name cannot be changed after initialization"); - return -1; - } else if (devnam_fixed) { - option_error("per-tty options file may not specify device name"); - return -1; - } - - if (devnam_info.priv && !privileged_option) { - option_error("device name cannot be overridden"); - return -1; - } + if (!dev_set_ok()) + return -1; - strlcpy(devnam, cp, sizeof(devnam)); devstat = statbuf; - default_device = 0; - devnam_info.priv = privileged_option; - devnam_info.source = option_source; + strlcpy(devnam, cp, sizeof(devnam)); return 1; } +int (*setdevname_hook) __P((const char *cp)) = setdevname_async; + +/* + * setdevname - Set the device name + */ +static int +setdevname(cp) + const char *cp; +{ + int result; + result = setdevname_hook(cp); + if (result == 1) { + default_device = 0; + devnam_info.priv = privileged_option; + devnam_info.source = option_source; + } + return result; +} /* * setipaddr - Set the IP address @@ -1545,27 +1606,106 @@ } #ifdef PLUGIN + +static struct plugin_info { + char *name; + void *handle; + struct plugin_info *next; +} *plugin_registry = NULL; + +/* Odd semantics - returns NULL if plugin was already in the registry + * (i.e. we already loaded this module, probably in prepass), otherwise + * a pointer to a newly allocated plugin_info + */ +static struct plugin_info * +add_plugin_to_registry (name) + const char *name; +{ + struct plugin_info *a, *last = NULL; + for (a = plugin_registry; a != NULL; a = a->next) { + if (strcmp(name, a->name) == 0) { + if (a->handle != NULL && !prepass) { + void (*init_later) __P((void)); + init_later = dlsym(a->handle, "plugin_init_later"); + if (init_later != NULL) + (*init_later)(); + a->handle = NULL; /* Only init once */ + } + return NULL; + } + last = a; + a = a->next; + } + /* OK, it wasn't found, allocate a new one */ + a = (struct plugin_info *) malloc(sizeof *a); + if (a == NULL) + novm("plugin_info structure"); + a->name = strdup(name); + if (a->name == NULL) + novm("plugin_info name"); + a->next = NULL; + a->handle = NULL; + if (last != NULL) + last->next = a; + else + plugin_registry = a; + return a; +} + +/* dlopen a plugin. If name contains no '/' or '.'s its relative */ +static void * +openplugin(p) + const char *p; +{ + char *buf = NULL; + const char *q; + void *result; + if (*p == '\0') + return NULL; + q = p; + while (*q != '/' && *q != '.' && *q !='\0') + q++; + if (*q == '\0') { + /* _PATH_PLUGIN contains a %s for the plugin name */ + int len = strlen(p) + strlen(_PATH_PLUGIN); + buf = malloc(len); + if (buf == NULL) + novm("plugin file name"); + slprintf(buf, len, _PATH_PLUGIN, p); + p = buf; + } + result = dlopen(p, RTLD_GLOBAL | RTLD_NOW); + if (buf != NULL) + free(buf); + return result; +} + static int loadplugin(argv) char **argv; { char *arg = *argv; - void *handle; const char *err; void (*init) __P((void)); + struct plugin_info *pi; - handle = dlopen(arg, RTLD_GLOBAL | RTLD_NOW); - if (handle == 0) { + pi = add_plugin_to_registry (arg); + if (pi == NULL) + return 1; /* already done */ + if (!prepass) + return 0; + pi->handle = openplugin(arg); + if (pi->handle == 0) { err = dlerror(); if (err != 0) option_error("%s", err); option_error("Couldn't load plugin %s", arg); return 0; } - init = dlsym(handle, "plugin_init"); + init = dlsym(pi->handle, "plugin_init"); if (init == 0) { option_error("%s has no initialization entry point", arg); - dlclose(handle); + dlclose(pi->handle); return 0; } info("Plugin %s loaded.", arg); diff -ur ppp-2.3.11/pppd/pathnames.h ppp-2.3.11mnb1/pppd/pathnames.h --- ppp-2.3.11/pppd/pathnames.h Fri Nov 19 21:09:26 1999 +++ ppp-2.3.11mnb1/pppd/pathnames.h Wed Sep 7 12:08:06 1904 @@ -17,6 +17,9 @@ #ifndef _ROOT_PATH #define _ROOT_PATH #endif +#ifndef _LIB_DIR +#define _LIB_DIR "/usr/lib" +#endif #define _PATH_UPAPFILE _ROOT_PATH "/etc/ppp/pap-secrets" #define _PATH_CHAPFILE _ROOT_PATH "/etc/ppp/chap-secrets" @@ -26,6 +29,7 @@ #define _PATH_AUTHUP _ROOT_PATH "/etc/ppp/auth-up" #define _PATH_AUTHDOWN _ROOT_PATH "/etc/ppp/auth-down" #define _PATH_TTYOPT _ROOT_PATH "/etc/ppp/options." +#define _PATH_ATMOPT _ROOT_PATH "/etc/ppp/options-atm." #define _PATH_CONNERRS _ROOT_PATH "/etc/ppp/connect-errors" #define _PATH_PEERFILES _ROOT_PATH "/etc/ppp/peers/" #define _PATH_RESOLV _ROOT_PATH "/etc/ppp/resolv.conf" @@ -41,3 +45,7 @@ #define _PATH_IPXUP _ROOT_PATH "/etc/ppp/ipx-up" #define _PATH_IPXDOWN _ROOT_PATH "/etc/ppp/ipx-down" #endif /* IPX_CHANGE */ + +#ifdef PLUGIN +#define _PATH_PLUGIN _LIB_DIR "/pppd/plugins/%s.so" +#endif diff -ur ppp-2.3.11/pppd/plugins/Makefile.linux ppp-2.3.11mnb1/pppd/plugins/Makefile.linux --- ppp-2.3.11/pppd/plugins/Makefile.linux Sun Nov 14 20:08:24 1999 +++ ppp-2.3.11mnb1/pppd/plugins/Makefile.linux Wed Sep 7 13:28:44 1904 @@ -1,5 +1,5 @@ CC = gcc -CFLAGS = -g -O2 -I.. -I../../include +CFLAGS = -g -O2 -I.. -I../../include -D_linux_=1 LDFLAGS = -shared all: minconn.so passprompt.so diff -ur ppp-2.3.11/pppd/plugins/Makefile.sol2 ppp-2.3.11mnb1/pppd/plugins/Makefile.sol2 --- ppp-2.3.11/pppd/plugins/Makefile.sol2 Tue Nov 16 19:49:27 1999 +++ ppp-2.3.11mnb1/pppd/plugins/Makefile.sol2 Wed Sep 7 13:29:21 1904 @@ -6,7 +6,7 @@ include ../../svr4/Makedefs -CFLAGS = -c -O -I.. -I../../include $(COPTS) +CFLAGS = -c -O -I.. -I../../include -DSVR4 -DSOL2 $(COPTS) LDFLAGS = -G all: minconn.so diff -ur ppp-2.3.11/pppd/pppd.h ppp-2.3.11mnb1/pppd/pppd.h --- ppp-2.3.11/pppd/pppd.h Wed Dec 22 17:29:42 1999 +++ ppp-2.3.11mnb1/pppd/pppd.h Wed Sep 7 13:43:53 1904 @@ -448,7 +448,8 @@ int privileged)); /* Parse options from an options file */ int options_from_user __P((void)); /* Parse options from user's .ppprc */ -int options_for_tty __P((void)); /* Parse options from /etc/ppp/options.tty */ +int options_from_devfile __P((const char *, const char *)); + /* Parse options device-specific file */ int options_from_list __P((struct wordlist *, int privileged)); /* Parse options from a wordlist */ int getword __P((FILE *f, char *word, int *newlinep, char *filename)); @@ -458,6 +459,8 @@ int int_option __P((char *, int *)); /* Simplified number_option for decimal ints */ void add_options __P((option_t *)); /* Add extra options */ +int remove_option __P((char *)); /* Remove option */ +int dev_set_ok __P((void)); /* OK to specify a device */ /* * This structure is used to store information about certain @@ -478,7 +481,8 @@ extern struct option_info ptycommand_info; /* - * Hooks to enable plugins to change various things. + * Hooks to enable plugins to change various things. These are documented + * in the PLUGINS file */ extern int (*new_phase_hook) __P((int)); extern int (*idle_time_hook) __P((struct ppp_idle *)); @@ -491,6 +495,18 @@ extern int (*pap_passwd_hook) __P((char *user, char *passwd)); extern void (*ip_up_hook) __P((void)); extern void (*ip_down_hook) __P((void)); +extern int (*setspeed_hook) __P((const char *)); +extern int (*setdevname_hook) __P((const char *)); +extern int (*options_for_device_hook) __P((void)); +extern int (*open_device_hook) __P((void)); +extern void (*post_open_setup_hook) __P((int)); +extern void (*pre_close_restore_hook) __P((int)); +extern void (*no_device_given_hook) __P((void)); +extern void (*set_line_discipline_hook) __P((int)); +extern void (*reset_line_discipline_hook) __P((int)); +extern void (*send_config_hook) __P((int, int, u_int32_t, int, int)); +extern void (*recv_config_hook) __P((int, int, u_int32_t, int, int)); +extern void (*set_xaccm_hook) __P((int, ext_accm)); /* * Inline versions of get/put char/short/long. diff -ur ppp-2.3.11/pppd/sys-linux.c ppp-2.3.11mnb1/pppd/sys-linux.c --- ppp-2.3.11/pppd/sys-linux.c Wed Dec 22 15:51:31 1999 +++ ppp-2.3.11mnb1/pppd/sys-linux.c Wed Sep 7 14:43:23 1904 @@ -136,7 +136,7 @@ static int restore_term = 0; /* 1 => we've munged the terminal */ static struct termios inittermios; /* Initial TTY termios */ -static int new_style_driver = 0; +int new_style_driver = 0; static char loop_name[20]; static unsigned char inbuf[512]; /* buffer for chars read from loopback */ @@ -355,6 +355,7 @@ int establish_ppp (int tty_fd) { int x; + extern struct stat devstat; /* * The current PPP device will be the tty file. @@ -365,7 +366,7 @@ /* * Ensure that the tty device is in exclusive mode. */ - if (ioctl(tty_fd, TIOCEXCL, 0) < 0) { + if (isatty(tty_fd) && ioctl(tty_fd, TIOCEXCL, 0) < 0) { if ( ! ok_error ( errno )) warn("ioctl(TIOCEXCL): %m"); } @@ -385,9 +386,13 @@ if (new_style_driver) ppp_disc = sync_serial ? N_SYNC_PPP:N_PPP; - if (ioctl(tty_fd, TIOCSETD, &ppp_disc) < 0) { - if ( ! ok_error (errno) ) - fatal("ioctl(TIOCSETD): %m(%d)", errno); + if (set_line_discipline_hook != NULL) + set_line_discipline_hook(tty_fd); + else { + if (ioctl(tty_fd, TIOCSETD, &ppp_disc) < 0) { + if ( ! ok_error (errno) ) + fatal("ioctl(TIOCSETD): %m(%d)", errno); + } } /* * Find out which interface we were given. @@ -425,8 +430,9 @@ set_kdebugflag (kdebugflag); looped = 0; - set_flags(tty_fd, get_flags(tty_fd) & ~(SC_RCV_B7_0 | SC_RCV_B7_1 | - SC_RCV_EVNP | SC_RCV_ODDP)); + if (S_ISCHR(devstat.st_mode)) + set_flags(tty_fd, get_flags(tty_fd) & ~(SC_RCV_B7_0 | SC_RCV_B7_1 | + SC_RCV_EVNP | SC_RCV_ODDP)); SYSDEBUG ((LOG_NOTICE, "Using version %d.%d.%d of PPP driver", driver_version, driver_modification, driver_patch)); @@ -455,22 +461,26 @@ if (new_style_driver) remove_fd(tty_fd); if (!hungup) { + if (reset_line_discipline_hook != NULL) + reset_line_discipline_hook(tty_fd); + else { /* * Flush the tty output buffer so that the TIOCSETD doesn't hang. */ - if (tcflush(tty_fd, TCIOFLUSH) < 0) - warn("tcflush failed: %m"); + if (tcflush(tty_fd, TCIOFLUSH) < 0) + warn("tcflush failed: %m"); /* * Restore the previous line discipline */ - if (ioctl(tty_fd, TIOCSETD, &tty_disc) < 0) { - if ( ! ok_error (errno)) - error("ioctl(TIOCSETD, N_TTY): %m"); - } + if (ioctl(tty_fd, TIOCSETD, &tty_disc) < 0) { + if ( ! ok_error (errno)) + error("ioctl(TIOCSETD, N_TTY): %m"); + } - if (ioctl(tty_fd, TIOCNXCL, 0) < 0) { - if ( ! ok_error (errno)) - warn("ioctl(TIOCNXCL): %m(%d)", errno); + if (ioctl(tty_fd, TIOCNXCL, 0) < 0) { + if ( ! ok_error (errno)) + warn("ioctl(TIOCNXCL): %m(%d)", errno); + } } /* Reset non-blocking mode on fd. */ --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pppoatm.c" // NOTE // NOTE // NOTE // NOTE // NOTE // NOTE // NOTE // NOTE // NOTE // // // This is only meant as an example of the new pppd plugins right now... // it won't work with the current PPPoATM code for the kernel (as // distributed by Jens Axboe), it is meant to work with a new version // of the in-kernel PPPoATM backend which I am working on. As such // it will neither compile nor work in this present form. // -- mitch@sfgoth.com // // NOTE // NOTE // NOTE // NOTE // NOTE // NOTE // NOTE // NOTE // NOTE // /* pppoatm.c - pppd plugin to implement PPPoATM protocol. * * Copyright 2000 Mitchell Blank Jr. * Based in part on work from Jens Axboe and Paul Mackerras. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version * 2 of the License, or (at your option) any later version. */ #include "pppd.h" #include static struct sockaddr_atmpvc pvcaddr; static char *qosstr = NULL; static int pppoatm_accept = 0; static bool llc_encaps = 0; static bool vc_encaps = 0; static option_t my_options[] = { #if 0 { "accept", o_bool, &pppoatm_accept, "set PPPoATM socket to accept incoming connections", 1 }, #endif { "llc-encaps", o_bool, &llc_encaps, "use LLC encapsulation for PPPoATM", 1}, { "vc-encaps", o_bool, &vc_encaps, "use VC multiplexing for PPPoATM (default)", 1}, { "qos", o_str, &qosstr, "set QoS for PPPoATM connection", 1}, { NULL } }; /* returns: * -1 if there's a problem with setting the device * 0 if we can't parse "cp" as a valid name of a device * 1 if "cp" is a reasonable thing to name a device * Note that we don't actually open the device at this point * We do need to fill in: * devnam: a string representation of the device * devstat: a stat structure of the device. In this case * we're not opening a device, so we just make sure * to set up S_ISCHR(devstat.st_mode) != 1, so we * don't get confused that we're on stdin. */ static int setdevname_pppoatm(const char *cp) { struct sockaddr_atmpvc addr; extern struct stat devstat; info("PPPoATM setdevname_pppoatm"); memset(&addr, 0, sizeof addr); if (text2atm(cp, (struct sockaddr *) &addr, sizeof(addr), T2A_PVC | T2A_NAME) < 0) return 0; if (!dev_set_ok()) return -1; memcpy(&pvcaddr, &addr, sizeof pvcaddr); strlcpy(devnam, cp, sizeof devname); devstat.st_mode = S_IFSOCK; info("PPPoATM setdevname_pppoatm - SUCCESS"); return 1; } static int setspeed_pppoatm(const char *cp) { return 0; } static int options_for_pppoatm(void) { return options_from_devfile(_PATH_ATMOPT, devnam); } #define pppoatm_overhead() (llc_encaps ? 6 : 2) static int open_device_pppoatm(void) { int fd; struct atm_qos qos; fd = socket(AF_ATMPVC, SOCK_DGRAM, 0); if (fd < 0) fatal("failed to create socket: %m"); memset(&qos, 0, sizeof qos); /* TODO: support simplified QoS setting */ if (qosstr != NULL) if (text2qos(qosstr, &qos, 0)) fatal("Can't parse QoS: \"%s\""); qos.txtp.max_sdu = mtu + pppoatm_overhead(); qos.rxtp.max_sdu = mru + pppoatm_overhead(); qos.aal = ATM_AAL5; if (setsockopt(fd, SOL_ATM, SO_ATMQOS, &qos, sizeof(qos)) < 0) fatal("setsockopt(SO_ATMQOS): %m"); /* TODO: accept on SVCs... */ if (connect(fd, (struct sockaddr *) &addr, sizeof(struct sockaddr_atmpvc)) fatal("connect(%s): %m", devnam); return fd; } static void post_open_setup_pppoatm(void) { /* NOTHING */ } static void pre_close_restore_pppoatm(void) { /* NOTHING */ } static void no_device_given_pppoatm(void) { fatal("No vpi.vci specified"); } static void set_line_discipline_pppoatm(int fd) { int encaps; if (ioctl(fd, ATM_SET_HANDLER, ATM_HANDLER_PPP) < 0) fatal("ioctl(ATM_SET_HANDLER, ATM_HANDLER_PPP): %m"); if (!llc_encaps) encaps = PPPOATM_ENCAPS_VC; else if (!vc_encaps) encaps = PPPOATM_ENCAPS_LLC; else encaps = PPPOATM_ENCAPS_AUTODETECT; if (ioctl(fd, PPPOATM_SET_ENCAPS, encaps) < 0) fatal("ioctl(PPPOATM_SET_ENCAPS): %m"); } static void unset_line_discipline_pppoatm(int fd) { if (ioctl(fd, ATM_SET_HANDLER, ATM_HANDLER_RAW) < 0) fatal("ioctl(ATM_SET_HANDLER, ATM_HANDLER_RAW): %m"); } static void send_config_pppoatm(int unit, int mtu, u_int32_t asyncmap, int pcomp, int accomp) { int sock; struct ifreq ifr; if (mtu > pppoatm_max_mtu) error("Couldn't increase MTU to %d", mtu); sock = socket(AF_INET, SOCK_DGRAM, 0); if (sock < 0) fatal("Couldn't create IP socket: %m"); strlcpy(ifr.ifr_name, ifname, sizeof(ifr.ifr_name)); ifr.ifr_mtu = mtu; if (ioctl(sock, SIOCSIFMTU, (caddr_t) &ifr) < 0) fatal("ioctl(SIOCSIFMTU): %m"); (void) close (sock); } static void recv_config_pppoatm(int unit, int mru, u_int32_t asyncmap, int pcomp, int accomp) { if (mru > pppoatm_max_mru) error("Couldn't increase MRU to %d", mru); } static void set_xaccm_pppoatm(int unit, ext_accm accm) { /* NOTHING */ } void plugin_init(void) { #if _linux_ extern int new_style_driver; /* From sys-linux.c */ #endif static char *bad_options[] = { "noaccomp", "-ac", "default-asyncmap", "-am", "asyncmap", "-as", "escape", "receive-all", "crtscts", "-crtscts", "nocrtscts", "cdtrcts", "nocdtrcts", "xonxoff", "modem", "local", "sync", NULL }; #if _linux_ if (!new_style_driver) fatal("Kernel doesn't support ppp_generic needed for PPPoATM"); #else fatal("No PPPoATM support on this OS"); #endif info("PPPoATM plugin_init"); add_options(my_options); setdevname_hook = setdevname_pppoatm; setspeed_hook = setspeed_pppoatm; options_from_device_hook = options_for_pppoatm; open_device_hook = open_device_pppoatm; post_open_setup_hook = post_open_setup_pppoatm; pre_close_restore_hook = pre_close_restore_pppoatm; no_device_given_hook = no_device_given_pppoatm; set_line_discipline_hook = set_line_discipline_pppoatm; reset_line_discipline_hook = reset_line_discipline_pppoatm; send_config_hook = send_config_pppoatm; recv_config_hook = recv_config_pppoatm; set_xaccm_hook = set_xaccm_pppoatm; { char **a; for (a = bad_options; *a != NULL; a++) remove_option(*a); } modem = 0; lcp_wantoptions[0].neg_accompression = 0; lcp_allowoptions[0].neg_accompression = 0; lcp_wantoptions[0].neg_asyncmap = 0; lcp_allowoptions[0].neg_asyncmap = 0; lcp_wantoptions[0].neg_pcompression = 0; } --azLHFNyN32YCQGCU-- From owner-netdev@oss.sgi.com Wed Feb 16 15:16:05 2000 Received: by oss.sgi.com id ; Wed, 16 Feb 2000 15:15:55 -0800 Received: from longneck.netc.pt ([212.18.160.140]:3312 "EHLO longneck.netc.pt") by oss.sgi.com with ESMTP id ; Wed, 16 Feb 2000 15:15:48 -0800 Received: from cod.netc.pt (cod) by longneck.netc.pt (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FQ100BEMPSNGJ@longneck.netc.pt>; Wed, 16 Feb 2000 23:12:23 +0000 (GMT) Received: from hippo.isp.pt ([10.41.1.19]) by cod.netc.pt (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with ESMTP id <0FQ100FD9PSMKL@cod.netc.pt>; Wed, 16 Feb 2000 23:12:22 +0000 (GMT) Received: from netc.pt (localhost [127.0.0.1]) by hippo.isp.pt (8.8.8+Sun/8.8.8) with ESMTP id XAA03199; Wed, 16 Feb 2000 23:12:22 +0000 (GMT) Date: Wed, 16 Feb 2000 23:12:22 +0000 From: Sampo Kellomaki Subject: 2.3.46-pre3 make modules fails (aironet4500_core.c:1754: structure has no member named `tbusy') To: Elmer.Joandi@ut.ee Cc: netdev@oss.sgi.com, dhinds@zen.stanford.edu, sampo@iki.fi, sampo@netc.pt Message-id: <38AB2ED6.D9E7F1DC@netc.pt> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing It appears that the aironet driver is out of sync from linux/netdevice.h as it refers to tbusy field which apparently does not exist (anymore?). 1. Got linux-2.3.45 and pre-patch-2.3.46-3 from kernel.org 2. Configured kernel, mostly everything as modules, including aironet (see .config in the end) 3. make dep && make bzImage 4. make modules ... make[2]: Entering directory `/home/src/linux-2.3.45/drivers/net' gcc -D__KERNEL__ -I/home/src/linux-2.3.45/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -DCPU=586 -DMODULE -DEXPORT _SYMTAB -c 8390.c gcc -D__KERNEL__ -I/home/src/linux-2.3.45/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -DCPU=586 -DMODULE -DEXPORT _SYMTAB -c aironet4500_card.c gcc -D__KERNEL__ -I/home/src/linux-2.3.45/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -DCPU=586 -DMODULE -DEXPORT _SYMTAB -c aironet4500_core.c aironet4500_core.c: In function `awc_802_11_tx_find_path_and_post': aironet4500_core.c:1754: structure has no member named `tbusy' aironet4500_core.c:1755: `NET_BH' undeclared (first use this function) aironet4500_core.c:1755: (Each undeclared identifier is reported only once aironet4500_core.c:1755: for each function it appears in.) aironet4500_core.c:1766: structure has no member named `tbusy' aironet4500_core.c:1774: structure has no member named `tbusy' aironet4500_core.c: In function `awc_802_11_after_tx_packet_to_card_write': aironet4500_core.c:1805: `NET_BH' undeclared (first use this function) aironet4500_core.c: In function `awc_802_11_after_tx_complete': aironet4500_core.c:1869: structure has no member named `tbusy' aironet4500_core.c:1870: `NET_BH' undeclared (first use this function) aironet4500_core.c: In function `awc_bh': aironet4500_core.c:2229: structure has no member named `tbusy' aironet4500_core.c:2230: structure has no member named `start' aironet4500_core.c: In function `awc_interrupt_process': aironet4500_core.c:2330: structure has no member named `interrupt' aironet4500_core.c:2357: structure has no member named `tbusy' aironet4500_core.c:2358: structure has no member named `start' aironet4500_core.c:2362: structure has no member named `interrupt' aironet4500_core.c:2371: structure has no member named `interrupt' aironet4500_core.c:2461: structure has no member named `tbusy' aironet4500_core.c:2462: `NET_BH' undeclared (first use this function) aironet4500_core.c:2505: structure has no member named `interrupt' aironet4500_core.c:2534: structure has no member named `interrupt' aironet4500_core.c: In function `awc_private_init': aironet4500_core.c:2909: structure has no member named `interrupt' aironet4500_core.c: In function `awc_open': aironet4500_core.c:2927: structure has no member named `interrupt' aironet4500_core.c:2927: structure has no member named `tbusy' aironet4500_core.c:2927: structure has no member named `start' aironet4500_core.c:2948: structure has no member named `tbusy' aironet4500_core.c:2948: structure has no member named `start' aironet4500_core.c:2952: structure has no member named `tbusy' aironet4500_core.c:2952: structure has no member named `start' aironet4500_core.c: In function `awc_close': aironet4500_core.c:2964: structure has no member named `start' aironet4500_core.c:2965: structure has no member named `tbusy' aironet4500_core.c: In function `awc_tx_timeout': aironet4500_core.c:3002: structure has no member named `tbusy' aironet4500_core.c: In function `awc_start_xmit': aironet4500_core.c:3025: structure has no member named `tbusy' aironet4500_core.c:3040: structure has no member named `tbusy' aironet4500_core.c:3065: structure has no member named `tbusy' aironet4500_core.c: In function `awc_tx_done': aironet4500_core.c:3081: `NET_BH' undeclared (first use this function) aironet4500_core.c: In function `awc_get_stats': aironet4500_core.c:3145: structure has no member named `start' aironet4500_core.c: In function `awc_change_mtu': aironet4500_core.c:3186: structure has no member named `start' make[2]: *** [aironet4500_core.o] Error 1 make[2]: Leaving directory `/home/src/linux-2.3.45/drivers/net' make[1]: *** [_modsubdir_net] Error 2 make[1]: Leaving directory `/home/src/linux-2.3.45/drivers' make: *** [_mod_drivers] Error 2 --------------- Here comes my .config # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set CONFIG_M586TSC=y # CONFIG_M686 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=m CONFIG_CARDBUS=y CONFIG_I82365=y # CONFIG_TCIC is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_PARPORT is not set CONFIG_ACPI=y # CONFIG_ACPI_S1_SLEEP is not set # CONFIG_APM is not set # # Plug and Play configuration # CONFIG_PNP=m CONFIG_ISAPNP=m # # Block devices # CONFIG_BLK_DEV_FD=m CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDECD is not set # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set CONFIG_IDEDMA_PCI_EXPERIMENTAL=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_AEC6210 is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD7409 is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set CONFIG_BLK_DEV_PIIX=y CONFIG_BLK_DEV_PIIX_TUNING=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y # CONFIG_IDE_CHIPSETS is not set # CONFIG_BLK_CPQ_DA is not set # # Additional Block Devices # CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=m CONFIG_MD_STRIPED=m CONFIG_BLK_DEV_RAM=m # CONFIG_BLK_DEV_XD is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_PARIDE is not set CONFIG_BLK_DEV_IDE_MODES=y # CONFIG_BLK_DEV_HD is not set # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y # CONFIG_RTNETLINK is not set CONFIG_NETLINK_DEV=m CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_IP_ROUTER is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_IP_ALIAS=y CONFIG_SYN_COOKIES=y # # (it is safe to leave these untouched) # CONFIG_SKB_LARGE=y CONFIG_IPV6=m # CONFIG_IPV6_EUI64 is not set # CONFIG_IPV6_NETLINK is not set CONFIG_KHTTPD=m # CONFIG_ATM is not set # # # CONFIG_IPX=m # CONFIG_IPX_INTERN is not set CONFIG_SPX=m CONFIG_ATALK=m # CONFIG_DECNET is not set CONFIG_X25=m CONFIG_LAPB=m # CONFIG_BRIDGE is not set CONFIG_LLC=y # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # # SCSI support # # CONFIG_SCSI is not set # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m CONFIG_IEEE1394_PCILYNX=m # CONFIG_IEEE1394_PCILYNX_LOCALRAM is not set CONFIG_IEEE1394_AIC5800=m CONFIG_IEEE1394_OHCI1394=m CONFIG_IEEE1394_RAWIO=m # # I2O device support # # CONFIG_I2O is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_EQUALIZER is not set CONFIG_ETHERTAP=m # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_DE4X5 is not set # CONFIG_TULIP is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set CONFIG_EEXPRESS_PRO100=y # CONFIG_LNE390 is not set # CONFIG_NE3210 is not set # CONFIG_NE2K_PCI is not set # CONFIG_RTL8129 is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_ES3210 is not set # CONFIG_EPIC100 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_YELLOWFIN is not set # CONFIG_ACENIC is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # # Appletalk devices # # CONFIG_LTPC is not set # CONFIG_COPS is not set # CONFIG_IPDDP is not set CONFIG_PPP=m CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y # CONFIG_SLIP_SMART is not set # CONFIG_SLIP_MODE_SLIP6 is not set # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y CONFIG_STRIP=m CONFIG_ARLAN=m CONFIG_AIRONET4500=m CONFIG_AIRONET4500_NONCS=m # CONFIG_AIRONET4500_PNP is not set # CONFIG_AIRONET4500_PCI is not set # CONFIG_AIRONET4500_ISA is not set CONFIG_AIRONET4500_I365=y CONFIG_AIRONET4500_PROC=m # # Token Ring driver support # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # CONFIG_WAN=y # CONFIG_HOSTESS_SV11 is not set # CONFIG_COSA is not set # CONFIG_SEALEVEL_4021 is not set # CONFIG_DLCI is not set CONFIG_LAPBETHER=m CONFIG_X25_ASY=m # CONFIG_SBNI is not set # # PCMCIA network device support # CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_3C589=m CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_FMVJ18X=m CONFIG_PCMCIA_PCNET=m CONFIG_PCMCIA_NMCLAN=m CONFIG_PCMCIA_SMC91C92=m CONFIG_PCMCIA_XIRC2PS=m CONFIG_AIRONET4500_CS=m CONFIG_PCMCIA_3C575=m CONFIG_PCMCIA_TULIP=m CONFIG_NET_PCMCIA_RADIO=y CONFIG_PCMCIA_RAYCS=m CONFIG_PCMCIA_NETWAVE=m CONFIG_PCMCIA_WAVELAN=m # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # CONFIG_IRDA=m # # IrDA protocols # CONFIG_IRLAN=m CONFIG_IRCOMM=m CONFIG_IRDA_ULTRA=y CONFIG_IRDA_OPTIONS=y # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y CONFIG_IRDA_DEBUG=y CONFIG_IRDA_COMPRESSION=y # # IrDA compressors # CONFIG_IRDA_DEFLATE=m # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=m CONFIG_IRPORT_SIR=m # # FIR device drivers # CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_TOSHIBA_FIR=m CONFIG_SMC_IRCC_FIR=m # # Dongle support # # CONFIG_DONGLE is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y # CONFIG_SERIAL_CONSOLE is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_UNIX98_PTYS is not set # # I2C support # # CONFIG_I2C is not set # # Mice # CONFIG_BUSMOUSE=m CONFIG_ATIXL_BUSMOUSE=m CONFIG_LOGIBUSMOUSE=m CONFIG_MS_BUSMOUSE=m CONFIG_MOUSE=m CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # # Joysticks # # CONFIG_JOYSTICK is not set # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_NVRAM=m CONFIG_RTC=m # # Video For Linux # CONFIG_VIDEO_DEV=m # # Radio Adapters # # CONFIG_RADIO_CADET is not set # CONFIG_RADIO_RTRACK is not set # CONFIG_RADIO_RTRACK2 is not set # CONFIG_RADIO_AZTECH is not set # CONFIG_RADIO_GEMTEK is not set # CONFIG_RADIO_MIROPCM20 is not set # CONFIG_RADIO_SF16FMI is not set # CONFIG_RADIO_TERRATEC is not set # CONFIG_RADIO_TRUST is not set # CONFIG_RADIO_TYPHOON is not set # CONFIG_RADIO_ZOLTRIX is not set # # Video Adapters # CONFIG_VIDEO_BT848=m CONFIG_VIDEO_PMS=m # CONFIG_VIDEO_SAA5249 is not set CONFIG_VIDEO_STRADIS=m CONFIG_VIDEO_ZORAN=m CONFIG_VIDEO_BUZ=m CONFIG_VIDEO_ZR36120=m # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_DRM=y CONFIG_DRM_TDFX=m CONFIG_DRM_GAMMA=m CONFIG_PCMCIA_SERIAL=m # # PCMCIA character device support # CONFIG_PCMCIA_SERIAL_CS=m CONFIG_PCMCIA_SERIAL_CB=m # CONFIG_AGP is not set # # USB support # CONFIG_USB=m # # USB Controllers # CONFIG_USB_UHCI=m CONFIG_USB_UHCI_HIGH_BANDWIDTH=y CONFIG_USB_UHCI_ALT=m CONFIG_USB_UHCI_ALT_UNLINK_OPTIMIZE=y CONFIG_USB_OHCI=m # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # # USB Devices # CONFIG_USB_PRINTER=m CONFIG_USB_SCANNER=m CONFIG_USB_AUDIO=m CONFIG_USB_ACM=m CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_VISOR=y CONFIG_USB_SERIAL_WHITEHEAT=y CONFIG_USB_SERIAL_FTDI_SIO=y CONFIG_USB_SERIAL_KEYSPAN_PDA=y CONFIG_USB_CPIA=m CONFIG_USB_IBMCAM=m CONFIG_USB_OV511=m CONFIG_USB_DC2XX=m CONFIG_USB_STORAGE=m CONFIG_USB_STORAGE_DEBUG=y CONFIG_USB_DABUSB=m CONFIG_USB_PLUSB=m # # USB HID # CONFIG_USB_HID=m CONFIG_USB_KBD=m CONFIG_USB_MOUSE=m # CONFIG_USB_GRAPHIRE is not set # CONFIG_USB_WMFORCE is not set CONFIG_INPUT_KEYBDEV=m CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_MIX=y # CONFIG_INPUT_MOUSEDEV_DIGITIZER is not set # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=m # # Misc devices # # # Filesystems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=m # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_UMSDOS_FS=m CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set CONFIG_CRAMFS=m CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_MINIX_FS=m CONFIG_NTFS_FS=m # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_QNX4FS_FS is not set CONFIG_ROMFS_FS=m CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set CONFIG_UDF_FS=m CONFIG_UDF_RW=y # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_CODA_FS=m CONFIG_NFS_FS=m CONFIG_NFSD=m CONFIG_SUNRPC=m CONFIG_LOCKD=m CONFIG_SMB_FS=m CONFIG_NCP_FS=m # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_MOUNT_SUBDIR is not set # CONFIG_NCPFS_NDS_DOMAINS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_SGI_PARTITION is not set # CONFIG_SUN_PARTITION is not set CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=m # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_874 is not set CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set # # Console drivers # CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # # CONFIG_FB is not set # # Sound # CONFIG_SOUND=m CONFIG_SOUND_CMPCI=m # CONFIG_SOUND_CMPCI_SPDIFLOOP is not set # CONFIG_SOUND_CMPCI_4CH is not set CONFIG_SOUND_ES1370=m CONFIG_SOUND_ES1371=m CONFIG_SOUND_ESSSOLO1=m CONFIG_SOUND_MAESTRO=m CONFIG_SOUND_SONICVIBES=m CONFIG_SOUND_TRIDENT=m # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set CONFIG_SOUND_OSS=m CONFIG_SOUND_AD1816=m CONFIG_SOUND_SGALAXY=m CONFIG_SOUND_CS4232=m CONFIG_SOUND_SSCAPE=m CONFIG_SOUND_GUS=m # CONFIG_GUS16 is not set # CONFIG_GUSMAX is not set CONFIG_SOUND_VMIDI=m CONFIG_SOUND_TRIX=m CONFIG_SOUND_MSS=m CONFIG_SOUND_MPU401=m CONFIG_SOUND_NM256=m CONFIG_SOUND_MAD16=m # CONFIG_MAD16_OLDCARD is not set CONFIG_SOUND_PAS=m CONFIG_SOUND_PSS=m # CONFIG_PSS_MIXER is not set CONFIG_SOUND_SOFTOSS=m CONFIG_SOUND_SB=m CONFIG_SOUND_WAVEFRONT=m CONFIG_SOUND_MAUI=m CONFIG_SOUND_VIA82CXXX=m CONFIG_SOUND_YM3812=m CONFIG_SOUND_OPL3SA1=m CONFIG_SOUND_OPL3SA2=m CONFIG_SOUND_UART6850=m # # Additional low level sound drivers # CONFIG_LOWLEVEL_SOUND=y CONFIG_ACI_MIXER=m CONFIG_AWE32_SYNTH=m CONFIG_AEDSP16=m CONFIG_AEDSP16_BASE=220 CONFIG_MPU_BASE=330 # # SC-6600 Audio Cards have no jumper switches at all # # CONFIG_SC6600 is not set # CONFIG_AEDSP16_SBPRO is not set # CONFIG_AEDSP16_MSS is not set # CONFIG_AEDSP16_MPU401 is not set # # Kernel hacking # CONFIG_MAGIC_SYSRQ=y --Sampo From owner-netdev@oss.sgi.com Wed Feb 16 15:44:26 2000 Received: by oss.sgi.com id ; Wed, 16 Feb 2000 15:44:16 -0800 Received: from www.ylenurme.ee ([193.40.6.1]:42227 "EHLO yle-server.ylenurme.ee") by oss.sgi.com with ESMTP id ; Wed, 16 Feb 2000 15:43:57 -0800 Received: from localhost (elmer@localhost) by yle-server.ylenurme.ee (8.8.7/8.8.7) with ESMTP id BAA29986; Thu, 17 Feb 2000 01:43:45 +0200 Date: Thu, 17 Feb 2000 01:43:45 +0200 (EET) From: Elmer Joandi To: Sampo Kellomaki cc: netdev@oss.sgi.com, dhinds@zen.stanford.edu, sampo@iki.fi Subject: Re: 2.3.46-pre3 make modules fails (aironet4500_core.c:1754: structure has no member named `tbusy') In-Reply-To: <38AB2ED6.D9E7F1DC@netc.pt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing jeah, I am waiting for this softnet thing to cool down a bit and some good examples/docs to come on other drivers. There has been many fundamental changes, dreaming about that they would have came all together. Besides, I can not test it normally, as on my working computer I get strange disk corruptions... And more whining from here :) But anyway, taking it up on weekend if not before. Actually, maybe before. I have used to give my outgoing patches nightly burnin test under several configurations(thus, several nights), therefore I dont release so often. elmer. From owner-netdev@oss.sgi.com Thu Feb 17 00:55:25 2000 Received: by oss.sgi.com id ; Thu, 17 Feb 2000 00:55:15 -0800 Received: from mail0.u-aizu.ac.jp ([163.143.1.43]:39648 "EHLO mail0.u-aizu.ac.jp") by oss.sgi.com with ESMTP id ; Thu, 17 Feb 2000 00:54:49 -0800 Received: from ccultra2.u-aizu.ac.jp (ccultra2.u-aizu.ac.jp [163.143.99.104]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id RAA09345; Thu, 17 Feb 2000 17:54:18 +0900 (JST) Received: from ccultra2.u-aizu.ac.jp ([163.143.99.156]) by ccultra2.u-aizu.ac.jp (8.9.1b+Sun/8.8.8) with ESMTP id RAA00590; Thu, 17 Feb 2000 17:50:45 +0900 (JST) Message-ID: <38ABB78D.901A101C@ccultra2.u-aizu.ac.jp> Date: Thu, 17 Feb 2000 17:55:42 +0900 From: Behcet Sarikaya X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: netdev@nuclecu.unam.mx, netdev@oss.sgi.com, sekiya@isi.edu Subject: Multicast routing question References: <38A3D170.EBA92D8B@ccultra2.u-aizu.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Does anyone know which Linux software can do v6 multicast routing? --behcet From owner-netdev@oss.sgi.com Thu Feb 17 15:14:54 2000 Received: by oss.sgi.com id ; Thu, 17 Feb 2000 15:14:34 -0800 Received: from godzilla.funcform.se ([193.15.93.193]:16649 "EHLO funcform.se") by oss.sgi.com with ESMTP id ; Thu, 17 Feb 2000 15:14:18 -0800 Received: from iguana.funcform.se (andersg@iguana.funcform.se [193.15.93.211]) by funcform.se (8.9.3/8.9.3/Capricorn-0.1Godzilla) with SMTP id AAA09312; Fri, 18 Feb 2000 00:15:02 +0100 Date: Fri, 18 Feb 2000 00:15:25 +0100 (CET) From: Anders Gustafsson To: netdev@oss.sgi.com cc: dhinds@zen.stanford.edu Subject: 3c575_cb and 3c59x mearge Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="264360797-715998893-950829325=:597" Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --264360797-715998893-950829325=:597 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi! Hope i sent this mail to right persons (i.e someone responsible for network-drivers, especially pcmcia in the linux-kernel). I found that drivers/net/pcmcia/3c575_cb.c and drivers/net/3c59x.c is the same code, expect that the pcmcia-driver isn't updated as often as 3c59x.c. So my suggestion is to let the 3c575_cb driver be built from the same sourcefile as 3c59x.c. I have attached a patch that makes this. I think that it needs some more testing on other computers though, especially on non-pccard-interfaces. //anders/g ---------------------------------------------------------------- #!/usr/bin/perl $_+=++$_+($_++);$^=$_;$_+=++$.;$_=$_.$^;$/=chr().chr($..$..'0'); $/=~s/(.)(.)/$1$2/;$_=lc $1;$_++;$_++;$_++;$_=$_++.$_;$/.=$_; s/(.)/chr 14+ord $1/eg;print $/.$_."\n"; --264360797-715998893-950829325=:597 Content-Type: APPLICATION/octet-stream; name="3c59x-mearge.patch.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: H4sICJxnrDgAAzNjNTl4LW1lYXJnZS5wYXRjaADMW/t34saS/tn8FR1yNoMH CQM2fmU8ZzDYM9yxzazByeTu7tERUmMUC0nRw5hM5n/fr6pbIGzs2Elmz+bc Owa1uqu6Hl89unG98ViYmTDNWDpZnHi3Ep8DOTPHni/FbbO2XdvZi2LZ3PK9 ILvbcmO8EidbgUy3tp3WwV3NEY+OlEzTfN4aG8NJJk7lSDT2RLN52Gge7hyI Zr1eL1Wr1ccJrExrHDa3D1t62rt3wmzsG42GqNKfbfHuXUmIjXrt4OBD1b9p 1OrCFP+S2P17O/7duxFvfr3mD++mduDG9o1MwnFac8Lp25LY2LiU0xCiwdfI Tr2R53vpXLhy7AUyEeMwFjcyDqQviEEvDBLxRjRrzdpdjSZfRa6dSn4NkhUk jzsxDd0MEvaCVMZj25Elc2OjVC1y2ACH7cDFiuJ9lqT2OEnCQLyx+dH1u3EW OFhyWkvk21J1Y+Nc2vG1dEU6kYLFI/AmfdprWc6ICIUiDKRIwix2JKm3VqpC Jq+3SqIksH7qOcKZ2LF4rXchjkpmWUv68LYoOhL5gcGSFkPQOyMFiY9KBkNp T8UkTaPDrS1HJq6X1K6TsVML7MSuXYe396zgNoxTeVebpFP/v4Pyj6XqOpIN peX9b0QTAth6Lcofg3CUlCFBOxW2+yuELsbSTrMYSiZhRnZsTyUUltRYbJgz kClL3AmjuRjF0r6JQoialZ0/N8PAn5upF8zNMS2QiMSZyCnkT1babNWNRl1U m62m0dhhO934Ut7udE5Pdlu7ojN3fFJbx47d4ywpGxv1u0b9eM8Q9TuM1+nv GP8ZmCY+dXrW1eBkYPX6fyw+n7cHw5NLQ/QGVueXzln/4uSPD+2BdfFz+xf+ 0Dm2Ti8GPL/RhISVcKwoDkey8dWAYX4psxmJRMYeuNesiEoW3AThLMitfrNM zOTMteot/juuE3PmnzN33O+fn1y2L94zV+e9niF2dx6yo6QTTsVxGE5lbAfX 6xgpSOkAFqOkhL/PkdKCkfUMVHP1QCSd4ZMKajW1DFhB1b+poOojClowdP4M g2l+e36gobrx1djg/+AjdQGXmXoBQNAFliep8p6v5HfkAa09IPS+qLb2d4xd doDvZeB6Y0EORtsYwdiSLIpAR8NVydSARb5mWV7gpTkb9NnS6Fq5DT13s2R+ gf1hvYp+xZWj7HqTEDeKscBN5ePJ5YXVuzjti/J/QGILO/qxZH7vjYHzotO+ 7B5fDTAnltfYgowtBSaVH/SiYZTQ+xgHYASiTnOln8jlI/1i4thBJXI8Kx35 TIE3WzK/lkzs3BsHRXqisM/i/CSNMycVtIznYs/jUOgl/+t/NkviiwqArd0D Yw8RsLW7jb8MLRsbt5H51vXidG6ld+JI5B9/5MEwS2eVtnPTC9JY/CG68Cr4 WuQD9QzhhbbrxqIqTs62rc55d1PNYcli0fTOGme+L374QX1HQkEkzAUJ8eZI DD9bl72L99ag9+8TDDU2NwVpR/Ollzgi8VXvPRT8lAhuIAXwxtYMUdr6LZOZ rLjyVjPzlf79quP/7p7OAHYbRkMLwL62vQDIbosYYRcADemnFO1mXjrB0wEE nuiQzdE5zqJUZPTAA9YA1LFIao8QPwUCkZcI/M8ljxvNET+lc6Nes1VgaA/O ReW7TdBxpbiWARCL3CBLZELMpOEU2uXVgazMwqvq0asaRAJLrwqhArS2AjJn /bJFj5IKXP1a68UQ2iggHZj4rYfdvSbBkDmIDT24cFbvlnb4+jaCXCuPDG5i uvmWvkId9zyhukE2GfquNfMCN5xhGS+YVdbZCL0LGym+e6RRaPMLIURn4kXw 8CSCK0A4iJ3yV+lATowUMATlQWQTX8GIchhBM68C37uRedJzdyBmEvvHGkEI +ZPXhcjxWFZLKU8ot0WsdqEphUW01ADSdyYCaRKtpqYodg2O/jRBSLj8PJ0s J2KbP/cuuv2fK7vYKgf0+va+ATjjv40DZXX5BsRXEsdzwEtjV/WLlt4qdlWf gV0PNfY0dlUL2FVV2FV9GrtyVVS/FiCZjdSy5N1yW44v7SCL7sFy9bkT9PtF My7aeCDv+AtZmvt3CprImTqevZXnzGtLmwfvPKPIeTDnXrlTbx62tp8qd9Yv 8C87EKIh6o3Deh3/E42DPV34GM1GqyWqdaNO1mfCuE9g0zFS5pvPZ8isRVtw CrV4SomA6PV6W5/PhKSHoCoUB5zKMkts8VgM2PRz7KWpDEDyYNfEPwcEft0w sH1XHAMCZQwEw3uMj1RJzexYiqmNHFkS9rnsUUjT09gbZQSItuOEscvQqRyQ coYES4Rj/vr+4kp8ykY+7OUMWg8SikcB5iArYEQF09ILiI9YjvE5cGSBB70X L1lk5iyA8k9sb2Vmp7zIKMt5qsuycJCCJITI53I6onJMs6TfARd+BnA/tRFV lhKlKqbOhWqT/23xv3tYhmjR/OW7kPq2gzxVl2wH9ZbIifIGpLCzdALGtQQB RYg0EFqCbyTtd52TQbc3WC16DALSzlYfS3QkRTJi/OTOkb5P0gHjYhBRDOza qc2kewFVlDaHw4Hj0VukAgShDoWvg+16rWWI96Hrgjs9+dT3riepUBQwGEsZ jKSfivMuTHpvr1EyyWwW8PAnJeaZaG0197dgUSvm9DeKO5Md4KXFnfm3izsT YsMKqbbpt6LRajSFHI8R2cCpPyf7pzwiwWJkmIobRT0XVkipCtGMAYogx1wg 1AIsfmQe276PeJpoOufDK6JlC5+aAbFIvN/hJ6N5ZCeJzl4QGaFif+nmmJtF j1CdphmINVo5tXP7zptmUwqDAcJj5fIOcoN+0sTAgk5tk6hPIE5gLeRMZrpM olZo8Oo2RTw9as3CmHa23cxV9ilDfoH/J/DKGaltGgJEOABe02Yg7MS+ltBX pX6IbYlpcm0AEFFqeLTDWk3sbiqi36tejSgGUbXSIsP/qX85PPlsdU+Or96v cLky52jlvWWO//j7jUKKr6wK2xG3tp9B8QRagiyIbSqSMfsfOaekN5QnKutM J6YTwsCxYzathRweiBWmEoRss8iyjNxy1BdOl11LKW05nmTTiZcmueTbMMZZ ziN7jAaedAbz02kZvTj0powjvyLsEhaO5Jh0BAMiTMwtLgWmJlOKGIzAkyxn OlcLioJh7/ykfzUUolLZqddff/j35lYDAXFTc/RRyojXimlRMmt4rYjCmUK1 dBayBOFdHuPW/AGBRdWx0dhdDlwWB7aby4FPH4fW8dWpNfj3xkajtb2rStkB CBM9NuxUTin4xHMBNxhlcOy4pqAur+Isq/8JG8PaloWnCIIBsS9+CTMxJQSi hiLlJQoA6BOXAApcYqQw8ICIjCD5rjh/IFXK61PI8bkJmcck7u4J1d6D3cUx pLKenA6JTLBs9su1op1+n0e1NwpcVSJWm7x9OKRan2uHCArd9SMpKXLtUAqb iteOYDdBuHbEC9Y/DqlnsHYIAOGHziOL5YC1bhTZ79rngFKVkK5nndD2ifHk hgzo3pCdTLe8+Dc8VdZ3Cl1eXFq9y/8cMGhoG195f+SlyObXLaQkp72Ju6Zr 29kG4y2NTYE9gPOufYv8/AMqoeQV8sTzTq/NoA8gUkEuL4IZxwAGbIeqXWNC yqYykCS3TaqEFecFN7y6sNrDyt2mqORQUhX4urnOFl3p23O9mfN+9+rsxGpf DT/0Lyvl1ZzhjU6O1iUNb8vUe9HTuyeDzmUPrtq/qKjmYp69UVKm8zyVKm4t 247KgYrrfGpfnlcYmA1R9h6MaFfGWMMsAxz02GBIEFTZ31w3hzoflptFvrx7 0bxivrCWmYfBd+1rbCO/WXmL4Yk34t+eGla2b3nu4iW2xH5EDRGP1LbMwFTI yZIM1jMXVDlQNY/EMbjOY4+KPjA0pRWOCGSD6YxKQp6vETGMPURJLL9It1Hn aJ0ecjuHbDjOAsIdkVfIi8pfNywaBq0e4JPtz+x5goAYRcjAATzaB2ShIb3K DbJ0TsfoQ7pkGWUjCt4JHkK0npIBr0XtzqnNXCCQpnHoL9hKVsOazkWG/WH7 THXU6nfN+nJ80clefWWnnqciyAGoYLbFOWTCYdqRHBU47Zgvj6fAwW+ZR7ny 1PVCgULXno78IgCw9yOXXEawheS7n/a393fqtGjou1hdlTijkGocwht+HVV8 bPN63CtLdKi1KS0yl4yMffta6QKkIMkJt3NW81cqMaaeZ+VsWpp7V/UQTV3F 4j/oLUQAB52FJdJwrwZtUo3TKUIkjahqUnUelkWlKxPvOsD6K9UlVYTLIo/S uJUnJfPzmcFvvkq4AAfYNuqU9ozsRA5hFnakdC56qFl8yIncNFlKuFE/H6FA W5w6apNfpasqSWWiGpbBaBQjoiO96HUT8jCSO2OewX+a6k9L/dkzVHmq/rSU GMgkfK68e4M2vdZokSSWFHQ/NZHk12kuLUO9WnOMvHB2S+ZiQ/oYVUcKyNK+ tT2fiiQxjsMpW4dYB+eHW1E2ulcIKkJUB7JKc52aSSQdD3liXjUlNEzyJ8dT qmWZkPeNveuM7GY0V2FtDi+cUmkzCqnBCMhg+0Xx8Ws2hQVhLW4/QpUjye4Q qoDIxp5rQa1y3OsPRDIJM0Qs/TLVbgmZkgIm7spcDNuCHsGRaBg+RKqdeYkU WcC9FL0e8gJOBmu5gk5OPl32zxfbZOOcStezRTqPJBskHjnSNSnKmCrK8M5R Ksv4FmC7slBh7pJtX45ToZvdgB07Q+lftrM0TKSP/LUMJlHiJoBz8FAyG2zc TdJt+6pHIg6oHibrhSMjq3bsgFybuxy+B9VTZpKqbrDSIxTZVZ4XFn12uDj4 1gEbsiFxLaGDwgJcjVq4kOgUhhXn3SYgxa0XQv/cRQaS8BJaX1GMejIuoiFj O8FgeI2YBbmYva2+OO2d9hNDGz54sn28T8degvbuS5PgHAYFOiYhOkwDJmdq rGf4RQ0hKomkJvZdullb7osSkTUNKjpHgJOx/gprLTllZnIfLJl0/KZwQtdk urXNsE8w5sRelIYxwfKqhNrnXXHWvuicbH3qINc1Smb3pCOGme9FuneUwnMH Eaw/3NaCG3sxVR3U3c8bPrFM6fwFPOfZpw+27glyVWUcI0dS0mS6hkFRV7w6 fsVkkwymiqo2SJWLlUzSJMMhS68fcGSRAVPn5TyKuOAn9RK1lq1MQgXpMXTE +s1PcHIYhj4JE+yI4QgiHEkqxpbRmsylHxRDPO+ciy2epvLsmY2lFjW/rW1D LG1DaNuY2nyUBB2NoQbtRBKqJt4UHdJ7ySwmDAs6SgUx26rNAEKYZ2NzxTaD Bx04KldiathkoCJx4fCLWhOh7xMzy9YXHwoSm4tyWNuvQXnOTBJj+EANec8B KMDlEJbzloDe9MLmZXBNCctIpjNSdLFrQGomrSoTTSd0DkOivuKOVve8vVgl UXtFyqayEbZ9pdURij1EzjAuBBtkEjMYwP3oqQy5H7MKGGvZsDhC63zM1/3t 1ayPtA14edwXvVyB6kBpovLBkulkKPWD1J+bGtBhnlAU9bZEyDhHXCwckuho +1TtnIWo4EiqG7dsFIeoOmPdb89lqHoV4joOs0hFOgSd0PHsZdgGAioNcVOT N/szDdzfnA73xkpLQYNS+fKz1el/+uX48qT9sbzsi17avB02YkCXd8deSP1+ ii+pvMenXltNF1y20zFeSQUtShOBAlw+J2R5q5NzCOdeligypLVBTfSSmXdz 2aEXjd5D8j1y3gmCGdfCELQrTTpSpBlTwFHMDp1yikDiX/ZZH7CXIykrDXY5 14cr2JLQveNb8KtMQjPjhAl7Z/7dVm+qJq9uEcFuimTyKNmpicE8cCZxGHi/ 6yhJotBKQsXD8qI4hhpH8tlrkBp5rFKORimtH84SxQMbP6McWPQSfQoSuNrs BAwKmQZSIhXKZcDpRfJgSYrMKqMqmXzEnMKk5pzaa32F2kT40FVTWgKS6jDH OR0vp1BaktAJGyDH5bMnsn/tRvo4Ssnpp5q4CNmcSDp2AJCAbDuQcUyHIJGX /o45NHsI4nNxnsXRhAsGTvG5bRuHtx43O7EX6YfRFHIsmYV0umUsTnbquuzR mVVAylycQhU3Svkek8DydBiuXs3xl8CoPeh1DIWOfJxEeXgeZjnkAKdcUe7C SoMy5NouHrGp3WBeophICNIhQEqzRey55MEq/pG/+cKeQmm0MSrTbxboRxca FR7lF3RGkPLycKHSqLU+bqrap9vticoOf9f2wn3c7/KiSud0XEeqxZLlQjmw jaRjk/nk/U7lWRoV2MZ9j4IGxnc+1vKzJ24WkHQ5djOlZCFHvriU266qtgDj U3geOBmFqC7jyFfXQYgQFyGavC41lHpnHhyZriP4jL3KLJQpckttnNH5jq5x NGsyyKZ8c4dsP7FG4JyuwxTuZR01jOU1rfOT86Nm8Ttf1TraMfScdrd7WT+i C19v3tTVe/SooR81lo+a+lFz+WhbP9rGal9/pGr6wR0j4k2dDqljPLIcuvSU NXY3bgEEYcwdnkKzZ/HRQsS4MdjH6ZyBb4+48a3aON0tssgaaGTNEX/ltbpd tlm8+IRB8TrCv4/dfDFUjU81o1i5KEO0uV9FH8h8wd+d+jYOXMsJUmpQfeVO AWvoC12GU90W0kfxkiDpY3lTTqkC9Oii3KefL63O8PKM5WoIfa3xiHo06htd qTuifoz6qi7W4cE+HigNcD9jze5W7tytF4ra/DppssiKAtGvrogFL7ECWURA LBLR5gOe1l5AE0dsKHxt9KCeJ8PUrIjoPuJG8YbkQb1whfUZt0SVEgCrzUdv qh60liRVK+WOqBaJtv4PiO48INr45kRN2NfqDdSDVvOfpUohSccrdcVznTLp pu1Lrvyuv2mrdkkxc5lkq/7BcFW2yyu+L71r/BLCZL7UEByFKxed8drLFPts 4vlV3qdIt15EWqOU8dRNbyx6bJ6eFaizZZ2e3b9V3f4GpFsrEl96b5HwC533 mffKn+Jg5z4Hf1Hhz+TguCD7R0Twl9S+uMb9Z0ooMkD96K3ji859Dva/LQfm 6ef7Ujh9IIVvYoEdMQyRfbvhKrXmCyHmWdT2F06+Smx/Qex5QPocYoP+hz4k aQ4/iw9ZHFMvaJXq3u7O7j++xVarJc7sKA2jR6i2/qIxP011r+jGy59CbKz5 fcq38GL985CnfxzSeCEDT/4Yw3zq1zt/5dcq35yhl/266Zuz88Ifz3xTfv7/ /NrK/Hu/tvpHsqFn/JhI12r3LhTwKTifrCeLU3o6E9IXCrj7h+JctYXU3Sh1 4y7DLHUrNJ1kST6Bl5B3+niTzw3KtUk5v2zFw6d84kGtAXVxIFm04WkRyVdl 790xyE+MdFt9yg0dLMWnGyi29IHA/7b3pd1tJEeCn6E3PyIlmxIgAhQAUhIF irIpHt3c5jUk2GqvV4sBgaJYFgigUYBIuSX/9o0zjzpAUN1te96O30yLqMrM isyMjIw7yMLg2UPh+6h254n5TgEuIgHG74D0WjEU1XNG9rh37M+wbOzbnLie YDB8Ahtaj8KnZ+2t9vmZvLDuGEjnL0n9iit4I27i05EdiHRxOs+qKJhuoglN o9HgftiIrHLqEQIwXprueDyA+8O6HaDejtXg0M+578qnu+hQN2SNmWqRquZi xrujeiv2N+gO1WmVlFSDaPgBdd2sky3/Y+05MOOj3jSaJqzKQj8Q74O90WzI 2LHarKEK58nOzWiC7lITT9XNA6j7CqkVNNrhuk8Cc3s07Q5Oo4Q9M1+/bgCb GezapmnI02l3Mt0edTGAq0mPoPvp7Q47FKMXLbc7vd0dypM1faIfeK79zscw HMVXveA25+PzYSKPyvSsskwtMRzsLPUCaCI+zvZYtTCh+gBerPPobQfTK33i AG/U9ZnC2WgooHvdjxEFpsFDnrXRUDV4sqoLNsUnu8MLfLimfeHxGR0mefHc tj693YvRUItPX3hP21eTKLkaDRD0xktvnHb4at32ad/SvuDDV7Y9Ptk53Dof k9e2t33wEBcOV4yf4yJz+JldoGbDG2eauGVqNnWk0VjxwC0AT+htjKA0eaaW QOIp9WctRxEDMKLxlLWilyP0Kif7w6CbJOgoZZWVtuMvtL0IFznyG0Kuw9lg Cmc0oS/jg7cTIC7yYA0fnKCCGZDBWIje4nkVv0GOkBukCd+K+75GInEDBAK2 +6CLoVsYVFYnafz7UTLdJd9XedZEjNJIRn1Iurr27ZalqfJ8HeFMNUYFHpym 7mTwWZ406X6Dj59GP8sjVOTRRu1JvCI8W6dmtNnDiE/wejUIrOSHr/DchY8a 2nV/eIIGcrQAKwng2xCtn84mSYaQKWqh0ZxCvsil7et+pndTeitNznaze3Ma 3lWmgfF0Cfn7u0uOb1LYQQktsG4ZTKdDmzgZ86QfmmsDdzpy26PxibepwX8u vb1nMthgYvlTB/0taJVxc9C4l3pwSyiQ8JO1qsXXmTyCfSAP9gkqaLcQQ/y3 bxk79iYR40Bju2poRa67MblhX+Kbi89TigGCzuoDbhkSD+Y6wfxuWN+NgLW5 hl0hWlelfRDqXm+po42eyRD9XXcK2EEiWNAf9hrOYfr4IK5OeIYw4foud/6x O4j7YtpwTEt6CvUOD92hyxXnIr9P0UCHy4M6a3n27nS/vUsP19xD4PHO+OE2 obU+frd79JYer8pqCPEDFEKj3jPkIdTzoFE310nUk+nYEXb2z+Sw8QhKJnls iUmQvuSzBfyQmyJ+kpdNbUiJh3IRLXiHsZJtM1efky3gl+qNTTSxyK/mKhlq 5NfaczQLHI760WB/Z5NuQuuQtwpPgFXe3/up92myf7wJWLh/+p/wJtp8hQ2P oJeMj2isP/EDDfcTvgDbj+SBTFDtGXRvrFbNNkYgJ7PrzcZzz37BGNI0v5R8 hGlavGp26LY9ZgdlHjmFwaupzqstc7i1/Yx95IjnsqMBVaGnuD74C9p1tqeT weYL/q2fWZevALuN8dfwRkb7RexDsWcOutG3ncs4GvQZCUuzoTheUuBL95qM SC1YB/z7Ju5Pr1oN/pGgZ1ILdgW3k1phoBEbPcbd/nprfSN/QGA6p9gPGjXW 8Y9b2LcW3GXOya3V8IdqrrVe4u+vZhZakXjl1nAh3TqutQwiwjN2rgvWcY0I 2k7c/cCXJz45iqby4AU/QJSDG3dw+OF6iriEzw5pLCIw4T7KK3eK+efZf+66 u88/hPiCY0iIx9VzuHW+L0By/0a9fSIDwOH2+g/QAfUi6rKb2d+6Fxfi8yBq /GCUg+FHd2f6UFCwnhuK+9fbP6Fqcu+n9BhvsQ2Ns15Pzx8W/CXhsb8DL1sG BezDwOXabsLLDr/AQ8cBU+7ZQTTUjdBH9gaxZwg5HCs83+3bTaDyWHhmmOR8 nHo3E1oPkX84gG4nU2ZxmoAee5PuB4XyFnUL+IBBhN89d5357Cu8uUTOI/wE 0GJ45n9gVQ+rZSJPOcMQ3HvObZAkchG2t+F84LneGoyvuiBfYSgGe9yDDI5O pCznrTYJ6R+KPEduzsgurNPVypLwAI4k+R7QmnUp8QAwFbcd9Cf763t2btJf oYv8wdZZu7N3uvWdoTuK/8fbf4BcKS7YM1ykcTdGXy1vMupTTuTnArawM8Gw vqRHezIDwNFJc0OxiYYDICefDXkPkSNJfUWk81IC7Zlp3ZDeKHTb3iAfQPMX q/T02UAASmCoJIkv1MGdRmHx1PZEJ343yyl588ToIsXhYThMcNn9yGF96kkC 2yi8NMHuIaHM1me1QZxTFnWTyAWeMeKMd4jXImM2K34IsojWjVAfFq9cYX+n 3nSGAahEV4gSMXdysn2FNxcMtAlcavM5MGTbqWdw1M53Us9eVr3OxM3Q41de d/uU8Hon87Rhcdvf7elvs9vag2ZabzV0A6useALeG5cpAoFrRTpb5Ag33Dt/ qT1sF+7hNLuH26fbwiCRJwJuXzvY1nXZQTgauqy42U0+O1U8MnZl8cWa98Iu 7ibT37qM1b5F5vN8PBihd9amO4pM6NF1/eYqQmdt8qJmRc119/MFq+oSmFdK 0Uc5Q2wE9w165qJq6QIjhmEUSkCjzrAxhrWRKxm5N02tS7u3UjjedncMawSU awwXAtNg8daARyc3E7pjedFMgC+pxCm/MP6HVHJCPvjOcf7nWbdfQz1Rjeib RjaV8giOEjc/XPX9Rqqx4qvSxXa6sYCEqBWhVO/7gdd8D9FaPKyNB+iyKo6V IWjJxw4+fYpgcYNCwGzTqW2aAasopQfHnGILyhDyFFe3o+ci4NMw09Dktmo4 49BGSWeKw7CYRo7HfFz5iPndOT8RDmCTIekIth+q4jmoA8crV9Lb5aDnzDyc QCa7EuYprwQDecJ+cOxJDrgcUQILn0kAFkDIAm+geCFTXAprXhJKwxC71A0h YIFTEMLDnlu9i87lsINM2AaTJ7UzYF5BHpdJBqmG6RsyrucztaFQcTgQCsYY 3oUHUYODYM3ICx5Hi6rqVcfMLjPPDmK7KeybNHTxid46UnhwB/kM/pO26jAc j9948Erk5YZetkk0qWFYDLGX13ECIqW6H449CTBEEwK6gw7Z6B+JEkBJNhEO Ux/OjBcgI/1LEhHToTfQRQA4zaFFz5zgpL294E8UY8ibtnPZx7994YP8twBp Oow0rYZ+RsMQuuIQ3x+xA/EHYqbIjTv4lBsDzgB9MfV0cosCUMDRSv+rG8oi kLiPf99NnPttT8RSXdiSJPUS4EfjaCh/Apkeszw1a7wQJOxEJAjoQ9iMSeqR tYvwSutG7+ESeyKnbiv0CC8HPD4N/qe5IXqRCQYEVXmb/OuCPygRJHBw7Q1/ 9K6rqG0DTGilQ1yiAzgGse2vzfcKKMZfCvGz5Nn7Wh9T2kyiPp2DcTzEaIbO FBUWHzdSbHlXTsAIIzoijcK7zjsg8N/ex7Qt5SYiQChjqSIoWQApkiBIcqax XKJhQakQBrM3KsrJHWb08UL8afvH047IfagZoN/QR/6SN8eAp8GTpv0lrjBV N5a4hUgL9K18IX+TZ+W6/Ni9neK7V/Jzh8/kppWO006NfNCZOPxiKab1dc3S BGTtWo0XzMuQOhuWH/VFQBOcPJ7SxpXQIba1rselrSEvHIFbGwMS0CmNZRhL HLg33m2t9Q2vtxeeR6EKn+n+86jgTTeeCrWnxB2ybzdyPBVJ6MgJt6Vr4dw6 DcjPj6wXHqCOUwFUkedLb165sSbZPNCaC73NIwpbRXSB/lYBURXJ1t8i7J3u PBuyZNdH+zc7k67XQxyqonqg7n+PYCFo6+p/6iFgqZT9jKLbTxbGg+FHhLGe QkhEv9w58tts/zWHrvTlTFf24SwpqGuN9OxWoYeZtyD1TJdwQbbg8hhGH0ZT PObSrehDPlg1OEkUmQDwze3koJOd1A7QY2+vEDg+jOkcmDnJdfwcmBnP5rm5 Mb1sPH76ORl3Ni4Y1fN89tv3RzdFcHg9PMDxolvwExho30k+D3vljO860pvU +NQaRZxsa7hqrCe3qrhzP4aq9mix/vyLoqoKloZumHLI0nUnH/KXJUGDaOcW 5JByml0GXrkws2U4llM1/CbDCWiT28U2OFB03AuJLJdbtg74LPCoC74i9BQ2 GETIp/jffGB7A2AKF/z6vfOIzglIEJlHwxI+wAsedzFQ4KpEURcEvgWA96Yb j3rTwV10IAaB7WdYNA33uO4XYSwj7Wg2XRDsbm8cUxba3ACM3NY403fHB3M+ 8B8uWskPp3wigskTvNsxzFAiEPXKZ15dY/gxqIYzsmmmLmaAWY1vJEQKRYJa DQP08bdGYWKoKqtmbS6HUKV6uPVT5/xov31m1oNNEQj/at8Tx4DpKOf9/9dw Zz2RJzXQ/HFEublFGmjKGzIYmJidUmBmIglJdgcSpTiaXKM1Za0lz5WfTSRn qyaj0bRj87x9AuiOzg8O9PLCu4sz4OTcZSJZSN4/zuhR605gWzgpJCUc+ZnE fMwPsdqk8LRBdJ1J8xZk5mHLhEvFE/y2MVikyccojY0w11eY4trPuCSZR3l1 OppZKvf4oODmJ9zOWTfE8XEV/iVVKrTxc9hSRj3zyB+t8n+GlCqohNuFSZ7R ieZxavU36OiMN4y8p8wJbB2cm/OYelU0vbFw1Dg+qg5TCiib4xrvb/Pli3mI PxDGCgfuD2eRmA9tjl1OCCafCQZxupcK0NzZ8BoXLnxO7T+SqskbgB9gU6sL 4xdPZe68sEZmQsuChkhOLq6bhtfKEEgtCJBKsLvTabd3hSvcoRt+NMGX8Kfs JcugfBvZOD+1Y8Qj+msdr64CfZ6onvxwO69lWkVFGj8PC6grrB3AU3uDyrGH m+bgeLsDh6RiJEGxHMDSmM8jhVTGw34nGYym2nMFc7ddoEzv/Yb2l0P7iYdE udODxiMZEmQySk3DHIYpc/RhnbvTqRtTPLOshF0q+4Kf4DteTvuCVyp9Jjiv c7hJuABL/apT1C3ZMEuztLaydounhlQpIO7w4KjpeQMi+QV6UtrvXQ6rsql2 +jhRoBGI4TQd+FuOkg/V7umpedRWvYAqDnc1VNdLPtLlPE2PcAQE5xFnt6F8 BGYpWQFIjRuS8hxRFK1kgEFdBh7Z/opOCQdRIP9kHmGyENGXPDIt+H36n0ww Sqkd/KpERNGPMkFZuUCfvl9x2G0xdXm5Yk+v29DNeZ0JVMyDL7v8OKdxGBlb gRGp15yGBEaJ8hPohs2BQXfPsHqXUz/20Rf4oSggsph2zgZ3uJeuyaOOE5ig RoEwS/4bD70dDZGzQjtlwlhgxbC8TeHjGoaz8qnCVuibXGWW2IXpWrZguWER l07tL6xxddQN/4XRP3KyxzJ6fYwuy65FpWq+2zvp4ALsHjCIQJJ6489lfE+H pINqH5oFnCD4k1vx6+vu38jDUH7FQ/Y39FoIIdYJl4AtgJXeRif4zvbx+VHb XxbsossSrtTXgiu3H1my7U+5+AKmhV3g9pWBlxKiJSZcjeBGhtll7mP9T3gZ y1qU7y42UMm/f3FrrsdluxUZuATj7QH56pADi1K48e/mDrzCB6nbvxLI/sK0 c6EKvK0k46/e1bQddut3dlNb/7V4b6Ucwu+wuTry/7+7u0i9i4W2fc7+oQ/m dfQ7bJ8M/D+79y27Nxvn7B2NZkUc8V1OnMoukYQGj7QAwyMbp8TXXjV1aKsh ElRDem31nHOrHEEDUgdlKoL8G1YzAlGzoKCR9sKpTDE5H9/xRfoPPRxWyO0D e2RrBYCYr/f98rL/5jXi1mIrkAc+nTxvAl+DvUFelMV5TVr8e+qnZXsl6UbS uSTNgKYtLdmM/8A/Y8IfTiTHm6d2pVKuXJUWioh1JGFImiGPKZIQ5gJRtYJI ECCUdoTT/mv9PTC0/1jVllm5Bysw1ehfFip4KCdMhBv1buv0aP/oO+T/pS4J LBlVA5DUey4BIK1GVbhP5j+vRjcRZWHlPIEsOUBTX9LwxATkT73ekou9+9lo 2k7KKV/rfe4NOAbtGk6sxpFR7ILfXfZV9DgPVV0B/wu0AnY5cPtEpuF4P0oK KtsG+3ARjxLS4quvM/oHFeyUZm0hWDCycvv48HDraKdqHmM7iSEQeIbRjT4R RNBfX/y+Epj5xX+0f7xht9Lv+BBvEDtq7s7yEeSMXqrRsrvEBvy+JA6ldfSX tjsFwfbZEizPudbeYt8X/jpJIrU39I+TDlnmzV8uf9bVAHTZMl1/MoPccwPg u8EWZIdXFMgVeAogJnJhTTEgBbkvOnHIoxOcVlv2yolEhHffReyEzaZerh4w xUoJUufBJa/krD0cfvxAMyj5Hdh5gCoKuLy1fFa4PAhn28McdXhl2TH6GLaC SetmrIzmNN09rNPE3n+U9pEGj27HlG26P5tQVkoZoesyRtZq8AtLbMTZlJsu OT72m63Tugr0G/Yh7pFOaZPWC3HwsQQvM8dC2lLzJ9NcWzctrk2CvUOE8Q8s Oi0vhC+ILgdb7d2j7b9Q8YtTObcCkaXDcuoU0Nc+2HZ/cy++ljlmXyU9O9JL TxkTQF7v8vbeQbti68iMLkmrNNQqIBiptdT3zxntp+P2PBCrAYQbCmDe4Vp0 seR0pZYr5zNf+R8+Y3Ulxe6ALC/bw8j/+aq36tHoRo4GGg7wgrQJQSmx3oW6 RNCO4CME2nKrxAB4RjSJQqszDMSQmw1991ri5O2DZW2tGyoJuFjt48gvAdjh 9LBlpQuZJPCVSt4VRC6zevQB4CHVcKK57e+4mHRy0B4CccYk7H3zhNKT27NE 17lf5a9+u70OUD/ECbzoP6/P/zQnvNXU4+puZHOIIuH5pVl9+ZVyz0+iT/a7 vgUDALgIAWhWXr9er8CPzJvVilu8shsEz/jeXl0BxzOeC3hIpTGvQZomp9cC wHjzhmM/FHPXMiQ6jaFZBLWomTInkVc9pi/vDjhL/v0tSIxIvu1IkK5wsqkS EF69B3vnZos8BHPiSXtz/urbn5Ql9xneP5k60Nva7tHxzu6PGZb8oRWYgtJi /5I8eWH6QJspLxDzs2KsWkPYZkr2E9+tjKMO/4rRFO+r1nmSVo8DozROdDil QlzWxStmDoCXmmRHrTxTdqaKB3lGBrwviPleosyf9dulAVYcUUNCitaHOmd+ LthkIfCkBgRmpK7bKingQ5YX6AnXGoP/WknnEB0Ye9EEM4YLmxgGGnE2icB7 XlAZ3Seuo+us8hfWHilF43lW9UvKBS5OaZ5WymVyiqjgKNi+gjIP/ENN4SFc lWU0ZtarxhvaKQOthQ4nFV17+m5+h0zgWIxdocExR22DhyRjc3bGMuiPrqDw 7Oxk/6hzcLz9Q+f8CP/Z3dmQBrJb0Ma3wBGkIh3a8cSfkPJyoMg1CbNyZLyc hduELYyu2TJG1JRxW5Wp9h1+FpUChgiRnBe4E61aP+ysXgXa8r32D1qRZkBA kYdvnLyJswy9t0nZJQ0fm5fE7DUrBugOEB6gPMa+azy3W+r5JmB/24QiQirQ twE967a585sOWjdeBE2/GlqMYjhfFny/4ENKX0tFy2tQ3xb4WdilNW9Ej5L9 WsOhmrqhEwYH7RSjZM/s7lm0Ir93YUC4th1L5flxOV5x3bpTbMZsuouJjVrD v+CC4fUjLRMFBeSouri2NezVah1ZBS/tjR+WX/E0XdzDD3S/qx9faRIVgGmK ieOZmkGE4WKNF02DbKSGbVFEkjpqU7yN9cbHiTJnjlG8G8Klv6GZ09+1mvKK M6qHVYbBfWYn4EwCQAlh1+sq4QjjYxWzzBvLBRS/N6myzkEOAtWj5mxMY503 Bgez99f/3TR2YOzqXWxl18j7G3ip9UpFZDLV/dm3DzlauCIB1d9NJpMq6XGo VgJWh9UKE1I8ii44XWMuA11mcJsNXoc8UJeXCdhvgPZrEcQPnK7ykXn69On+ 0Y9bB8CGb3+/u/3D2fkhqzfgBVzA9vqXmzW91qtuoctldNQQRTiq3ulC5l28 msKJLOuc8Eqrv889VC/ceAriUm+pudK8BVhiIF1PWk+AeD0xT8Qsqh+C79CA 7tQ27/oAHLCLcnoQ74TFPGc5y51OMu5OelhL0YJGyROAZyFbSAe50k48HXXL ymRU/AOd6tSnTrblhlx90QArbGCZHwompBIynyhLBvTyrryg0KcY+5mxeS0+ FPYBHFwp3FfJ6Kmd+hP3+x3XeGwJhFSlYChJxVXNiA19hwh/Bh5b7fsHeBzA +xWbdhtQ1eWkE3qCHj2XQ7iqOxqf7Nkn0sFhHHsmNMt2muss03S+UK4HH77Q B4p4RgwqG3sNKesjj5DPwqbD2GxqmaX1lXVUGI4zK8fcq/+NHGcsqyjYxeIo WDJlNvGD7tI3GCm7BFlwOAowMpaoNFbfb3hvmt6b5/aNH6LkNXjx3vE6bmhL 1efe378wIcN4FpvcgiM7Hj1vrcJpeLTaauA/Df5ntfX80Vda7kySDv6H3rkT v+oY4FRIVvYisVFZDiPKeR2ZnsptxSE2k9HHaIj1FJDcPbPIk/0kcQg0Z46d iQmMQQgGx9V4Pnr+wQZpnrEzxyJrqFgMlWqQRbF6FFSYIQ23xgpUtnnxPfD6 D6y4NgpatXiBijDeAIn4Aahf7QZ5xdOtQ5TeTm9bGBCOW1uF30uJ88gK/KjW zevX+vHZiiZPsa+DN5RKBT2uUB9Orlaou3NjOWQKB8RH77NDuuhFHNP9ekZD P8p2wFgy2AovnAs7vlbC7C3sGxhCu7vgpWAgFlgdpgZBmigg+Y0dPjuYN/Nm 4qiEHswUKw+X/8scbzrdSQ4Ss6252owtyMhOWH2Ddv9gF7Mfqnrzzr71J88X x2WHbM6bOUM5AaWgebB0jiyFLTdtwJO7FFPvMF7PY+LHV5+rEnfiRB1HZdZE Cs8r8SgatLnvbKyM6rQwfQo7kzG3giVekGYiDHibw50IF7wC9FolfpKerz4D AcN3VgyhKSAAfEvSTHAaOBgSs8YlM+quCeoIMkBhLwsWLavXgYQ47zdxlpia 1toEFLi/CtjAxjIMt2rvykPCVB1Q1sZh/h4R1Jb61cB+Kp9fEiucAO0A8+0Y PvyPJWFeIITM3TWntM9vVqtZAm4xxzM557BcMF/gpOQHMl9Ho/QCJLwCnmXX Lmsdl7O5xjKTJ8QzsXDhwbl7641SNWveFqdubt+Ch6GxLrCYK33ueNqYxJm8 0iA83jT/wNDFLbWJePFe+SDxb2+MSmoTQlIXsCqPvXQZtLNB6Iv438ztbNNv eAqcbIS69bVLYzJsLKWOkvp8QYXFa03tu2RrhSUBQS07puwxnD68ZyJM+0hX 083VaBDVKDPsI+NukGycPAqJmYFQ6dMMuMl3EQflIxJHyVRtOxUk/5aXeAZ8 X0+KmSfEdMpOp3pZwpFR0Ep1nZQf6wOr6qO6ma4wqia8sGpX0oezMns2US0F jUUBERg04eIbrUYXo/+9WDyvmXtoGyeYOti1oEg2+9IGlHkt7DPbqj/iiDCv Ef1234Au15qhlHNIQFMv+sy2dLFgzljvntlmN+gl3R994BfQtP0TWSePz9sb vmmDVasZV0EMyO7AhdNx5RQLvYY0ds05CCEv2xQTI2mq4LXssFO8u6TO2Ex0 HrVabFV9FPVA6qLcnpzmGZUaQSbRSo4veuxIuX8gj47b+9u7LJ2p90b9dqm+ doveXVzaW5IPPSyQzSRmL71+D2p3hu3yaoWG2XCeCP2v9zacIx3ZRIZ83M5s AqD4sozS99b2yX6FT5QLKFS9vDumbzlYnxKaA8/7d6Rtwo5OJe3DJ9XNI6HI qFBZNFtMDlqIiV1MVHKi+XwGN8PbpnAgh8+1zX4Hftfo/B2D7017IbUK8bQP xNrrf9dyvASUxzlgxpIYqzJTFnmX690P8yTSiZtPmT1sVgzfVJ75lm3Fd7hQ gYemQNx2y+kP9n6F4lSEVUt9pqiLujMzy3BfSQLtlxxHTkF59GdFtSOc40cd hTbN6flRZ6tdLoIEaW2qb5/T6IZB6hWxt7lmVunlrhXJPIQbxpp5qUgpx7jf zwX7QY7eUM9MjnYBz8w+H3c/t8dSyK54R6RwE9x9n1UM+RYdj0CIyL0ZiGtK 6c3D+xwB1fQOyp6mYy7d+bXiI8oHwBM1qvrX83wBUi1Sbw/PTk0Ze1Q4Khqz Vg2A6zOYJNNPiMKyB7a8m61vOCkVQbi7w3OngnKdVK4zOHkTPq+rvq/kchCN /FxCIMsOR5w6dQxkY4h1XyPrYV5ydlj3QRLMGuobg0Na6lEDcUMlDIQm1am+ rU5zLNhR1zZ04mx+eNFj/aHvd3yVXVZL+Q0XC0z4D0t9J4uS3i2YtVd/m197 Wjnr9baUSPz8ijMMuMtHt8ndOhksq6YNoig84E+SHa66g0uRItO3spUHMJmn LR4sY1zEepmTuaScp/TF7ch+Gw3TaGeG1/hVtdJPZ7iiz8mxERWk1CR1JjVn 8zy6ldVleZTLT3hSsXpSPuqsjHdkzGf1hER4y5LHJRNLLDUimLMtanTqGimf HNSC+MKJw7NFUO6ceIacLLQSaA4CXPVzLZmUF3NI1dW6k1EPS16pSj4GpS3s yHbjBY5CnaTfb0rhdswFhdBZJ5rf2oLHA3DfRhM7bza19025nmmeFyjPxqlO coXUa5i1JoQpzC193x+iBgPu9oPdHaxi350gDWACVMzJWU9B9g9sPn/J9Gdo vmg5iMwH7OCjS6JIFEhA6bvc1+76HFFPLHyFB5q+uGiP5v160JSCOa2psyrt yTAgBzlr+3X+ZS0ptyqySFwXhdy7r+IhBol7rP8KakEkLypcjoPBZxKMzfP6 dbKyIunO+OBq2Zv845oF52GWP8icWho57S+hZwudvsouw9kXm66sIjS1VMwt 29RwwVrqyOGhBWYeT+LIHl2tkcGlpZkZIc9kenfxmZxH4NJyNwMtj60RU7BC bvYvck92o+6OduBNKwfTX6VGPedZU83oR9FNK1X64ybioAHK8c1Twrdvu/2z sx1OTWOjmNLbFADjvrKyQoXd+TMuKSV8KZJQdngeocmWCWIyjXuJn2VfnIK4 dkuwTZJp30ngbpOsZg5jH16SP4+UPpklUWYCL1MSdVZZiFH6BWnile2kwzwT zSLJS5K01ppHiBaJciCS1N5cr8aC2yWV5+j6Ohr2LbG3d6Jf8mjZlBvPV1+8 edPMqw+m52ZQlkI4ronNI+81+gSgdqYjnDNLRJrOuP7eH90mnLduRUUrNr21 eQ1yU+s7cbhID5mXK2zDX+dpuM5Tt85045380O68Pd/rnP3vN2/WvTmkEuxX NqhkDHxMfd8p4a9Ch54V9hic3lZtmujAD8w7nn6aZXdQS/6axu9XrE3Jiz7w BmkXD+KyNJPPUN3baG+SXvEBu1XCeYhGnRIpRS0zpgBYOIifpb6Uuaj10LcD Ty0y1Jxe2IvX8VOBaaSuI25cECIPI3Gd26hqFecUPulabU0cLVyqNZ0cXEVA sBkHfp5Fs8h49gn6rpZQK/rorqMzOnmftLQX7C6mCXfibaSn7OaFpBWliKto 6LmWBDly0Qc4ZG9tLawvXKvqi61Q9cWVxKK7rOCsgZQQlKtqGa9mllyDBYQN unpFrVpeWS2/n+e/+iejlbJaklaHd84m/OX5aYW3L8YW//riQwW/vApe9CVX l8tbEurl2hleIWz+xcwHDRp7M/sSrJDF2czuFNBSCgvlyCMMH6dk4J/QsZ9v f7xlRL8rtR0AcuTlfUTTSnhzl4TvA50n+/bnQmTB95Z+DtOVYtZLNiftyfbh 9v4WzGoEK0Me5HE/HuHtq16YaIPEe4QLSaRcwJbZNuor/mMstbhANs07AjAW 1uy7qIqMR7HOnPKA4WTE2uPCVqxHMCcd59KTo5uajb9K4G6KyLHQxIg8mC7a T+KOn1ArH8iAZScMWguXkrSqOdvqnH0PQ1VT4mNFWF8L3tZ3W/tHIRf/zYxJ joDcLHSYQnHY7MUDssyKdfGU77yUzqWSe3Vl7z/RnOek+XTmeu9qlEQXvfEM GZJBtNos5k7i5cb7SiV3GO+GdZe4WrE8hU2mo5QWDSFwzAQcTVvKRb4MM2Et bIfiWPB+9jqE4Pl3t10BSs+Bg3AeosDfmw8qMOAYTIk1eARqaE8CvUSZcLPD LobkJ1KtQKvnUkw8H7wVrzt6f0aTT1GZEq4Cv84XWvxhaPZP8JJuvKACP+YC /Su6ZG7OXzKx2hVtGYE6BSInW/VVGKt3k+6Yb2UnJYVD1xr3w4f6+8oinOk3 sJ0PbMI7Lz+JTTcoatG83FEPggwdRalo8lLxou1jbi4aj0D6byrY8bexmd5l lUXKS2FRmKYeWryoP/3+f+uL0Udl4VwadnW38l2vgAnvsCT9bQaY3MoSlDjf XKFjMSxo9deZZPossAfkne9gC3pa26XXL8WaroZyPYvL/oJkdWW+DiJhqTbQ mzBVJUbdz9TdwlLJ7plYBfKe7t229G4IIHnscqFjmTal3rSZDUeu8pX/87do KaHMErZMHOxKOjHEgvtSDdBJqIpnFF7UOziALU4k8UUhhL8OQOuJ4fbicH+/ 5W0N6sBoVwK/wUWtWMZ4m2QMa9qCFTCmaA1SPoW4DvmKbxjEX4KUEyF/NeND WF9TNDLGM/4tbm+TgR8GplDnYEljZd0r+WMuGlCbPlbzmahjsWXauhYYyjbs eFn3P/xuyhGwZDKGHm2zYVvk28nO0nYug2eV1Ge4RzYvRMk8QnNakQENk0Ok 9y3cuTutYF63YEd0nSpuKncaxbhZJgSBnrLB7E7DmBy/ueYxr12hoYzff9U/ ci8v28L+Y48uEgBygmipNfeYysd7Lp7iaECcV/tWi9kmc5hxPp3FhzNLoETG pCz/IYX6FfTJUQ9ln8xDIClq1yl0nyJuaiTIf2+nEyOuLuYbfV2sOTrXyCG1 LURI+m4Exwnza4x0G3VXTMppIdffxVKA+18vjju5hOnBCa8Cd44HXb7hh6As Jewd9i33TnAV/vKrbusQZOShQCzGmjUItu9gnoX33gCX/HM4zz3IyQ9sE0qx Lr+fIehBjkvAwhFLdznsLO56w9OeZ88DimhtcEAWz6ajMZnjeAFy1UNfA+7U 8bT0khVLGdY3n08ntcIdhCzNqF/Gwzi5yvDo93eaKvA2s6hF0yly/LLiotbx csbvve7HCPV2Bco1lu7myXZ3Fq34rRRhd4hrD8KkIpTQG/dFNdu0IZR+ukrF IIUBxLjifG4wPOaB/a99KzYmbZiRjsRtWbWrZ4P4w9WUU+ZcDEbdqWjSZwni yCSO4FL97KncyvmfY3+bdWHe4I+04Ghn3Xb6fMqlRKZNmD4WnhsNBnFCoam1 msujbZMe9khbKzl7/pSjFcskYQr9tFX9W5S4nd0K1Q4yHiXovKAOWv1ogDw6 PAlgQ/3kBaYYYc6jO6TStaL2yYNR1UpxP+oaaBqtrNA30ARMW9HFmq2DgfAz WJYwuhGlt1XWpBScnvKz79Lua5okuOKlDlYZ/tsdaHLQynxtjXMajIt8eIzZ Q5fGDT+UhBPwA/xL/Q2uGopOPW7FejM45sNpkDTNeJx7AAQzzFIRsRpYHUUj TgbJQicjY9GNq5+Qd5X5BAu5NA4z5/v3iG/Fsy0eCySk8ArMn0uB3fB9vn42 a1rMib6yUC/1W+bPS2MjBY4FbiUG+IMwK3aMSgBe7PnioeYOlXa98awcthGV a2WhtsKxOk2il6hqIT+0B84kl6zAwFTkOuEItruxMHvn1eeyf/TZqZawEeMx 16OGyyqfxfPCnJ2puxaaut9gEhyUfwsRxovayzfxL4RDCl6hZdnCKYeD0iwU w/16M/gAvG6o7aPkj2IzrxWbf4URTH2/EvQajTOd7uccYLkAnPc5FysqYASc 73yAX/3JCLMbMILxXbefJDNCBjEtL2aLfqCBT0hJJGPDpvlbfHkZR4kb/Ff5 wHzlMqVYI9R8z3R/hklarkdD4yzznDQCLYRUBAv+D9m6cXeCPMkEJoLZeLFC BbB21/HfIxqOk+n24L/x9bjbm2oh0rxoITqTc+OshAz8kzgnzvY4QlYOjSbq myAUw4ofbc92/ktJndfRW+4RbCzO6RHtgnNVDyvOOqZrs4Cb0ov7xPPagG41 YTDJT48cuICtjcivqMYM/DxbIJ0YdBZ333/I3BMe5gy5K6B3AVNlaAerXtl7 i4zETxYKtxYER1wcVBSZvVbhS9oesMv4chRQ8Zxeq+vpXt0LnFc/7Ei0oR7Q g7O50KwKhQ1xg1WwSA1US3SY2g52tMx4lJQWogJf03gnXgOMdIR1t4YCYjk3 DdoBUxzb5DYgiL5vggy26Let04ZF+d3rMfBaaQ8fm4IVjxL6aOzE/TamF1VK n4OZa3OvVpt0mvc0j8UNCiiqgtlOHCtgb23/0DLikOn7H3YTzioUkjzPK4wo n58ZGfjmq+4n3tmbCdITpxR86J2+YO6bfI2zoqZYYPAXObMkNjtRZlFkLqq/ YTOWp75BNpi9VQumm7em3pWhSmB1T3Q+P+W0GyoqZ9wsihwW09cRPPGWK8y8 GqIhu8tonjHguqYjSjw5yL22PK/KRR2A7uNvk4HOejOpMhWETCJbgCDp/Dzi 82xf59kG9/b3jtXztUB+xE8qFcbmBscajhAjPFo8L6rBQmBPy5Yk+0eEmk0i I3kdEiCTz9BHhMgfukNNIgwMDO6ceVw1O8aynwJaw6ooyd7Y9Pume9P9bF0P 8kr7zGH8R8CxERNOYSSXl+qOkTHm+wZEt/hkDVqrzyHz2farXproRYJeeAHU hAILeRkPKBkC+5qroIrY5Dlw5HhhlhbzhzwNbqGUS2TmPrC4W3Qw/PPoLZCs wEKhQYtee8V+Zsm31RP+52neiiUSZttPZpiwjFGgP5rBMmAeJ3MVdfuwNyvO j3DA/jQgM/t8yk9EEwJNpjtpshUeknl6EsxQPBkNBoJwmrwfW4Wu0Bkpkl2Q 0EslUFm/7HBikK2+1r5kXb2CDY1W6T5Yze12EEmFE+ft7PlKuSATcvW8GRZh JUyWpSWA9DOXLLyIOKQhonQ5OEF1F7V3hMzVN6BQCMMKkTW3JoaSeXM5kq63 X95aJZ5cLttTNXbJqia1Hm/eaN49dCSj0mQ0dWzmuM/gJmBhtUKm0NUXSnHm CsxWRGWSqzfjzKvuQJcF2hkn6hN/3b2tYW6Sfgoh7L3fvldYwleXfbpIlOUj 4RzvnRgB//TUqdbqBS1PvqFPUOFFpSCIBAUpNUqPH5fKd0taFZJ1PBtaivHf Vl5jC/rUHGtFVy4zhhNku60FvNgLs9hiAvOWK9xXxodFHoqFpzy40RXjDump SH66W3wqkJCsX8Rid4GtEbHIpaCNWXILw0Sd8Ia33slobEO3Uohkr7ACTz26 aH517fp/h7sG96fhroPt7qA3G2ipI/K0bN/6OdwxzZCt00Jp7/GB2MdFwxeq DDdY1KN54JIhP4ADmqfjCRA26U97FmghPZ1hDSBM6SE3AmUJrQAlMZATnnO2 VufKjm02YwP1TiLMniaUjRQWMRD227CWSjbPia/vT2sgCw3v9Ry7eyC9wddP ES62MkyiS3YSUDARxwKtcY7aWHG44TSkYdgQ7YDvfuzvAr9Un9t60ftFHH6J MagUjZDrZW1vxIyPdc4Iln4XjNC+RQb2fDyAkxLZukvJOB5iAe2PaNFOQF5n XTg+qTJKWfbhHUa4aiJwUvxS0gnR8Nkc1UU0DZmTM+ylQppiv605O9elOZxt xWcB5ir81V9zrspfBp0TMFYqEeXod/hgeKL3oupwXurZUBd7wjJ57nrrFvOp 8rR48wwgGTtCrhmhEZoRcgwCyuypro7ZDtyveDRLPP2Br0lFc6YaM6eeBbQD t0L8gVyzlAC5fddrMdz6f2Qx1aWpv9v+Md8m4F9ptp6mRP64mWlunP4IhHlE dKmrBLLo9Ipy4HOxP4lzHiZmNn5Qw2pfl9PIsmjcdCWt1TcZK7GtzsKFPPpS tl5rv1C2vMQ8xf/e5QDPfTd+64tVdf62YJbjL/Exrkanj5LDJnLH3vbjG0Zo S2mMQ3mV9+ZYGly5s5AvtY4q+R7jnr5Q7/msbuyBaGHh6Rfr4kbeLpbI6gOl /l/TVg6b7YbQ+8MISKJgTye6jW3+oVxNbsFl7MVHpfLDyFos9cmdv9CFXyMJ /FJj6pGYA8zz+e5v+74idDAajavFvtA5YDhK7ennrV3IVz75SvigvQtb9Mi5 r5NxDQrZYseu+p/56vglz2rlhYoWsS7zFq3U/omFRcykcdO1HrArLiUrU5xJ 9ETEytiTNTnsmjyHi6VMN3cP3MLJM9HENH15NDOzAn5kqK3Z4Rd78iLM/UtI bq40hP5whSCKUBpccL5130pNPtddYKb3hK953IEg7Z2shrTz48/2Uf0YkzNQ Mnwi9Vsx52mUeMalgBUO2E0nAwbaDXIrzG2/ocDm867qki+SIkAYSKeMQSiW GrNNnl2YznEwunGQ6lIGqYtLqXQC3kaXMnx+1tNhIS+HfDeHeSjrpVW+r7ND iOas7fIPecqyoDo435nOL3qouTga9Xo9V3nnC9xbUsmQXMa8hZ+DAKqfxmI8 no30ktzdWPoJUG0Bddj8lbXMnwn0YaQMu4ci7FtVYaX5u6dY6fY/rNMICJT1 zqDacKNhLzD5Wxwo+4H1LtrcD73PCbev+DiTywj45YlKgRdHnwtqe4FajgLX ao6Tej03EbjIx6ORuZ71rpgdjYc5rIPvSG+v66JbGtdTjb9+aL9bTJe0c+Sf X8smAR/lqR4dHvjpHcr/CLo8trTK2hxt7EohmqSumHJqxPrtS9iIYh2ZRlmU i7lHbB04p/o3t/hqkxodDhlbj/JWKRrku1eX5rloawL9QufsTPErJi/D0Q2w GR+YUrjKPznZFgCHvbQLRev06/IkLJYoAXnqBXZDvaPxyHrZIjxOstgLfy6z jUx6gOJF3G0Rb+tz+y2Vc1jMT0k6KRWqcWzvv1ZD6nyJOVXdxDMf5K/o8/wV fWSwvAz25/ugXElLMBPnRp9ZXbfny96O+zkEl0+tNQKhVayZBMYLD3FO84wX lJ8iUMmv8Y1OuW3YusB+MuJIo+gc+qZNhJ6nBdNTdmxTgjrHypHnYHwqBo5W 1sBhv+jRDwZwcpsyO8gUGT6O3wzcveAdpo++s1cz3Yu1lHf2W0v3o+oDd3Zb T3frTXp3dUJXmrthDALAhH6J4ZKbt2DLUZu5tvL8h4eudjTWdfk4xSFhm0Ok aVxeSk2U/EQe/ConE4YOuGyDeYs9vfJw5JT8E8hrmmeAHJhJ5ZJNCeXyTe/8 eZ9GIB9Kpg2901PZNOzDX5EjA1s+wSHGMyAMT9jnO/ESCALlGV3aZaRM13Cr dLPClJfhSFzFSqWHC/HulHjWccJ5FnwCj2Yni1bxAmnnWvVL32rYL6XM+Ofj Oeyx1oBccLIKeoq9l8fx0LfKn3pW+ewyuFXwUDgw1IeGytNb4CTRXanI7YYM kPD/QPPS4gOtIIjT01FvhEJhBAca/QY7JP4wXJ5UwCID3qPqGyBq4AEWzaCE g74KOEU7nXBs8ZRMHV0ziK9jFJUp3Swg6ocR/pesFWmIbVhJs06BJVz3NK7V dAc0Cfkcr8a8chWhIJEq9l6Q4iGHdvgVLY5GWN15NKGc4USX8K7r2pMHh9AP ZxXykpEbFC9Cu5pd1cDNf57bl2CJ5wqxmNX592eb8uy7E9Q1naZ0TYvwVz5T pQ9I2CMkS2fIXA6+IbYe/v59mTKu+WeChZvDl7mAsN+JQ0vHMk3yzJjE6ANu WO7esm61WrhwrzWoxx2TNIcH46iz6TfzeG48TGDz4n+Yu/9h7v5VbJvOkxVf 8aXvhhcn7AwSDUezDxT09DdKX8yZTLH+CtzNepx7o7F6fXRReT2OUPnFCj1W MLvFunS3/msEB/vSiWNoUfU7n9ltVrg8w783iwkXY2/8OZ8P9DYGOVAgYcg6 lu+gZ0gVK5XspiqfImtp1e4Bg8b24Gl0PXa8yUk3SQihcUq0S3CJo6H5syaV 1vSEPjslF8wkZTrw+KH0K8MigbRAGNhHJrswDrZT4Cso5AMd1xE9Eb0ohB35 IwpyNhPWZods/b0XFHEJYVIuKdfnXypTm1otWC0uLwBo0x9RBPk1KpNsKiGK Ho/DC7NllsZ+dLLHB3ndvhkrsDNNxuHEcBRghUqT9+CKrf8GZvHExH43qKOz dd29mnxCDHvwmHJ+ZMhhFNXpf55dzTW2Ipj3bBNYrP2T7Sv80o9U7vaLaW/7 D/xkU/P7ne8E/TzxjdYjHnfg3TVZ6LUWfef86Gh3e/fsbOv0Lyo34TmDhlex x+l71oQ8GWKeCDFHgqDxlG8sLy871q2SwztKJurT6DLmIu56fMW+o7yJ1KMI uMTXPlsYvLJh7EVZRn2+1o6Xhc4ljM1Qh1BjsFDOz//WeT3v4ern5fYsIq26 D1ZwymWDF0jXSrL2+fiOUOxiqSqIM6Yoon9fd90HtUKDCp8iTqcOeO5F+22d bZ2sGAwEFo7fHt3ABL5gOQr+jtrI/HghjojIhLA6XcgcDw3x7L7ry4vWLrHL oKVLqLALLMJ3aKt66GOOzYdU9M1sLCMX8SrsMDfGdE7eZgEpzNsfFli4I4Xt XVn/vRHuX/y3KNCKqr7+uxhwZIZ8gBgQrDqdAFGhedDsciIG8xUKheWy/BpR PP9KSp/gAlRSERrpFEn5yrCi5EnZ+M5M0SpDALFY3zKWk0JJS1ht+NPLEzS9 ZSLTxxaoipxENWWSrulpEfB27KqOXDWBkzA/F6bD02+Rs0eYGj21D/knhNUX 6NSRX0MEoA95hkWLcWQv+dh5KAX+KdlmuRKEV4ojCIcsjHqdP7H2nRMrKBCS db+aO7FpwcRya4x4JcUxz/XObpjn2k+GTR0K7t8M5ZCq0U/TNaN/bxpTGE0y n6IIm5kOIzAFcQTB7RASMk94yXeVLxjTY24e27t9w7l2cw4AP5vBCvQ4Hw7i jxGXpMVrHKgPpiwYRhEXeL4ZTYBB7l5gDKrnS9S7AtwEPg1GoMQGnOxacxpd TkbXBgMhJ8OoCwOjE67mEEM9DPsMfpiBNAYDdD904yFqZ8ykC7vZGw37MSUC JKC67IQkwDsP3JlmNIDvIxTsg28zz5DvEDDDVvyeXklw59bZoSk/rLA8/iEa Rpiepo/cc4LATEfXgI68PwmD8GR58wmuVdqBPdhE72763UO9KI36nTnGHdr6 ba17FuvO4rFJZsmYykph0dHob1Fv6lw3bRZDkqAZV6Zcdv72VYAoU5/nTNwC kuo7LHm2QNk0Ci6IgJ38jLybdkzXQAucO3vdCcgsqvAtlZZTHgn1bJcrkCam mNBbO6X7sAcSSlpYex4dfFwOQIQpVWqtmfqEa1zKwrOahYdXoHAGa6kekyBM M9v+efYLIqLngJOzokHjMLHiq8pjjuF8/dqsyRpZA2ZSwpVJrc3LyoahnNCH SAFof22tXsUKCjJE57XuIDE5Y6zrduyMyNuYcxnSGbW5K14hAmHhuGiIK4+K Tn2XmBePX+JBRv+cS8Te/gjPPeEgvDKfuoMZ4CxVZffpAMjYwL6MuSrnxehT xGMgpRl+QnVMqqYTbQ3K0olZTh3ORg4aFrT8JxbkeyBR07N1VKmmD8GqC7bL zq4MHciycUnIIDah/Plp20tGnEbTMYNobY74WolsNmahWS/h4sUSxBV3TfEy ZCboEToqsFBxHEdWdrEBSKMeZk8oyComz2PgkH42T7mY69T0rvv/NKkGs8I8 tRXP8Ufl8eRnlH4nHa3pQVacK9VkSVZ2seHw/nK1iDIC7mpEnO0fb+/s/nhy uv/jVnu3RVLzd5ILQvTDGvN18v1fUB3sUsSV8Nv4lU388kb+kMuNlivWTaR+ HPXiyxguDUxcrydTh8yku6FvrL7PrQig3+dZyu+G/ub+fphbHnjNlpSciSXY OR8+z2X6IcnMg6i8vXXSOdptd7Z2DvePxE3B1mk62T093MidEc2DXEIXnIj8 br7PzkiTznvPa7vHJ0fH7bPzkxM5XMr/nYBEt/0ZxMIhnrN4nHBequEIqGBv huWrYNLXeM/BQk0l2QzgP1/RWOiPQvtcC+X24oSzCpL+h/ylvVHQKIq+sFto hYQnNAalr0HWA93ouwaveQ4gNJjRh8KaGQcxjU0VOEniO667w8+GSH6SDSb0 897M5b4Wq11zQyOl1E3Ea6Mr9N5e5+T0+HD/bPte+T997xOt6DAGVjlOejMM KcVP5ubWUngMldA7vd2jvfnCTgZwKcFfh7rk8PfbCUxP/j6B8QkRyKDGKZJp 9OteB1POVrg6fXaCWwcHh+cH7X0Vbb4VBvfx4lHIg1nGob/93qp80675GjfF 8nTJEkljA/hBycVXCP+IGiGbeWPPvX/aE0nCn4wup2gtqjkpIYkmcXdAgxzu 7B8bNUMBhp9FbiShIlyLIUG+eudkfXV9rb7F1tbkKor4KKAE349QU25LXort /rp7G1/PrrlDj/yoKZEmHLfmynNzePV3EnciTqcJDafxtRzHWTLD9JJ8XuEo gRyEV2ptOqrR1XqyvW/2nx2bHpCDyMlmIIVFE5TD+tGAz2GX1eKoIUJnCoIC vvEIPpLMIoH4DxzwzBSaumKx9OGgTA/IxEeZnqUZrhtWu9trd7YPfiih40bq 5c7+aefd6X57F1+upV9utbf4bd1QZg9AmLBXpbBHg3o0F+txuru1gwA0Uy93 j9529o9K+Kou2/Wd4Ae7IMAldX0xsGnQ+rTHMRf4NcnnYe9qMhrGf5ci70Ne X06jDfwLxk07/M2hdLSqOEwociLdQuOhT+bsBiBL5yeKOwEGAbBzgKpeq83f TVCIjpMrAhKRJpG4l64Qb7PaNIPRB4AELhFVQtk0Olzo9I1zbqBjm96CqoPK uxAFbTYKu+meWcS5c5yvWYbP8RCZpQMWhoLNKbp71NNI/V88rTK7q0HvDjBR yIsBI/uC+FgqKlrmIfDBc/ytowRKJR5iCkKD6sPuu1FaSUnRrKNoVrGLQMih k1tVBh+l7qv4cirWGqCAGCKGVJD2jdLEOhMrKhUba6ELp8u4jjSJ51DWBXlc brx+HcNt8afsqWtljq7baBlqQbTQD38LNgR86PRGkprFXC4H2GrOv0XXAqxn LcYsx169cbcsr2hZwlVxSMv04e75WDQoy1+ISYRI5BzrumPttYAq4Ro3bJnd zKe/bXGEfxRYHlOhpbpUUkJ9EXyP371502Ahjp3DMuUtPAZ3oVPGv0j09g4c DSAHrX77HGuV14nWe8esuUrLpQPRAq7jIxrs3ocrbT769afsrgO22ljggNmV +O9xwg4izXZLutpLVOniUcqcoryp3/8U/SbIn1IS/Add6lvbJ/sts9X/1B32 gHJzvZ3ZxF7b5gStyRwdjLPkCUoyxXfdj1HteFg72Doitp7Lpksex4sRZi+F 5RmZnVVAaBynhnbIip/M0z9TgSX2X+6YQEELOPfZGBiBlmlsbqKJmfPUmD0R HJubm4dd5BVOWClYNWubmwdYmY6tmPmZ5nlDmx6TD3xWTzVhbfILEqHh2nPp xGWFtbHypufLcB9hZZ5fwrz0qQzdNmuviAmk9aHdNLTNG0b7UzYdVF9OAUdM dHkJkokAPO7FHTnuhG3o4N0nk9yYdFH126iO/11v1FdF6HGfJaML4lMyiKJx hT4LLDKXH6+w4HPCtWlatJCqDIAj+SGacoIflAykkBt6xpn+bKJFKtxt+TAf PzGUXlEMZ4LeSk/HDjVnwD0iJsEU8B/gBAFiX8mFnYRkVs34ZqI/6P26ofc2 8w41xroBA+DMq5g3iJETnzNP4i2hv3yPvZGtO0XZewi326pXJsOZQHKHNjw2 LFxn+/jwcOtoBz/hZlLJ69n3oMKeb7fOdjtbOzunu2dnHYSR1un+XRvStbFQ 19PjQ+0J/WQzcnuiBtef6cFWe/do+y+d9v7h7qnM18+yc1f/7a3t73c7B/tH u2Sq1hXT7VxojP2j9u7p6flJm8aBIVwJsvxzZMJDhPyE/VDQ+q7dCTdn8a4N QfzFuga7k96coOddK6Nlie/smNrWvF2d2z+zrfm7Wrg1wSHyzhBc6s+tkucP 8SWI4+bweOf8YBf9j2LJPjYbo35oNojK+Kw4QxhVfmNfezva9tbpztvzMxLV VA3U6U9QBC8/lvtyNGZDu8arR90xcRCalU2MNSO2iaJxiyITuPo3OkVU0Vcz +Zwg9xHBCgi0FfFGDuXpyWg07Vid4qfQjzV7vW+W2Um+ku7IF7vqEXnmYiag nwwEvfamDusF7TJAOJbLJVBH5Ex90fIL6cBNcXrHRG4Y+lbc0Q8UADzAIn/k r3YVj4H5f7+C/Hf8d1GPkvdKPqz8im5QWAWPC0y1hhXx0MLqDnhr2WxJ+EZb 9B+2Fs4BiB4DEDcmMd7sSYsekn8q7GFNsLdlHn3o9UxtR4ao7XQ6qA/ePeh0 TO0dXru1d7CxcW9aI30i14utHb8wtR5a2l/drvTMf/3V1C7Ns1kyeRYPe4NZ P3oGh2p2+ww2UAqmJStX5j2mH4p6VyP+3o+7p2f7x0dn//WIQTs7PKkVgdfp wFsE6VcBKh/CWEbMJl70MTlwv3ZVaiP88+XzTu9iBaa8T+uTTHqyNuPedS/u 1npJbXWlvvLKrpwCWcOkrsNpbRB9igYts6aPAQ/jXm10eQn4bR9Puxe1m7iP gVT8ZBfmw9WKAEkuTW1marVJhKU/0BBSqw2jm9olHuZPzZXVlbWXIEw2BTAm LckzOGcC5LNDYJ+o9Z0tHtRqtfuNWWpfzcxedGEaL02z2Wo0W2uvMES3/mB5 efnuDwbdG63mi9Zanbv/+c+mtrZeXTXL8N9X5s9/fmAOf+ocv/1fZ6VSa9P8 sSw1C/B/fyxHt+iuWxtd/C2pVOE3/FG7rlQemAdGdgYeto9PdvZPK89OgSwl K9cAwoPlB8tul1tmZeWZ7P+D5dIfy9vbFei2vXew9d1ZxUcoi2OEJ3/8s/nj 6wfL5sFyNI57jXrdjSYPvmW8/weHX40ZiDUBAA== --264360797-715998893-950829325=:597-- From owner-netdev@oss.sgi.com Thu Feb 17 17:24:15 2000 Received: by oss.sgi.com id ; Thu, 17 Feb 2000 17:23:55 -0800 Received: from hill-b-039.resnet.purdue.edu ([128.211.205.39]:53002 "EHLO hill-b-039.resnet.purdue.edu") by oss.sgi.com with ESMTP id ; Thu, 17 Feb 2000 17:23:42 -0800 Received: from tremere (tremere.succubus.ml.org [192.168.1.10]) by hill-b-039.resnet.purdue.edu (8.9.3/8.9.3/Debian 8.9.3-6) with SMTP id UAA08135 for ; Thu, 17 Feb 2000 20:23:49 -0500 X-Authentication-Warning: hill-b-039.resnet.purdue.edu: Host tremere.succubus.ml.org [192.168.1.10] claimed to be tremere From: "Michael A. Lemler" To: Subject: IPv6 Multicast and Linux 2.2.14 Date: Thu, 17 Feb 2000 20:23:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Are there any knows issues that would cause Ethernet interfaces to have to reset the transmit timers on Ethernet devices while IPv6 Multicast is occurring on that interface? Specifically, routing updates and the like Thanks in advance. Michael A. Lemler Undergrad, Purdue University From owner-netdev@oss.sgi.com Sat Feb 19 19:22:57 2000 Received: by oss.sgi.com id ; Sat, 19 Feb 2000 19:22:38 -0800 Received: from [213.228.30.121] ([213.228.30.121]:54277 "EHLO rduhaut.duhaut.com") by oss.sgi.com with ESMTP id ; Sat, 19 Feb 2000 19:22:18 -0800 Received: from duhaut.com (localhost [127.0.0.1]) by rduhaut.duhaut.com (8.9.3/8.9.3) with ESMTP id EAA11443 for ; Sun, 20 Feb 2000 04:22:55 +0100 Message-ID: <38AF5E0E.49620DDF@duhaut.com> Date: Sun, 20 Feb 2000 03:22:54 +0000 From: Duhaut Renaud X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: fr, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Ip aliasing and IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On my linux Box (kernel 2.2.14), I use ipv6 stack and interface aliasing too. It seems to be a little problematic with net-tools (v1.52 or v1.53) because, when I try to shut down one alias, all the adresses of the interface go down ! For example : Without Ipv6 : ifconfig eth0 192.168.1.1 up ifconfig eth0:0 192.168.1.2 up ifconfig eth0 down I keep my eth0:0 running.Cool. With Ipv6: ifconfig eth0 down Drop down eth0:0 AND eth0 ! Bad. I need to use aliasing AND ipv6 stack, because i have virtual hosts on my Linux Box and all are also visible through IPv6. For instance I use 2 versions of net-tools , one without IPv6 and one who have it. But I want to know if this is "A feature or a bug" ? I've looked in ipv6 code of the 2.2 kernel and not seen any reference to aliasing stuff.It seems logic because v6 don't need aliasing, but it must handle it for v4 compatabilities, No ? Thanks you. -- Duhaut Renaud .~. Network Admin /V\ 13eme B.C.A // \\ Guilde-Reseau /( )\ renaud@duhaut.com ^`~'^ From owner-netdev@oss.sgi.com Sat Feb 19 20:18:17 2000 Received: by oss.sgi.com id ; Sat, 19 Feb 2000 20:18:07 -0800 Received: from dibbler.ne.mediaone.net ([24.218.56.247]:62988 "EHLO dibbler.ne.mediaone.net") by oss.sgi.com with ESMTP id ; Sat, 19 Feb 2000 20:17:46 -0800 Received: (from rodrigc@localhost) by dibbler.ne.mediaone.net (8.9.3/8.9.3) id XAA08992 for netdev@oss.sgi.com; Sat, 19 Feb 2000 23:23:54 -0500 Date: Sat, 19 Feb 2000 23:23:54 -0500 From: Craig Rodrigues To: netdev@oss.sgi.com Subject: Re: Ip aliasing and IPv6 Message-ID: <20000219232354.A8966@mediaone.net> References: <38AF5E0E.49620DDF@duhaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <38AF5E0E.49620DDF@duhaut.com>; from renaud@duhaut.com on Sun, Feb 20, 2000 at 03:22:54AM +0000 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi, I don't know if this will help you at all, but if you go to ftp://rawhide.redhat.com and pick up the newly released net-tools-1.54-3.i386.rpm and setup-2.1.4-1.noarch.rpm, those packages are IPv6 enabled by default. I'm not sure if they fix your problem with IPv6 aliasing, however. -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From owner-netdev@oss.sgi.com Sun Feb 20 09:32:05 2000 Received: by oss.sgi.com id ; Sun, 20 Feb 2000 09:31:55 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:3590 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Sun, 20 Feb 2000 09:31:39 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA28924; Sun, 20 Feb 2000 20:31:20 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002201731.UAA28924@ms2.inr.ac.ru> Subject: Re: Ip aliasing and IPv6 To: renaud@duhaut.COM (Duhaut Renaud) Date: Sun, 20 Feb 2000 20:31:20 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: <38AF5E0E.49620DDF@duhaut.com> from "Duhaut Renaud" at Feb 20, 0 07:13:09 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 381 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > Without Ipv6 : > ifconfig eth0 192.168.1.1 up > ifconfig eth0:0 192.168.1.2 up > ifconfig eth0 down > I keep my eth0:0 running.Cool. It is not cool. It is simply impossible. Check again. > With Ipv6: > ifconfig eth0 down > Drop down eth0:0 AND eth0 ! Bad. "ifconfig eth0 down" shutdowns ethernet hardware, no matter what you configured on this hardware. Alexey From owner-netdev@oss.sgi.com Sun Feb 20 11:43:16 2000 Received: by oss.sgi.com id ; Sun, 20 Feb 2000 11:42:56 -0800 Received: from populo.vip.fi ([194.197.215.5]:19751 "EHLO populo.vip.fi") by oss.sgi.com with ESMTP id ; Sun, 20 Feb 2000 11:42:35 -0800 Received: from localhost (viha@localhost) by populo.vip.fi (8.8.8/8.8.5) with ESMTP id VAA20446; Sun, 20 Feb 2000 21:42:30 +0200 Date: Sun, 20 Feb 2000 21:42:30 +0200 (EET) From: Ville To: netdev@oss.sgi.com cc: Duhaut Renaud Subject: Re: Ip aliasing and IPv6 In-Reply-To: <200002201731.UAA28924@ms2.inr.ac.ru> Message-ID: X-Important: This is an unattended mailbox. firstname@vip.fi is for urgent -private- messages. X-Feds1: Are you telling me it wasn't just paranoia? X-Feds2: Darn. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Sun, 20 Feb 2000 kuznet@ms2.inr.ac.ru wrote: > > ifconfig eth0 192.168.1.1 up > > ifconfig eth0:0 192.168.1.2 up > > ifconfig eth0 down > > I keep my eth0:0 running.Cool. > It is not cool. It is simply impossible. Check again. I think Mr. Renaud had a little flaw of thought while writing, but yes, I can confirm the behaviour indeed is erroneous or quite surprisingly tweaked: The whole interface is dropped when you down eth0:42 and have a standard IPv6-tools package. At least this was the case on all Linux-boxes I attempted this on (admittedly most of them were the same breed, though). I had been able to take advantage of the exact same set of commands on my IPv4 boxen earlier. I am not, however, aware of the exact cause for this. As a matter of fact, this was some weeks ago, on a cosy Sunday morning, me using a production-box at work to perform what I thought would be a normal peaceful administrative procedure that I can quickly take care of while at home.... ,) Though, I doubt anybody mind the eth0 being down until late afternoon... > Alexey -- Have a nice day, Ville/viha@ircnet.org (The IRC6 Project) From owner-netdev@oss.sgi.com Sun Feb 20 14:41:07 2000 Received: by oss.sgi.com id ; Sun, 20 Feb 2000 14:40:57 -0800 Received: from lyon2-55-141.dial.proxad.net ([212.27.55.141]:3076 "EHLO rduhaut.duhaut.com") by oss.sgi.com with ESMTP id ; Sun, 20 Feb 2000 14:40:39 -0800 Received: from duhaut.com (localhost [127.0.0.1]) by rduhaut.duhaut.com (8.9.3/8.9.3) with ESMTP id XAA00988 for ; Sun, 20 Feb 2000 23:40:43 +0100 Message-ID: <38B06D6A.D94FA39D@duhaut.com> Date: Sun, 20 Feb 2000 22:40:42 +0000 From: Duhaut Renaud X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: fr, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Re: Ip aliasing and IPv6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Ville wrote: > > On Sun, 20 Feb 2000 kuznet@ms2.inr.ac.ru wrote: > > > > ifconfig eth0 192.168.1.1 up > > > ifconfig eth0:0 192.168.1.2 up > > > ifconfig eth0 down > > > I keep my eth0:0 running.Cool. > > > It is not cool. It is simply impossible. Check again. > > I think Mr. Renaud had a little flaw of thought while writing, > but yes, I can confirm the behaviour indeed is erroneous or > quite surprisingly tweaked: > > The whole interface is dropped when you down eth0:42 and have > a standard IPv6-tools package. At least this was the case on > all Linux-boxes I attempted this on (admittedly most of them > were the same breed, though). > > I had been able to take advantage of the exact same set of > commands on my IPv4 boxen earlier. I am not, however, aware > of the exact cause for this. > > As a matter of fact, this was some weeks ago, on a cosy Sunday > morning, me using a production-box at work to perform what I > thought would be a normal peaceful administrative procedure > that I can quickly take care of while at home.... ,) > > Though, I doubt anybody mind the eth0 being down until late > afternoon... > > > Alexey > > -- > Have a nice day, > > Ville/viha@ircnet.org (The IRC6 Project) Sorry, It was very late in the night when I wrote my posting and effectively my exemple was wrong. ifconfig eth0 down , drop down the interface and it's effectively normal (Thanks you Alexey !) The good is example is : ifconfig eth0:0 192.168.1.1 ifconfig eth0:1 192.168.1.2 ifconfig eth0:1 ----> Drop down eth0:1 AND eth0:0 too. And sorry for my bad english.... -- Duhaut Renaud .~. Network Admin /V\ 13eme B.C.A // \\ Guilde-Reseau /( )\ renaud@duhaut.com ^`~'^ From owner-netdev@oss.sgi.com Mon Feb 21 15:58:18 2000 Received: by oss.sgi.com id ; Mon, 21 Feb 2000 15:58:09 -0800 Received: from tklab2.cs.UiT.No ([129.242.16.92]:15117 "EHLO tklab2.cs.uit.no") by oss.sgi.com with ESMTP id ; Mon, 21 Feb 2000 15:57:49 -0800 Received: from dagb-home.cs.uit.no (dagb-home.pasta.cs.UiT.No [129.242.17.14]) by tklab2.cs.uit.no with ESMTP (8.8.6 (PHNE_14041)/8.7.1) id AAA24118 for ; Tue, 22 Feb 2000 00:57:45 +0100 (MET) Received: (from dagb@localhost) by dagb-home.cs.uit.no (8.9.3/8.9.3) id AAA04154; Tue, 22 Feb 2000 00:57:43 +0100 To: netdev@oss.sgi.com Subject: Re: RFC: PPP over X References: <20000203120127.J72648@sfgoth.com> <20000207143007.O31166@sfgoth.com> <20000216061853.A83604@sfgoth.com> From: Dag Brattli Date: 22 Feb 2000 00:57:43 +0100 In-Reply-To: Mitchell Blank Jr's message of "Wed, 16 Feb 2000 06:18:53 -0800" Message-ID: Lines: 30 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Bryce Canyon" Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi, I'm about to start implementing PPP over IrDA (called IrNET by Microsoft). Right now it's possible to run PPP over IrCOMM (serial port emulation) but this has a lot of disadvantages because IrDA is reliable and we don't need to do HDLC framing, CRC calculations or involve the TTY subsystem since that really slows things down at 4Mbps. IrNET is already implemented in Win2K, and will probably also be implemented in the Palm Pilot, so I think it's time to support this in Linux as well. So I guess I need to make use of these new changes you are making to pppd since I don't have any tty to attach to. What I need to do is to simply run PPP frames over an IrTTP connection without any encoding at all. IrTTP does not have any device associated with it, but you can currently access it directly using the AF_IRDA sockets interface. So from the kernel side should just need to open one IrTTP connection and send raw PPP frames over it. Should really be three lines of code, but I guess I'll need some more in order to interface cleanly with the current PPP architecture Could anybody please give me some hints on which version of the kernel, patches, pppd etc I should use, and which direction to take. Can I do this with the current Linux-2.3.x PPP code, or must I apply some special patches? -- Dag -- / Dag Brattli | The Linux-IrDA Project / // University of Tromsoe, Norway | Infrared communication for Linux // /// http://www.cs.uit.no/~dagb | http://www.cs.uit.no/linux-irda/ /// From owner-netdev@oss.sgi.com Tue Feb 22 04:38:26 2000 Received: by oss.sgi.com id ; Tue, 22 Feb 2000 04:38:17 -0800 Received: from ikar.t17.ds.pwr.wroc.pl ([156.17.215.227]:27404 "HELO ikar.t17.ds.pwr.wroc.pl") by oss.sgi.com with SMTP id ; Tue, 22 Feb 2000 04:37:48 -0800 Received: by ikar.t17.ds.pwr.wroc.pl (Postfix, from userid 1002) id A2278C805F; Tue, 22 Feb 2000 13:08:39 +0100 (CET) Date: Tue, 22 Feb 2000 13:08:39 +0100 From: Arkadiusz Miskiewicz To: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: SIOCGIFCONF and IPv6 addresses Message-ID: <20000222130839.A26768@admin.misiek.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i X-URL: http://www.misiek.eu.org X-Operating-System: Linux sunsite 4.0.20 #119 Tue Jan 16 12:21:53 MET 2001 i986 pld Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Currently Linux SIOCGIFCONF doesn't return any IPv6 addresses because sockaddr filled with ipv6 addr doesnt fit ... Kame guys said that it doesn't matter if we correctly parse output. IMHO simplest way for Linux to allow getting ipv6 addresses via this ioctl but don't break old application is: ioctl(AF_INET6 socket, ...) - return IPv6 addresses only or both IPv4 and IPv6 addresses. ioctl(AF_INET socket, ...) - return only ipv4 addresses (this same result as when using current Linux kernel) this won't break old applications because they are using AF_INET socket and will allow to get ipv6 adresses ... ANK: what you think about this ? -- Arkadiusz Mi¶kiewicz http://www.misiek.eu.org/ PLD/Linux [IPv6 enabled] http://www.pld.org.pl/ From owner-netdev@oss.sgi.com Tue Feb 22 04:58:07 2000 Received: by oss.sgi.com id ; Tue, 22 Feb 2000 04:57:57 -0800 Received: from 32.arlington-01-02rs.va.dial-access.att.net ([12.78.114.32]:7175 "EHLO kanako.v6.linux.or.jp") by oss.sgi.com with ESMTP id ; Tue, 22 Feb 2000 04:57:49 -0800 Received: from localhost (IDENT:sekiya@LOCALHOST [::ffff:127.0.0.1] (may be forged)) by kanako.v6.linux.or.jp (8.9.3+3.1W/3.3Wb4) with ESMTP id VAA05208; Tue, 22 Feb 2000 21:56:02 +0900 Date: Tue, 22 Feb 2000 21:55:53 +0900 Message-ID: From: Yuji Sekiya To: misiek@pld.org.pl, kuznet@ms2.inr.ac.ru Cc: netdev@oss.sgi.com Subject: Re: SIOCGIFCONF and IPv6 addresses In-Reply-To: In your message of "Tue, 22 Feb 2000 13:08:39 +0100" <20000222130839.A26768@admin.misiek.eu.org> References: <20000222130839.A26768@admin.misiek.eu.org> User-Agent: Wanderlust/2.2.18 (Please Forgive Me) EMIKO/1.13.11 (Euglena viridis) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) MULE XEmacs/21.2 (beta19) (Shinjuku) (i586-pc-linux) Organization: Information Sciences Institute MIME-Version: 1.0 (generated by EMIKO 1.13.11 - "Euglena viridis") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 990604(IM116) Lines: 26 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >>>>> In <20000222130839.A26768@admin.misiek.eu.org> >>>>> Arkadiusz Miskiewicz wrote: Hello, > IMHO simplest way for Linux to allow getting ipv6 addresses > via this ioctl but don't break old application is: > ioctl(AF_INET6 socket, ...) - return IPv6 addresses only or > both IPv4 and IPv6 addresses. > ioctl(AF_INET socket, ...) - return only ipv4 addresses (this > same result as when using current > Linux kernel) KAME people propose new function called getifaddrs(3). BSDI4 has it already to get local IPv6 addresses. I noticed that SIOCFIGCONF doesn't return IPv6 addresses and thinked of it. But I have no idea. What do you think about it, Alexey ? --- SEKIYA Yuji USC/ISI Computer Networks Division 7 From owner-netdev@oss.sgi.com Tue Feb 22 05:37:47 2000 Received: by oss.sgi.com id ; Tue, 22 Feb 2000 05:37:37 -0800 Received: from colin.muc.de ([193.149.48.1]:34828 "HELO colin.muc.de") by oss.sgi.com with SMTP id ; Tue, 22 Feb 2000 05:37:24 -0800 Received: by colin.muc.de id <140559-3>; Tue, 22 Feb 2000 14:37:13 +0100 Message-ID: <20000222143711.42089@colin.muc.de> From: Andi Kleen To: Yuji Sekiya Cc: misiek@pld.org.pl, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: SIOCGIFCONF and IPv6 addresses References: <20000222130839.A26768@admin.misiek.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: ; from Yuji Sekiya on Tue, Feb 22, 2000 at 01:59:07PM +0100 Date: Tue, 22 Feb 2000 14:37:11 +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Tue, Feb 22, 2000 at 01:59:07PM +0100, Yuji Sekiya wrote: > >>>>> In <20000222130839.A26768@admin.misiek.eu.org> > >>>>> Arkadiusz Miskiewicz wrote: > > Hello, > > > IMHO simplest way for Linux to allow getting ipv6 addresses > > via this ioctl but don't break old application is: > > ioctl(AF_INET6 socket, ...) - return IPv6 addresses only or > > both IPv4 and IPv6 addresses. > > ioctl(AF_INET socket, ...) - return only ipv4 addresses (this > > same result as when using current > > Linux kernel) > > KAME people propose new function called getifaddrs(3). > BSDI4 has it already to get local IPv6 addresses. > > I noticed that SIOCFIGCONF doesn't return IPv6 addresses and > thinked of it. But I have no idea. getifaddrs() could be implemented in user space using rtnetlink. -Andi From owner-netdev@oss.sgi.com Tue Feb 22 05:44:37 2000 Received: by oss.sgi.com id ; Tue, 22 Feb 2000 05:44:28 -0800 Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:60170 "EHLO cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP id ; Tue, 22 Feb 2000 05:44:20 -0800 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id WAA22340; Tue, 22 Feb 2000 22:40:28 +0900 To: misiek@pld.org.pl Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: SIOCGIFCONF and IPv6 addresses From: Hideaki YOSHIFUJI In-Reply-To: <20000222130839.A26768@admin.misiek.eu.org> References: <20000222130839.A26768@admin.misiek.eu.org> X-Mailer: Mew version 1.94 on Emacs 20.5 / Mule 4.1 =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000222224028Z.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Tue, 22 Feb 2000 22:40:28 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 23 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing In article <20000222130839.A26768@admin.misiek.eu.org> (at Tue, 22 Feb 2000 13:08:39 +0100), Arkadiusz Miskiewicz says: > Currently Linux SIOCGIFCONF doesn't return any IPv6 addresses > because sockaddr filled with ipv6 addr doesnt fit ... > > Kame guys said that it doesn't matter if we correctly > parse output. : > this won't break old applications because they are using AF_INET socket > and will allow to get ipv6 adresses ... > > ANK: what you think about this ? It might be done AFTER sin6_scope_id goes into the kernel. (Alexey, please, please take it into the kernel!) Alternatively, we may standardize / deploy new function like getifaddrs() on BSDi. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 From owner-netdev@oss.sgi.com Tue Feb 22 09:28:02 2000 Received: by oss.sgi.com id ; Tue, 22 Feb 2000 09:27:52 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:7174 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Tue, 22 Feb 2000 09:27:37 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA23593; Tue, 22 Feb 2000 20:25:44 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002221725.UAA23593@ms2.inr.ac.ru> Subject: Re: SIOCGIFCONF and IPv6 addresses To: yoshfuji@ecei.tohoku.ac.jp (Hideaki YOSHIFUJI) Date: Tue, 22 Feb 2000 20:25:44 +0300 (MSK) Cc: misiek@pld.org.pl, netdev@oss.sgi.com In-Reply-To: <20000222224028Z.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> from "Hideaki YOSHIFUJI" at Feb 22, 0 10:40:28 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 1606 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > > ANK: what you think about this ? Function getting address list can be implemented via /proc/net/if_inet6. The question, how to call this function getifaddrs() or somewhat differently, does not make much of sense, because there is no consensus in this area yet. I would prefer KAME way, no matter, what is it. 8). Low level ioctl() set is different question and it is not an important question at all. I think that overloading SIOCGIFCONF does not make much of sense in 4.3BSD framework, which Linux is. BTW do you know how does Solaris work? Actually, I am even not sure that creating standard high level function getting address list is useful. All known IP applications, using SIOCGIFCONF were hopelessly broken and must be reimplemented to use routing socket and its analogues in non-4.4BSD systems in any case. For IPv6, where addresses are more dynamic, it becomes critical and function getifaddrs() only open door for bugs, which are impossible to repaire without complete redesign of application as rule. Standartizing evidently wrong thing is bad idea. > It might be done AFTER sin6_scope_id goes into the kernel. I see no connection... If you are about to return an array of addresses without explicit record marking, it is wrong and will not pass in any case. We have enough of pain with SIOCGIFCONF. > (Alexey, please, please take it into the kernel!) I have already taken. Unfortunately, the patch, which I got at apps.ipv6 is too ugly (and, seems, wrong) to be applied in that form. It will take a (short) time to make something reasonable and working instead... Alexey From owner-netdev@oss.sgi.com Tue Feb 22 15:37:24 2000 Received: by oss.sgi.com id ; Tue, 22 Feb 2000 15:37:14 -0800 Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:19467 "EHLO cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP id ; Tue, 22 Feb 2000 15:37:01 -0800 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id IAA23751; Wed, 23 Feb 2000 08:36:09 +0900 To: kuznet@ms2.inr.ac.ru Cc: misiek@pld.org.pl, netdev@oss.sgi.com Subject: sin6_scope_id (Re: SIOCGIFCONF and IPv6 addresses) From: Hideaki YOSHIFUJI In-Reply-To: <200002221725.UAA23593@ms2.inr.ac.ru> References: <20000222224028Z.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <200002221725.UAA23593@ms2.inr.ac.ru> X-Mailer: Mew version 1.94 on Emacs 20.5 / Mule 4.1 =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000223083608A.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Wed, 23 Feb 2000 08:36:08 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 14 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing In article <200002221725.UAA23593@ms2.inr.ac.ru> (at Tue, 22 Feb 2000 20:25:44 +0300 (MSK)), kuznet@ms2.inr.ac.ru says: > > (Alexey, please, please take it into the kernel!) > > I have already taken. Unfortunately, the patch, which I got at apps.ipv6 > is too ugly (and, seems, wrong) to be applied in that form. It will > take a (short) time to make something reasonable and working instead... Hmm, please tell me what you think ugly (or wrong). -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 From owner-netdev@oss.sgi.com Tue Feb 22 18:17:20 2000 Received: by oss.sgi.com id ; Tue, 22 Feb 2000 18:17:10 -0800 Received: from tnt.isi.edu ([128.9.128.128]:41149 "EHLO tnt.isi.edu") by oss.sgi.com with ESMTP id ; Tue, 22 Feb 2000 18:16:52 -0800 Received: from orb.isi.edu (orb-e.isi.edu [128.9.160.66]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id SAA15143; Tue, 22 Feb 2000 18:16:30 -0800 (PST) Received: from orb.isi.edu (LOCALHOST [127.0.0.1]) by orb.isi.edu (8.8.7/8.8.6) with ESMTP id SAA11132; Tue, 22 Feb 2000 18:16:29 -0800 (PST) Date: Tue, 22 Feb 2000 18:16:29 -0800 Message-ID: From: Yuji Sekiya To: kuznet@ms2.inr.ac.ru Cc: yoshfuji@ecei.tohoku.ac.jp, misiek@pld.org.pl, netdev@oss.sgi.com Subject: Re: SIOCGIFCONF and IPv6 addresses In-Reply-To: In your message of "Tue, 22 Feb 2000 20:25:44 +0300 (MSK)" <200002221725.UAA23593@ms2.inr.ac.ru> References: <20000222224028Z.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <200002221725.UAA23593@ms2.inr.ac.ru> User-Agent: Wanderlust/2.2.15 (More Than Words) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 8) (Bryce Canyon) (sparc-sun-solaris2.7) Organization: Information Sciences Institute MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing At Tue, 22 Feb 2000 20:25:44 +0300 (MSK), kuznet@ms2.inr.ac.ru wrote: Hello, > Low level ioctl() set is different question and it is not > an important question at all. I think that overloading SIOCGIFCONF > does not make much of sense in 4.3BSD framework, which Linux is. > BTW do you know how does Solaris work? I'm not an expert of Solaris, but AFAIK, solaris always return the 16byte buffer by SIOCGIFCONF. Using SIOCGLIFCONF, it returns long buffer than 16byte. In order to get sockaddr_in6, we can use SIOCGLIFCONF. -- SEKIYA Yuji USC/ISI Computer Networks Division 7 From owner-netdev@oss.sgi.com Tue Feb 22 20:40:41 2000 Received: by oss.sgi.com id ; Tue, 22 Feb 2000 20:40:22 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:61444 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Tue, 22 Feb 2000 20:40:00 -0800 Received: from box.linuxcare.com.au (penicillin.linuxcare.com.au [10.61.2.27]) by front.linuxcare.com.au (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id PAA00848; Wed, 23 Feb 2000 15:39:53 +1100 Received: from linuxcare.com (localhost [127.0.0.1]) by box.linuxcare.com.au (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id PAA32437; Wed, 23 Feb 2000 15:39:51 +1100 Message-Id: <200002230439.PAA32437@box.linuxcare.com.au> X-Authentication-Warning: box.linuxcare.com.au: Host localhost [127.0.0.1] claimed to be linuxcare.com From: Rusty Russell To: Greg Simpson Cc: netdev@oss.sgi.com Subject: Re: routing tricks In-reply-to: Your message of "Tue, 08 Feb 2000 01:22:46 CDT." Date: Wed, 23 Feb 2000 15:39:51 +1100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing In message you wri te: > Ideally.. if I could do something like.. > ipchains -A input -p udp -s x.x.0.0/255.255.252.0 -d 0/0 -j MASQ How equisitely disgusting! My advice: use LD_PRELOAD and tell it what it wants to know when it calls getsockname(). OR: use the ethertap device, grab a free address in the C class you want, and aim a host route out to tap0. Then write something in userspace, which loops like so: 1) read packet from /dev/tap0 2) recalculate IP checksum 3) recalc protocol checksum if TCP or UDP 4) rewrite destination IP (source IP for `reply' packets). Similar code can be found in libfw. Enjoy, Rusty. -- Hacking time. From owner-netdev@oss.sgi.com Wed Feb 23 03:40:34 2000 Received: by oss.sgi.com id ; Wed, 23 Feb 2000 03:40:14 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:64783 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Wed, 23 Feb 2000 03:39:53 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id OAA00483; Wed, 23 Feb 2000 14:38:33 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002231138.OAA00483@ms2.inr.ac.ru> Subject: Re: SIOCGIFCONF and IPv6 addresses To: sekiya@ISI.EDU (Yuji Sekiya) Date: Wed, 23 Feb 2000 14:38:33 +0300 (MSK) Cc: yoshfuji@ecei.tohoku.ac.jp, misiek@pld.org.pl, netdev@oss.sgi.com In-Reply-To: from "Yuji Sekiya" at Feb 22, 0 06:16:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 140 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > In order to get sockaddr_in6, we can use SIOCGLIFCONF. Oh! It sounds interesting. Is this extension specific to Solaris? Alexey From owner-netdev@oss.sgi.com Wed Feb 23 04:09:07 2000 Received: by oss.sgi.com id ; Wed, 23 Feb 2000 04:08:57 -0800 Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:6668 "EHLO cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP id ; Wed, 23 Feb 2000 04:08:40 -0800 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id VAA04891; Wed, 23 Feb 2000 21:07:17 +0900 To: kuznet@ms2.inr.ac.ru Cc: sekiya@ISI.EDU, misiek@pld.org.pl, netdev@oss.sgi.com Subject: Re: SIOCGIFCONF and IPv6 addresses From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) In-Reply-To: <200002231138.OAA00483@ms2.inr.ac.ru> References: <200002231138.OAA00483@ms2.inr.ac.ru> X-Mailer: Mew version 1.94 on Emacs 20.5 / Mule 4.1 =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000223210717L.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Wed, 23 Feb 2000 21:07:17 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 25 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi! In article <200002231138.OAA00483@ms2.inr.ac.ru> (at Wed, 23 Feb 2000 14:38:33 +0300 (MSK)), kuznet@ms2.inr.ac.ru says: > > In order to get sockaddr_in6, we can use SIOCGLIFCONF. > > Oh! It sounds interesting. Is this extension specific to Solaris? KAME seems to have SIOC{AGD}LIFADDR and if_laddrreq{}. /* * Structure for SIOC[AGD]LIFADDR */ struct if_laddrreq { char iflr_name[IFNAMSIZ]; unsigned int flags; unsigned int prefixlen; /* in/out */ struct sockaddr_storage addr; /* in/out */ struct sockaddr_storage dstaddr; /* out */ }; -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 From owner-netdev@oss.sgi.com Wed Feb 23 04:18:17 2000 Received: by oss.sgi.com id ; Wed, 23 Feb 2000 04:18:07 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:45072 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Wed, 23 Feb 2000 04:18:00 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id PAA00760; Wed, 23 Feb 2000 15:17:14 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002231217.PAA00760@ms2.inr.ac.ru> Subject: Re: SIOCGIFCONF and IPv6 addresses To: yoshfuji@ecei.tohoku.ac.jp (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Wed, 23 Feb 2000 15:17:14 +0300 (MSK) Cc: sekiya@ISI.EDU, misiek@pld.org.pl, netdev@oss.sgi.com In-Reply-To: <20000223210717L.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> from "=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=" at Feb 23, 0 09:07:17 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 198 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > KAME seems to have SIOC{AGD}LIFADDR and if_laddrreq{}. It is strange. KAME is 4.4BSD, which has well-defined interface not requiring any additional letters "L" from its birthday. Alexey From owner-netdev@oss.sgi.com Wed Feb 23 04:19:07 2000 Received: by oss.sgi.com id ; Wed, 23 Feb 2000 04:18:57 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:46096 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Wed, 23 Feb 2000 04:18:55 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id PAA00735; Wed, 23 Feb 2000 15:14:35 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002231214.PAA00735@ms2.inr.ac.ru> Subject: Re: sin6_scope_id (Re: SIOCGIFCONF and IPv6 addresses) To: yoshfuji@ecei.tohoku.ac.jp (Hideaki YOSHIFUJI) Date: Wed, 23 Feb 2000 15:14:35 +0300 (MSK) Cc: misiek@pld.org.pl, netdev@oss.sgi.com In-Reply-To: <20000223083608A.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> from "Hideaki YOSHIFUJI" at Feb 23, 0 08:36:08 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 995 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > Hmm, please tell me what you think ugly Ugly? Well, all. 8)8) Do not be bothered, "ugly" is aestetical rather than technical category. As rule, author understands this himself by plain peering at his product. F.e. how do you find putting with_scopeid flag close to ipv6 parameter block but not inside it? 8) > (or wrong). We will discuss it a bit later. Probably, it is me who is wrong. F.e. why does the patch always interpret scope_id for multicasts as ifindex? Multicast addresses have scope exactly as unicast ones. Also, I can answer one question asked in the patch: af_inet6.c "Why don't we check this?". We do not check this, because it is undefined. Internal functions copy to kernel buffer of fixed size 128 and return true address length. Actually, I want to kill this sk->with_scopeid. It is evidently wrong feature, this state cannot be discovered and should not be stored. BTW what is "future" of multicast addresses with TCP? I never heard this before. Alexey From owner-netdev@oss.sgi.com Wed Feb 23 05:30:58 2000 Received: by oss.sgi.com id ; Wed, 23 Feb 2000 05:30:37 -0800 Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:17932 "EHLO cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP id ; Wed, 23 Feb 2000 05:30:20 -0800 Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id WAA05100; Wed, 23 Feb 2000 22:28:22 +0900 To: kuznet@ms2.inr.ac.ru Cc: sekiya@ISI.EDU, misiek@pld.org.pl, netdev@oss.sgi.com Subject: Re: SIOCGIFCONF and IPv6 addresses From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) In-Reply-To: <200002231217.PAA00760@ms2.inr.ac.ru> References: <20000223210717L.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <200002231217.PAA00760@ms2.inr.ac.ru> X-Mailer: Mew version 1.94 on Emacs 20.5 / Mule 4.1 =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000223222821M.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Wed, 23 Feb 2000 22:28:21 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 15 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing In article <200002231217.PAA00760@ms2.inr.ac.ru> (at Wed, 23 Feb 2000 15:17:14 +0300 (MSK)), kuznet@ms2.inr.ac.ru says: > > KAME seems to have SIOC{AGD}LIFADDR and if_laddrreq{}. > > It is strange. KAME is 4.4BSD, which has well-defined > interface not requiring any additional letters "L" from its birthday. I've seeked the source code: It says the interfaces are deprecated, but, literally, KAME have them. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 From owner-netdev@oss.sgi.com Wed Feb 23 08:00:38 2000 Received: by oss.sgi.com id ; Wed, 23 Feb 2000 08:00:28 -0800 Received: from cx778703-a.omhan1.ne.home.com ([24.3.227.28]:42229 "EHLO majordomo.paktronix.com") by oss.sgi.com with ESMTP id ; Wed, 23 Feb 2000 08:00:11 -0800 Received: from netmonster.pakuni.net ([192.168.3.13]) by majordomo.paktronix.com (8.9.3/8.9.3) with ESMTP id MAA28692; Wed, 23 Feb 2000 12:00:25 -0600 Date: Wed, 23 Feb 2000 10:00:11 -0600 (CST) From: "Matthew G. Marsh" X-Sender: mgm@netmonster.pakuni.net To: Duhaut Renaud cc: netdev@oss.sgi.com Subject: Re: Ip aliasing and IPv6 In-Reply-To: <38AF5E0E.49620DDF@duhaut.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Sun, 20 Feb 2000, Duhaut Renaud wrote: > On my linux Box (kernel 2.2.14), I use ipv6 stack and interface aliasing > too. > It seems to be a little problematic with net-tools (v1.52 or v1.53) > because, when I try to > shut down one alias, all the adresses of the interface go down ! > For example : > Without Ipv6 : > ifconfig eth0 192.168.1.1 up > ifconfig eth0:0 192.168.1.2 up > ifconfig eth0 down > I keep my eth0:0 running.Cool. Use Alexey's ip utility instead to do aliases. The xxx:# form of aliasing is a kludge that really hurts the routing structures. Using ip you can have multiple addresses on an interface and you can have groups of addresses that all delete out together as well. IE: ip addr add 192.168.1.1/32 dev eth0 ip addr add 192.168.1.2/32 dev eth0 Will add two independant addresses to eth0. These addresses can be deleted independantly. Now if you want to delete both (or more) at once then you do: ip addr add 192.168.1.1/24 dev eth0 ip addr add 192.168.1.2/24 dev eth0 And since these addresses are both within the same network (as per the netmask) whenever you delete the primary address (the first one added in the netbloack) then all related secondary addresses are deleted. Extended example: ip addr add 192.168.1.1/24 dev eth0 ip addr add 192.168.1.2/24 dev eth0 ip addr add 192.168.1.3/32 dev eth0 ip addr add 192.168.1.4/32 dev eth0 Then when you delete 192.168.1.1/24 you will take out the first two addresses (1.1, 1.2) and leave the second two running. And ip will work the same with IPv6 as well. I run both multiple aliases and IPv6 on multihomed connections and play all types of games like this. Works very well. > With Ipv6: > ifconfig eth0 down > Drop down eth0:0 AND eth0 ! Bad. > > I need to use aliasing AND ipv6 stack, because i have virtual hosts on > my Linux Box and all are also visible through IPv6. > For instance I use 2 versions of net-tools , one without IPv6 > and one who have it. > But I want to know if this is "A feature or a bug" ? > I've looked in ipv6 code of the 2.2 kernel and not seen any reference > to aliasing stuff.It seems logic because v6 don't need aliasing, but it > must handle it for v4 compatabilities, > No ? > Thanks you. > -- > Duhaut Renaud .~. > Network Admin /V\ > 13eme B.C.A // \\ > Guilde-Reseau /( )\ > renaud@duhaut.com ^`~'^ Enjoy! -------------------------------------------------- Matthew G. Marsh, President Paktronix Systems LLC 1506 North 59th Street Omaha NE 68104 Phone: (402) 932-7250 Email: mgm@paktronix.com WWW: http://www.paktronix.com -------------------------------------------------- From owner-netdev@oss.sgi.com Wed Feb 23 09:15:09 2000 Received: by oss.sgi.com id ; Wed, 23 Feb 2000 09:14:59 -0800 Received: from ikar.t17.ds.pwr.wroc.pl ([156.17.215.227]:18439 "HELO ikar.t17.ds.pwr.wroc.pl") by oss.sgi.com with SMTP id ; Wed, 23 Feb 2000 09:14:43 -0800 Received: by ikar.t17.ds.pwr.wroc.pl (Postfix, from userid 1002) id 6474DC8064; Wed, 23 Feb 2000 18:10:35 +0100 (CET) Date: Wed, 23 Feb 2000 18:10:35 +0100 From: Arkadiusz Miskiewicz To: itojun@kame.net Cc: netdev@oss.sgi.com, core@kame.net Subject: Re: SIOCGIFCONF and IPv6 addresses Message-ID: <20000223181035.A637@admin.misiek.eu.org> References: <20000222224028Z.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <200002221725.UAA23593@ms2.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <200002221725.UAA23593@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Tue, Feb 22, 2000 at 08:25:44PM +0300 X-URL: http://www.misiek.eu.org X-Operating-System: Linux sunsite 4.0.20 #119 Tue Jan 16 12:21:53 MET 2001 i986 pld Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Tue, 22 Feb 2000, kuznet@ms2.inr.ac.ru wrote: > I would prefer KAME way, no matter, what is it. 8). itojun please send information how on KAME SIOCGIFCONF ioctl() returns ipv6 adresses (how it's done with struct ifreq ?) etc ... -- Arkadiusz Mi¶kiewicz http://www.misiek.eu.org/ PLD/Linux [IPv6 enabled] http://www.pld.org.pl/ From owner-netdev@oss.sgi.com Thu Feb 24 11:36:39 2000 Received: by oss.sgi.com id ; Thu, 24 Feb 2000 11:36:29 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:23307 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Thu, 24 Feb 2000 11:36:10 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA21158; Thu, 24 Feb 2000 22:35:51 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002241935.WAA21158@ms2.inr.ac.ru> Subject: Re: Worthless Without Documentation To: satch@concentric.NET (Stephen Satchell) Date: Thu, 24 Feb 2000 22:35:51 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: <4.2.0.58.20000223125826.009c0890@pop3.concentric.net> from "Stephen Satchell" at Feb 24, 0 03:13:12 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 259 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > slow down (is the Nagle algorithm properly fixed yet?) before starting in It is fixed, but you will have to answer to the question (properly or not) yourself. 8) 2.3 uses Minshall's algorithm, which seems to be better than old bsd's one. Alexey From owner-netdev@oss.sgi.com Thu Feb 24 17:56:01 2000 Received: by oss.sgi.com id ; Thu, 24 Feb 2000 17:55:51 -0800 Received: from tnt.isi.edu ([128.9.128.128]:64698 "EHLO tnt.isi.edu") by oss.sgi.com with ESMTP id ; Thu, 24 Feb 2000 17:55:29 -0800 Received: from orb.isi.edu (orb-e.isi.edu [128.9.160.66]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id RAA10090; Thu, 24 Feb 2000 17:54:49 -0800 (PST) Received: from orb.isi.edu (LOCALHOST [127.0.0.1]) by orb.isi.edu (8.8.7/8.8.6) with ESMTP id RAA11446; Thu, 24 Feb 2000 17:54:48 -0800 (PST) Date: Thu, 24 Feb 2000 17:54:47 -0800 Message-ID: From: Yuji Sekiya To: kuznet@ms2.inr.ac.ru Cc: yoshfuji@ecei.tohoku.ac.jp, misiek@pld.org.pl, netdev@oss.sgi.com Subject: Re: sin6_scope_id (Re: SIOCGIFCONF and IPv6 addresses) In-Reply-To: In your message of "Wed, 23 Feb 2000 15:14:35 +0300 (MSK)" <200002231214.PAA00735@ms2.inr.ac.ru> References: <20000223083608A.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> <200002231214.PAA00735@ms2.inr.ac.ru> User-Agent: Wanderlust/2.2.15 (More Than Words) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 8) (Bryce Canyon) (sparc-sun-solaris2.7) Organization: Information Sciences Institute MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing At Wed, 23 Feb 2000 15:14:35 +0300 (MSK), kuznet@ms2.inr.ac.ru wrote: Hello, Alexey, we understand your opinion. I think it is reasonable. Actually, Yoshfuji's patch is just a conceputal one. We have recognizeed that we have need to improve it in order to adopt in Linux kernel. I describe our concepts regarding sin6_scope_id below. - In each socket connection, we try to keep the status of whether sin6_socpe_id is or not, in order to keep backward compatibility at binary level. - We have recognized that it is a problem that we treat sin6_scope_id as ifindex in case of multicast. - We suggest the idea we can switch the behaviour of sin6_scope_id using /proc/net/ipv6_scope_id or someting. We welcome your comments and suggestions. I think we need more discussion and improvement. We are serious to introduce sin6_scope_id. I hope you understand our point of view... Regards. -- SEKIYA Yuji USC/ISI Computer Networks Division 7 From owner-netdev@oss.sgi.com Fri Feb 25 06:36:54 2000 Received: by oss.sgi.com id ; Fri, 25 Feb 2000 06:36:44 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:59404 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Fri, 25 Feb 2000 06:36:27 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id RAA29360; Fri, 25 Feb 2000 17:29:41 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002251429.RAA29360@ms2.inr.ac.ru> Subject: Re: sin6_scope_id (Re: SIOCGIFCONF and IPv6 addresses) To: sekiya@ISI.EDU (Yuji Sekiya) Date: Fri, 25 Feb 2000 17:29:41 +0300 (MSK) Cc: yoshfuji@ecei.tohoku.ac.jp, misiek@pld.org.pl, netdev@oss.sgi.com In-Reply-To: from "Yuji Sekiya" at Feb 24, 0 05:54:47 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 18358 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > We welcome your comments and suggestions. I think we need more > discussion and improvement. We are serious to introduce sin6_scope_id. I append reworked patch. It is preliminary version. Please, check and comment, if you find something wrong. Alexey diff -ur ../vger3-000223/linux/include/linux/in6.h linux/include/linux/in6.h --- ../vger3-000223/linux/include/linux/in6.h Fri Aug 20 21:32:25 1999 +++ linux/include/linux/in6.h Wed Feb 23 21:05:44 2000 @@ -56,9 +56,9 @@ __u16 sin6_port; /* Transport layer port # */ __u32 sin6_flowinfo; /* IPv6 flow information */ struct in6_addr sin6_addr; /* IPv6 address */ + __u32 sin6_scope_id; /* scope id (new in RFC2553) */ }; - struct ipv6_mreq { /* IPv6 multicast address of group */ struct in6_addr ipv6mr_multiaddr; @@ -156,18 +156,6 @@ #define IPV6_NEXTHOP 9 #define IPV6_AUTHHDR 10 #define IPV6_FLOWINFO 11 - -#if 0 -/* Aliases for obsolete names */ -#define IPV6_RXHOPOPTS IPV6_HOPOPTS -#define IPV6_RXDSTOPTS IPV6_DSTOPTS -#define IPV6_RXSRCRT IPV6_RTHDR -#endif - -/* - * Alternative names - */ -#define SCM_SRCRT IPV6_RXSRCRT #define IPV6_UNICAST_HOPS 16 #define IPV6_MULTICAST_IF 17 diff -ur ../vger3-000223/linux/include/net/ipv6.h linux/include/net/ipv6.h --- ../vger3-000223/linux/include/net/ipv6.h Mon Jan 10 23:15:23 2000 +++ linux/include/net/ipv6.h Wed Feb 23 21:05:43 2000 @@ -20,6 +20,8 @@ #include #include +#define SIN6_LEN_RFC2133 24 + /* * NextHeader field of IPv6 header */ diff -ur ../vger3-000223/linux/net/ipv6/af_inet6.c linux/net/ipv6/af_inet6.c --- ../vger3-000223/linux/net/ipv6/af_inet6.c Sun Feb 13 19:12:25 2000 +++ linux/net/ipv6/af_inet6.c Thu Feb 24 22:07:19 2000 @@ -9,6 +9,9 @@ * * $Id: af_inet6.c,v 1.54 2000/02/12 23:34:45 davem Exp $ * + * Fixes: + * Hideaki YOSHIFUJI : sin6_scope_id support + * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version @@ -220,9 +223,8 @@ if(sk->prot->bind) return sk->prot->bind(sk, uaddr, addr_len); - if (addr_len < sizeof(struct sockaddr_in6)) + if (addr_len < SIN6_LEN_RFC2133) return -EINVAL; - addr_type = ipv6_addr_type(&addr->sin6_addr); if ((addr_type & IPV6_ADDR_MULTICAST) && sock->type == SOCK_STREAM) return -EINVAL; @@ -258,6 +260,22 @@ return -EINVAL; } + if (addr_type & IPV6_ADDR_LINKLOCAL) { + if (addr_len >= sizeof(struct sockaddr_in6) && + addr->sin6_scope_id) { + /* Override any existing binding, if another one + * is supplied by user. + */ + sk->bound_dev_if = addr->sin6_scope_id; + } + + /* Binding to link-local address requires an interface */ + if (sk->bound_dev_if == 0) { + release_sock(sk); + return -EINVAL; + } + } + sk->rcv_saddr = v4addr; sk->saddr = v4addr; @@ -338,6 +356,7 @@ sin->sin6_family = AF_INET6; sin->sin6_flowinfo = 0; + sin->sin6_scope_id = 0; if (peer) { if (!sk->dport) return -ENOTCONN; @@ -360,7 +379,9 @@ sin->sin6_port = sk->sport; } - *uaddr_len = sizeof(*sin); + if (ipv6_addr_type(&sin->sin6_addr) & IPV6_ADDR_LINKLOCAL) + sin->sin6_scope_id = sk->bound_dev_if; + *uaddr_len = sizeof(*sin); return(0); } diff -ur ../vger3-000223/linux/net/ipv6/datagram.c linux/net/ipv6/datagram.c --- ../vger3-000223/linux/net/ipv6/datagram.c Fri Aug 20 21:42:24 1999 +++ linux/net/ipv6/datagram.c Wed Feb 23 21:05:42 2000 @@ -134,14 +134,20 @@ sin->sin6_family = AF_INET6; sin->sin6_flowinfo = 0; sin->sin6_port = serr->port; + sin->sin6_scope_id = 0; if (serr->ee.ee_origin == SO_EE_ORIGIN_ICMP6) { memcpy(&sin->sin6_addr, skb->nh.raw + serr->addr_offset, 16); if (sk->net_pinfo.af_inet6.sndflow) sin->sin6_flowinfo = *(u32*)(skb->nh.raw + serr->addr_offset - 24) & IPV6_FLOWINFO_MASK; - } else + if (ipv6_addr_type(&sin->sin6_addr) & IPV6_ADDR_LINKLOCAL) { + struct inet6_skb_parm *opt = (struct inet6_skb_parm *) skb->cb; + sin->sin6_scope_id = opt->iif; + } + } else { ipv6_addr_set(&sin->sin6_addr, 0, 0, __constant_htonl(0xffff), *(u32*)(skb->nh.raw + serr->addr_offset)); + } } memcpy(&errhdr.ee, &serr->ee, sizeof(struct sock_extended_err)); @@ -154,6 +160,10 @@ memcpy(&sin->sin6_addr, &skb->nh.ipv6h->saddr, 16); if (sk->net_pinfo.af_inet6.rxopt.all) datagram_recv_ctl(sk, msg, skb); + if (ipv6_addr_type(&sin->sin6_addr) & IPV6_ADDR_LINKLOCAL) { + struct inet6_skb_parm *opt = (struct inet6_skb_parm *) skb->cb; + sin->sin6_scope_id = opt->iif; + } } else { ipv6_addr_set(&sin->sin6_addr, 0, 0, __constant_htonl(0xffff), diff -ur ../vger3-000223/linux/net/ipv6/ip6_input.c linux/net/ipv6/ip6_input.c --- ../vger3-000223/linux/net/ipv6/ip6_input.c Wed Feb 23 17:52:05 2000 +++ linux/net/ipv6/ip6_input.c Wed Feb 23 20:05:35 2000 @@ -26,6 +26,9 @@ #include #include +#include +#include + #include #include @@ -38,6 +41,16 @@ #include + +static inline int ip6_rcv_finish( struct sk_buff *skb) +{ + + if (skb->dst == NULL) + ip6_route_input(skb); + + return skb->dst->input(skb); +} + int ipv6_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt) { struct ipv6hdr *hdr; @@ -77,12 +90,7 @@ return 0; } } - - if (skb->dst == NULL) - ip6_route_input(skb); - - return skb->dst->input(skb); - + return NF_HOOK(PF_INET6,NF_IP6_PRE_ROUTING, skb, dev, NULL, ip6_rcv_finish); truncated: IP6_INC_STATS_BH(Ip6InTruncatedPkts); err: @@ -97,7 +105,8 @@ * Deliver the packet to the host */ -int ip6_input(struct sk_buff *skb) + +static inline int ip6_input_finish(struct sk_buff *skb) { struct ipv6hdr *hdr = skb->nh.ipv6h; struct inet6_protocol *ipprot; @@ -178,6 +187,12 @@ } return 0; +} + + +int ip6_input(struct sk_buff *skb) +{ + return NF_HOOK(PF_INET6,NF_IP6_LOCAL_IN, skb, skb->dev, NULL, ip6_input_finish); } int ip6_mc_input(struct sk_buff *skb) diff -ur ../vger3-000223/linux/net/ipv6/ip6_output.c linux/net/ipv6/ip6_output.c --- ../vger3-000223/linux/net/ipv6/ip6_output.c Mon Jan 10 23:16:39 2000 +++ linux/net/ipv6/ip6_output.c Wed Feb 23 21:11:58 2000 @@ -34,6 +34,9 @@ #include #include +#include +#include + #include #include @@ -57,11 +60,30 @@ spin_unlock_bh(&ip6_id_lock); } +static inline int ip6_output_finish(struct sk_buff *skb) +{ + + struct dst_entry *dst = skb->dst; + struct hh_cache *hh = dst->hh; + + if (hh) { + read_lock_bh(&hh->hh_lock); + memcpy(skb->data - 16, hh->hh_data, 16); + read_unlock_bh(&hh->hh_lock); + skb_push(skb, hh->hh_len); + return hh->hh_output(skb); + } else if (dst->neighbour) + return dst->neighbour->output(skb); + + kfree_skb(skb); + return -EINVAL; + +} + int ip6_output(struct sk_buff *skb) { struct dst_entry *dst = skb->dst; struct net_device *dev = dst->dev; - struct hh_cache *hh = dst->hh; skb->protocol = __constant_htons(ETH_P_IPV6); skb->dev = dev; @@ -84,18 +106,29 @@ IP6_INC_STATS(Ip6OutMcastPkts); } - if (hh) { - read_lock_bh(&hh->hh_lock); - memcpy(skb->data - 16, hh->hh_data, 16); - read_unlock_bh(&hh->hh_lock); - skb_push(skb, hh->hh_len); - return hh->hh_output(skb); - } else if (dst->neighbour) - return dst->neighbour->output(skb); + return NF_HOOK(PF_INET6, NF_IP6_POST_ROUTING, skb,NULL, skb->dev,ip6_output_finish); - kfree_skb(skb); +} + +#ifdef CONFIG_NETFILTER +static int route6_me_harder(struct sk_buff *skb) +{ return -EINVAL; } +#endif /* CONFIG_NETFILTER */ + +static inline int ip6_maybe_reroute(struct sk_buff *skb) +{ +#ifdef CONFIG_NETFILTER + if (skb->nfcache & NFC_ALTERED){ + if (route6_me_harder(skb) != 0){ + kfree_skb(skb); + return -EINVAL; + } + } +#endif /* CONFIG_NETFILTER */ + return skb->dst->output(skb); +} /* * xmit an sk_buff (used by TCP) @@ -159,7 +192,7 @@ if (skb->len <= dst->pmtu) { IP6_INC_STATS(Ip6OutRequests); - return dst->output(skb); + return NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, dst->dev, ip6_maybe_reroute); } printk(KERN_DEBUG "IPv6: sending pkt_too_big to self\n"); @@ -388,7 +421,7 @@ IP6_INC_STATS(Ip6FragCreates); IP6_INC_STATS(Ip6OutRequests); - err = dst->output(skb); + err = NF_HOOK(PF_INET6,NF_IP6_LOCAL_OUT, skb, NULL, dst->dev, ip6_maybe_reroute); if (err) { kfree_skb(last_skb); return err; @@ -414,7 +447,7 @@ IP6_INC_STATS(Ip6FragCreates); IP6_INC_STATS(Ip6FragOKs); IP6_INC_STATS(Ip6OutRequests); - return dst->output(last_skb); + return NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, last_skb, NULL,dst->dev, ip6_maybe_reroute); } int ip6_build_xmit(struct sock *sk, inet_getfrag_t getfrag, const void *data, @@ -582,7 +615,7 @@ if (!err) { IP6_INC_STATS(Ip6OutRequests); - err = dst->output(skb); + err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, dst->dev, ip6_maybe_reroute); } else { err = -EFAULT; kfree_skb(skb); @@ -636,6 +669,11 @@ return 0; } +static inline int ip6_forward_finish(struct sk_buff *skb) +{ + return skb->dst->output(skb); +} + int ip6_forward(struct sk_buff *skb) { struct dst_entry *dst = skb->dst; @@ -726,7 +764,7 @@ hdr->hop_limit--; IP6_INC_STATS_BH(Ip6OutForwDatagrams); - return dst->output(skb); + return NF_HOOK(PF_INET6,NF_IP6_FORWARD, skb, skb->dev, dst->dev, ip6_forward_finish); drop: IP6_INC_STATS_BH(Ip6InAddrErrors); diff -ur ../vger3-000223/linux/net/ipv6/ipv6_sockglue.c linux/net/ipv6/ipv6_sockglue.c --- ../vger3-000223/linux/net/ipv6/ipv6_sockglue.c Tue Feb 1 22:16:23 2000 +++ linux/net/ipv6/ipv6_sockglue.c Wed Feb 23 20:00:57 2000 @@ -35,6 +35,7 @@ #include #include #include +#include #include #include @@ -371,6 +372,14 @@ case IPV6_FLOWLABEL_MGR: retv = ipv6_flowlabel_opt(sk, optval, optlen); break; + +#ifdef CONFIG_NETFILTER + default: + retv = nf_setsockopt(sk, PF_INET6, optname, optval, + optlen); + break; +#endif + } release_sock(sk); @@ -450,7 +459,17 @@ break; } default: +#ifdef CONFIG_NETFILTER + lock_sock(sk); + val = nf_getsockopt(sk, PF_INET6, optname, optval, + &len); + release_sock(sk); + if (val >= 0) + val = put_user(len, optlen); + return val; +#else return -EINVAL; +#endif } len=min(sizeof(int),len); if(put_user(len, optlen)) diff -ur ../vger3-000223/linux/net/ipv6/raw.c linux/net/ipv6/raw.c --- ../vger3-000223/linux/net/ipv6/raw.c Tue Jan 18 22:57:10 2000 +++ linux/net/ipv6/raw.c Thu Feb 24 22:26:53 2000 @@ -9,6 +9,9 @@ * * $Id: raw.c,v 1.33 2000/01/18 08:24:22 davem Exp $ * + * Fixes: + * Hideaki YOSHIFUJI : sin6_scope_id support + * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version @@ -183,9 +186,8 @@ int addr_type; int err; - if (addr_len < sizeof(struct sockaddr_in6)) + if (addr_len < SIN6_LEN_RFC2133) return -EINVAL; - addr_type = ipv6_addr_type(&addr->sin6_addr); /* Raw sockets are IPv6 only */ @@ -198,6 +200,20 @@ if (sk->state != TCP_CLOSE) goto out; + if (addr_type & IPV6_ADDR_LINKLOCAL) { + if (addr_len >= sizeof(struct sockaddr_in6) && + addr->sin6_scope_id) { + /* Override any existing binding, if another one + * is supplied by user. + */ + sk->bound_dev_if = addr->sin6_scope_id; + } + + /* Binding to link-local address requires an interface */ + if (sk->bound_dev_if == 0) + goto out; + } + /* Check if the address belongs to the host. */ if (addr_type != IPV6_ADDR_ANY) { /* ipv4 addr of the socket is invalid. Only the @@ -325,6 +341,11 @@ memcpy(&sin6->sin6_addr, &skb->nh.ipv6h->saddr, sizeof(struct in6_addr)); sin6->sin6_flowinfo = 0; + sin6->sin6_scope_id = 0; + if (ipv6_addr_type(&sin6->sin6_addr) & IPV6_ADDR_LINKLOCAL) { + struct inet6_skb_parm *opt = (struct inet6_skb_parm *) skb->cb; + sin6->sin6_scope_id = opt->iif; + } } if (sk->net_pinfo.af_inet6.rxopt.all) @@ -429,14 +450,15 @@ */ fl.fl6_flowlabel = 0; + fl.oif = 0; if (sin6) { - if (addr_len < sizeof(struct sockaddr_in6)) - return(-EINVAL); + if (addr_len < SIN6_LEN_RFC2133) + return -EINVAL; if (sin6->sin6_family && sin6->sin6_family != AF_INET6) return(-EINVAL); - + /* port is the proto value [0..255] carried in nexthdr */ proto = ntohs(sin6->sin6_port); @@ -457,11 +479,15 @@ } } - /* Otherwise it will be difficult to maintain sk->dst_cache. */ if (sk->state == TCP_ESTABLISHED && !ipv6_addr_cmp(daddr, &sk->net_pinfo.af_inet6.daddr)) daddr = &sk->net_pinfo.af_inet6.daddr; + + if (addr_len >= sizeof(struct sockaddr_in6) && + sin6->sin6_scope_id && + ipv6_addr_type(daddr)&IPV6_ADDR_LINKLOCAL) + fl.oif = sin6->sin6_scope_id; } else { if (sk->state != TCP_ESTABLISHED) return(-EINVAL); @@ -479,7 +505,8 @@ return(-EINVAL); } - fl.oif = sk->bound_dev_if; + if (fl.oif == 0) + fl.oif = sk->bound_dev_if; fl.fl6_src = NULL; if (msg->msg_controllen) { diff -ur ../vger3-000223/linux/net/ipv6/tcp_ipv6.c linux/net/ipv6/tcp_ipv6.c --- ../vger3-000223/linux/net/ipv6/tcp_ipv6.c Tue Feb 1 22:16:24 2000 +++ linux/net/ipv6/tcp_ipv6.c Thu Feb 24 22:07:19 2000 @@ -12,6 +12,9 @@ * linux/net/ipv4/tcp_input.c * linux/net/ipv4/tcp_output.c * + * Fixes: + * Hideaki YOSHIFUJI : sin6_scope_id support + * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version @@ -509,8 +512,8 @@ int addr_type; int err; - if (addr_len < sizeof(struct sockaddr_in6)) - return(-EINVAL); + if (addr_len < SIN6_LEN_RFC2133) + return -EINVAL; if (usin->sin6_family != AF_INET6) return(-EAFNOSUPPORT); @@ -540,6 +543,24 @@ if(addr_type & IPV6_ADDR_MULTICAST) return -ENETUNREACH; + if (addr_type&IPV6_ADDR_LINKLOCAL) { + if (addr_len >= sizeof(struct sockaddr_in6) && + usin->sin6_scope_id) { + /* If interface is set while binding, indices + * must coincide. + */ + if (sk->bound_dev_if && + sk->bound_dev_if != usin->sin6_scope_id) + return -EINVAL; + + sk->bound_dev_if = usin->sin6_scope_id; + } + + /* Connect to link-local address requires an interface */ + if (sk->bound_dev_if == 0) + return -EINVAL; + } + if (tp->ts_recent_stamp && ipv6_addr_cmp(&np->daddr, &usin->sin6_addr)) { tp->ts_recent = 0; tp->ts_recent_stamp = 0; @@ -605,15 +626,6 @@ goto failure; } - if (fl.oif == 0 && addr_type&IPV6_ADDR_LINKLOCAL) { - /* Ough! This guy tries to connect to link local - * address and did not specify interface. - * Actually we should kick him out, but - * we will be patient :) --ANK - */ - sk->bound_dev_if = dst->dev->ifindex; - } - ip6_dst_store(sk, dst, NULL); if (saddr == NULL) { @@ -1723,6 +1735,9 @@ sin6->sin6_port = sk->dport; /* We do not store received flowlabel for TCP */ sin6->sin6_flowinfo = 0; + sin6->sin6_scope_id = 0; + if (sk->bound_dev_if && ipv6_addr_type(&sin6->sin6_addr)&IPV6_ADDR_LINKLOCAL) + sin6->sin6_scope_id = sk->bound_dev_if; } static int tcp_v6_remember_stamp(struct sock *sk) diff -ur ../vger3-000223/linux/net/ipv6/udp.c linux/net/ipv6/udp.c --- ../vger3-000223/linux/net/ipv6/udp.c Tue Jan 18 22:57:13 2000 +++ linux/net/ipv6/udp.c Thu Feb 24 22:07:18 2000 @@ -9,6 +9,9 @@ * * $Id: udp.c,v 1.50 2000/01/18 08:24:24 davem Exp $ * + * Fixes: + * Hideaki YOSHIFUJI : sin6_scope_id support + * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version @@ -218,7 +221,7 @@ goto ipv4_connected; } - if (addr_len < sizeof(*usin)) + if (addr_len < SIN6_LEN_RFC2133) return -EINVAL; if (usin->sin6_family != AF_INET6) @@ -278,6 +281,21 @@ return 0; } + if (addr_type&IPV6_ADDR_LINKLOCAL) { + if (addr_len >= sizeof(struct sockaddr_in6) && + usin->sin6_scope_id) { + if (sk->bound_dev_if && sk->bound_dev_if != usin->sin6_scope_id) { + fl6_sock_release(flowlabel); + return -EINVAL; + } + sk->bound_dev_if = usin->sin6_scope_id; + } + + /* Connect to link-local address requires an interface */ + if (sk->bound_dev_if == 0) + return -EINVAL; + } + ipv6_addr_copy(&np->daddr, daddr); np->flow_label = fl.fl6_flowlabel; @@ -392,6 +410,7 @@ sin6->sin6_family = AF_INET6; sin6->sin6_port = skb->h.uh->source; sin6->sin6_flowinfo = 0; + sin6->sin6_scope_id = 0; if (skb->protocol == __constant_htons(ETH_P_IP)) { ipv6_addr_set(&sin6->sin6_addr, 0, 0, @@ -404,6 +423,10 @@ if (sk->net_pinfo.af_inet6.rxopt.all) datagram_recv_ctl(sk, msg, skb); + if (ipv6_addr_type(&sin6->sin6_addr) & IPV6_ADDR_LINKLOCAL) { + struct inet6_skb_parm *opt = (struct inet6_skb_parm *) skb->cb; + sin6->sin6_scope_id = opt->iif; + } } } err = copied; @@ -746,12 +769,13 @@ return -EMSGSIZE; fl.fl6_flowlabel = 0; + fl.oif = 0; if (sin6) { if (sin6->sin6_family == AF_INET) return udp_sendmsg(sk, msg, ulen); - if (addr_len < sizeof(*sin6)) + if (addr_len < SIN6_LEN_RFC2133) return -EINVAL; if (sin6->sin6_family && sin6->sin6_family != AF_INET6) @@ -777,6 +801,11 @@ if (sk->state == TCP_ESTABLISHED && !ipv6_addr_cmp(daddr, &sk->net_pinfo.af_inet6.daddr)) daddr = &sk->net_pinfo.af_inet6.daddr; + + if (addr_len >= sizeof(struct sockaddr_in6) && + sin6->sin6_scope_id && + ipv6_addr_type(daddr)&IPV6_ADDR_LINKLOCAL) + fl.oif = sin6->sin6_scope_id; } else { if (sk->state != TCP_ESTABLISHED) return -ENOTCONN; @@ -802,7 +831,8 @@ } udh.daddr = NULL; - fl.oif = sk->bound_dev_if; + if (!fl.oif) + fl.oif = sk->bound_dev_if; fl.fl6_src = NULL; if (msg->msg_controllen) { From owner-netdev@oss.sgi.com Fri Feb 25 13:22:18 2000 Received: by oss.sgi.com id ; Fri, 25 Feb 2000 13:21:58 -0800 Received: from lore.mcnc.org ([152.45.4.102]:25618 "EHLO lore.mcnc.org") by oss.sgi.com with ESMTP id ; Fri, 25 Feb 2000 13:21:52 -0800 Received: from anr.mcnc.org (localhost [127.0.0.1]) by lore.mcnc.org (8.8.7/8.8.7) with ESMTP id QAA25347; Fri, 25 Feb 2000 16:23:33 -0500 Message-ID: <38B6F2D5.2B757236@anr.mcnc.org> Date: Fri, 25 Feb 2000 16:23:33 -0500 From: Ilia Baldine Organization: MCNC ANR X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: divert@riffraff.mcnc.org, "netdev@oss.sgi.com" Subject: Divert sockets for Linux 2.2.12 Content-Type: multipart/alternative; boundary="------------0C1AD684F9B8552589E21CC4" Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing --------------0C1AD684F9B8552589E21CC4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, This is an announcement of FreeBSD divert sockets now available for Linux 2.2.12 (together with modified ipchains-1.3.9). Please visit http://www.anr.mcnc.org/~divert Latest available release is 1.0.4. Anything before that should be considered beta. Divert sockets let you bring packets to user space and selectively reinject them in any direction (inbound, outbound,forward) based on firewall rule selection. Whatever the firewall can filter out you can bring to user space. Unlike the raw sockets, with divert sockets you get the actual packet, not its copy, so if you do not reinject it - its intended recepient will not see it. For more questions please read the HOWTO available at the same URL. -ilia PS An older version for Linux 2.0.36 is also available. -- -------------------------------------+---------------------- Ilia Baldine | ibaldin@anr.mcnc.org Network Research Engineer, | ph#:(919)248-1847 Advanced Networking Research, MCNC | FAX:(919)248-1455 -------------------------------------+---------------------- "We demand rigidly defined areas of doubt and uncertainty!" -- Vroomfondel ------------------------------------------------------------ --------------0C1AD684F9B8552589E21CC4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

This is an announcement of FreeBSD divert sockets now available
for Linux 2.2.12 (together with modified ipchains-1.3.9). Please
visit

http://www.anr.mcnc.org/~divert

Latest available release is 1.0.4. Anything before that should be
considered beta.

Divert sockets let you bring packets to user space and selectively
reinject them in any direction (inbound, outbound,forward) based
on firewall rule selection. Whatever the firewall can filter out
you can bring to user space.

Unlike the raw sockets, with divert sockets you get the actual packet,
not its copy, so if you do not reinject it - its intended recepient will
not see it.

For more questions please read the HOWTO available at the same
URL.

-ilia 

PS An older version for Linux 2.0.36 is also
available.
-- 
-------------------------------------+----------------------
Ilia Baldine                         | ibaldin@anr.mcnc.org
Network Research Engineer,           | ph#:(919)248-1847
Advanced Networking Research, MCNC   | FAX:(919)248-1455
-------------------------------------+----------------------
"We demand rigidly defined areas of doubt and uncertainty!"
                -- Vroomfondel
------------------------------------------------------------
  --------------0C1AD684F9B8552589E21CC4-- From owner-netdev@oss.sgi.com Fri Feb 25 18:32:50 2000 Received: by oss.sgi.com id ; Fri, 25 Feb 2000 18:32:40 -0800 Received: from [202.102.223.33] ([202.102.223.33]:11358 "EHLO mx1.ustc.edu.cn") by oss.sgi.com with ESMTP id ; Fri, 25 Feb 2000 18:32:24 -0800 Received: from ustc.edu.cn (hpe25.nic.ustc.edu.cn [202.38.64.1]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id KAA17396 for ; Sat, 26 Feb 2000 10:53:00 -0800 Received: from mail.ustc.edu.cn by ustc.edu.cn with SMTP (8.6.10/16.2) id KAA05618; Sat, 26 Feb 2000 10:36:15 +0800 Received: (qmail 26739 invoked by uid 6110); 26 Feb 2000 02:33:46 -0000 Date: Sat, 26 Feb 2000 10:33:46 +0800 (CST) From: Ji Xiang To: netdev@oss.sgi.com Subject: How Flow Labels be used? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi, I want to use flow label for something.Can anyone tell me how to get use of it in linux kernel 2.2.x or give me some information of how flow label is used yet. Thanks, Xiang Ji From owner-netdev@oss.sgi.com Fri Feb 25 21:07:11 2000 Received: by oss.sgi.com id ; Fri, 25 Feb 2000 21:07:01 -0800 Received: from coconut.itojun.org ([210.160.95.97]:47826 "EHLO coconut.itojun.org") by oss.sgi.com with ESMTP id ; Fri, 25 Feb 2000 21:06:40 -0800 Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id OAA16136; Sat, 26 Feb 2000 14:06:13 +0900 (JST) To: Arkadiusz Miskiewicz cc: netdev@oss.sgi.com, core@kame.net In-reply-to: misiek's message of Wed, 23 Feb 2000 18:10:35 +0100. <20000223181035.A637@admin.misiek.eu.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: SIOCGIFCONF and IPv6 addresses From: itojun@iijlab.net Date: Sat, 26 Feb 2000 14:06:13 +0900 Message-ID: <16134.951541573@coconut.itojun.org> Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >> I would prefer KAME way, no matter, what is it. 8). >itojun please send information how on KAME SIOCGIFCONF >ioctl() returns ipv6 adresses (how it's done with struct ifreq ?) etc ... fine, this is a bit long story... In summary, - BSD SIOCGIFCONF has alignment issue already - KAME SIOCGIFCONF is natural extension to BSD SIOCGIFCONF, which returns sockaddr_in6 - Solaris8 defined SIOCG*L*IFCONF separately from SIOCGIFCONF. - KAME and *BSD (well, OpenBSD/NetBSD/BSDI at this moment), will switch to use getifaddrs(3). getifaddrs uses sysctl internally to get list of addresses configured. do linux have sysctl(NET_RT_IFLIST)? - KAME and *BSD may supply SIOCGLIFCONF as extra interface, if it gets very popular. And my recommendation to linux camp is: - include getifaddrs into libc. - if you have sysctl(RT_NET_IFLIST): - use sysctl(RT_NET_IFLIST) as backend of getifaddrs. - may implement SIOCGLIFCONF as extra interface. - if you do not have sysctl(RT_NET_IFLIST): - implement SIOCGLIFCONF. use it as backend of getifaddrs. getifaddrs implementation is included in BSDI4. It is redistributable (BSDI folks put normal BSD license on it). If you have trouble getting the code, I can send one. itojun BSD SIOCGIFCONF =============== structure definition is like this. we pass pointer struct ifconf to SIOCGIFCONF, pointing a buffer memory region. buffer memory region will be filled by ifreq (packed structs). struct ifconf { int ifc_len; /* size of associated buffer */ union { caddr_t ifcu_buf; struct ifreq *ifcu_req; } ifc_ifcu; #define ifc_buf ifc_ifcu.ifcu_buf /* buffer address */ #define ifc_req ifc_ifcu.ifcu_req /* array of structures returned */ }; struct ifreq { char ifr_name[IFNAMSIZ]; /* if name, e.g. "en0" */ union { struct sockaddr ifru_addr; /* other members omitted */ } ifr_ifru; #define ifr_addr ifr_ifru.ifru_addr /* address */ }; packed ifreq will look like this, regardless from architectures (since it is packed, there will be no padding) --- ifr_name 16bytes/"ne0" ifru_addr 16bytes/sockaddr_in for 10.1.1.1 ifr_name 16bytes/"ne1" ifru_addr 16bytes/sockaddr_in for 10.1.1.2 ifr_name 16bytes/"lo0" ifru_addr 16bytes/sockaddr_in for 127.0.0.1 --- Since introduction of AF_LINK (sockaddr_dl - somewhere between 4.3 and 4.4?), we see items larger than sizeof(sockaddr) attached to ifru_addr. The rule is: - if item in ifru_addr is smaller than sizeof(sockaddr), we pad them by sizeof(sockaddr). - if item in ifru_addr is larger, consult sa_len. So, it will look like this: --- ifr_name 16bytes/"ne0" ifru_addr 16bytes/sockaddr_in for 10.1.1.1 ifr_name 16bytes/"ne1" ifru_addr 30bytes/sockaddr_dl, sa_len = 30 ifr_name 16bytes/"lo0" ifru_addr 16bytes/sockaddr_in for 127.0.0.1 --- The API can break alignment constraint on picky architecutures. For example, in the above "lo0" is from address (start + 78), which is not multiple of 8. we'll see panic if we point this packed struct with aligned-to-8 pointer. Luckily, we see very few sockaddr_dl that violates boundary. Most of existing userland appliation can cope with ifru_addr larger than sizeof(sockaddr) - they properly check sa_len. Most of them, however, are unable to cope with unaligned data access in packed struct. KAME SIOCGIFCONF ================ KAME SIOCGIFCONF is natural extension to BSD SIOCGIFCONF. we include sockaddr_in6 into results whenever necessary. We can skip over larger sockaddrs by using sa_len, just like AF_LINK. --- ifr_name 16bytes/"ne0" ifru_addr 16bytes/sockaddr_in for 10.1.1.1 ifr_name 16bytes/"lo0" ifru_addr 28bytes/sockaddr_in6, for ::1, sa_len = 28, ifr_name 16bytes/"lo0" ifru_addr 16bytes/sockaddr_in for 127.0.0.1 --- This comes with alignment problems, however, this is not us introduced boundary issues. This was BSD 4.3/4.4 which introduced boundary issues. NOTE: we don't promote this. We promote getifaddrs since SIOCGIFCONF is too hard for normal users to use correctly. Solaris SIOCGLIFCONF ==================== Solaris has no sa_len, and they are using SIOCGIFCONF without sa_len (i.e. no AF_LINK). it never return ifru_addr bigger than sizeof(sockaddr). To return sockaddr_in6, Solaris8 includes SIOCG*L*IFCONF (stars are not part of the name, of course). This is defined like this: struct lifreq { char lifr_name[LIFNAMSIZ]; /* if name, e.g. "en0" */ union { int lifru_addrlen; /* for subnet/token etc */ /* other members omitted } lifr_lifru1; #define lifr_addrlen lifr_lifru1.lifru_addrlen int32_t __lifr_pad0; /* pad - sockaddr_storage used */ union { struct sockaddr_storage lifru_addr; /* other members omitted */ } lifr_lifru; #define lifr_addr lifr_lifru.lifru_addr /* address */ }; Since this API uses sockaddr_storage, it will not raise alignment issues. They define padding constraint differently between 64bit API and 32bit API, so please consult Solaris 8 headers for complete definitions. From owner-netdev@oss.sgi.com Sat Feb 26 10:23:37 2000 Received: by oss.sgi.com id ; Sat, 26 Feb 2000 10:23:27 -0800 Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:59918 "EHLO grok.myip.org") by oss.sgi.com with ESMTP id ; Sat, 26 Feb 2000 10:23:00 -0800 Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1]) by grok.myip.org (8.9.3/8.9.3) with ESMTP id LAA01560; Sat, 26 Feb 2000 11:47:07 -0700 Message-ID: <38B81FAA.9CB62163@candelatech.com> Date: Sat, 26 Feb 2000 11:47:06 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: "netdev@oss.sgi.com" , VLAN Mailing List Subject: How to know the ethernet LINK is down. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing I'm working on adding link-aggregation to VLANs and I want to be able to detect if a link is down (cable pulled, dead NIC, dead remote NIC...) Obviously, some errors will not be detectable. Right now, I'm planning on testing the ethernet netdevice->flags to see if IFF_UP is set. Will this do what I want? Are there other things I can check? Thanks, Ben -- Ben Greear (greearb@candelatech.com) http://scry.wanfear.com/~greear Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL) http://scry.wanfear.com From owner-netdev@oss.sgi.com Sat Feb 26 15:46:48 2000 Received: by oss.sgi.com id ; Sat, 26 Feb 2000 15:46:38 -0800 Received: from 99.arlington-10-15rs.va.dial-access.att.net ([12.78.181.99]:14854 "EHLO kanako.v6.linux.or.jp") by oss.sgi.com with ESMTP id ; Sat, 26 Feb 2000 15:46:11 -0800 Received: from localhost (IDENT:sekiya@LOCALHOST [::ffff:127.0.0.1] (may be forged)) by kanako.v6.linux.or.jp (8.9.3+3.1W/3.3Wb4) with ESMTP id IAA02572; Sun, 27 Feb 2000 08:45:12 +0900 Date: Sun, 27 Feb 2000 08:45:05 +0900 Message-ID: From: Yuji Sekiya To: kuznet@ms2.inr.ac.ru Cc: yoshfuji@ecei.tohoku.ac.jp, misiek@pld.org.pl, netdev@oss.sgi.com Subject: Re: sin6_scope_id (Re: SIOCGIFCONF and IPv6 addresses) In-Reply-To: In your message of "Fri, 25 Feb 2000 17:29:41 +0300 (MSK)" <200002251429.RAA29360@ms2.inr.ac.ru> References: <200002251429.RAA29360@ms2.inr.ac.ru> User-Agent: Wanderlust/2.2.18 (Please Forgive Me) EMIKO/1.13.11 (Euglena viridis) CLIME/1.13.6 (=?ISO-2022-JP?B?GyRCQ2YlTj4xGyhC?=) MULE XEmacs/21.2 (beta19) (Shinjuku) (i586-pc-linux) Organization: Information Sciences Institute MIME-Version: 1.0 (generated by EMIKO 1.13.11 - "Euglena viridis") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 990604(IM116) Lines: 21 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >>>>> In <200002251429.RAA29360@ms2.inr.ac.ru> >>>>> kuznet@ms2.inr.ac.ru wrote: Hello, > I append reworked patch. It is preliminary version. > Please, check and comment, if you find something wrong. Thanks !! We are very pleased at your help. It seems good for me at a glance. We will survey and check it at detail and make a report to you. Thanks again. --- SEKIYA Yuji USC/ISI Computer Networks Division 7 From owner-netdev@oss.sgi.com Sat Feb 26 16:03:28 2000 Received: by oss.sgi.com id ; Sat, 26 Feb 2000 16:03:18 -0800 Received: from laurin.munich.netsurf.de ([194.64.166.1]:1023 "EHLO laurin.munich.netsurf.de") by oss.sgi.com with ESMTP id ; Sat, 26 Feb 2000 16:03:04 -0800 Received: from fred.muc.de (none@ns1213.munich.netsurf.de [195.180.235.213]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id BAA27083; Sun, 27 Feb 2000 01:02:54 +0100 (MET) Received: from andi by fred.muc.de with local (Exim 2.05 #1) id 12OrCq-0002Wh-00; Sun, 27 Feb 2000 01:05:04 +0100 Date: Sun, 27 Feb 2000 01:05:03 +0100 From: Andi Kleen To: Ben Greear Cc: "netdev@oss.sgi.com" , VLAN Mailing List Subject: Re: How to know the ethernet LINK is down. Message-ID: <20000227010503.A9701@fred.muc.de> References: <38B81FAA.9CB62163@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <38B81FAA.9CB62163@candelatech.com>; from Ben Greear on Sat, Feb 26, 2000 at 07:24:39PM +0100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Sat, Feb 26, 2000 at 07:24:39PM +0100, Ben Greear wrote: > I'm working on adding link-aggregation to VLANs and I want > to be able to detect if a link is down (cable pulled, dead > NIC, dead remote NIC...) Obviously, some errors will > not be detectable. Are you planning to implement LACP ? > > Right now, I'm planning on testing the ethernet netdevice->flags to see > if IFF_UP is set. Will this do what I want? Are there other things > I can check? No, it won't, except on some broken drivers like the 3c90x. Linux really has no generic interface for this, it is all driver specific (and some drivers don't notice at all except on timeouts). The cleanest way would be to change all the drivers to raise NETDEV_GOING_DOWN events on netdev_chain when they detect link loss or too many timeouts. -Andi -- This is like TV. I don't like TV. From owner-netdev@oss.sgi.com Sat Feb 26 16:47:19 2000 Received: by oss.sgi.com id ; Sat, 26 Feb 2000 16:47:09 -0800 Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:7173 "EHLO grok.myip.org") by oss.sgi.com with ESMTP id ; Sat, 26 Feb 2000 16:46:48 -0800 Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1]) by grok.myip.org (8.9.3/8.9.3) with ESMTP id SAA07819 for ; Sat, 26 Feb 2000 18:09:41 -0700 Message-ID: <38B87955.B545160A@candelatech.com> Date: Sat, 26 Feb 2000 18:09:41 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: "netdev@oss.sgi.com" Subject: Setting MAC addr on ethernet cards? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing I took a peek at the rtl and tulip drivers, and neither implement the ability to set the MAC address. (ifconfig shows the MAC is set, but the card won't accept the pkts unless it's in promisc mode.) Was this not implemented in these drivers because the hardware doesn't support it, or just because the coders didn't get around to it? If it's the latter, anyone wanna volunteer a patch? :) -- Ben Greear (greearb@candelatech.com) http://scry.wanfear.com/~greear Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL) http://scry.wanfear.com From owner-netdev@oss.sgi.com Sat Feb 26 18:22:09 2000 Received: by oss.sgi.com id ; Sat, 26 Feb 2000 18:22:00 -0800 Received: from adsl-216-103-211-230.dsl.snfc21.pacbell.net ([216.103.211.230]:25614 "EHLO xidus.net") by oss.sgi.com with ESMTP id ; Sat, 26 Feb 2000 18:21:44 -0800 Received: from bork.weath (bork [192.129.100.107]) by xidus.net (8.9.3/8.9.3) with ESMTP id SAA25736; Sat, 26 Feb 2000 18:21:36 -0800 Date: Sat, 26 Feb 2000 18:22:15 -0800 (PST) From: Jeremy Weatherford X-Sender: xidus@bork.weath To: Ben Greear cc: "netdev@oss.sgi.com" Subject: Re: Setting MAC addr on ethernet cards? In-Reply-To: <38B87955.B545160A@candelatech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing I'll admit being ignorant of higher-level cards, but to my knowledge, MAC addresses are fixed, like a serial number, on the network card. Having the ability to pick your MAC address on a local LAN would cause the same problems as putting your card into promiscuous mode -- you could intercept traffic intended for other machines. I really don't see this as being likely. Thus, I'm almost certain that the cards these drivers support don't allow anything like this. I can't promise that for higher-end cards, though. Jeremy Weatherford xidus@xidus.net http://xidus.net On Sat, 26 Feb 2000, Ben Greear wrote: > I took a peek at the rtl and tulip drivers, and neither implement > the ability to set the MAC address. (ifconfig shows the MAC is > set, but the card won't accept the pkts unless it's in promisc mode.) > > Was this not implemented in these drivers because the hardware > doesn't support it, or just because the coders didn't get around > to it? > > If it's the latter, anyone wanna volunteer a patch? :) > > -- > Ben Greear (greearb@candelatech.com) http://scry.wanfear.com/~greear > Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL) > http://scry.wanfear.com > From owner-netdev@oss.sgi.com Sun Feb 27 03:29:22 2000 Received: by oss.sgi.com id ; Sun, 27 Feb 2000 03:29:12 -0800 Received: from populo.vip.fi ([194.197.215.5]:60266 "EHLO populo.vip.fi") by oss.sgi.com with ESMTP id ; Sun, 27 Feb 2000 03:28:45 -0800 Received: from localhost (viha@localhost) by populo.vip.fi (8.8.8/8.8.5) with ESMTP id NAA29945; Sun, 27 Feb 2000 13:28:36 +0200 Date: Sun, 27 Feb 2000 13:28:36 +0200 (EET) From: Ville To: Jeremy Weatherford cc: "netdev@oss.sgi.com" Subject: Re: Setting MAC addr on ethernet cards? In-Reply-To: Message-ID: X-Importance: This is a low-priority mailbox. X-Feds1: Are you telling me it wasn't just paranoia? X-Feds2: Darn. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Sat, 26 Feb 2000, Jeremy Weatherford wrote: > Having the ability to pick your MAC address on a local LAN would cause the > same problems as putting your card into promiscuous mode -- you could > intercept traffic intended for other machines. I really don't see this as > being likely. I'm not quite familiar with the details, but isn't this very much needed functionality to put up working 'backup' servers to take over all of a high-priority server's tasks when it goes down? [setting MAC's] This is one of the reasons people should not use MAC-addresses as a way of fool-proof box/card-identification, especially when it comes to copy- protecting software or trusting the source. Most NICs do allow it being altered (I'm not familiar with the one mentioned in the earlier posting, though). AFAIR usually the command is ~ # ifconfig eth0 hw ether 00:00:00:00:00:01 # > Jeremy Weatherford -- Ville(viha@cryptlink.net); From owner-netdev@oss.sgi.com Sun Feb 27 03:35:12 2000 Received: by oss.sgi.com id ; Sun, 27 Feb 2000 03:35:02 -0800 Received: from tazenda.demon.co.uk ([158.152.220.239]:25348 "EHLO kings-cross.london.uk.eu.org") by oss.sgi.com with ESMTP id ; Sun, 27 Feb 2000 03:35:01 -0800 Received: from localhost ([::ffff:127.0.0.1] helo=kings-cross.london.uk.eu.org ident=phil) by kings-cross.london.uk.eu.org with esmtp (Exim 3.11 #1) id 12P1r1-0004DF-00; Sun, 27 Feb 2000 11:27:15 +0000 X-Mailer: exmh version 2.0.2 2/24/98 (debian) To: Ben Greear cc: "netdev@oss.sgi.com" Subject: Re: Setting MAC addr on ethernet cards? In-Reply-To: Message from Ben Greear of "Sat, 26 Feb 2000 18:09:41 MST." <38B87955.B545160A@candelatech.com> References: <38B87955.B545160A@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 27 Feb 2000 11:27:15 +0000 From: Philip Blundell Message-Id: Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >Was this not implemented in these drivers because the hardware >doesn't support it, or just because the coders didn't get around >to it? The latter. Virtually all cards allow you to set the MAC address; the Tulip and RTL8319 certainly do. >If it's the latter, anyone wanna volunteer a patch? :) Well, the API is a little sketchy at the moment. There is a dev-> set_mac_address method in the device structure, which is what ifconfig uses. Currently this is initialised to `eth_mac_addr', which copies the new MAC address into dev->dev_addr (so it will be used on outgoing frames) but doesn't call the driver to actually reconfigure the receive filter. The thing to do, probably, is have the driver override dev->set_mac_address to point to a new function of its own which does both of these tasks. You can copy eth_mac_addr's code; it's in drivers/net/net_init.c. The code to actually change the hardware settings can be cribbed from the driver's `open' method for both the cards you mentioned. p. From owner-netdev@oss.sgi.com Sun Feb 27 04:31:42 2000 Received: by oss.sgi.com id ; Sun, 27 Feb 2000 04:31:32 -0800 Received: from quechua.inka.de ([212.227.14.2]:32046 "EHLO mail.inka.de") by oss.sgi.com with ESMTP id ; Sun, 27 Feb 2000 04:31:14 -0800 Received: from dungeon.inka.de by mail.inka.de with uucp (rmailwrap 0.4) id 12P2qi-00007C-00; Sun, 27 Feb 2000 13:31:00 +0100 Received: by dungeon.inka.de (Postfix, from userid 1000) id 071E8B787D; Sun, 27 Feb 2000 13:30:39 +0100 (CET) Date: Sun, 27 Feb 2000 13:30:39 +0100 From: Andreas Jellinghaus To: Ji Xiang Cc: netdev@oss.sgi.com Subject: Re: How Flow Labels be used? Message-ID: <20000227133039.A30374@dungeon.inka.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.0.1i In-Reply-To: ; from jixiang@mail.ustc.edu.cn on Sat, Feb 26, 2000 at 10:33:46AM +0800 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing documentation on flow labels is on of alexey´s pacvkages. i guess either in iputils or iproute2. both are available at ftp://ftp.funet.fi/pub/mirrors/ftp.inr.ac.ru/ip-routing/ regards, andreas From owner-netdev@oss.sgi.com Sun Feb 27 10:22:43 2000 Received: by oss.sgi.com id ; Sun, 27 Feb 2000 10:22:34 -0800 Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:22532 "EHLO grok.myip.org") by oss.sgi.com with ESMTP id ; Sun, 27 Feb 2000 10:22:22 -0800 Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1]) by grok.myip.org (8.9.3/8.9.3) with ESMTP id LAA14832; Sun, 27 Feb 2000 11:46:27 -0700 Message-ID: <38B97103.D3FCDFFF@candelatech.com> Date: Sun, 27 Feb 2000 11:46:27 -0700 From: Ben Greear Organization: Candela Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: Ville CC: Jeremy Weatherford , "netdev@oss.sgi.com" Subject: Re: Setting MAC addr on ethernet cards? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Ville wrote: > > On Sat, 26 Feb 2000, Jeremy Weatherford wrote: > > > Having the ability to pick your MAC address on a local LAN would cause the > > same problems as putting your card into promiscuous mode -- you could > > intercept traffic intended for other machines. I really don't see this as > > being likely. > > I'm not quite familiar with the details, but isn't this very much needed > functionality to put up working 'backup' servers to take over all of a > high-priority server's tasks when it goes down? [setting MAC's] > > This is one of the reasons people should not use MAC-addresses as a way > of fool-proof box/card-identification, especially when it comes to copy- > protecting software or trusting the source. > > Most NICs do allow it being altered (I'm not familiar with the one > mentioned in the earlier posting, though). > > AFAIR usually the command is ~ > > # ifconfig eth0 hw ether 00:00:00:00:00:01 > # That definately makes it **look** like it was set, but unless the underlying driver does the work to send the bytes out to the card, then you are just in a fuzzy state where your system only works when you are watching it with tcpdump, because it's in promisc mode then! (Don't ask how long it took me to figure **that** little wierdness out!!) :) I would say it's definately very much needed, especially as Linux moves into the world of High Availibility and embedded applications.... Ben -- Ben Greear (greearb@candelatech.com) http://scry.wanfear.com/~greear Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL) http://scry.wanfear.com From owner-netdev@oss.sgi.com Sun Feb 27 15:07:04 2000 Received: by oss.sgi.com id ; Sun, 27 Feb 2000 15:06:54 -0800 Received: from nat-su-33.valinux.com ([198.186.202.33]:9022 "EHLO mail.valinux.com") by oss.sgi.com with ESMTP id ; Sun, 27 Feb 2000 15:06:28 -0800 Received: from tungsten.su.varesearch.com ([10.1.0.74] helo=tungsten.su.valinux.com) by mail.valinux.com with esmtp (Exim 2.12 #6) id 12PClY-0006ey-00; Sun, 27 Feb 2000 15:06:20 -0800 Received: (from rob@localhost) by tungsten.su.valinux.com (8.8.7/8.8.7) id PAA05146; Sun, 27 Feb 2000 15:06:20 -0800 From: Rob Walker MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 27 Feb 2000 15:06:20 -0800 (PST) To: greearb@candelatech.com Cc: viha@vip.fi, xidus@xidus.net, netdev@oss.sgi.com Subject: Re: Setting MAC addr on ethernet cards? In-Reply-To: <38B97103.D3FCDFFF@candelatech.com> References: <38B97103.D3FCDFFF@candelatech.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14521.44497.880846.334396@tungsten.su.valinux.com> Reply-To: rob@valinux.com X-PGP-Fingerprint: CD 3B D7 01 69 A1 DD E3 3E 69 11 23 6D 8E A2 6A Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing >>>>> On Sun, 27 Feb 2000 11:46:27 -0700, Ben Greear >>>>> said: >> AFAIR usually the command is ~ >> >> # ifconfig eth0 hw ether 00:00:00:00:00:01 >> # Ben> That definately makes it **look** like it was set, but unless the Ben> underlying driver does the work to send the bytes out to the Ben> card, then you are just in a fuzzy state where your system only Ben> works when you are watching it with tcpdump, because it's in Ben> promisc mode then! (Don't ask how long it took me to figure Ben> **that** little wierdness out!!) :) Ben> I would say it's definately very much needed, especially as Linux Ben> moves into the world of High Availibility and embedded Ben> applications.... very very much needed. rob From owner-netdev@oss.sgi.com Sun Feb 27 17:36:45 2000 Received: by oss.sgi.com id ; Sun, 27 Feb 2000 17:36:36 -0800 Received: from [202.102.223.33] ([202.102.223.33]:6468 "EHLO mx1.ustc.edu.cn") by oss.sgi.com with ESMTP id ; Sun, 27 Feb 2000 17:36:32 -0800 Received: from ustc.edu.cn (hpe25.nic.ustc.edu.cn [202.38.64.1]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id JAA31424; Mon, 28 Feb 2000 09:56:12 -0800 Received: from tarn.isdn.ustc.edu.cn by ustc.edu.cn with ESMTP (8.6.10/16.2) id JAA04831; Mon, 28 Feb 2000 09:39:56 +0800 Date: Mon, 28 Feb 2000 09:51:55 +0800 (CST) From: Wang Hui X-Sender: hwang@tarn.isdn.ustc.edu.cn To: linux-ipv6@inner.net cc: users@ipv6.org, netdev@oss.sgi.com, becker@cesdis1.gsfc.nasa.gov Subject: bug found on Linux kernel 2.2.13 about ipv6 stack Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi, folks here, We are the IPv6 Tech Research Team,USTC. Our recent study tells a big bug in linux kernel 2.2.13. We have two boxes installed Mandrake Linux 6.1 with the kernel 2.2.13. Each of the boxes has a 100M D-Link NIC, witch is supported by the via-rhine driver carried in the kernel. Each box are implemented the IPv6 stack of course. The two boxes are connected via a 100M optics fibre. After the two boxes boot up, everything goes well. The connection is very good. But after some time, say one or two days, the connection will lost. But if we use the `tcpdump' to see what's going on at this time, the connection will rebuild! We guess that the via-rhine driver has some wrong codes witch will flood the buffer of the 100M NIC. Now we are looking into the source code, and we believe the reason will be found soon. I wonder if there is any patch for this bug already. It will save us a lot of work. :)) Regards, Wang From owner-netdev@oss.sgi.com Sun Feb 27 21:14:29 2000 Received: by oss.sgi.com id ; Sun, 27 Feb 2000 21:14:20 -0800 Received: from dsl-209-162-215-52.easystreet.com ([209.162.215.52]:63750 "EHLO southstation.m5p.com") by oss.sgi.com with ESMTP id ; Sun, 27 Feb 2000 21:14:01 -0800 Received: (from ehem@localhost) by southstation.m5p.com (8.10.0.Beta12/8.10.0.Beta12) id e1S5CCJ04525; Sun, 27 Feb 2000 21:12:12 -0800 (PST) From: Elliott Mitchell Message-Id: <200002280512.e1S5CCJ04525@southstation.m5p.com> Subject: Re: bug found on Linux kernel 2.2.13 about ipv6 stack In-Reply-To: from Wang Hui at "Feb 28, 2000 09:51:55 am" To: Wang Hui Date: Sun, 27 Feb 2000 21:12:12 -0800 (PST) CC: linux-ipv6@inner.net, users@ipv6.org, netdev@oss.sgi.com, becker@cesdis1.gsfc.nasa.gov X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing > From: Wang Hui > We are the IPv6 Tech Research Team,USTC. Our recent study tells > a big bug in linux kernel 2.2.13. > > We have two boxes installed Mandrake Linux 6.1 with the kernel 2.2.13. > Each of the boxes has a 100M D-Link NIC, witch is supported by the > via-rhine driver carried in the kernel. Each box are implemented the > IPv6 stack of course. The two boxes are connected via a 100M optics > fibre. > > After the two boxes boot up, everything goes well. The connection is > very good. But after some time, say one or two days, the connection will > lost. But if we use the `tcpdump' to see what's going on at this time, > the connection will rebuild! We guess that the via-rhine driver has some > wrong codes witch will flood the buffer of the 100M NIC. Now we are > looking into the source code, and we believe the reason will be found > soon. I wonder if there is any patch for this bug already. It will save > us a lot of work. :)) Kernel 2.2.14 perhaps? -- |\__/|\__/|\______ --=> 8-) EHM <=-- ______/|\__/|\__/| \ | | | EHeM@gremlin.m5p.com PGP 8881EF59 | | | / \ \ | ______| -O #include O- |______ | / / \___\_|/82 04 A1 3C C7 B1 37 2A E3 6E 84 DA 97 4C 40 E6\|_/___/ From owner-netdev@oss.sgi.com Sun Feb 27 21:56:20 2000 Received: by oss.sgi.com id ; Sun, 27 Feb 2000 21:56:10 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:44042 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Sun, 27 Feb 2000 21:56:06 -0800 Received: (from paulus@localhost) by front.linuxcare.com.au (8.9.3/8.9.3/Debian 8.9.3-6) id QAA19899; Mon, 28 Feb 2000 16:54:25 +1100 From: Paul Mackerras Organization: Linuxcare, Inc. To: jamal , Michal Ostrowski Subject: PPP generic layer update Date: Mon, 28 Feb 2000 16:38:18 +1100 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain Cc: Mitchell Blank Jr , netdev@oss.sgi.com, axboe@suse.de, Mark Spencer , Andi Kleen , Marc Boucher , Ben LaHaise References: MIME-Version: 1.0 Message-Id: <00022816534900.00976@argo.linuxcare.com.au> Content-Transfer-Encoding: 8bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing I have been hacking on the PPP generic layer with the aim of making it easier to implement ppp channels by removing the requirement that the channel code has to provide read/write/ioctl methods; instead these are provided per-channel in the generic code. Secondarily I have been improving the SMP locking. Currently it works for async ttys on UP systems. There is some kind of deadlock in the SMP locking that I am still chasing, and I haven't updated the sync ppp channel code yet. There is some embryonic multilink code in there but it isn't complete. If you are interested to have a look, the url is: ftp://linuxcare.com.au/pub/ppp/linux-2.3-ppp.patch.gz The `register channel' and `connect channel to ppp interface' functions are now distinct. When a channel is ready to do PPP, it should call register_channel, which now only takes one argument, the address of the ppp_channel structure. Pppd will arrange to do the `connect channel to ppp interface' part via the generic layer. The generic code lets pppd attach an open instance of /dev/ppp to an individual channel and do read/write/ioctl on it. The channel can provide an ioctl function which gets called from the generic layer if it gets an ioctl on an instance of /dev/ppp that is attached to a channel and it doesn't recognize the command. For now, the async tty channel code provides read/write/ioctl by calling compatibility functions in the generic code - this lets pppd-2.3.11 run with the new code. So all the channel code has to do is to call register_channel and unregister_channel at the appropriate times, provide a start_xmit function and optionally an ioctl function, and call ppp_input with received frames. Should be a piece of cake, no? :-) -- Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax paulus@linuxcare.com.au, http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. From owner-netdev@oss.sgi.com Mon Feb 28 05:28:55 2000 Received: by oss.sgi.com id ; Mon, 28 Feb 2000 05:28:45 -0800 Received: from styx.uwaterloo.ca ([129.97.40.10]:58379 "EHLO styx.uwaterloo.ca") by oss.sgi.com with ESMTP id ; Mon, 28 Feb 2000 05:28:40 -0800 Received: (from mostrows@localhost) by styx.uwaterloo.ca (8.9.3/8.9.3) id IAA31512; Mon, 28 Feb 2000 08:28:27 -0500 From: Michal Ostrowski MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14522.30715.522651.676100@styx.uwaterloo.ca> Date: Mon, 28 Feb 2000 08:28:27 -0500 (EST) To: Paul Mackerras Cc: netdev@oss.sgi.com Subject: PPP generic layer update In-Reply-To: <00022816534900.00976@argo.linuxcare.com.au> References: <00022816534900.00976@argo.linuxcare.com.au> X-Mailer: VM 6.72 under 21.1 (patch 4) "Arches" XEmacs Lucid Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing These changes look good .... I get the impression that this may just solve a problem that me and Jamal found yesterday. We would like to be able to kill a channel from within the kernel when we recognize a PPPoE disconnect. With this patch it appears to me that we can do this by unregistering the channel and pppd will be notified of this via /dev/ppp and subsequently close the tty_fd. Is this correct? I'll take this opportunity to mention that I've successfully ported my old pppd hack to use Mitch's pppd patch and it all seems to work quite well. Jamal is currently in the process of incorporating his discovery code into a pppd plugin and so we'll be able to present a PPPoE solution for comments shortly. Michal Ostrowski mostrows@styx.uwaterloo.ca From owner-netdev@oss.sgi.com Mon Feb 28 05:29:04 2000 Received: by oss.sgi.com id ; Mon, 28 Feb 2000 05:28:55 -0800 Received: from [202.102.223.33] ([202.102.223.33]:44872 "EHLO mx1.ustc.edu.cn") by oss.sgi.com with ESMTP id ; Mon, 28 Feb 2000 05:28:36 -0800 Received: from ustc.edu.cn (hpe25.nic.ustc.edu.cn [202.38.64.1]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id VAA27683 for ; Mon, 28 Feb 2000 21:48:36 -0800 Received: from mail.ustc.edu.cn by ustc.edu.cn with SMTP (8.6.10/16.2) id VAA14756; Mon, 28 Feb 2000 21:32:27 +0800 Received: (qmail 22114 invoked by uid 6110); 28 Feb 2000 13:26:42 -0000 Date: Mon, 28 Feb 2000 21:26:42 +0800 (CST) From: Ji Xiang To: netdev@oss.sgi.com Subject: How to get CBQ algorithm Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi, I'am studying "Class-Based Queueing discipline",but what I have is the source code of Linux Kernel. Can anyone tell me where can I download the document talk about CBQ algorithm. Thanks Xiang Ji From owner-netdev@oss.sgi.com Mon Feb 28 06:11:25 2000 Received: by oss.sgi.com id ; Mon, 28 Feb 2000 06:11:15 -0800 Received: from dibbler.ne.mediaone.net ([24.218.56.247]:34573 "EHLO dibbler.ne.mediaone.net") by oss.sgi.com with ESMTP id ; Mon, 28 Feb 2000 06:11:12 -0800 Received: (from rodrigc@localhost) by dibbler.ne.mediaone.net (8.9.3/8.9.3) id JAA08545 for netdev@oss.sgi.com; Mon, 28 Feb 2000 09:17:34 -0500 Date: Mon, 28 Feb 2000 09:17:34 -0500 From: Craig Rodrigues To: netdev@oss.sgi.com Subject: Re: How to get CBQ algorithm Message-ID: <20000228091734.A8536@mediaone.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us In-Reply-To: ; from jixiang@mail.ustc.edu.cn on Mon, Feb 28, 2000 at 09:26:42PM +0800 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Mon, Feb 28, 2000 at 09:26:42PM +0800, Ji Xiang wrote: > Can anyone tell me where can I download the document talk about > CBQ algorithm. http://www.aciri.org/floyd/cbq.html -- Craig Rodrigues http://www.gis.net/~craigr rodrigc@mediaone.net From owner-netdev@oss.sgi.com Mon Feb 28 09:57:06 2000 Received: by oss.sgi.com id ; Mon, 28 Feb 2000 09:56:56 -0800 Received: from minus.inr.ac.ru ([193.233.7.97]:61448 "HELO ms2.inr.ac.ru") by oss.sgi.com with SMTP id ; Mon, 28 Feb 2000 09:56:36 -0800 Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA17143; Mon, 28 Feb 2000 20:51:19 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200002281751.UAA17143@ms2.inr.ac.ru> Subject: Re: bug found on Linux kernel 2.2.13 about ipv6 stack To: hwang@371.NET (Wang Hui) Date: Mon, 28 Feb 2000 20:51:19 +0300 (MSK) Cc: netdev@oss.sgi.com In-Reply-To: from "Wang Hui" at Feb 28, 0 05:13:18 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Length: 351 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! > very good. But after some time, say one or two days, the connection will > lost. But if we use the `tcpdump' to see what's going on at this time, > the connection will rebuild! Try "tcpdump -p". If this command does not result in magic revival and plain tcpdump does, the problem is surely in the driver, losing multicast filter. Alexey From owner-netdev@oss.sgi.com Mon Feb 28 11:40:37 2000 Received: by oss.sgi.com id ; Mon, 28 Feb 2000 11:40:27 -0800 Received: from 255.255.255.255.in-addr.de ([212.8.197.242]:9770 "HELO 255.255.255.255.in-addr.de") by oss.sgi.com with SMTP id ; Mon, 28 Feb 2000 11:40:01 -0800 Received: (qmail 20886 invoked from network); 28 Feb 2000 19:39:58 -0000 Received: from 1.0.0.127.in-addr.de (HELO pointer.teuto.de) (lmb@212.8.197.180) by mail.in-addr.de with SMTP; 28 Feb 2000 19:39:58 -0000 Received: (from lmb@localhost) by pointer.teuto.de (8.8.7/8.8.7) id UAA31852 for netdev@oss.sgi.com; Mon, 28 Feb 2000 20:39:57 +0100 Date: Mon, 28 Feb 2000 20:39:56 +0100 From: lmb To: netdev@oss.sgi.com Subject: shared-state firewalls/routers Message-ID: <20000228203956.C23998@pointer.teuto.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i X-Ctuhulu: HASTUR Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Good morning, after a (brief) discussion with Alan and rusty, I decided to take this here. Problem: In a HA setting, you want two routers (at least) with a private heartbeat link to eliminate SPOFs. Routing alone is quite easy - if one box fails, take over the IP addresses and continue. (which reminds me we still need VRRP ;) On the other hand, dynamic NAT (masquerading, the LinuxVirtualServer etc) and stateful packet filtering aren't that easy. The firewalls need to share state one way or the other. Alan pointed out that two basic methods exist: 1. share data by passing it around. If you establish a connection, send a notice to the other box to permit it there too etc. (This would best be done from userspace) 2. "share" data by computing it from the connection parameters in a deterministic way. For example: Hashing (src port, src ip, dest port, dest ip) into the port number for n:1 NAT and so on. Basically, 2. has many advantages: it is much faster, robust in case of corrupt data passed around and basically requires no state at all, making DoS attacks more difficult. However. You _can't_ do that in all cases. Corrupt protocols like FTP screw you up, complex load balancing decisions not only based on the IP hdr data may do so as well, other cases can be constructed. I also do not think that passing the data around creates a DoS attack on the private link between the two systems, as long as this link is at least the bandwidth of the external links. I understand 1. gets exceptionally more complex if you allow both systems to be active at the same time. This may not be desirable at the beginning, it may be easier to just have one of the systems as a hot standby, but not passing packets around. a) Take the above, tear it down, and lets have a useful discussion on how this may be done ;) b) Has anyone already started working on such? Sincerely, Lars Marowsky-Brée -- From owner-netdev@oss.sgi.com Mon Feb 28 12:12:46 2000 Received: by oss.sgi.com id ; Mon, 28 Feb 2000 12:12:37 -0800 Received: from kogge.hanse.de ([192.76.134.17]:52740 "EHLO kogge.Hanse.DE") by oss.sgi.com with ESMTP id ; Mon, 28 Feb 2000 12:12:15 -0800 Received: (from uucp@localhost) by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id VAA12583 for netdev@oss.sgi.com; Mon, 28 Feb 2000 21:14:17 +0100 (CET) (envelope-from eis@baty.hanse.de) Received: (from eis@localhost) by baty.hanse.de (8.9.3/8.9.3) id UAA05154; Mon, 28 Feb 2000 20:51:15 +0100 To: netdev@oss.sgi.com Subject: ppp_channel_ops.start_xmit() From: Henner Eisen Date: 28 Feb 2000 20:51:15 +0100 In-Reply-To: Henner Eisen's message of "03 Feb 2000 23:03:17 +0100" Message-ID: Lines: 25 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi, Our large discussion about pppoe/ppp/socket related stuff suddenly ended, I guess everybody was busy with doing softnet changes, but this is done now. I'm now going to try interfacing the X.25 protocol stack to the generic ppp layer (will try to do this in a generic 'ppp over socket' manner). The first question arising was the return logic of ppp_hannel_ops.start_xmit(): struct ppp_channel_ops { /* Send a packet (or multilink fragment) on this channel. Returns 1 if it was accepted, 0 if not. */ int (*start_xmit)(struct ppp_channel *, struct sk_buff *); }; Is there any rationale behind returning 1 on success, 0 on error? Most other kernel functions return 0 on succes and != 0 otherwise. The latter allows to return error codes, which could be evaluated by the caller. It is also constistent with dev->hard_start_xmit() conventions. Is it worthy to change this? Currently, it would be easy because there are only very few drivers who use this. Henner From owner-netdev@oss.sgi.com Mon Feb 28 14:00:18 2000 Received: by oss.sgi.com id ; Mon, 28 Feb 2000 13:59:57 -0800 Received: from MaxCow.borg.com ([205.217.206.188]:10247 "EHLO maxcow.borg.com") by oss.sgi.com with ESMTP id ; Mon, 28 Feb 2000 13:59:35 -0800 Received: from mail.borg.com (mail.borg.com [205.217.206.192]) by maxcow.borg.com (8.9.0/8.8.8) with ESMTP id QAA18420; Mon, 28 Feb 2000 16:59:33 -0500 (EST) Received: from swc (cti-fw2.borg.com [205.217.206.199]) by mail.borg.com (8.9.3/8.9.3) with SMTP id QAA10963; Mon, 28 Feb 2000 16:59:29 -0500 (EST) (envelope-from stu@critical.com) Message-Id: <3.0.6.32.20000228170321.007d6790@mail.borg.com> X-Sender: stu@mail.borg.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 28 Feb 2000 17:03:21 -0500 To: lmb From: Stuart Card Subject: Re: shared-state firewalls/routers Cc: netdev@oss.sgi.com In-Reply-To: <20000228203956.C23998@pointer.teuto.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing At 08:39 PM 2000-02-28 +0100, lmb wrote: >On the other hand, dynamic NAT (masquerading, the LinuxVirtualServer etc) and >stateful packet filtering aren't that easy. The firewalls need to share state >one way or the other. Alan pointed out that two basic methods exist: > >1. share data by passing it around. > If you establish a connection, send a notice to the other box to permit it > there too etc. (This would best be done from userspace) > >2. "share" data by computing it from the connection parameters in a > deterministic way. > > For example: Hashing (src port, src ip, dest port, dest ip) into the port > number for n:1 NAT and so on. There is a third method: have the standby router snoop what the active router did. This requires enough 'intelligence' in the standby to match each packet it sees on the LAN side with the correct corresponding packet on the WAN side. For basic NAT etc. this shouldn't be too hard. The third method has something in common with the second: matching packets requires an understanding of how they _might have been_ transformed by the active router; which is similar to, but slightly easier than, knowing _a priori_ exactly how they _must have been_ transformed (down to specific addresses, port numbers, etc. which are dynamically assigned in what may not be a completely deterministic fashion). The third method also _may_ have something in common with the first: an active router which knows it is being snooped by a standby router, and which wants to be cooperative, might do some things slightly differently, in order to provide more 'hints' to the snooping standby. No, I am _not_ trying anything like this, but am working in several related areas. ------------------------------------------------------------------------ Stuart W. Card, Chief Scientist & Vice-Pres., Critical Technologies Inc. Suite 400 Technology Center, 4th Floor 1001 Broad Street, Utica NY 13501 315-793-0248 FAX -9710 http://www.critical.com From owner-netdev@oss.sgi.com Mon Feb 28 14:06:28 2000 Received: by oss.sgi.com id ; Mon, 28 Feb 2000 14:06:17 -0800 Received: from 255.255.255.255.in-addr.de ([212.8.197.242]:11823 "HELO 255.255.255.255.in-addr.de") by oss.sgi.com with SMTP id ; Mon, 28 Feb 2000 14:06:07 -0800 Received: (qmail 21304 invoked from network); 28 Feb 2000 22:06:02 -0000 Received: from 1.0.0.127.in-addr.de (HELO pointer.teuto.de) (lmb@212.8.197.180) by mail.in-addr.de with SMTP; 28 Feb 2000 22:06:02 -0000 Received: (from lmb@localhost) by pointer.teuto.de (8.8.7/8.8.7) id XAA32519; Mon, 28 Feb 2000 23:06:01 +0100 Date: Mon, 28 Feb 2000 23:06:00 +0100 From: Lars Marowsky-Bree To: Stuart Card Cc: netdev@oss.sgi.com Subject: Re: shared-state firewalls/routers Message-ID: <20000228230600.L23998@pointer.teuto.de> References: <20000228203956.C23998@pointer.teuto.de> <3.0.6.32.20000228170321.007d6790@mail.borg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <3.0.6.32.20000228170321.007d6790@mail.borg.com>; from "Stuart Card" on 2000-02-28T17:03:21 X-Ctuhulu: HASTUR Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On 2000-02-28T17:03:21, Stuart Card said: > There is a third method: have the standby router snoop what the active > router did. Only possible on none switched networks where both routers share the same physical segment (or at least running "port mirroring" on the switch to make both ports appear the same). *considers* This might even work quite easily. The simplest case may even be to configure the switch to mirror both the inside and the outside ports of each box, and toggle IP forwarding as the failover happens. (Ignoring for once that now your switch is the SPOF, but that can probably be taken care of by using two switches linked to eachother) However, you'll need to resynchronise at least once after the failed system restarts, because obviously it missed all the packets in between. Sincerely, Lars Marowsky-Brée -- From owner-netdev@oss.sgi.com Mon Feb 28 14:27:47 2000 Received: by oss.sgi.com id ; Mon, 28 Feb 2000 14:27:38 -0800 Received: from kogge.hanse.de ([192.76.134.17]:12293 "EHLO kogge.Hanse.DE") by oss.sgi.com with ESMTP id ; Mon, 28 Feb 2000 14:27:21 -0800 Received: (from uucp@localhost) by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id XAA16400 for netdev@oss.sgi.com; Mon, 28 Feb 2000 23:29:22 +0100 (CET) (envelope-from eis@baty.hanse.de) Received: (from eis@localhost) by baty.hanse.de (8.9.3/8.9.3) id XAA05947; Mon, 28 Feb 2000 23:21:34 +0100 To: netdev@oss.sgi.com Subject: MSG_EOR flag From: Henner Eisen Date: 28 Feb 2000 23:21:33 +0100 Message-ID: Lines: 14 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hi, somewhere in 2.3.x, sock_write() was changed to call proto_ops.sendmsg() of SOCK_SEQPACK sockets with MSG_EOR flag set (which broke some protocols first). My questions now are: how should the MSG_EOR be used consistently? Should sockets which do not support sending fragments via sendmsg refuse to accept sendmsg without MSG_EOR set? This seems consistent, but can cause compatibility problems with 2.2.x kernels. How should the MSG_EOR flag affect recvmsg()? Henner From owner-netdev@oss.sgi.com Tue Feb 29 00:07:50 2000 Received: by oss.sgi.com id ; Tue, 29 Feb 2000 00:07:41 -0800 Received: from [202.102.223.33] ([202.102.223.33]:49696 "EHLO mx1.ustc.edu.cn") by oss.sgi.com with ESMTP id ; Tue, 29 Feb 2000 00:07:17 -0800 Received: from ustc.edu.cn (hpe25.nic.ustc.edu.cn [202.38.64.1]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id QAA18403; Tue, 29 Feb 2000 16:27:08 -0800 Received: from tarn.isdn.ustc.edu.cn by ustc.edu.cn with ESMTP (8.6.10/16.2) id QAA28454; Tue, 29 Feb 2000 16:11:11 +0800 Date: Tue, 29 Feb 2000 16:23:10 +0800 (CST) From: Wang Hui X-Sender: hwang@tarn.isdn.ustc.edu.cn To: kuznet@ms2.inr.ac.ru cc: netdev@oss.sgi.com Subject: Re: bug found on Linux kernel 2.2.13 about ipv6 stack In-Reply-To: <200002281751.UAA17143@ms2.inr.ac.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing Hello! On Mon, 28 Feb 2000 kuznet@ms2.inr.ac.ru wrote: > Hello! > > > very good. But after some time, say one or two days, the connection will > > lost. But if we use the `tcpdump' to see what's going on at this time, > > the connection will rebuild! > > Try "tcpdump -p". If this command does not result in magic revival > and plain tcpdump does, the problem is surely in the driver, > losing multicast filter. Yes, you got it. :)) When I use `tcpdump -p', connection cannot re-build. Then the problem is surely in the driver. :)) I wonder if the problem is due to a hardware bug or the software bug. any idea? Regards, Wang. From owner-netdev@oss.sgi.com Tue Feb 29 01:37:49 2000 Received: by oss.sgi.com id ; Tue, 29 Feb 2000 01:37:40 -0800 Received: from gw.chygwyn.com ([62.172.158.50]:7428 "EHLO gw.chygwyn.com") by oss.sgi.com with ESMTP id ; Tue, 29 Feb 2000 01:37:22 -0800 Received: (from steve@localhost) by gw.chygwyn.com (8.9.3/8.9.3) id JAA00926; Tue, 29 Feb 2000 09:30:31 GMT From: Steve Whitehouse Message-Id: <200002290930.JAA00926@gw.chygwyn.com> Subject: Re: MSG_EOR flag To: eis@baty.hanse.de (Henner Eisen) Date: Tue, 29 Feb 2000 09:30:31 +0000 (GMT) Cc: netdev@oss.sgi.com In-Reply-To: from "Henner Eisen" at Feb 28, 2000 11:21:33 PM Organization: ChyGywn Limited X-RegisteredOffice: 7, New Yatt Road, Witney, Oxfordshire. OX8 6NU England X-RegisteredNumber: 03887683 Reply-To: Steve Whitehouse X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing > > Hi, > > somewhere in 2.3.x, sock_write() was changed to call proto_ops.sendmsg() of > SOCK_SEQPACK sockets with MSG_EOR flag set (which broke some protocols first). > > My questions now are: how should the MSG_EOR be used consistently? > > Should sockets which do not support sending fragments via sendmsg refuse > to accept sendmsg without MSG_EOR set? This seems consistent, but can cause > compatibility problems with 2.2.x kernels. > > How should the MSG_EOR flag affect recvmsg()? > > Henner > Hi, Guess I should own up since it was I who introduced the change :-) The reason for it was that DECnet needed to be able to use SEQPACKET sockets. In the case where there was not enough buffer space kernel side to be able to copy all the data from user space without blocking (assuming that you'd set O_NONBLOCK on your socket) there had to be a method for userspace to send the data in chunks and put a marker in to tell the kernel when the end of the message segment was. This was the original reason for implementation. The flag is part of the draft POSIX standard, which I followed when updating the code. Basically it works like this... o sendmsg() - MSG_EOR indicates that the data sent is the last in a record. Data in a sendmsg() call must all be part of one record. If the sendmsg() call returns before all the data is sent, then the MSG_EOR is ignored so that the rest of the record may be sent in a later sendmsg() call when more buffer space is available. o recvmsg() - Each call may only return data from a single record. MSG_EOR is returned when the last bit of data from a record is returned. Aside from the above, SOCK_SEQPACKET works like SOCK_STREAM. There was an obvious problem, in that with write() you can't specify any flags, so the implicit MSG_EOR was added so that it could do something vagely sensible without forcing people to use sendmsg() to terminate each record. (POSIX doesn't actually say if write() should have an implicit MSG_EOR or not, it stays slient on the matter) As to what to do when the sockets don't support sending fragments, I'd suggest that they ought to print out a message (suitably rate limited) that the application is an old one and should be updated if it does not set MSG_EOR. This seems to be the usual approach that I've seen elsewhere around the kernel. Its probably also a good idea to update as many applications as possible before this message is added though. btw, are you thinking about AX.25 ? So far as I'm aware its the only other SEQPACKET supporting protocol... Steve. From owner-netdev@oss.sgi.com Tue Feb 29 10:17:17 2000 Received: by oss.sgi.com id ; Tue, 29 Feb 2000 10:17:07 -0800 Received: from ikar.t17.ds.pwr.wroc.pl ([156.17.215.227]:57092 "HELO ikar.t17.ds.pwr.wroc.pl") by oss.sgi.com with SMTP id ; Tue, 29 Feb 2000 10:17:06 -0800 Received: by ikar.t17.ds.pwr.wroc.pl (Postfix, from userid 1002) id 75249C805C; Tue, 29 Feb 2000 19:14:01 +0100 (CET) Date: Tue, 29 Feb 2000 19:14:01 +0100 From: Arkadiusz Miskiewicz To: netdev@oss.sgi.com Subject: Re: SIOCGIFCONF and IPv6 addresses Message-ID: <20000229191401.D20157@admin.misiek.eu.org> References: <20000223181035.A637@admin.misiek.eu.org> <16134.951541573@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <16134.951541573@coconut.itojun.org>; from itojun@iijlab.net on Sat, Feb 26, 2000 at 02:06:13PM +0900 X-URL: http://www.misiek.eu.org X-Operating-System: Linux sunsite 4.0.20 #119 Tue Jan 16 12:21:53 MET 2001 i986 pld Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing On Sat, 26 Feb 2000, itojun@iijlab.net wrote: > >itojun please send information how on KAME SIOCGIFCONF > >ioctl() returns ipv6 adresses (how it's done with struct ifreq ?) etc ... > > fine, this is a bit long story... [...] ANK, and witch one you will prefer/implement ? -- Arkadiusz Mi¶kiewicz http://www.misiek.eu.org/ PLD/Linux [IPv6 enabled] http://www.pld.org.pl/ From owner-netdev@oss.sgi.com Tue Feb 29 19:55:33 2000 Received: by oss.sgi.com id ; Tue, 29 Feb 2000 19:55:24 -0800 Received: from linuxcare.canberra.net.au ([203.29.91.49]:15370 "EHLO front.linuxcare.com.au") by oss.sgi.com with ESMTP id ; Tue, 29 Feb 2000 19:55:09 -0800 Received: from halfway.linuxcare.com.au (penicillin.linuxcare.com.au [10.61.2.27]) by front.linuxcare.com.au (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id OAA26641; Wed, 1 Mar 2000 14:54:59 +1100 X-Authentication-Warning: front.linuxcare.com.au: Host penicillin.linuxcare.com.au [10.61.2.27] claimed to be halfway.linuxcare.com.au Received: from linuxcare.com.au (really [127.0.0.1]) by linuxcare.com.au via in.smtpd with esmtp id (Debian Smail3.2.0.102) for ; Wed, 1 Mar 2000 14:55:32 +1100 (EST) Message-Id: From: Rusty Russell To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [PATCH] Baby Bear: Netfilter merge patch I vs. vger Date: Wed, 01 Mar 2000 14:55:32 +1100 Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing This is JamesM's netfilter queing registration changes. Working on patches II (ct pointer in skb) and III (all the netfilter modules in official tree). Index: include/linux/netfilter.h =================================================================== RCS file: /cvs/linux/linux/include/linux/netfilter.h,v retrieving revision 1.5 diff -u -r1.5 netfilter.h --- include/linux/netfilter.h 1999/12/21 04:00:16 1.5 +++ include/linux/netfilter.h 2000/03/01 03:51:15 @@ -6,6 +6,7 @@ #include #include #include +#include #include #include #endif @@ -39,19 +40,12 @@ const struct net_device *out, int (*okfn)(struct sk_buff *)); -typedef unsigned int nf_cacheflushfn(const void *packet, - const struct net_device *in, - const struct net_device *out, - u_int32_t packetcount, - u_int32_t bytecount); - struct nf_hook_ops { struct list_head list; /* User fills in from here down. */ nf_hookfn *hook; - nf_cacheflushfn *flush; int pf; int hooknum; /* Hooks are ordered in ascending priority. */ @@ -74,6 +68,19 @@ int (*get)(struct sock *sk, int optval, void *user, int *len); }; +/* Each queued (to userspace) skbuff has one of these. */ +struct nf_info +{ + /* The ops struct which sent us to userspace. */ + struct nf_hook_ops *elem; + + /* If we're sent to userspace, this keeps housekeeping info */ + int pf; + unsigned int hook; + struct net_device *indev, *outdev; + int (*okfn)(struct sk_buff *); +}; + /* Function to register/unregister hook points. */ int nf_register_hook(struct nf_hook_ops *reg); void nf_unregister_hook(struct nf_hook_ops *reg); @@ -85,7 +92,7 @@ extern struct list_head nf_hooks[NPROTO][NF_MAX_HOOKS]; -/* Activate hook/flush; either okfn or kfree_skb called, unless a hook +/* Activate hook; either okfn or kfree_skb called, unless a hook returns NF_STOLEN (in which case, it's up to the hook to deal with the consequences). @@ -117,47 +124,20 @@ struct net_device *indev, struct net_device *outdev, int (*okfn)(struct sk_buff *)); -void nf_cacheflush(int pf, unsigned int hook, const void *packet, - const struct net_device *indev, const struct net_device *outdev, - __u32 packetcount, __u32 bytecount); - /* Call setsockopt() */ int nf_setsockopt(struct sock *sk, int pf, int optval, char *opt, int len); int nf_getsockopt(struct sock *sk, int pf, int optval, char *opt, int *len); - -struct nf_wakeme -{ - wait_queue_head_t sleep; - struct sk_buff_head skbq; -}; - -/* For netfilter device. */ -struct nf_interest -{ - struct list_head list; - - int pf; - /* Bitmask of hook numbers to match (1 << hooknum). */ - unsigned int hookmask; - /* If non-zero, only catch packets with this mark. */ - unsigned int mark; - /* If non-zero, only catch packets of this reason. */ - unsigned int reason; - - struct nf_wakeme *wake; -}; -/* For asynchronous packet handling. */ -extern void nf_register_interest(struct nf_interest *interest); -extern void nf_unregister_interest(struct nf_interest *interest); -extern void nf_getinfo(const struct sk_buff *skb, - struct net_device **indev, - struct net_device **outdev, - unsigned long *mark); +/* Packet queuing */ +typedef int (*nf_queue_outfn_t)(struct sk_buff *skb, + struct nf_info *info, void *data); +extern int nf_register_queue_handler(int pf, + nf_queue_outfn_t outfn, void *data); +extern int nf_unregister_queue_handler(int pf); extern void nf_reinject(struct sk_buff *skb, - unsigned long mark, + struct nf_info *info, unsigned int verdict); #ifdef CONFIG_NETFILTER_DEBUG Index: include/linux/netfilter_ipv4.h =================================================================== RCS file: /cvs/linux/linux/include/linux/netfilter_ipv4.h,v retrieving revision 1.4 diff -u -r1.4 netfilter_ipv4.h --- include/linux/netfilter_ipv4.h 1999/11/23 05:44:08 1.4 +++ include/linux/netfilter_ipv4.h 2000/03/01 03:51:16 @@ -51,7 +51,6 @@ #ifdef CONFIG_NETFILTER_DEBUG #ifdef __KERNEL__ -void debug_print_hooks_ip(unsigned int nf_debug); void nf_debug_ip_local_deliver(struct sk_buff *skb); void nf_debug_ip_loopback_xmit(struct sk_buff *newskb); void nf_debug_ip_finish_output2(struct sk_buff *skb); Index: net/netsyms.c =================================================================== RCS file: /cvs/linux/linux/net/netsyms.c,v retrieving revision 1.139 diff -u -r1.139 netsyms.c --- net/netsyms.c 2000/02/27 19:41:08 1.139 +++ net/netsyms.c 2000/03/01 03:51:17 @@ -581,10 +581,9 @@ EXPORT_SYMBOL(nf_unregister_hook); EXPORT_SYMBOL(nf_register_sockopt); EXPORT_SYMBOL(nf_unregister_sockopt); -EXPORT_SYMBOL(nf_getinfo); EXPORT_SYMBOL(nf_reinject); -EXPORT_SYMBOL(nf_register_interest); -EXPORT_SYMBOL(nf_unregister_interest); +EXPORT_SYMBOL(nf_register_queue_handler); +EXPORT_SYMBOL(nf_unregister_queue_handler); EXPORT_SYMBOL(nf_hook_slow); EXPORT_SYMBOL(nf_hooks); #endif Index: net/core/netfilter.c =================================================================== RCS file: /cvs/linux/linux/net/core/netfilter.c,v retrieving revision 1.7 diff -u -r1.7 netfilter.c --- net/core/netfilter.c 1999/12/21 04:04:58 1.7 +++ net/core/netfilter.c 2000/03/01 03:51:17 @@ -5,6 +5,8 @@ * way. * * Rusty Russell (C)1998 -- This code is GPL. + * + * February 2000: Modified by James Morris to have 1 queue per protocol. */ #include #include @@ -16,7 +18,7 @@ #include #include #include -#include +#include #define __KERNEL_SYSCALLS__ #include @@ -32,41 +34,31 @@ #define NFDEBUG(format, args...) #endif -/* Each queued (to userspace) skbuff has one of these. */ -struct nf_info -{ - /* The ops struct which sent us to userspace. */ - struct nf_hook_ops *elem; - - /* If we're sent to userspace, this keeps housekeeping info */ - int pf; - unsigned long mark; - unsigned int hook; - struct net_device *indev, *outdev; - int (*okfn)(struct sk_buff *); -}; - -static rwlock_t nf_lock = RW_LOCK_UNLOCKED; +/* Sockopts only registered and called from user context, so + BR_NETPROTO_LOCK would be overkill. Also, [gs]etsockopt calls may + sleep. */ static DECLARE_MUTEX(nf_sockopt_mutex); struct list_head nf_hooks[NPROTO][NF_MAX_HOOKS]; static LIST_HEAD(nf_sockopts); -static LIST_HEAD(nf_interested); + +/* + * A queue handler may be registered for each protocol. Each is protected by + * long term mutex. The handler must provide an an outfn() to accept packets + * for queueing and must reinject all packets it receives, no matter what. + */ +static struct nf_queue_handler_t { + nf_queue_outfn_t outfn; + void *data; +} queue_handler[NPROTO]; int nf_register_hook(struct nf_hook_ops *reg) { struct list_head *i; -#ifdef CONFIG_NETFILTER_DEBUG - if (reg->pf<0 || reg->pf>=NPROTO || reg->hooknum >= NF_MAX_HOOKS) { - NFDEBUG("nf_register_hook: bad vals: pf=%i, hooknum=%u.\n", - reg->pf, reg->hooknum); - return -EINVAL; - } -#endif NFDEBUG("nf_register_hook: pf=%i hook=%u.\n", reg->pf, reg->hooknum); - - write_lock_bh(&nf_lock); + + br_write_lock_bh(BR_NETPROTO_LOCK); for (i = nf_hooks[reg->pf][reg->hooknum].next; i != &nf_hooks[reg->pf][reg->hooknum]; i = i->next) { @@ -74,22 +66,15 @@ break; } list_add(®->list, i->prev); - write_unlock_bh(&nf_lock); + br_write_unlock_bh(BR_NETPROTO_LOCK); return 0; } void nf_unregister_hook(struct nf_hook_ops *reg) { -#ifdef CONFIG_NETFILTER_DEBUG - if (reg->pf<0 || reg->pf>=NPROTO || reg->hooknum >= NF_MAX_HOOKS) { - NFDEBUG("nf_unregister_hook: bad vals: pf=%i, hooknum=%u.\n", - reg->pf, reg->hooknum); - return; - } -#endif - write_lock_bh(&nf_lock); + br_write_lock_bh(BR_NETPROTO_LOCK); list_del(®->list); - write_unlock_bh(&nf_lock); + br_write_unlock_bh(BR_NETPROTO_LOCK); } /* Do exclusive ranges overlap? */ @@ -105,22 +90,6 @@ struct list_head *i; int ret = 0; -#ifdef CONFIG_NETFILTER_DEBUG - if (reg->pf<0 || reg->pf>=NPROTO) { - NFDEBUG("nf_register_sockopt: bad val: pf=%i.\n", reg->pf); - return -EINVAL; - } - if (reg->set_optmin > reg->set_optmax) { - NFDEBUG("nf_register_sockopt: bad set val: min=%i max=%i.\n", - reg->set_optmin, reg->set_optmax); - return -EINVAL; - } - if (reg->get_optmin > reg->get_optmax) { - NFDEBUG("nf_register_sockopt: bad get val: min=%i max=%i.\n", - reg->get_optmin, reg->get_optmax); - return -EINVAL; - } -#endif if (down_interruptible(&nf_sockopt_mutex) != 0) return -EINTR; @@ -149,12 +118,6 @@ void nf_unregister_sockopt(struct nf_sockopt_ops *reg) { -#ifdef CONFIG_NETFILTER_DEBUG - if (reg->pf<0 || reg->pf>=NPROTO) { - NFDEBUG("nf_register_sockopt: bad val: pf=%i.\n", reg->pf); - return; - } -#endif /* No point being interruptible: we're probably in cleanup_module() */ down(&nf_sockopt_mutex); list_del(®->list); @@ -167,6 +130,33 @@ #include #include +static void debug_print_hooks_ip(unsigned int nf_debug) +{ + if (nf_debug & (1 << NF_IP_PRE_ROUTING)) { + printk("PRE_ROUTING "); + nf_debug ^= (1 << NF_IP_PRE_ROUTING); + } + if (nf_debug & (1 << NF_IP_LOCAL_IN)) { + printk("LOCAL_IN "); + nf_debug ^= (1 << NF_IP_LOCAL_IN); + } + if (nf_debug & (1 << NF_IP_FORWARD)) { + printk("FORWARD "); + nf_debug ^= (1 << NF_IP_FORWARD); + } + if (nf_debug & (1 << NF_IP_LOCAL_OUT)) { + printk("LOCAL_OUT "); + nf_debug ^= (1 << NF_IP_LOCAL_OUT); + } + if (nf_debug & (1 << NF_IP_POST_ROUTING)) { + printk("POST_ROUTING "); + nf_debug ^= (1 << NF_IP_POST_ROUTING); + } + if (nf_debug) + printk("Crap bits: 0x%04X", nf_debug); + printk("\n"); +} + void nf_dump_skb(int pf, struct sk_buff *skb) { printk("skb: pf=%i %s dev=%s len=%u\n", @@ -257,7 +247,7 @@ { /* If it's owned, it must have gone through the * NF_IP_LOCAL_OUT and NF_IP_POST_ROUTING. - * Otherwise, must have gone through NF_IP_RAW_INPUT, + * Otherwise, must have gone through * NF_IP_PRE_ROUTING, NF_IP_FORWARD and NF_IP_POST_ROUTING. */ if (skb->sk) { @@ -269,9 +259,6 @@ } } else { if (skb->nf_debug != ((1 << NF_IP_PRE_ROUTING) -#ifdef CONFIG_IP_NETFILTER_RAW_INPUT - | (1 << NF_IP_RAW_INPUT) -#endif | (1 << NF_IP_FORWARD) | (1 << NF_IP_POST_ROUTING))) { printk("ip_finish_output: bad unowned skb = %p: ",skb); @@ -280,29 +267,8 @@ } } } - - #endif /*CONFIG_NETFILTER_DEBUG*/ -void nf_cacheflush(int pf, unsigned int hook, const void *packet, - const struct net_device *indev, const struct net_device *outdev, - __u32 packetcount, __u32 bytecount) -{ - struct list_head *i; - - read_lock_bh(&nf_lock); - for (i = nf_hooks[pf][hook].next; - i != &nf_hooks[pf][hook]; - i = i->next) { - if (((struct nf_hook_ops *)i)->flush) - ((struct nf_hook_ops *)i)->flush(packet, indev, - outdev, - packetcount, - bytecount); - } - read_unlock_bh(&nf_lock); -} - /* Call get/setsockopt() */ static int nf_sockopt(struct sock *sk, int pf, int val, char *opt, int *len, int get) @@ -360,15 +326,12 @@ struct nf_hook_ops *elem = (struct nf_hook_ops *)*i; switch (elem->hook(hook, skb, indev, outdev, okfn)) { case NF_QUEUE: - NFDEBUG("nf_iterate: NF_QUEUE for %p.\n", *skb); return NF_QUEUE; case NF_STOLEN: - NFDEBUG("nf_iterate: NF_STOLEN for %p.\n", *skb); return NF_STOLEN; case NF_DROP: - NFDEBUG("nf_iterate: NF_DROP for %p.\n", *skb); return NF_DROP; #ifdef CONFIG_NETFILTER_DEBUG @@ -384,6 +347,38 @@ return NF_ACCEPT; } +int nf_register_queue_handler(int pf, nf_queue_outfn_t outfn, void *data) +{ + int ret; + + br_write_lock_bh(BR_NETPROTO_LOCK); + if (queue_handler[pf].outfn) + ret = -EBUSY; + else { + queue_handler[pf].outfn = outfn; + queue_handler[pf].data = data; + ret = 0; + } + br_write_unlock_bh(BR_NETPROTO_LOCK); + + return ret; +} + +/* The caller must flush their queue before this */ +int nf_unregister_queue_handler(int pf) +{ + NFDEBUG("Unregistering Netfilter queue handler for pf=%d\n", pf); + br_write_lock_bh(BR_NETPROTO_LOCK); + queue_handler[pf].outfn = NULL; + queue_handler[pf].data = NULL; + br_write_unlock_bh(BR_NETPROTO_LOCK); + return 0; +} + +/* + * Any packet that leaves via this function must come back + * through nf_reinject(). + */ static void nf_queue(struct sk_buff *skb, struct list_head *elem, int pf, unsigned int hook, @@ -391,61 +386,43 @@ struct net_device *outdev, int (*okfn)(struct sk_buff *)) { - struct list_head *i; + int status; + struct nf_info *info; - struct nf_info *info = kmalloc(sizeof(*info), GFP_ATOMIC); + if (!queue_handler[pf].outfn) { + NFDEBUG("nf_queue: noone wants the packet, dropping it.\n"); + kfree_skb(skb); + return; + } + + info = kmalloc(sizeof(*info), GFP_ATOMIC); if (!info) { - NFDEBUG("nf_hook: OOM.\n"); + if (net_ratelimit()) + printk(KERN_ERR "OOM queueing packet %p\n", + skb); kfree_skb(skb); return; } - /* Can't do struct assignments with arrays in them. Damn. */ - info->elem = (struct nf_hook_ops *)elem; - info->mark = skb->nfmark; - info->pf = pf; - info->hook = hook; - info->okfn = okfn; - info->indev = indev; - info->outdev = outdev; - skb->nfmark = (unsigned long)info; + *info = (struct nf_info) { + (struct nf_hook_ops *)elem, pf, hook, indev, outdev, okfn }; /* Bump dev refs so they don't vanish while packet is out */ if (indev) dev_hold(indev); if (outdev) dev_hold(outdev); - - for (i = nf_interested.next; i != &nf_interested; i = i->next) { - struct nf_interest *recip = (struct nf_interest *)i; - if ((recip->hookmask & (1 << info->hook)) - && info->pf == recip->pf - && (!recip->mark || info->mark == recip->mark) - && (!recip->reason || skb->nfreason == recip->reason)) { - /* FIXME: Andi says: use netlink. Hmmm... --RR */ - if (skb_queue_len(&recip->wake->skbq) >= 100) { - NFDEBUG("nf_hook: queue to long.\n"); - goto free_discard; - } - /* Hand it to userspace for collection */ - skb_queue_tail(&recip->wake->skbq, skb); - NFDEBUG("Waking up pf=%i hook=%u mark=%lu reason=%u\n", - pf, hook, skb->nfmark, skb->nfreason); - wake_up_interruptible(&recip->wake->sleep); - - return; - } + status = queue_handler[pf].outfn(skb, info, queue_handler[pf].data); + if (status < 0) { + /* James M doesn't say fuck enough. */ + if (indev) dev_put(indev); + if (outdev) dev_put(outdev); + kfree_s(info, sizeof(*info)); + kfree_skb(skb); + return; } - NFDEBUG("nf_hook: noone wants the packet.\n"); - - free_discard: - if (indev) dev_put(indev); - if (outdev) dev_put(outdev); - - kfree_s(info, sizeof(*info)); - kfree_skb(skb); } -/* nf_hook() doesn't have lock, so may give false positive. */ +/* We have BR_NETPROTO_LOCK here */ int nf_hook_slow(int pf, unsigned int hook, struct sk_buff *skb, struct net_device *indev, struct net_device *outdev, @@ -455,21 +432,6 @@ unsigned int verdict; int ret = 0; -#ifdef CONFIG_NETFILTER_DEBUG - if (pf < 0 || pf >= NPROTO || hook >= NF_MAX_HOOKS) { - NFDEBUG("nf_hook: bad vals: pf=%i, hook=%u.\n", - pf, hook); - kfree_skb(skb); - return -EINVAL; /* -ECODERFUCKEDUP ?*/ - } - - if (skb->nf_debug & (1 << hook)) { - NFDEBUG("nf_hook: hook %i already set.\n", hook); - nf_dump_skb(pf, skb); - } - skb->nf_debug |= (1 << hook); -#endif - read_lock_bh(&nf_lock); elem = &nf_hooks[pf][hook]; verdict = nf_iterate(&nf_hooks[pf][hook], &skb, hook, indev, outdev, &elem, okfn); @@ -477,7 +439,6 @@ NFDEBUG("nf_hook: Verdict = QUEUE.\n"); nf_queue(skb, elem, pf, hook, indev, outdev, okfn); } - read_unlock_bh(&nf_lock); switch (verdict) { case NF_ACCEPT: @@ -492,85 +453,42 @@ return ret; } - -struct nf_waitinfo { - unsigned int verdict; - struct task_struct *owner; -}; -/* For netfilter device. */ -void nf_register_interest(struct nf_interest *interest) +void nf_reinject(struct sk_buff *skb, struct nf_info *info, + unsigned int verdict) { - /* First in, best dressed. */ - write_lock_bh(&nf_lock); - list_add(&interest->list, &nf_interested); - write_unlock_bh(&nf_lock); -} - -void nf_unregister_interest(struct nf_interest *interest) -{ - struct sk_buff *skb; - - write_lock_bh(&nf_lock); - list_del(&interest->list); - write_unlock_bh(&nf_lock); - - /* Blow away any queued skbs; this is overzealous. */ - while ((skb = skb_dequeue(&interest->wake->skbq)) != NULL) - nf_reinject(skb, 0, NF_DROP); -} - -void nf_getinfo(const struct sk_buff *skb, - struct net_device **indev, - struct net_device **outdev, - unsigned long *mark) -{ - const struct nf_info *info = (const struct nf_info *)skb->nfmark; - - *indev = info->indev; - *outdev = info->outdev; - *mark = info->mark; -} - -void nf_reinject(struct sk_buff *skb, unsigned long mark, unsigned int verdict) -{ - struct nf_info *info = (struct nf_info *)skb->nfmark; struct list_head *elem = &info->elem->list; struct list_head *i; - - read_lock_bh(&nf_lock); + /* We don't have BR_NETPROTO_LOCK here */ + br_read_lock_bh(BR_NETPROTO_LOCK); for (i = nf_hooks[info->pf][info->hook].next; i != elem; i = i->next) { if (i == &nf_hooks[info->pf][info->hook]) { /* The module which sent it to userspace is gone. */ + NFDEBUG("%s: module disappeared, dropping packet.\n", + __FUNCTION__); verdict = NF_DROP; break; } } - /* Continue traversal iff userspace said ok, and devices still - exist... */ + /* Continue traversal iff userspace said ok... */ if (verdict == NF_ACCEPT) { - skb->nfmark = mark; verdict = nf_iterate(&nf_hooks[info->pf][info->hook], &skb, info->hook, info->indev, info->outdev, &elem, info->okfn); } - if (verdict == NF_QUEUE) { - nf_queue(skb, elem, info->pf, info->hook, - info->indev, info->outdev, info->okfn); - } - read_unlock_bh(&nf_lock); - switch (verdict) { case NF_ACCEPT: - local_bh_disable(); info->okfn(skb); - local_bh_enable(); break; + case NF_QUEUE: + nf_queue(skb, elem, info->pf, info->hook, + info->indev, info->outdev, info->okfn); + case NF_DROP: kfree_skb(skb); break; @@ -579,51 +497,17 @@ /* Release those devices we held, or Alexey will kill me. */ if (info->indev) dev_put(info->indev); if (info->outdev) dev_put(info->outdev); - + kfree_s(info, sizeof(*info)); return; } -/* FIXME: Before cache is ever used, this must be implemented for real. */ -void nf_invalidate_cache(int pf) -{ -} - -#ifdef CONFIG_NETFILTER_DEBUG - -void debug_print_hooks_ip(unsigned int nf_debug) -{ - if (nf_debug & (1 << NF_IP_PRE_ROUTING)) { - printk("PRE_ROUTING "); - nf_debug ^= (1 << NF_IP_PRE_ROUTING); - } - if (nf_debug & (1 << NF_IP_LOCAL_IN)) { - printk("LOCAL_IN "); - nf_debug ^= (1 << NF_IP_LOCAL_IN); - } - if (nf_debug & (1 << NF_IP_FORWARD)) { - printk("FORWARD "); - nf_debug ^= (1 << NF_IP_FORWARD); - } - if (nf_debug & (1 << NF_IP_LOCAL_OUT)) { - printk("LOCAL_OUT "); - nf_debug ^= (1 << NF_IP_LOCAL_OUT); - } - if (nf_debug & (1 << NF_IP_POST_ROUTING)) { - printk("POST_ROUTING "); - nf_debug ^= (1 << NF_IP_POST_ROUTING); - } - if (nf_debug) - printk("Crap bits: 0x%04X", nf_debug); - printk("\n"); -} -#endif /* CONFIG_NETFILTER_DEBUG */ - void __init netfilter_init(void) { int i, h; - for (i = 0; i < NPROTO; i++) + for (i = 0; i < NPROTO; i++) { for (h = 0; h < NF_MAX_HOOKS; h++) INIT_LIST_HEAD(&nf_hooks[i][h]); + } } -- Hacking time.