From bunk@fs.tum.de Sun Aug 1 07:28:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 07:28:20 -0700 (PDT) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i71ESAPm020056 for ; Sun, 1 Aug 2004 07:28:13 -0700 Received: (qmail 28287 invoked from network); 1 Aug 2004 14:20:58 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 1 Aug 2004 14:20:58 -0000 Date: Sun, 1 Aug 2004 16:27:59 +0200 From: Adrian Bunk To: Marcelo Tosatti , Stephen Hemminger Cc: linux-kernel@vger.kernel.org, davem@redhat.com, netdev@oss.sgi.com Subject: [2.4 patch] CONFIG_NET_SCH_NETEM Configure.help entry Message-ID: <20040801142759.GQ2746@fs.tum.de> References: <20040731142658.GA6497@logos.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040731142658.GA6497@logos.cnet> User-Agent: Mutt/1.5.6i X-archive-position: 7388 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: netdev On Sat, Jul 31, 2004 at 11:26:59AM -0300, Marcelo Tosatti wrote: >... > Summary of changes from v2.4.27-rc3 to v2.4.27-rc4 > ============================================ >... > Stephen Hemminger: > o [PKT_SCHED]: Update to network emulation QOS scheduler > o [PKT_SCHED]: One small netem fixes > o [BRIDGE]: Fix assertion failure in 2.4.27-rc3 > o [PKT_SCHED]: netem update for 2.4 >... The Configure.help entry was forgotten: Signed-off-by: Adrian Bunk --- linux-2.4.27-rc4-full/Documentation/Configure.help.old 2004-08-01 16:20:15.000000000 +0200 +++ linux-2.4.27-rc4-full/Documentation/Configure.help 2004-08-01 16:22:23.000000000 +0200 @@ -10949,13 +10949,15 @@ whenever you want). If you want to compile it as a module, say M here and read . -Network delay simualtor -CONFIG_NET_SCH_DELAY - Say Y if you want to delay packets by a fixed amount of - time. This is often useful to simulate network delay when +CONFIG_NET_SCH_NETEM + Say Y if you want to emulate network delay, loss, and packet + re-ordering. This is often useful to simulate networks when testing applications or protocols. - - This code is also available as a module called sch_delay.o + + To compile this driver as a module, choose M here: the module + will be called sch_netem. + + If unsure, say N. Ingress Qdisc CONFIG_NET_SCH_INGRESS From bunk@fs.tum.de Sun Aug 1 07:33:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 07:33:22 -0700 (PDT) Received: from hermes.fachschaften.tu-muenchen.de (hermes.fachschaften.tu-muenchen.de [129.187.202.12]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i71EXG3b020415 for ; Sun, 1 Aug 2004 07:33:17 -0700 Received: (qmail 28500 invoked from network); 1 Aug 2004 14:26:05 -0000 Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58) by hermes.fachschaften.tu-muenchen.de with QMQP; 1 Aug 2004 14:26:05 -0000 Date: Sun, 1 Aug 2004 16:33:07 +0200 From: Adrian Bunk To: Stephen Hemminger Cc: linux-kernel@vger.kernel.org, davem@redhat.com, netdev@oss.sgi.com Subject: [2.6 patch] update NET_SCH_NETEM help text Message-ID: <20040801143307.GR2746@fs.tum.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 7389 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bunk@fs.tum.de Precedence: bulk X-list: netdev The patch below contains the following changes for the NET_SCH_NETEM help text: - correct the module name - "If unsure, say N." Signed-off-by: Adrian Bunk --- linux-2.6.8-rc2-mm1-full/net/sched/Kconfig.old 2004-08-01 16:28:22.000000000 +0200 +++ linux-2.6.8-rc2-mm1-full/net/sched/Kconfig 2004-08-01 16:29:12.000000000 +0200 @@ -207,19 +207,21 @@ config NET_SCH_NETEM tristate "Network emulator" depends on NET_SCHED help Say Y if you want to emulate network delay, loss, and packet re-ordering. This is often useful to simulate networks when testing applications or protocols. To compile this driver as a module, choose M here: the module - will be called sch_delay. + will be called sch_netem. + + If unsure, say N. config NET_SCH_INGRESS tristate "Ingress Qdisc" depends on NET_SCHED help If you say Y here, you will be able to police incoming bandwidth and drop packets when this bandwidth exceeds your desired rate. If unsure, say Y. From rddunlap@osdl.org Sun Aug 1 10:43:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 10:43:44 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i71HhbY4027638 for ; Sun, 1 Aug 2004 10:43:38 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i71HhP116814; Sun, 1 Aug 2004 10:43:26 -0700 Date: Sun, 1 Aug 2004 10:22:47 -0700 From: "Randy.Dunlap" To: bruce@it.usyd.edu.au (Bruce Janson) Cc: netdev Subject: Re: 2.6.7 kernel boot-time configuration of a non-modular tulip driver Message-Id: <20040801102247.33363e99.rddunlap@osdl.org> In-Reply-To: <200407311521.i6VFLcOC022100@nlp0.cs.usyd.edu.au> References: <200407311521.i6VFLcOC022100@nlp0.cs.usyd.edu.au> Organization: OSDL X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7390 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev (moving this to netdev mailing list) On Sun, 01 Aug 2004 00:48:22 +1000 Bruce Janson wrote: | I have a linux 2.6.7 kernel which contains a compiled-in tulip driver. | I would like to be able to boot the kernel with parameters that | will allow control of the tulip device. On some ethernet devices | this used to be possible via (something like): | | ether=0,0,1,0,eth0 | | which would pass the four numeric parameters (as, I think, dev->irq, | dev->ioaddr, dev->mem_start and dev->mem_end) to the net driver that | controlled eth0. A convention adopted by some net drivers then allowed | dev->mem_start to be interpretted as a set of flags that would control | device characteristics (e.g. full-duplex vs half-duplex mode). | In .../linux-2.6.7/drivers/net/tulip/tulip_core.c:1587: | | if (dev->mem_start & MEDIA_MASK) | tp->default_port = dev->mem_start & MEDIA_MASK; | | suggests that this might still work. However, I have been unable | to force dev->mem_start in that driver to become non-zero via any | kernel boot-time parameters. My limited understanding of the code | that precedes the above lines in that file suggests that the "dev" | structure is not what it used to be... The driver never calls netdev_boot_setup_check(), which is what would give the driver its command line parameters. Did this work in early 2.6.x? There have been several changes in this area. The driver can't do a simple call to netdev_boot_setup_check() because that will overwrite dev-> {irq, base_addr, mem_start, mem_end}, and those values come from PCI config space for PCI drivers. The driver could create a fake for that purpose, but it's more likely that ethtool or mii-tool should be used to change media/speed etc... Although now that I look at the driver source code, I don't see ethtool or mii-tool support for those options. | ../linux-2.6.7/Documentation/kernel-parameters.txt:402 still | mentions "ether=..." but marks it as obsolete, replaced by | the equivalent "netdev=...". Elsewhere in that file, the entry | for "netdev=..." describes what appears to be the functionality | that I seek. | | So, is it still possible to perform the same sort of control | operations on a tulip driver via kernel boot-time parameters | as one can do via module load-time parameters? If so, how? The current tulip-core driver supports setting only the default transceiver (media type) on the kernel boot/command line when the driver is built into the kernel image (using mem_start, as you noted above). When modular, it supports that plus forcing full duplex and MTU for jumbo frames. Anyone have more definite answers on this? -- ~Randy From kaber@trash.net Sun Aug 1 10:51:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 10:51:44 -0700 (PDT) Received: from www.legaleagle.de (legaleagle.de [217.160.128.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i71HpYw8028091 for ; Sun, 1 Aug 2004 10:51:35 -0700 Received: from eru.coreworks.de (unknown [172.16.0.2]) by www.legaleagle.de (Postfix) with ESMTP id 74DC919F353; Sun, 1 Aug 2004 19:51:25 +0200 (CEST) Received: from trash.net (unknown [172.16.0.123]) by eru.coreworks.de (Postfix) with ESMTP id B89CB3940EE; Sun, 1 Aug 2004 19:51:20 +0200 (CEST) Message-ID: <410D2E30.2050104@trash.net> Date: Sun, 01 Aug 2004 19:53:52 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: Tomasz Paszkowski Cc: "David S. Miller" , hadi@cyberus.ca, devik@cdi.cz, netdev@oss.sgi.com Subject: Re: Fw: hfsc and huge set of rules References: <20040729211844.61e8d328.davem@redhat.com> <410A2449.3020701@trash.net> <20040730110815.GA7812@krezus.e-wro.net> In-Reply-To: <20040730110815.GA7812@krezus.e-wro.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7391 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Tomasz Paszkowski wrote: >On Fri, Jul 30, 2004 at 12:34:49PM +0200, Patrick McHardy wrote: > > >>hfsc_destroy_qdisc takes O(n) time wrt. the number of classes, >>but 5-6 seconds is still long. If all these classes contain inner >>qdiscs other than the default, I guess removing the classes from >>dev->qdisc_list in qdisc_destroy takes up most of the time, with >>n O(n) operations. The __qdisc_destroy rcu callback also calls >>reset before destroy, I don't know any qdisc where this is really >>neccessary. Without inner qdiscs, I need to see the script first to >>judge what's going wrong. Tomasz ? >> >> > >http://www.e-wro.pl/~acid/tc.batch.gz. In my opinion it's not the case >of expensive algorithms, but the number of classes. With this rule set loaded >(tc -b tc.batch) command: > >for i in 'e1.903 e0.930 e0.931 e0.932' ; do > tc qdisc del dev ${i} root >done >completly freezes machine for about 5-6 seconds. > > I've done some profiles with your script (on an old kernel without the lockless loopback patch), qdisc_destroy takes up 89% of the time when destroying the qdiscs. These are the exact results: - execute the script on unpatched kernel: time: real 2m28.822s user 0m2.347s sys 2m25.395s top 5 in profile: 799773 65.4986 vmlinux vmlinux qdisc_lookup 199964 16.3763 vmlinux vmlinux qdisc_destroy 92504 7.5758 sch_hfsc.ko sch_hfsc hfsc_adjust_levels 36722 3.0074 sch_hfsc.ko sch_hfsc hfsc_get_class 12471 1.0213 vmlinux vmlinux mark_offset_tsc - execute the script on kernel using double-linked lists for dev->qdisc_list: time: real 0m51.804s user 0m2.286s sys 0m48.795s top 5 in profile: 201152 49.6049 vmlinux vmlinux qdisc_lookup 92706 22.8617 sch_hfsc.ko sch_hfsc hfsc_adjust_levels 37140 9.1589 sch_hfsc.ko sch_hfsc hfsc_get_class 12310 3.0357 sch_hfsc.ko sch_hfsc hfsc_bind_tcf 12190 3.0061 sch_hfsc.ko sch_hfsc hfsc_change_class - destroy the qdiscs on unpatched kernel: time: real 0m13.258s user 0m0.019s sys 0m13.206s top 5 in profile: 29839 89.5367 vmlinux vmlinux qdisc_destroy 1229 3.6878 sch_hfsc.ko sch_hfsc hfsc_reset_class 338 1.0142 vmlinux vmlinux mark_offset_tsc 289 0.8672 vmlinux vmlinux qdisc_reset 287 0.8612 sch_hfsc.ko sch_hfsc rtsc_init - destroy the qdiscs on kernel using double-linked lists for dev->qdisc_list: time: real 0m0.389s user 0m0.019s sys 0m0.363s top 5 in profile: 1261 33.6896 sch_hfsc.ko sch_hfsc hfsc_reset_class 311 8.3088 sch_hfsc.ko sch_hfsc rtsc_init 277 7.4005 vmlinux vmlinux qdisc_reset 187 4.9960 vmlinux vmlinux free_block 181 4.8357 vmlinux vmlinux kfree So double-linked lists clearly solve your problem. Using a hash would speed up creating the qdiscs even more, but it wastes too much memory in my opinion. I'm going to send a patch after I've fixed the other problems with qdisc_destroy. >I was trying do modify the code od hfsc_qdisc_destroy scheduling another >task using schedule_task (), but i don't have enough knowledge to do deal >with proper locking of qdisc structures. > > That doesn't work, hfsc_qdisc_destroy is called under a lock. Regards Patrick From kaber@trash.net Sun Aug 1 10:53:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 10:53:51 -0700 (PDT) Received: from www.legaleagle.de (legaleagle.de [217.160.128.82]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i71HrkLp028447 for ; Sun, 1 Aug 2004 10:53:46 -0700 Received: from eru.coreworks.de (unknown [172.16.0.2]) by www.legaleagle.de (Postfix) with ESMTP id 7A7C519F353; Sun, 1 Aug 2004 19:53:37 +0200 (CEST) Received: from trash.net (unknown [172.16.0.123]) by eru.coreworks.de (Postfix) with ESMTP id D39343940EE; Sun, 1 Aug 2004 19:53:32 +0200 (CEST) Message-ID: <410D2EB4.1060205@trash.net> Date: Sun, 01 Aug 2004 19:56:04 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5 X-Accept-Language: en MIME-Version: 1.0 To: devik Cc: "David S. Miller" , hadi@cyberus.ca, netdev@oss.sgi.com, tomasz.paszkowski@e-wro.pl Subject: Re: Fw: hfsc and huge set of rules References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7392 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev devik wrote: >Also IIRC class lookup is done before each remove. With >hashing size a few tens of buckets the complexity >starts to be very near to O(n^2). > > I think the hash size of HTB, HFSC and CBQ should be increased, the hash function performs well even with 2^16. With HFSC using many classes doesn't scale well right now, but with the rbtree patches it will. Regards Patrick >devik > >On Fri, 30 Jul 2004, Patrick McHardy wrote: > > > >>David S. Miller wrote: >> >> >>>Looks like qdisc destruction has some expensive algorithms. >>>Any quick ideas about the root culprit at least in the hfsc >>>case? He says htb does it too. >>> >>> >>hfsc_destroy_qdisc takes O(n) time wrt. the number of classes, >>but 5-6 seconds is still long. If all these classes contain inner >>qdiscs other than the default, I guess removing the classes from >>dev->qdisc_list in qdisc_destroy takes up most of the time, with >>n O(n) operations. The __qdisc_destroy rcu callback also calls >>reset before destroy, I don't know any qdisc where this is really >>neccessary. Without inner qdiscs, I need to see the script first to >>judge what's going wrong. Tomasz ? >> >> From JDrabb@tampabay.rr.com Sun Aug 1 11:15:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 11:16:01 -0700 (PDT) Received: from ms-smtp-03.tampabay.rr.com (ms-smtp-03-smtplb.tampabay.rr.com [65.32.5.133]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i71IFrin029245 for ; Sun, 1 Aug 2004 11:15:54 -0700 Received: from [192.168.1.101] (189-66.35-65.tampabay.rr.com [65.35.66.189]) by ms-smtp-03.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id i71IFgfP011721; Sun, 1 Aug 2004 14:15:42 -0400 (EDT) Message-ID: <410D3377.3030505@tampabay.rr.com> Date: Sun, 01 Aug 2004 14:16:23 -0400 From: James Drabb User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: c-d.hailfinger.kernel.2004@gmx.net, manfred@colorfullife.com Subject: forcedeth Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-archive-position: 7393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: JDrabb@tampabay.rr.com Precedence: bulk X-list: netdev I am having some issues with the forcedeth driver. jim@keelie $ modinfo forcedeth parm: max_interrupt_work:forcedeth maximum events handled per interrupt author: Manfred Spraul description: Reverse Engineered nForce ethernet driver license: GPL vermagic: 2.6.7-1 686 REGPARM gcc-3.3 depends: alias: pci:v000010DEd000001C3sv*sd*bc*sc*i* alias: pci:v000010DEd00000066sv*sd*bc*sc*i* alias: pci:v000010DEd000000D6sv*sd*bc*sc*i* jim@keelie $ uname -a Linux keelie 2.6.7-1 #1 Thu Jul 22 11:42:58 CEST 2004 i686 athlon i386 GNU/Linux My system is an Athlon XP 2800+, on an MSI K7N2 Delta Mobo based on the NForce 2 chipset. I have a dual boot with WinXP and Fedora Core 2 and spend 99% of my time in FC2. Once in a while I shut the system down. When I boot from a cold boot right into FC2, the forcedeth driver appears not to work. I am not able to get to the net over my cable mode. Bringing eth0 up and down, unplugging the network cable does nothing. However, if I reboot into WinXP, and then reboot right away back into FC2, the forcedeth driver works like a champ. Is there anything I can do to look into what might be causing this issue? Any more information I may be able to send to help? Thanks for any help, -- James Drabb Senior Programmer Davenport, FL USA From scarfboy@gmail.com Sun Aug 1 12:03:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 12:03:43 -0700 (PDT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i71J3ajP030662 for ; Sun, 1 Aug 2004 12:03:37 -0700 Received: by mproxy.gmail.com with SMTP id 73so103371rnk for ; Sun, 01 Aug 2004 12:03:32 -0700 (PDT) Received: by 10.38.181.17 with SMTP id d17mr222682rnf; Sun, 01 Aug 2004 12:03:32 -0700 (PDT) Message-ID: Date: Sun, 1 Aug 2004 21:03:32 +0200 From: Bart Alewijnse To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: gigabit trouble In-Reply-To: <20040731231836.A31121@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_60_22762740.1091387012317" References: <20040729210401.A32456@electric-eye.fr.zoreil.com> <20040730205412.A15669@electric-eye.fr.zoreil.com> <20040730234120.A15536@electric-eye.fr.zoreil.com> <20040731231836.A31121@electric-eye.fr.zoreil.com> X-archive-position: 7394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scarfboy@gmail.com Precedence: bulk X-list: netdev ------=_Part_60_22762740.1091387012317 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, 31 Jul 2004 23:18:36 +0200, Francois Romieu wrote: > > Right, both computers now run 2.6.8-rc2-mm1. It's better. Roughly > > speaking, the top *benchmark* speeds, rouding slightly up, are: > > udp: 33MB/s (using ~26Kints) one way, 12MB/s (9Kints/s) the other, > > tcp: 22MB/s (16Kints)one way, 12MB/s (9Kints/s) the other. > > > > (The 9Kints ca be 12 when the packet size is 1K or 2K) > > Can you give a try to a napi version of the module (it is a compile-time > option) ? > You may want higher {r/w}mem_max as well as renicing ksoftirqd with > a strongly < 0 value on the celeron client. That's with NAPI on both. I notice r/wmem has an effect, but it's not much. Although on my new computer it seems moot as there's something weird going on with interrupts with my botherboard. > > Oddly enough, the slow direction is sending from my new computer > > (XP1700, KT333, 1GB ram) to my old (both running linux and the > > mentioned kernel). I'm fairly sure this is due to the fact that my > > The r8169 driver has been reported to be faster on Rx than on Tx so your > observation makes sense. How does that make sense? When one side receives, the other sends, hrm? They're two identical cards, it should be entirely symmetrical assuming equal hardware - not faster on the years older hardware. > [...] > > I guess I'll have to settle for this. I'm just annoyed that the 'giga' > > is basically a joke, especially on my setup. > > It should be possible to make things slightly better for the celeron box > as a client. I'll cook up a patch. The celeron box is the server, that's the entire point. Anyhow, it's much faster in transmission than my new computer right now due to said mobo problem, so I *want* it as the server. > Would you be kind enough to do some ftp transfer test where the celeron > box retrieves data and send the 'vmstat 1' output of the client during > the test ? Sure, but I can tell you right now with reasonable certaintly that my new computer won't top 9000interrupts/sec, i.e. 9000 packets per second, and therefore do the 12MB/s at most, and probably less; interruptwise, my new computer is the bottleneck, and I'm guessing UDP is faster because TCP is limited by the amount of packets, or in the other direction ACKs, it can send per second. Transfers to the celeron are a relatively pointless measure because of my new computer being horribly interrupt limited at the moment. That may have started when I installed the gbit card, but mostly because it disturbs the mobo's precious and unguessable hardware balance. I'll try figuring out if I can solve it, but basically it just involves swapping around cards until it works better, so that'ld take a while. Attached are the vmstats for an ftp and nfs transfer, as measured from my old computer (the nfs and ftp server). Both were going at a pretty low speed, sub-9000 packets; this may have to do with drive fragmentation, my hard drives are rather full at the moment. Also, the logs on the client (my new computer) while sending data to my old one. These were made at a different time, and I believe the transfer rate was better (6MB for ftp, 9MB for nfs) than for the -to-old- logs, which were worse, and varied more. --Bart ------=_Part_60_22762740.1091387012317 Content-Type: application/octet-stream; name="ftp-put-to-old-computer__lin-mm-to-lin-mm_larger" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ftp-put-to-old-computer__lin-mm-to-lin-mm_larger" cHJvY3MgLS0tLS0tLS0tLS1tZW1vcnktLS0tLS0tLS0tIC0tLXN3YXAtLSAtLS0tLWlvLS0tLSAt LXN5c3RlbS0tIC0tLS1jcHUtLS0tCiByICBiICAgc3dwZCAgIGZyZWUgICBidWZmICBjYWNoZSAg IHNpICAgc28gICAgYmkgICAgYm8gICBpbiAgICBjcyB1cyBzeSBpZCB3YQogMSAgMCAgICAgIDAg IDQ4NTMyICAyOTY0OCAxNzU0NjQgICAgMCAgICAwICAgMTAxICAgIDMxICAyNzMgICAxNjkgMTUg IDIgODAgIDIKIDAgIDAgICAgICAwICA0ODUzMiAgMjk2NDggMTc1NDY4ICAgIDAgICAgMCAgICAg MCAgICAgMCAxMDA3ICAgICA5ICAwICAxIDk5ICAwCiAxICAwICAgICAgMCAgNDU3OTYgIDI5NjQ4 IDE3ODIxMiAgICAwICAgIDAgICAgIDAgICAgIDAgMjg3MyAgICAzNSAgMiAzMyA2NSAgMAogMSAg MCAgICAgIDAgIDM5MjE2ICAyOTY0OCAxODQ1MzIgICAgMCAgICAwICAgICAwICAgICAwIDUxMzEg ICAgMzYgIDcgNzYgMTcgIDAKIDEgIDAgICAgICAwICAzMjgyMCAgMjk2NDggMTkxMzQ4ICAgIDAg ICAgMCAgICAgMCAgICAgMCA0OTM4ICAgIDUyICA3IDc3IDE2ICAwCiAwICAxICAgICAgMCAgMjg3 ODggIDI5OTA4IDE5NTAyOCAgICAwICAgIDAgICAgIDAgIDQ2MjggMzI3NiAgICA0MSAgNCA0NyAy NiAyMwogMSAgMSAgICAgIDAgIDI0MzA4ICAyOTkwOCAxOTkwMjAgICAgMCAgICAwICAgICAwICA4 NjU2IDQyMTEgICAgNDAgIDggOTAgIDAgIDIKIDEgIDAgICAgICAwICAyMDU5NiAgMjk5MDggMjAy NzI0ICAgIDAgICAgMCAgICAgMCAgNjUwMCAzOTY0ICAgMjU3ICA2IDk0ICAwICAwCiAxICAwICAg ICAgMCAgMTM5NDAgIDI5OTA4IDIwOTQwNCAgICAwICAgIDAgICAgIDAgICAgIDAgNTk5NCAgICAx NCAgOCA5MiAgMCAgMAogMSAgMCAgICAgIDAgICA3MjE2ICAyOTkwOCAyMTYxMTYgICAgMCAgICAw ICAgICAwICAgICA4IDU5OTYgICAgMTIgIDYgOTQgIDAgIDAKIDEgIDAgICAgICAwICAgMjQwOCAg Mjk4NDAgMjIxMDg0ICAgIDAgICAgMCAgICAgMCAgICAgOCA1OTMxICAgIDI4ICA4IDkyICAwICAw CiAxICAwICAgICAgMCAgIDI4NTYgIDI5NzQwIDIyMTMyMCAgICAwICAgIDAgICAgIDAgIDExODQg NTU3NCAgICA1MSAgNSA5NSAgMCAgMAogMSAgMSAgICAgIDAgICAyNTM2ICAzMDQwMCAyMjE0MDAg ICAgMCAgICAwICAgICAwICA2NTI0IDQ4ODYgICAgOTAgIDYgOTQgIDAgIDAKIDEgIDIgICAgICAw ICAgMjg1NiAgMzAyNzYgMjIxNTgwICAgIDAgICAgMCAgICAgMCAgNzc4MCA0Mjc5ICAgIDczICA3 IDkzICAwICAwCiAxICAyICAgICAgMCAgIDI0MDggIDMwMjQ4IDIyMjM2OCAgICAwICAgIDAgICAg IDAgIDYzNjggNDI1MSAgICA3MyAgNSA5NSAgMCAgMAogMSAgMiAgICAgIDAgICAyMjQ0ICAyOTkw NCAyMjMyNjAgICAgMCAgICAwICAgICAwICA2MzQ0IDQ5NTIgICAgNjggIDYgOTQgIDAgIDAKIDEg IDIgICAgICAwICAgMzExNiAgMjk2MzYgMjIyOTYwICAgIDAgICAgMCAgICAgMCAgNTI0NCA0MTYz ICAgIDgxICA4IDkyICAwICAwCiAxICAxICAgICAgMCAgIDI0NzIgIDI5NTI4IDIyMzk2OCAgICAw ICAgIDAgICAgIDAgIDU2NjQgNDczMSAgIDEwMSAgNyA5MyAgMCAgMAogMSAgMCAgICAgIDAgICAy OTIwICAyOTQxNiAyMjQwMjAgICAgMCAgICAwICAgICAwICAxMjY4IDUxMjQgICAxOTQgIDYgOTQg IDAgIDAKIDEgIDAgICAgICAwICAgMjk4NCAgMjkxMzIgMjI0NjI4ICAgIDAgICAgMCAgICAgMCAg IDYzNiA1ODI1ICAgIDQwICA4IDkyICAwICAwCiAxICAwICAgICAgMCAgIDIyODAgIDI4OTQ0IDIy NTc5NiAgICAwICAgIDAgICAgIDAgIDY2NjggNDgwNyAgICA3MyAgNiA5NCAgMCAgMApwcm9jcyAt LS0tLS0tLS0tLW1lbW9yeS0tLS0tLS0tLS0gLS0tc3dhcC0tIC0tLS0taW8tLS0tIC0tc3lzdGVt LS0gLS0tLWNwdS0tLS0KIHIgIGIgICBzd3BkICAgZnJlZSAgIGJ1ZmYgIGNhY2hlICAgc2kgICBz byAgICBiaSAgICBibyAgIGluICAgIGNzIHVzIHN5IGlkIHdhCiAyICAwICAgICAgMCAgIDIyNjAg IDI4NjY4IDIyNjM1MiAgICAwICAgIDAgICAgIDAgIDM5NzYgNDk3MyAgICA3NyAgNyA5MyAgMCAg MAogMSAgMCAgICAgIDAgICAyNDA4ICAyODQyMCAyMjY2NjQgICAgMCAgICAwICAgICAwICA1MzIw IDQ1MTQgICAgOTYgIDYgOTQgIDAgIDAKIDEgIDEgICAgICAwICAgMjY2NCAgMjgzNjggMjI2NDgw ICAgIDAgICAgMCAgICAgMCAxOTI2NCAzMjYxICAgIDQ0ICA2IDk0ICAwICAwCiAxICAxICAgICAg MCAgIDI0NzYgIDI4Mjg4IDIyNjczMiAgICAwICAgIDAgICAgIDAgMTYxODQgMjEyNCAgIDI1MiAg NyA5MyAgMCAgMAogMSAgMCAgICAgIDAgICAyOTIwICAyODA1NiAyMjY5NjggICAgMCAgICAwICAg ICAwICAgNTM2IDM4OTggICAgNjcgIDcgOTMgIDAgIDAKIDEgIDAgICAgICAwICAgMjgwNCAgMjc2 OTYgMjI3NzAwICAgIDAgICAgMCAgICAgMCAgICAgOCA1ODYzICAgIDUzICA2IDk0ICAwICAwCiAx ICAwICAgICAgMCAgIDI5ODQgIDI3NTA0IDIyNzkyOCAgICAwICAgIDAgICAgIDAgICAgIDggNTky OSAgICA3MCAgNyA5MyAgMCAgMAogMSAgMCAgICAgIDAgICAyOTIwICAyNzAwOCAyMjg2NDggICAg MCAgICAwICAgICAwICAgICA0IDU5NDkgICAgNTMgIDkgOTEgIDAgIDAKIDEgIDAgICAgICAwICAg MjQwOCAgMjY4NDAgMjI5NDY4ICAgIDAgICAgMCAgICAgMCAgMTQzNiA1NTQzICAgIDUwICA2IDk0 ICAwICAwCiAyICAwICAgICAgMCAgIDI3OTIgIDI2ODA4IDIyODU2MCAgICAwICAgIDAgICAgIDAg MzU1MzIgMzY4NSAgICA0NiAgOCA5MiAgMCAgMAogMSAgMSAgICAgIDAgICAzMDY0ICAyNjcxNiAy Mjg5MTYgICAgMCAgICAwICAgICAwICAgICAwIDIwODUgICAyMTcgIDggOTIgIDAgIDAKIDEgIDAg ICAgICAwICAgMjk4NCAgMjY1MjAgMjI5NTcyICAgIDAgICAgMCAgICAgMCAgIDE2MCAzNzUxICAg IDY5ICA2IDk0ICAwICAwCiAxICAwICAgICAgMCAgIDI1MzYgIDI2MzUyIDIzMDMyNCAgICAwICAg IDAgICAgIDAgICAgIDggNTk1MyAgICA1MCAgOCA5MiAgMCAgMAogMSAgMCAgICAgIDAgICAyOTIw ICAyNDExNiAyMzIzMzIgICAgMCAgICAwICAgICAwICAgICA4IDU4OTQgICAgNTMgIDcgOTMgIDAg IDAKIDEgIDAgICAgICAwICAgMzA0OCAgMjI0MjAgMjM0MTgwICAgIDAgICAgMCAgICAgMCAgICAg NCA1OTQ1ICAgIDQ4ICA2IDk0ICAwICAwCiAxICAwICAgICAgMCAgIDMxMTIgIDIxMDY0IDIzNTM5 NiAgICAwICAgIDAgICAgIDAgIDEzNDggNTQ3NiAgICA1NSAgNyA5MSAgMiAgMAogMSAgMSAgICAg IDAgICAxOTQ0ICAyMDU3MiAyMzY1MDggICAgMCAgICAwICAgICAwIDM1NjUyIDM2MjggICAgNTIg IDYgOTQgIDAgIDAKIDAgIDIgICAgICAwICAgMjEzMiAgMjAwNTYgMjM3MDQ4ICAgIDAgICAgMCAg MTA2NCAgICAgMCAxMTI1ICAgMTUwICA3IDIyICAwIDcwCiAxICAxICAgICAgMCAgIDMxODggIDE4 OTg0IDIzNjQwOCAgICAwICAgIDAgICAyMjQgICAgIDAgMTA3NyAgIDEwOCA2MSAxMCAgMCAyOQog MCAgMCAgICAgIDAgICA0NjE2ICAxODk4NCAyMzY0MDggICAgMCAgICAwICAgICAwICAgMTQ0IDEw MzQgICAgMzQgIDIgIDIgODMgMTMKIDAgIDAgICAgICAwICAgNDYxNiAgMTg5ODQgMjM2NDA4ICAg IDAgICAgMCAgICAgMCAgICAgMCAxMDA2ICAgIDEwICAwICAwIDEwMCAgMApwcm9jcyAtLS0tLS0t LS0tLW1lbW9yeS0tLS0tLS0tLS0gLS0tc3dhcC0tIC0tLS0taW8tLS0tIC0tc3lzdGVtLS0gLS0t LWNwdS0tLS0KIHIgIGIgICBzd3BkICAgZnJlZSAgIGJ1ZmYgIGNhY2hlICAgc2kgICBzbyAgICBi aSAgICBibyAgIGluICAgIGNzIHVzIHN5IGlkIHdhCiAxICAwICAgICAgMCAxNzg1MTYgIDE4OTg0 ICA2MzY3NiAgICAwICAgIDAgICAgIDAgICAgIDAgMTAwOSAgICAxMiAgMCAzMyA2NyAgMAogMCAg MCAgICAgIDAgMTc3NTcyICAyMDE4MCAgNjM2ODAgICAgMCAgICAwICAgIDQ4ICAxMTkyIDEwMzMg ICAgNzMgIDEgIDQgNzAgMjUKIDAgIDAgICAgICAwIDE3NzU3MiAgMjAxODAgIDYzNjgwICAgIDAg ICAgMCAgICAgMCAgICAgMCAxMDA4ICAgIDEwICAwICAwIDEwMCAgMAogMCAgMCAgICAgIDAgMTc3 ODkyICAyMDIxNiAgNjM2ODAgICAgMCAgICAwICAgICAwICAxMTI0IDEyMjQgICAgMzkgIDAgIDMg NDAgNTcKIDAgIDAgICAgICAwIDE3Nzg5MiAgMjAyMTYgIDYzNjg0ICAgIDAgICAgMCAgICAgMCAg ICAgMCAxMDY3ICAgIDEzICAwICAxIDg1IDE0CiAwICAwICAgICAgMCAxNzc4OTIgIDIwMjIwICA2 MzY4OCAgICAwICAgIDAgICAgIDggICAgIDAgMTAxMSAgICAxNiAgMCAgMCA5OSAgMQo= ------=_Part_60_22762740.1091387012317 Content-Type: application/octet-stream; name="nfs-to-old-computer__lin-mm-to-lin-mm" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="nfs-to-old-computer__lin-mm-to-lin-mm" cHJvY3MgLS0tLS0tLS0tLS1tZW1vcnktLS0tLS0tLS0tIC0tLXN3YXAtLSAtLS0tLWlvLS0tLSAt LXN5c3RlbS0tIC0tLS1jcHUtLS0tCiByICBiICAgc3dwZCAgIGZyZWUgICBidWZmICBjYWNoZSAg IHNpICAgc28gICAgYmkgICAgYm8gICBpbiAgICBjcyB1cyBzeSBpZCB3YQogMSAgMCAgICAgIDAg MTc4MjQwICAyMDM2MCAgNjM2ODggICAgMCAgICAwICAgMTAxICAgIDMzICAyNzYgICAxNjkgMTUg IDIgODAgIDIKIDAgIDAgICAgICAwIDE3ODI0MCAgMjA0MDAgIDYzNjk2ICAgIDAgICAgMCAgICAg OCAgICA2OCAxMDE5ICAgIDI3ICAwICAxIDk2ICAzCiAwICAwICAgICAgMCAxNzgyNDAgIDIwNDAw ICA2MzY5NiAgICAwICAgIDAgICAgIDAgICAgIDAgMTAwNiAgICAgOCAgMCAgMCAxMDAgIDAKIDAg IDAgICAgICAwIDE3ODI0MCAgMjA0MDAgIDYzNjk2ICAgIDAgICAgMCAgICAgMCAgICAgMCAxMDA4 ICAgIDE0ICAwICAwIDEwMCAgMAogMCAgMCAgICAgIDAgMTc4MjQwICAyMDQwMCAgNjM2OTYgICAg MCAgICAwICAgICAwICAgICAwIDEwMDQgICAgMTIgIDAgIDAgMTAwICAwCiAwICAwICAgICAgMCAx NzgyNDAgIDIwNDAwICA2MzY5NiAgICAwICAgIDAgICAgIDAgICAgIDAgMTAwNSAgICAxNCAgMCAg MCAxMDAgIDAKIDAgIDAgICAgICAwIDE3ODI0MCAgMjA0MTIgIDYzNjk2ICAgIDAgICAgMCAgICAg MCAgICAyMCAxMDExICAgIDIwICAwICAwIDEwMCAgMAogMCAgMCAgICAgIDAgMTc4MTc2ICAyMDQ2 MCAgNjM2OTYgICAgMCAgICAwICAgICA0ICAgIDcyIDEwMjQgICAgMzcgIDAgIDAgOTkgIDEKIDEg IDAgICAgICAwIDE3MTAxMiAgMjA0NjggIDcwNTEyICAgIDAgICAgMCAgICAgMCAgICAgMCAyNTg5 ICAgMjIyICAwIDc1IDI1ICAwCiAxICAwICAgICAgMCAxNjIyNDQgIDIwNDc2ICA3OTI4MCAgICAw ICAgIDAgICAgIDAgICAgIDAgNTQ5NyAgIDI4OSAgMCAxMDAgIDAgIDAKIDEgIDAgICAgICAwIDE1 MzczMiAgMjA0ODQgIDg4MDQ4ICAgIDAgICAgMCAgICAgMCAgICAgMCA1NjE4ICAxMjE0ICAwIDEw MCAgMCAgMAogMSAgMSAgICAgIDAgMTQ1NTQwICAyMTAxNiAgOTUyODAgICAgMCAgICAwICAgICAw ICA1ODQ4IDQ4ODcgICA1MjggIDEgOTkgIDAgIDAKIDEgIDEgICAgICAwIDEzOTI2OCAgMjEwMjAg MTAxNTUyICAgIDAgICAgMCAgICAgMCAgNTI3NiA0NDE0ICAxMjYwICAwIDEwMCAgMCAgMAogMSAg MiAgICAgIDAgMTMyMjI4ICAyMTAyOCAxMDg2NTYgICAgMCAgICAwICAgICAwICAyODI4IDQ5OTIg IDU1MDAgIDAgMTAwICAwICAwCiAxICAyICAgICAgMCAxMjUzODAgIDIxMDM2IDExNTQwOCAgICAw ICAgIDAgICAgIDAgIDQzMjAgNDg4NSAgNjAyNCAgMCAxMDAgIDAgIDAKIDEgIDIgICAgICAwIDEx OTA0NCAgMjEwNDAgMTIxODQwICAgIDAgICAgMCAgICAgMCAgNTc2MCA1MzUyICA1ODI5ICAwIDEw MCAgMCAgMAogMSAgMiAgICAgIDAgMTEzOTg4ICAyMTA0OCAxMjY4MzIgICAgMCAgICAwICAgICAw ICA2MTk2IDQyNjggIDQ3MzEgIDEgOTkgIDAgIDAKIDIgIDEgICAgICAwIDEwOTc2NCAgMjEwNTIg MTMwODg4ICAgIDAgICAgMCAgICAgMCAgNTIyNCA0MDExICAzNzY2ICAwIDY0ICAwIDM2CiAxICAw ICAgICAgMCAxMDM4NzYgIDIxMDU2IDEzNjgxMiAgICAwICAgIDAgICAgIDAgIDc4NzYgNDgzMSAg NTYxOCAgMCAxMDAgIDAgIDAKIDEgIDAgICAgICAwICA5NjUxNiAgMjEwNjQgMTQzOTE2ICAgIDAg ICAgMCAgICAgMCAgICAgMCA1NTI5ICA2NjcxICAwIDEwMCAgMCAgMAogMSAgMCAgICAgIDAgIDkx MzMyICAyMTA2OCAxNDkwNjggICAgMCAgICAwICAgICAwICA5MzQ4IDM4MDQgIDQ4NjQgIDAgMTAw ICAwICAwCnByb2NzIC0tLS0tLS0tLS0tbWVtb3J5LS0tLS0tLS0tLSAtLS1zd2FwLS0gLS0tLS1p by0tLS0gLS1zeXN0ZW0tLSAtLS0tY3B1LS0tLQogciAgYiAgIHN3cGQgICBmcmVlICAgYnVmZiAg Y2FjaGUgICBzaSAgIHNvICAgIGJpICAgIGJvICAgaW4gICAgY3MgdXMgc3kgaWQgd2EKIDIgIDEg ICAgICAwICA4Mjk0OCAgMjEwNzYgMTU3MDY0ICAgIDAgICAgMCAgICAgMCAgNjcyNCA2Mjg3ICA3 NTAzICAwIDEwMCAgMCAgMAogMSAgMSAgICAgIDAgIDc5MzY0ICAyMTM1NiAxNTk4NDggICAgMCAg ICAwICAgICAwIDM2MjIwIDE5NjcgIDI3MTkgIDAgMTAwICAwICAwCiAxICAxICAgICAgMCAgNzYy MjggIDIxMzYwIDE2MzMzNiAgICAwICAgIDAgICAgIDAgICAgIDAgMjA2NCAgMzMzNSAgMCAxMDAg IDAgIDAKIDEgIDAgICAgICAwICA3MTYyMCAgMjEzNjQgMTY4MjI0ICAgIDAgICAgMCAgICAgMCAg IDI4MCAzNDIyICA0NTc2ICAxIDk5ICAwICAwCiAxICAwICAgICAgMCAgNjc3MTYgIDIxNDI0IDE3 MjA5MiAgICAwICAgIDAgICAgIDAgMTA4MDggMzY4MSAgMzc3NSAgMCA1NiAgMCA0NAogMSAgMCAg ICAgIDAgIDU5Mzk2ICAyMTQzMiAxODAyODQgICAgMCAgICAwICAgICAwICAgICAwIDYzNTYgIDc2 NzYgIDAgMTAwICAwICAwCiAxICAwICAgICAgMCAgNTEwMTIgIDIxNDQwIDE4ODUzNiAgICAwICAg IDAgICAgIDAgICAgIDAgNjM3OSAgNzczOSAgMCAxMDAgIDAgIDAKIDEgIDAgICAgICAwICA0MjYy OCAgMjE0NDggMTk2ODM2ICAgIDAgICAgMCAgICAgMCAgICAgMCA2NDY1ICA3NzcyICAwIDEwMCAg MCAgMAogMSAgMSAgICAgIDAgIDM1NDYwICAyMTUzMiAyMDMyNTYgICAgMCAgICAwICAgICAwIDMz MzM2IDQ4MzYgIDU5ODYgIDAgMTAwICAwICAwCiAxICAxICAgICAgMCAgMzIxOTYgIDIxNTM2IDIw Njg1MiAgICAwICAgIDAgICAgIDAgICAgIDAgMjE4MCAgMzQzMCAgMCAxMDAgIDAgIDAKIDEgIDAg ICAgICAwICAyNzkwOCAgMjE1NDAgMjExMjUyICAgIDAgICAgMCAgICAgMCAgIDM3NiAzMDIxICA0 MTY1ICAwIDEwMCAgMCAgMAogMSAgMCAgICAgIDAgIDE5NjUyICAyMTU0OCAyMTk0MjggICAgMCAg ICAwICAgICAwICAgICA0IDYxNTQgIDc2NjEgIDAgMTAwICAwICAwCiAxICAwICAgICAgMCAgMTE1 MjQgIDIxNTU2IDIyNzUwNCAgICAwICAgIDAgICAgIDAgICAgIDQgNjQxNiAgNzU2MyAgMCAxMDAg IDAgIDAKIDEgIDAgICAgICAwICAgMzEyOCAgMjE1NjQgMjM1NzcyICAgIDAgICAgMCAgICAgMCAg ICAgMCA2NDMyICA3NzQ2ICAxIDk5ICAwICAwCiAzICAwICAgICAgMCAgIDIzNTIgIDE3NDI4IDI0 MDk4OCAgICAwICAgIDAgICAgIDAgIDM2MDQgNTQxMSAgNTk4MiAgMCAxMDAgIDAgIDAKIDAgIDIg ICAgICAwICAgMjgxNiAgMTYwODAgMjQxMDY0ICAgIDAgICAgMCAgICAgMCAzMjg2MCA0NjQzICAz MzY0ICAwIDg1ICAwIDE1CiAyICAxICAgICAgMCAgIDI4MzIgIDE1NjA0IDI0MTk0NCAgICAwICAg IDAgICAgIDAgICAyOTIgMjA5MSAgMjU5MSAgMCA4NCAgMCAxNgogMiAgMSAgICAgIDAgICAyNjAw ICAxNDgzNiAyNDM1MDQgICAgMCAgICAwICAgICAwICAzNjQwIDMzNTggIDQxNjcgIDAgMTAwICAw ICAwCiAyICAwICAgICAgMCAgIDI4NTYgIDEzODM2IDI0NDY2NCAgICAwICAgIDAgICAgIDAgIDU3 OTYgNDM5NiAgMTkzMSAgMCAxMDAgIDAgIDAKIDAgIDEgICAgICAwICAgMjIyNCAgMTM1MzIgMjQ1 NzQwICAgIDAgICAgMCAgICAgMCAgNDIyNCAyOTcwICAyMzEyICAwIDM1ICAwIDY1CiAwICAxICAg ICAgMCAgIDMwNjAgIDEzNDA0IDI0NDgyOCAgICAwICAgIDAgICAgIDAgIDgwMjggMTY2MCAgICA1 MiAgMCAgNSAgMCA5NQpwcm9jcyAtLS0tLS0tLS0tLW1lbW9yeS0tLS0tLS0tLS0gLS0tc3dhcC0t IC0tLS0taW8tLS0tIC0tc3lzdGVtLS0gLS0tLWNwdS0tLS0KIHIgIGIgICBzd3BkICAgZnJlZSAg IGJ1ZmYgIGNhY2hlICAgc2kgICBzbyAgICBiaSAgICBibyAgIGluICAgIGNzIHVzIHN5IGlkIHdh CiAyICAwICAgICAgMCAgIDI3MzYgIDEzMzgwIDI0NTcwOCAgICAwICAgIDAgICAgIDAgIDMxNDgg MzMxMCAgMjMxNyAgMCA0MiAgMCA1OAogMSAgMCAgICAgIDAgICAyODU2ICAxMjYxNiAyNDY1MDAg ICAgMCAgICAwICAgICAwICAgICAwIDY4OTIgIDU3OTIgIDAgMTAwICAwICAwCiAxICAxICAgICAg MCAgIDI3MzIgIDEyMzk2IDI0NzU0NCAgICAwICAgIDAgICAgIDAgIDI2MjQgNjI4NyAgMTEzMSAg MCAxMDAgIDAgIDAKIDEgIDEgICAgICAwICAgMjUzNiAgMTIxMDAgMjQ4MTk2ICAgIDAgICAgMCAg ICAgMCAxMTQwNCAzOTQwICAgMjUxICAwIDEwMCAgMCAgMAo= ------=_Part_60_22762740.1091387012317 Content-Type: application/octet-stream; name="clientlog-ftpput" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="clientlog-ftpput" cHJvY3MgLS0tLS0tLS0tLS1tZW1vcnktLS0tLS0tLS0tIC0tLXN3YXAtLSAtLS0tLWlvLS0tLSAt LXN5c3RlbS0tIC0tLS1jcHUtLS0tCiByICBiICAgc3dwZCAgIGZyZWUgICBidWZmICBjYWNoZSAg IHNpICAgc28gICAgYmkgICAgYm8gICBpbiAgICBjcyB1cyBzeSBpZCB3YQogMSAgMCAgICAgIDAg MTk4MzEyICA3MDMzNiAyNTgyNDAgICAgMCAgICAwICAgMjk5ICAgIDg1IDE1MzYgICA3NjcgIDgg IDYgNzggIDgKIDAgIDAgICAgICAwIDE5ODIyOCAgNzAzMzYgMjU4MzA4ICAgIDAgICAgMCAgICA2 OCAgICAgMCAxNDM3ICAgNDYzICAzICAxIDk0ICAyCiAwICAwICAgICAgMCAxOTgyMjggIDcwMzM2 IDI1ODMwOCAgICAwICAgIDAgICAgIDAgICAgIDAgMjAxMyAgMTU4OSAxMSAgNiA4MyAgMAogMCAg MSAgICAgIDAgMTk2NjUyICA3MDM4OCAyNTk4MjAgICAgMCAgICAwICAxNTA2ICAgIDkyIDIzMjkg ICA1NDAgIDIgIDMgODcgIDgKIDAgIDAgICAgICAwIDE5MDI0MCAgNzAzOTIgMjY2MjA4ICAgIDAg ICAgMCAgNjQxNCAgICAgMCA2NTY3ICAgODA4ICAwIDExIDg0ICA1CiAwICAwICAgICAgMCAxODM2 MDQgIDcwNDAwIDI3Mjg2NCAgICAwICAgIDAgIDY2NjIgICAgIDAgNjYxOCAgIDgxNCAgMCAxMCA4 NCAgNgogMCAgMCAgICAgIDAgMTc5MjM2ICA3MDQwNCAyNzcyMTIgICAgMCAgICAwICA0MzU3ICAg ICAwIDUzMDMgIDEzMDUgIDYgMTAgODEgIDMKIDAgIDAgICAgICAwIDE3NTAyNCAgNzA0MDggMjgx NDI0ICAgIDAgICAgMCAgNDIyOCAgICAgMCA0NTQ1ICAgNzEyICAxICA3IDg5ICAzCiAwICAwICAg ICAgMCAxNjc4MzIgIDcwNDI4IDI4ODEzNiAgICAwICAgIDAgIDY3MTggICAgMjAgNzM2OSAgMTAy NiAgOCAxMyA3MyAgNgogMCAgMCAgICAgIDAgMTYwNDkyICA3MDQzMiAyOTQ3OTYgICAgMCAgICAw ICA2NjYzICAgICAwIDY2NDggICA5MDYgIDAgIDkgODUgIDUKIDAgIDAgICAgICAwIDE1MzIzNiAg NzA0NDAgMzAxMzg0ICAgIDAgICAgMCAgNjUzNCAgICAgMCA2NjEyICAgOTA1ICAxIDExIDgzICA1 CiAwICAwICAgICAgMCAxNDU3NDggIDcwNDQ4IDMwODEwOCAgICAwICAgIDAgIDY3OTEgICAgIDAg NjY5NiAgIDkyNiAgMSAxMSA4MSAgNwogMCAgMCAgICAgIDAgMTQyNjEyICA3MDQ0OCAzMTA5NjQg ICAgMCAgICAwICAyODE4ICAgICAwIDM0NzcgICA2NDggIDEgIDUgOTIgIDIKIDAgIDAgICAgICAw IDE0MjYxMiAgNzA0NjAgMzEwOTUyICAgIDAgICAgMCAgICAgMCAgICAyMCAxMTEyICAgNTAwICAw ICAwIDEwMCAgMAogMCAgMCAgICAgIDAgMTM1OTU2ICA3MDQ2OCAzMTY5OTYgICAgMCAgICAwICA2 MDIyICAgICAwIDYxMjkgICA4NTYgIDEgMTAgODQgIDUKIDAgIDAgICAgICAwIDEyODcyNCAgNzA0 NzIgMzIzNTIwICAgIDAgICAgMCAgNjUzNSAgICAgMCA2NjcwICAgODg4ICAxIDEzIDgwICA2CiAw ICAwICAgICAgMCAxMjEzNjQgIDcwNDgwIDMzMDE3NiAgICAwICAgIDAgIDY2NjIgICAgIDAgNjYw NiAgIDg5NCAgMCAxMSA4MyAgNgogMCAgMCAgICAgIDAgMTE0MDA0ICA3MDQ4OCAzMzY4MzIgICAg MCAgICAwICA2NjYzICAgICAwIDY2NzggICA5MjUgIDEgMTIgODEgIDYKIDAgIDAgICAgICAwIDEw NzE1NiAgNzA1MDQgMzQyOTM2ICAgIDAgICAgMCAgNjE1MCAgICAyMCA2MzYwICAgODY3ICAxIDEw IDgyICA2CiAwICAwICAgICAgMCAxMDQzNDAgIDcwNTA4IDM0NTUxNiAgICAwICAgIDAgIDI1NjIg ICAgIDAgMzIwMCAgIDY4NSAgMSAgNSA5MSAgMwogMCAgMCAgICAgIDAgMTAxMzk2ICA3MDUwOCAz NDgxNjggICAgMCAgICAwICAyNjkxICAgICAwIDMzMzggICA2NDUgIDAgIDMgOTUgIDIKcHJvY3Mg LS0tLS0tLS0tLS1tZW1vcnktLS0tLS0tLS0tIC0tLXN3YXAtLSAtLS0tLWlvLS0tLSAtLXN5c3Rl bS0tIC0tLS1jcHUtLS0tCiByICBiICAgc3dwZCAgIGZyZWUgICBidWZmICBjYWNoZSAgIHNpICAg c28gICAgYmkgICAgYm8gICBpbiAgICBjcyB1cyBzeSBpZCB3YQogMiAgMCAgICAgIDAgIDk0MTY0 ICA3MDUxNiAzNTQ3NTYgICAgMCAgICAwICA2NTM0ICAgICAwIDY2OTggICA5MDQgIDEgMTEgODIg IDYKIDAgIDAgICAgICAwICA4Njc0MCAgNzA1MjQgMzYxNDEyICAgIDAgICAgMCAgNjY2MyAgICAg MCA2NjY4ICAgOTM1ICA0IDEyIDc3ICA2CiAwICAwICAgICAgMCAgNzkzODAgIDcwNTQwIDM2ODA2 MCAgICAwICAgIDAgIDY2NjIgICAgMjAgNjY1MSAgIDg5NyAgMSAxMSA4MyAgNQogMCAgMCAgICAg IDAgIDcyMDIwICA3MDU0OCAzNzQ3MTYgICAgMCAgICAwICA2NjYzICAgICAwIDY2ODUgICA5MDMg IDEgMTEgODIgIDYKIDAgIDAgICAgICAwICA2NjcyMCAgNzA1NTIgMzc5Njc2ICAgIDAgICAgMCAg NDk5NyAgICAgMCA1Nzc3ICAgODcxICAyICA4IDg1ICA0CiAxICAwICAgICAgMCAgNjQxNDggIDcw NTU2IDM4MTk4NCAgICAwICAgIDAgIDIzMDYgICAgIDAgMzMwOSAgMTAzOSAgNSAgNiA4NyAgMgog MCAgMCAgICAgIDAgIDYwNzY0ICA3MDU1NiAzODUwNDQgICAgMCAgICAwICAzMDc1ICAgICAwIDQw MTMgICA2MzEgIDEgIDYgOTEgIDIKIDAgIDAgICAgICAwICA1MzQwNCAgNzA1NzYgMzkxNjg4ICAg IDAgICAgMCAgNjY2MiAgICAyMCA3MzAyICAxMzkwICA1IDE1IDc0ICA2CiAxICAwICAgICAgMCAg NDY0MTIgIDcwNTgwIDM5ODAwOCAgICAwICAgIDAgIDYyNzggICAgIDAgNjgyNCAgMTQ1OSAgNiAx NSA3NSAgNAogMCAgMCAgICAgIDAgIDQ2NDEyICA3MDU4MCAzOTgwMDggICAgMCAgICAwICAgICAw ICAgICAwIDExOTEgICA0MDAgIDEgIDEgOTggIDAKIDAgIDAgICAgICAwICA0NjQxMiAgNzA1ODAg Mzk4MDA4ICAgIDAgICAgMCAgICAgMCAgICAgMCAxMDkxICAgMzk2ICAwICAxIDk5ICAwCiAwICAw ICAgICAgMCAgNDY0MTIgIDcwNTgwIDM5ODAwOCAgICAwICAgIDAgICAgIDAgICAgIDAgMTExMyAg IDQzNiAgMSAgMCA5OSAgMAogMCAgMCAgICAgIDAgIDQ2NDEyICA3MDU5MiAzOTc5OTYgICAgMCAg ICAwICAgICAwICAgIDIwIDExMjcgICA1NjMgIDIgIDAgOTggIDAKIDAgIDAgICAgICAwICA0NjQx MiAgNzA1OTIgMzk3OTk2ICAgIDAgICAgMCAgICAgMCAgICAgMCAxMTcxICAgNjE3ICAzICAxIDk2 ICAwCiAwICAwICAgICAgMCAgNDY0MjggIDcwNTkyIDM5Nzk5NiAgICAwICAgIDAgICAgIDAgICAg IDAgMTMwMCAgIDU4MCAgMyAgMSA5NiAgMAogMCAgMCAgICAgIDAgIDQ2NDI4ICA3MDU5MiAzOTc5 OTYgICAgMCAgICAwICAgICAwICAgICAwIDEwOTcgICA0MDkgIDEgIDAgOTkgIDAKIDAgIDAgICAg ICAwICA0NjQyOCAgNzA1OTIgMzk3OTk2ICAgIDAgICAgMCAgICAgMCAgICAgMCAxMjAzICAgODA0 ICA1ICAxIDk0ICAwCiAwICAwICAgICAgMCAgNDYzMDAgIDcwNjQwIDM5ODAxNiAgICAwICAgIDAg ICAgIDAgICAxMTIgMTIzNiAgMTI3MyAxMSAgMyA4NiAgMAogMCAgMCAgICAgIDAgIDQ2MzAwICA3 MDY0MCAzOTgwMTYgICAgMCAgICAwICAgICAwICAgICAwIDE1NjggIDE1NzQgMTMgIDQgODMgIDAK IDAgIDAgICAgICAwICA0NjYyMCAgNzA2NDAgMzk4MDE2ICAgIDAgICAgMCAgICAgMCAgICAgMCAy Mjk4ICAxNDM5IDEyICA2IDgyICAwCiAwICAwICAgICAgMCAgNDY2NDggIDcwNjQwIDM5ODAxNiAg ICAwICAgIDAgICAgIDAgICAgIDAgMTQwOCAgIDkwOCAgNSAgMiA5MyAgMAo= ------=_Part_60_22762740.1091387012317 Content-Type: application/octet-stream; name="clientlog-nfsput" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="clientlog-nfsput" cHJvY3MgLS0tLS0tLS0tLS1tZW1vcnktLS0tLS0tLS0tIC0tLXN3YXAtLSAtLS0tLWlvLS0tLSAt LXN5c3RlbS0tIC0tLS1jcHUtLS0tCiByICBiICAgc3dwZCAgIGZyZWUgICBidWZmICBjYWNoZSAg IHNpICAgc28gICAgYmkgICAgYm8gICBpbiAgICBjcyB1cyBzeSBpZCB3YQogMSAgMCAgICAgIDAg IDE2Nzc2IDI5MjAxMiAxNjY5ODggICAgMCAgICAwICAgMjc2ICAgIDg3IDE1MjEgICA3NzAgIDgg IDYgNzggIDgKIDAgIDAgICAgICAwICAxNjc0OCAyOTIwMTIgMTY2OTg4ICAgIDAgICAgMCAgICAg MCAgICAgMCAxNDc2ICAgNDE2ICAzICAxIDk2ICAwCiAwICAwICAgICAgMCAgMTY3NDggMjkyMDEy IDE2Njk4OCAgICAwICAgIDAgICAgIDAgICAgIDAgMjY0MCAgMTU2NCAxMiAgNiA4MiAgMAogMCAg MCAgICAgIDAgIDE2NzQ4IDI5MjAxMiAxNjY5ODggICAgMCAgICAwICAgICAwICAgICAwIDExMDQg ICA0MjYgIDEgIDAgOTkgIDAKIDAgIDAgICAgICAwICAxNjc0OCAyOTIwMTIgMTY2OTg4ICAgIDAg ICAgMCAgICAgMCAgICAgMCAxMjE5ICAgNDM1ICAxICAxIDk4ICAwCiAwICAxICAgICAgMCAgMTUz NTYgMjkyMDUyIDE2ODMwOCAgICAwICAgIDAgICA3NDQgICAgODAgMTI1OSAgIDQ4OCAgMSAgMiA5 MyAgNAogMCAgMSAgICAgIDAgICA1MDM2IDI4NjU4MCAxODQ1MjQgICAgMCAgICAwICA5NDc2ICAg ICAwIDEyODQgICA2MjIgIDMgMTQgIDAgODMKIDAgIDEgICAgICAwICAgNDU4OCAyNzU2MzYgMTk4 ODY4ICAgIDAgICAgMCAgOTM0OCAgICAgMCAxMzAxICAgNjY0ICA0IDE3ICAwIDc5CiAwICAxICAg ICAgMCAgIDQ5NzIgMjY5Mzc2IDIwNjM1MiAgICAwICAgIDAgIDQ2MjUgICAgIDAgMTI2MyAgIDU2 NCAgMSAgOCAgMCA5MQogMSAgMSAgICAgIDAgICA1MjQ4IDI2NDI2OCAyMTIyMDggICAgMCAgICAw ICAzNzI1ICAgICAwIDE0OTUgICA2ODcgIDUgIDggIDAgODcKIDEgIDEgICAgICAwICAgNTI5MiAy Mzg3NjQgMjQzNzY0ICAgIDAgICAgMCAxOTM1OCAgICAxNiAyMTI5ICAxODg2IDE2IDM4ICAwIDQ3 CiAwICAxICAgICAgMCAgIDUxNjQgMjEyMzMyIDI3NDg4OCAgICAwICAgIDAgMTk2MTMgICAgIDgg MjE2MCAgMTAyMyAgNyAzNiAgMCA1NwogMCAgMSAgICAgIDAgICA1MDA4IDE5OTcxMiAyODkxNDAg ICAgMCAgICAwIDE0NzM5ICAgICAwIDM5MzggICA5MjEgIDYgMzIgIDAgNjIKIDAgIDEgICAgICAw ICAgNTM0NCAxODA5ODAgMzEyMDIwICAgIDAgICAgMCAxODU3OCAgICAgMCA4MTE2ICAxMTQ5ICA2 IDQ0ICAwIDQ5CiAwICAxICAgICAgMCAgIDQ5NjAgMTczMDQ4IDMyMjg3NiAgICAwICAgIDAgIDg4 NTIgICAgIDAgNzk4OCAgMTA4NiAgNCAyNSAgMCA3MQogMCAgMSAgICAgIDAgICA1MzYwIDE2MzY0 MCAzMzQxODggICAgMCAgICAwICA4NDc0ICAgICAwIDY1NzggIDEwMTIgIDUgMjIgIDAgNzMKIDAg IDIgICAgICAwICAgNTI4OCAxNTQ2NzYgMzQ2MjgwICAgIDAgICAgMCAgOTczMCAgICAgNCA0NDYz ICAgOTE1ICA0IDIzICAwIDcyCiAwICAyICAgICAgMCAgIDUzNDggMTQ1MTQwIDM1ODMzMiAgICAw ICAgIDAgIDc4MTIgICAgMTIgNzA1NiAgMTE2OCAgNCAyNSAgMCA3MQogMCAgMSAgICAgIDAgICA1 MzY4IDEzOTE1MiAzNjY1NjQgICAgMCAgICAwICA1MDY1ICAgICAwIDc3OTggIDEwNjIgIDMgMTgg IDAgNzkKIDAgIDEgICAgICAwICAgNTAxMiAxMzM3ODAgMzcyODIwICAgIDAgICAgMCAgMzg1NSAg ICAgMCA3ODU0ICAgOTk1ICAzIDE4ICAwIDc5CiAwICAxICAgICAgMCAgIDUwMTIgMTMwMjA4IDM3 NzAwNCAgICAwICAgIDAgIDI1NzEgICAgIDAgNzg0MSAgIDk2NyAgMyAxNCAgMCA4Mwpwcm9jcyAt LS0tLS0tLS0tLW1lbW9yeS0tLS0tLS0tLS0gLS0tc3dhcC0tIC0tLS0taW8tLS0tIC0tc3lzdGVt LS0gLS0tLWNwdS0tLS0KIHIgIGIgICBzd3BkICAgZnJlZSAgIGJ1ZmYgIGNhY2hlICAgc2kgICBz byAgICBiaSAgICBibyAgIGluICAgIGNzIHVzIHN5IGlkIHdhCiAxICAxICAgICAgMCAgIDUxMzYg MTI4MjkyIDM3OTA1NiAgICAwICAgIDAgIDExNjEgICAgIDAgNzI3MCAgMjAzOSAxMiAxNiAgMCA3 MgogMCAgMSAgICAgIDAgICA0NzYwIDEyMDY1NiAzODgzOTIgICAgMCAgICAwICA1OTA0ICAgICAw IDQwNTkgICA4MDUgIDQgMTUgIDAgODEKIDAgIDIgICAgICAwICAgNTUzNiAxMTE2ODggMzk3NDk2 ICAgIDAgICAgMCAgNTc2MiAgICAxMiA0MTk1ICAgODk5ICAzIDE1ICAwIDgyCiAxICAxICAgICAg MCAgIDU1MjggMTA4MDMyIDQwMTc2NCAgICAwICAgIDAgIDI3MjEgICAgIDQgMzYwNSAgIDg1MSAg MyAxMSAgMCA4NgogMCAgMSAgICAgIDAgICA1Mjc2IDEwMDk1MiA0MTAyMDQgICAgMCAgICAwICA1 MjQzICAgICAwIDc2NDEgIDEwNDUgIDIgMjAgIDAgNzgKIDAgIDEgICAgICAwICAgNDYzNiAgOTU1 MzIgNDE3MTg4ICAgIDAgICAgMCAgNDI4OSAgICAgMCA3NjIxICAxMDQyICAzIDE1ICAwIDgxCiAw ICAxICAgICAgMCAgIDU2MTIgIDkwODA4IDQyMTQzNiAgICAwICAgIDAgIDI3ODEgICAgIDAgNzYw OSAgMTA1MyAgMiAxNCAgMCA4NAogMCAgMSAgICAgIDAgICA1Mjc2ICA4MDcyNCA0MzM2OTYgICAg MCAgICAwICA3MjU2ICAgICA0IDc3NDggIDEwOTMgIDMgMjIgIDAgNzQKIDAgIDAgICAgICAwICAg NDkwOCAgNjk4NzIgNDQ2MDQ0ICAgIDAgICAgMCAgNzUzMyAgICAyMCA1MDc0ICAgOTQ4ICA0IDE3 IDYxIDE3CiAwICAwICAgICAgMCAgIDQ5MDggIDY5ODcyIDQ0NjA0NCAgICAwICAgIDAgICAgIDAg ICAgIDAgMzgwMyAgIDYxMCAgMCAgMyA5NyAgMAogMCAgMCAgICAgIDAgICA0OTA4ICA2OTg3MiA0 NDYwNDQgICAgMCAgICAwICAgICAwICAgICAwIDUwNjQgICA3MTMgIDEgIDMgOTYgIDAKIDAgIDAg ICAgICAwICAgNDk3MiAgNjk4NzIgNDQ2MDQ0ICAgIDAgICAgMCAgICAgMCAgICAgMCA2OTc4ICAg ODY0ICAwICA4IDkyICAwCiAwICAwICAgICAgMCAgIDUxNjQgIDY5ODcyIDQ0NjA0NCAgICAwICAg IDAgICAgIDAgICAgIDAgNzQ5MyAgIDkxNCAgMCAgNiA5NCAgMAogMCAgMCAgICAgIDAgICA1MTY0 ICA2OTg4NCA0NDYwMzIgICAgMCAgICAwICAgICAwICAgIDIwIDEyMDcgICA0MTkgIDEgIDEgOTgg IDAKIDAgIDAgICAgICAwICAgNjM4MCAgNjk4ODQgNDQ2MDMyICAgIDAgICAgMCAgICAgMCAgICAg MCA0OTkyICAgNzEyICAwICA2IDk0ICAwCiAwICAwICAgICAgMCAgIDY1MDggIDY5ODg0IDQ0NjAz MiAgICAwICAgIDAgICAgIDAgICAgIDAgNzM5NCAgIDkxNSAgMCAgNSA5NSAgMAogMCAgMCAgICAg IDAgICA2NTcyICA2OTg4NCA0NDYwMzIgICAgMCAgICAwICAgICAwICAgICAwIDM4NTggICA2MTkg IDEgIDUgOTQgIDAKIDAgIDAgICAgICAwICAgNjYzNiAgNjk4ODQgNDQ2MTAwICAgIDAgICAgMCAg ICAxMiAgICAgMCA1NzAwICAgODIwICAxICA0IDk0ICAxCiAwICAwICAgICAgMCAgIDc2MDAgIDY5 OTI4IDQ0NjA1NiAgICAwICAgIDAgICAgIDAgICAxMDQgNTg2MCAgIDc4MyAgMSAgNyA5MiAgMAog MCAgMCAgICAgIDAgICA4MTE2ICA2OTkyOCA0NDYwNTYgICAgMCAgICAwICAgICAwICAgICAwIDU0 ODkgICA3NjIgIDMgIDYgOTEgIDAKIDAgIDAgICAgICAwICAgODQ0MCAgNjk5MjggNDQ2MDU2ICAg IDAgICAgMCAgICAgMCAgICAgMCA2MDIwICAgODUyICAxICA2IDkzICAwCnByb2NzIC0tLS0tLS0t LS0tbWVtb3J5LS0tLS0tLS0tLSAtLS1zd2FwLS0gLS0tLS1pby0tLS0gLS1zeXN0ZW0tLSAtLS0t Y3B1LS0tLQogciAgYiAgIHN3cGQgICBmcmVlICAgYnVmZiAgY2FjaGUgICBzaSAgIHNvICAgIGJp ICAgIGJvICAgaW4gICAgY3MgdXMgc3kgaWQgd2EKIDEgIDAgICAgICAwICAgODU2OCAgNjk5Mjgg NDQ2MDU2ICAgIDAgICAgMCAgICAgMCAgICAgMCA1NDMzICAgODIyICAxICA1IDk0ICAwCiAwICAw ICAgICAgMCAgMTA0ODggIDY5OTQ0IDQ0NjA0MCAgICAwICAgIDAgICAgIDcgICAgIDAgMjA5OSAg IDcyOCAgNCAgNiA4NiAgNAogMCAgMCAgICAgIDAgIDEwNDgwICA2OTk1NiA0NDYwOTYgICAgMCAg ICAwICAgICAwICAgIDIwIDEyMjQgICA5NTIgIDQgIDEgOTUgIDAKIDAgIDAgICAgICAwICAxMDQ4 MCAgNjk5NTYgNDQ2MDk2ICAgIDAgICAgMCAgICAgMCAgICAgMCAxMjgzICAgNDY1ICAyICAxIDk3 ICAwCiAwICAwICAgICAgMCAxOTkyNTIgIDY5OTU2IDI1NzYwMCAgICAwICAgIDAgICAgIDAgICAg IDAgMTc3OSAgMTMwMCAgOSAgNyA4NCAgMAogMCAgMCAgICAgIDAgMTk5MjUyICA2OTk1NiAyNTc2 MDAgICAgMCAgICAwICAgICAwICAgICAwIDE0NDUgIDEyMDUgMTkgIDQgNzcgIDAK ------=_Part_60_22762740.1091387012317-- From jgarzik@pobox.com Sun Aug 1 12:03:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 12:03:53 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i71J3jMr030684 for ; Sun, 1 Aug 2004 12:03:48 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.33) id 1BrLcR-0005Pa-LB; Sun, 01 Aug 2004 20:03:39 +0100 Message-ID: <410D3E77.4090303@pobox.com> Date: Sun, 01 Aug 2004 15:03:19 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wright CC: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ethtool_get_regs copy right number of bytes to user References: <20040615155541.Q21045@build.pdx.osdl.net> In-Reply-To: <20040615155541.Q21045@build.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7395 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From manfred@colorfullife.com Sun Aug 1 12:13:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 12:13:30 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i71JDNut031783 for ; Sun, 1 Aug 2004 12:13:24 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i71JCbuG024874; Sun, 1 Aug 2004 21:12:39 +0200 Message-ID: <410D4120.2020604@colorfullife.com> Date: Sun, 01 Aug 2004 21:14:40 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Drabb CC: netdev@oss.sgi.com, c-d.hailfinger.kernel.2004@gmx.net Subject: Re: forcedeth References: <410D3377.3030505@tampabay.rr.com> In-Reply-To: <410D3377.3030505@tampabay.rr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred@colorfullife.com Precedence: bulk X-list: netdev James Drabb wrote: > jim@keelie $ uname -a > Linux keelie 2.6.7-1 #1 Thu Jul 22 11:42:58 CEST 2004 i686 athlon i386 > GNU/Linux There should be a message in the dmesg log about the driver version: If it's less than 0.28: could you try a newer kernel? 0.28 is definitively in 2.5.8-rc1-mm1 and later. I could also send you just the forcedeth.c file, then you don't have to upgrade the whole kernel. > However, if I reboot into WinXP, and then reboot right away back into > FC2, the forcedeth driver works like a champ. Probably the phy reset and/or the media detection do not work properly. That part is completely rewritten in 0.28. I'm interested in two infos: - with 2.6.7 (probably version 0.25), after booting into winXP first: what does # ethtool eth0 report? Then unplug the network cable. Run ethtool again. Does it report "Link detected: No"? What if you plug the network cable back in? - The same thing with the 0.28 driver. Note that the phy initialization in 0.28 is not perfect either: it seems there is a race between the phy reset and the media detection. You might have to wait 2 seconds or so between modprobe and ifup. -- Manfred From JDrabb@tampabay.rr.com Sun Aug 1 15:00:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 15:00:54 -0700 (PDT) Received: from ms-smtp-04.tampabay.rr.com (ms-smtp-04-smtplb.tampabay.rr.com [65.32.5.134]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i71M0kjG005473 for ; Sun, 1 Aug 2004 15:00:47 -0700 Received: from [192.168.1.101] (189-66.35-65.tampabay.rr.com [65.35.66.189]) by ms-smtp-04.tampabay.rr.com (8.12.10/8.12.7) with ESMTP id i71M0Z7t029887; Sun, 1 Aug 2004 18:00:35 -0400 (EDT) Message-ID: <410D682F.4090809@tampabay.rr.com> Date: Sun, 01 Aug 2004 18:01:19 -0400 From: James Drabb User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: netdev@oss.sgi.com, c-d.hailfinger.kernel.2004@gmx.net Subject: Re: forcedeth References: <410D3377.3030505@tampabay.rr.com> <410D4120.2020604@colorfullife.com> In-Reply-To: <410D4120.2020604@colorfullife.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-archive-position: 7397 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: JDrabb@tampabay.rr.com Precedence: bulk X-list: netdev Manfred Spraul wrote: > James Drabb wrote: > >> jim@keelie $ uname -a >> Linux keelie 2.6.7-1 #1 Thu Jul 22 11:42:58 CEST 2004 i686 athlon i386 >> GNU/Linux > > > There should be a message in the dmesg log about the driver version: If > it's less than 0.28: could you try a newer kernel? 0.28 is definitively > in 2.5.8-rc1-mm1 and later. I could also send you just the forcedeth.c > file, then you don't have to upgrade the whole kernel. dmesg shows version 0.25. > Probably the phy reset and/or the media detection do not work properly. > That part is completely rewritten in 0.28. > > I'm interested in two infos: > - with 2.6.7 (probably version 0.25), after booting into winXP first: > what does > # ethtool eth0 > report? Then unplug the network cable. Run ethtool again. Does it report > "Link detected: No"? What if you plug the network cable back in? ethtool eth0 shows: Settings for eth0: Supports Wake-on: g Wake-on: d Link detected: yes Unplugging the network cable showed the same settings: Settings for eth0: Supports Wake-on: g Wake-on: d Link detected: yes > -- > Manfred Please send me the latest forcedeth.c and I will give it a go. Do you have the makefile so I can compile the module outside of the kernel? Thanks, Jim Drabb -- James Drabb Senior Programmer Davenport, FL USA From laforge@netfilter.org Sun Aug 1 16:03:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 16:04:03 -0700 (PDT) Received: from ganesha.gnumonks.org (Debian-exim@ganesha.gnumonks.org [213.95.27.120]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i71N3reK007511 for ; Sun, 1 Aug 2004 16:03:55 -0700 Received: from dsl-082-083-225-237.arcor-ip.net ([82.83.225.237] helo=sunbeam.gnumonks.org) by ganesha.gnumonks.org with asmtp (TLSv1:RC4-SHA:128) (Exim 4.30) id 1BrPMl-00027N-JB; Mon, 02 Aug 2004 01:03:43 +0200 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.34) id 1BrPMg-00050K-Ab; Mon, 02 Aug 2004 01:03:38 +0200 Date: Mon, 2 Aug 2004 01:03:38 +0200 From: Harald Welte To: David Miller Cc: Netfilter Development Mailinglist , netdev@oss.sgi.com, immidi_kiran@yahoo.com Subject: [PATCH 2.6] NETFILTER: new ip_conntrack_sctp Message-ID: <20040801230338.GE18758@sunbeam2> Mail-Followup-To: Harald Welte , David Miller , Netfilter Development Mailinglist , netdev@oss.sgi.com, immidi_kiran@yahoo.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6e7ZaeXHKrTJCxdu" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-archive-position: 7398 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --6e7ZaeXHKrTJCxdu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Dave! Incremental to all other patches so far, there is also the new SCTP conntrack helper by Kiran Kumar. Please apply for 2.6.9 ++, thanks. Signed-off-by: Kiran Kumar Immidi Signed-off-by: Harald Welte Please apply, thanks. diff --exclude-from /sunbeam/home/laforge/scripts/dontdiff -Nru linux-2.6.8= -rc2-nfquilt/include/linux/netfilter_ipv4/ip_conntrack.h linux-2.6.8-rc2-nf= quilt-nfp/include/linux/netfilter_ipv4/ip_conntrack.h --- linux-2.6.8-rc2-nfquilt/include/linux/netfilter_ipv4/ip_conntrack.h 200= 4-08-02 00:51:27.793033003 +0200 +++ linux-2.6.8-rc2-nfquilt-nfp/include/linux/netfilter_ipv4/ip_conntrack.h= 2004-08-02 00:52:49.107882646 +0200 @@ -51,10 +51,12 @@ =20 #include #include +#include =20 /* per conntrack: protocol private data */ union ip_conntrack_proto { /* insert conntrack proto private data here */ + struct ip_ct_sctp sctp; struct ip_ct_tcp tcp; struct ip_ct_icmp icmp; }; diff --exclude-from /sunbeam/home/laforge/scripts/dontdiff -Nru linux-2.6.8= -rc2-nfquilt/include/linux/netfilter_ipv4/ip_conntrack_sctp.h linux-2.6.8-r= c2-nfquilt-nfp/include/linux/netfilter_ipv4/ip_conntrack_sctp.h --- linux-2.6.8-rc2-nfquilt/include/linux/netfilter_ipv4/ip_conntrack_sctp.= h 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.8-rc2-nfquilt-nfp/include/linux/netfilter_ipv4/ip_conntrack_s= ctp.h 2004-08-02 00:52:49.088883383 +0200 @@ -0,0 +1,25 @@ +#ifndef _IP_CONNTRACK_SCTP_H +#define _IP_CONNTRACK_SCTP_H +/* SCTP tracking. */ + +enum sctp_conntrack { + SCTP_CONNTRACK_NONE, + SCTP_CONNTRACK_CLOSED, + SCTP_CONNTRACK_COOKIE_WAIT, + SCTP_CONNTRACK_COOKIE_ECHOED, + SCTP_CONNTRACK_ESTABLISHED, + SCTP_CONNTRACK_SHUTDOWN_SENT, + SCTP_CONNTRACK_SHUTDOWN_RECD, + SCTP_CONNTRACK_SHUTDOWN_ACK_SENT, + SCTP_CONNTRACK_MAX +}; + +struct ip_ct_sctp +{ + enum sctp_conntrack state; + + u_int32_t vtag[IP_CT_DIR_MAX]; + u_int32_t ttag[IP_CT_DIR_MAX]; +}; + +#endif /* _IP_CONNTRACK_SCTP_H */ diff --exclude-from /sunbeam/home/laforge/scripts/dontdiff -Nru linux-2.6.8= -rc2-nfquilt/include/linux/netfilter_ipv4/ip_conntrack_tuple.h linux-2.6.8-= rc2-nfquilt-nfp/include/linux/netfilter_ipv4/ip_conntrack_tuple.h --- linux-2.6.8-rc2-nfquilt/include/linux/netfilter_ipv4/ip_conntrack_tuple= =2Eh 2004-06-16 07:19:43.000000000 +0200 +++ linux-2.6.8-rc2-nfquilt-nfp/include/linux/netfilter_ipv4/ip_conntrack_t= uple.h 2004-08-02 00:52:49.143881251 +0200 @@ -25,6 +25,9 @@ struct { u_int16_t id; } icmp; + struct { + u_int16_t port; + } sctp; }; =20 /* The manipulable part of the tuple. */ @@ -55,6 +58,9 @@ struct { u_int8_t type, code; } icmp; + struct { + u_int16_t port; + } sctp; } u; =20 /* The protocol. */ diff --exclude-from /sunbeam/home/laforge/scripts/dontdiff -Nru linux-2.6.8= -rc2-nfquilt/include/linux/sysctl.h linux-2.6.8-rc2-nfquilt-nfp/include/lin= ux/sysctl.h --- linux-2.6.8-rc2-nfquilt/include/linux/sysctl.h 2004-08-01 23:52:00.0215= 86979 +0200 +++ linux-2.6.8-rc2-nfquilt-nfp/include/linux/sysctl.h 2004-08-02 00:52:49.= 146881135 +0200 @@ -410,6 +410,13 @@ NET_IPV4_NF_CONNTRACK_ICMP_TIMEOUT=3D12, NET_IPV4_NF_CONNTRACK_GENERIC_TIMEOUT=3D13, NET_IPV4_NF_CONNTRACK_BUCKETS=3D14, + NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_CLOSED=3D15, + NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_COOKIE_WAIT=3D16, + NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_COOKIE_ECHOED=3D17, + NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_ESTABLISHED=3D18, + NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_SHUTDOWN_SENT=3D19, + NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_SHUTDOWN_RECD=3D20, + NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_SHUTDOWN_ACK_SENT=3D21, }; =20 /* /proc/sys/net/ipv6 */ diff --exclude-from /sunbeam/home/laforge/scripts/dontdiff -Nru linux-2.6.8= -rc2-nfquilt/net/ipv4/netfilter/Kconfig linux-2.6.8-rc2-nfquilt-nfp/net/ipv= 4/netfilter/Kconfig --- linux-2.6.8-rc2-nfquilt/net/ipv4/netfilter/Kconfig 2004-08-02 00:51:27.= 223055074 +0200 +++ linux-2.6.8-rc2-nfquilt-nfp/net/ipv4/netfilter/Kconfig 2004-08-02 00:52= :49.115882336 +0200 @@ -636,5 +636,9 @@ tristate 'SCTP protocol match support' depends on IP_NF_IPTABLES =20 +config IP_NF_CT_PROTO_SCTP + tristate 'SCTP protocol connection tracking support (EXPERIMENTAL)' + depends on IP_NF_CONNTRACK && EXPERIMENTAL + endmenu =20 diff --exclude-from /sunbeam/home/laforge/scripts/dontdiff -Nru linux-2.6.8= -rc2-nfquilt/net/ipv4/netfilter/Makefile linux-2.6.8-rc2-nfquilt-nfp/net/ip= v4/netfilter/Makefile --- linux-2.6.8-rc2-nfquilt/net/ipv4/netfilter/Makefile 2004-08-02 00:51:27= =2E224055035 +0200 +++ linux-2.6.8-rc2-nfquilt-nfp/net/ipv4/netfilter/Makefile 2004-08-02 00:5= 2:49.117882259 +0200 @@ -19,6 +19,9 @@ # connection tracking obj-$(CONFIG_IP_NF_CONNTRACK) +=3D ip_conntrack.o =20 +# SCTP protocol connection tracking +obj-$(CONFIG_IP_NF_CT_PROTO_SCTP) +=3D ip_conntrack_proto_sctp.o + # connection tracking helpers obj-$(CONFIG_IP_NF_AMANDA) +=3D ip_conntrack_amanda.o obj-$(CONFIG_IP_NF_TFTP) +=3D ip_conntrack_tftp.o diff --exclude-from /sunbeam/home/laforge/scripts/dontdiff -Nru linux-2.6.8= -rc2-nfquilt/net/ipv4/netfilter/ip_conntrack_proto_sctp.c linux-2.6.8-rc2-n= fquilt-nfp/net/ipv4/netfilter/ip_conntrack_proto_sctp.c --- linux-2.6.8-rc2-nfquilt/net/ipv4/netfilter/ip_conntrack_proto_sctp.c 19= 70-01-01 01:00:00.000000000 +0100 +++ linux-2.6.8-rc2-nfquilt-nfp/net/ipv4/netfilter/ip_conntrack_proto_sctp.= c 2004-08-02 00:52:49.098882995 +0200 @@ -0,0 +1,650 @@ +/* + * Connection tracking protocol helper module for SCTP. + *=20 + * SCTP is defined in RFC 2960. References to various sections in this cod= e=20 + * are to this RFC. + *=20 + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +/* + * Added support for proc manipulation of timeouts. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#if 0 +#define DEBUGP(format, ...) printk(format, ## __VA_ARGS__) +#else +#define DEBUGP(format, args...) +#endif + +/* Protects conntrack->proto.sctp */ +static DECLARE_RWLOCK(sctp_lock); + +/* FIXME: Examine ipfilter's timeouts and conntrack transitions more + closely. They're more complex. --RR=20 + + And so for me for SCTP :D -Kiran */ + +static const char *sctp_conntrack_names[] =3D { + "NONE", + "CLOSED", + "COOKIE_WAIT", + "COOKIE_ECHOED", + "ESTABLISHED", + "SHUTDOWN_SENT", + "SHUTDOWN_RECD", + "SHUTDOWN_ACK_SENT", +}; + +#define SECS * HZ +#define MINS * 60 SECS +#define HOURS * 60 MINS +#define DAYS * 24 HOURS + +unsigned long ip_ct_sctp_timeout_closed =3D 10 SECS; +unsigned long ip_ct_sctp_timeout_cookie_wait =3D 3 SECS; +unsigned long ip_ct_sctp_timeout_cookie_echoed =3D 3 SECS; +unsigned long ip_ct_sctp_timeout_established =3D 5 DAYS; +unsigned long ip_ct_sctp_timeout_shutdown_sent =3D 300 SECS / 1000; +unsigned long ip_ct_sctp_timeout_shutdown_recd =3D 300 SECS / 1000; +unsigned long ip_ct_sctp_timeout_shutdown_ack_sent =3D 3 SECS; + +static unsigned long * sctp_timeouts[] +=3D { 0, /* SCTP_CONNTRACK_NONE */ + &ip_ct_sctp_timeout_closed, /* SCTP_CONNTRACK_CLOSED */ + &ip_ct_sctp_timeout_cookie_wait, /* SCTP_CONNTRACK_COOKIE_WAIT */ + &ip_ct_sctp_timeout_cookie_echoed, /* SCTP_CONNTRACK_COOKIE_ECHOED= */ + &ip_ct_sctp_timeout_established, /* SCTP_CONNTRACK_ESTABLISHED */ + &ip_ct_sctp_timeout_shutdown_sent, /* SCTP_CONNTRACK_SHUTDOWN_SENT= */ + &ip_ct_sctp_timeout_shutdown_recd, /* SCTP_CONNTRACK_SHUTDOWN_RECD= */ + &ip_ct_sctp_timeout_shutdown_ack_sent /* SCTP_CONNTRACK_SHUTDOWN_ACK_= SENT */ + }; + +#define sNO SCTP_CONNTRACK_NONE +#define sCL SCTP_CONNTRACK_CLOSED +#define sCW SCTP_CONNTRACK_COOKIE_WAIT +#define sCE SCTP_CONNTRACK_COOKIE_ECHOED +#define sES SCTP_CONNTRACK_ESTABLISHED +#define sSS SCTP_CONNTRACK_SHUTDOWN_SENT +#define sSR SCTP_CONNTRACK_SHUTDOWN_RECD +#define sSA SCTP_CONNTRACK_SHUTDOWN_ACK_SENT +#define sIV SCTP_CONNTRACK_MAX + +/*=20 + These are the descriptions of the states: + +NOTE: These state names are tantalizingly similar to the states of an=20 +SCTP endpoint. But the interpretation of the states is a little different, +considering that these are the states of the connection and not of an end= =20 +point. Please note the subtleties. -Kiran + +NONE - Nothing so far. +COOKIE WAIT - We have seen an INIT chunk in the original direction, = or also=20 + an INIT_ACK chunk in the reply direction. +COOKIE ECHOED - We have seen a COOKIE_ECHO chunk in the original direc= tion. +ESTABLISHED - We have seen a COOKIE_ACK in the reply direction. +SHUTDOWN_SENT - We have seen a SHUTDOWN chunk in the original directio= n. +SHUTDOWN_RECD - We have seen a SHUTDOWN chunk in the reply directoin. +SHUTDOWN_ACK_SENT - We have seen a SHUTDOWN_ACK chunk in the direction opp= osite + to that of the SHUTDOWN chunk. +CLOSED - We have seen a SHUTDOWN_COMPLETE chunk in the directio= n of=20 + the SHUTDOWN chunk. Connection is closed. +*/ + +/* TODO + - I have assumed that the first INIT is in the original direction.=20 + This messes things when an INIT comes in the reply direction in CLOSED + state. + - Check the error type in the reply dir before transitioning from=20 +cookie echoed to closed. + - Sec 5.2.4 of RFC 2960 + - Multi Homing support. +*/ + +/* SCTP conntrack state transitions */ +static enum sctp_conntrack sctp_conntracks[2][9][SCTP_CONNTRACK_MAX] =3D { + { +/* ORIGINAL */ +/* sNO, sCL, sCW, sCE, sES, sSS, sSR, sSA */ +/* init */ {sCW, sCW, sCW, sCE, sES, sSS, sSR, sSA}, +/* init_ack */ {sCL, sCL, sCW, sCE, sES, sSS, sSR, sSA}, +/* abort */ {sCL, sCL, sCL, sCL, sCL, sCL, sCL, sCL}, +/* shutdown */ {sCL, sCL, sCW, sCE, sSS, sSS, sSR, sSA}, +/* shutdown_ack */ {sSA, sCL, sCW, sCE, sES, sSA, sSA, sSA}, +/* error */ {sCL, sCL, sCW, sCE, sES, sSS, sSR, sSA},/* Cant have S= tale cookie*/ +/* cookie_echo */ {sCL, sCL, sCE, sCE, sES, sSS, sSR, sSA},/* 5.2.4 - Big= TODO */ +/* cookie_ack */ {sCL, sCL, sCW, sCE, sES, sSS, sSR, sSA},/* Cant come i= n orig dir */ +/* shutdown_comp*/ {sCL, sCL, sCW, sCE, sES, sSS, sSR, sCL} + }, + { +/* REPLY */ +/* sNO, sCL, sCW, sCE, sES, sSS, sSR, sSA */ +/* init */ {sIV, sCL, sCW, sCE, sES, sSS, sSR, sSA},/* INIT in sCL= Big TODO */ +/* init_ack */ {sIV, sCL, sCW, sCE, sES, sSS, sSR, sSA}, +/* abort */ {sIV, sCL, sCL, sCL, sCL, sCL, sCL, sCL}, +/* shutdown */ {sIV, sCL, sCW, sCE, sSR, sSS, sSR, sSA}, +/* shutdown_ack */ {sIV, sCL, sCW, sCE, sES, sSA, sSA, sSA}, +/* error */ {sIV, sCL, sCW, sCL, sES, sSS, sSR, sSA}, +/* cookie_echo */ {sIV, sCL, sCW, sCE, sES, sSS, sSR, sSA},/* Cant come i= n reply dir */ +/* cookie_ack */ {sIV, sCL, sCW, sES, sES, sSS, sSR, sSA}, +/* shutdown_comp*/ {sIV, sCL, sCW, sCE, sES, sSS, sSR, sCL} + } +}; + +static int sctp_pkt_to_tuple(const struct sk_buff *skb, + unsigned int dataoff, + struct ip_conntrack_tuple *tuple) +{ + sctp_sctphdr_t hdr; + + DEBUGP(__FUNCTION__); + DEBUGP("\n"); + + /* Actually only need first 8 bytes. */ + if (skb_copy_bits(skb, dataoff, &hdr, 8) !=3D 0) + return 0; + + tuple->src.u.sctp.port =3D hdr.source; + tuple->dst.u.sctp.port =3D hdr.dest; + + return 1; +} + +static int sctp_invert_tuple(struct ip_conntrack_tuple *tuple, + const struct ip_conntrack_tuple *orig) +{ + DEBUGP(__FUNCTION__); + DEBUGP("\n"); + + tuple->src.u.sctp.port =3D orig->dst.u.sctp.port; + tuple->dst.u.sctp.port =3D orig->src.u.sctp.port; + return 1; +} + +/* Print out the per-protocol part of the tuple. */ +static unsigned int sctp_print_tuple(char *buffer, + const struct ip_conntrack_tuple *tuple) +{ + DEBUGP(__FUNCTION__); + DEBUGP("\n"); + + return sprintf(buffer, "sport=3D%hu dport=3D%hu ", + ntohs(tuple->src.u.sctp.port), + ntohs(tuple->dst.u.sctp.port)); +} + +/* Print out the private part of the conntrack. */ +static unsigned int sctp_print_conntrack(char *buffer, + const struct ip_conntrack *conntrack) +{ + enum sctp_conntrack state; + + DEBUGP(__FUNCTION__); + DEBUGP("\n"); + + READ_LOCK(&sctp_lock); + state =3D conntrack->proto.sctp.state; + READ_UNLOCK(&sctp_lock); + + return sprintf(buffer, "%s ", sctp_conntrack_names[state]); +} + +#define for_each_sctp_chunk(skb, sch, offset, count) \ +for (offset =3D skb->nh.iph->ihl * 4 + sizeof (sctp_sctphdr_t), count =3D = 0; \ + offset < skb->len && !skb_copy_bits(skb, offset, &sch, sizeof(sch)); \ + offset +=3D (htons(sch.length) + 3) & ~3, count++) + +/* Some validity checks to make sure the chunks are fine */ +static int do_basic_checks(struct ip_conntrack *conntrack, + const struct sk_buff *skb, + char *map) +{ + u_int32_t offset, count; + sctp_chunkhdr_t sch; + int flag; + + DEBUGP(__FUNCTION__); + DEBUGP("\n"); + + flag =3D 0; + + for_each_sctp_chunk (skb, sch, offset, count) { + DEBUGP("Chunk Num: %d Type: %d\n", count, sch.type); + + if (sch.type =3D=3D SCTP_CID_INIT=20 + || sch.type =3D=3D SCTP_CID_INIT_ACK + || sch.type =3D=3D SCTP_CID_SHUTDOWN_COMPLETE) { + flag =3D 1; + } + + /* Cookie Ack/Echo chunks not the first OR=20 + Init / Init Ack / Shutdown compl chunks not the only chunks */ + if ((sch.type =3D=3D SCTP_CID_COOKIE_ACK=20 + || sch.type =3D=3D SCTP_CID_COOKIE_ECHO + || flag) + && count !=3D0 ) { + DEBUGP("Basic checks failed\n"); + return 1; + } + + if (map) { + set_bit (sch.type, (void *)map); + } + } + + DEBUGP("Basic checks passed\n"); + return 0; +} + +static int new_state(enum ip_conntrack_dir dir, + enum sctp_conntrack cur_state, + int chunk_type) +{ + int i; + + DEBUGP(__FUNCTION__); + DEBUGP("\n"); + + DEBUGP("Chunk type: %d\n", chunk_type); + + switch (chunk_type) { + case SCTP_CID_INIT:=20 + DEBUGP("SCTP_CID_INIT\n"); + i =3D 0; break; + case SCTP_CID_INIT_ACK:=20 + DEBUGP("SCTP_CID_INIT_ACK\n"); + i =3D 1; break; + case SCTP_CID_ABORT:=20 + DEBUGP("SCTP_CID_ABORT\n"); + i =3D 2; break; + case SCTP_CID_SHUTDOWN:=20 + DEBUGP("SCTP_CID_SHUTDOWN\n"); + i =3D 3; break; + case SCTP_CID_SHUTDOWN_ACK:=20 + DEBUGP("SCTP_CID_SHUTDOWN_ACK\n"); + i =3D 4; break; + case SCTP_CID_ERROR:=20 + DEBUGP("SCTP_CID_ERROR\n"); + i =3D 5; break; + case SCTP_CID_COOKIE_ECHO:=20 + DEBUGP("SCTP_CID_COOKIE_ECHO\n"); + i =3D 6; break; + case SCTP_CID_COOKIE_ACK:=20 + DEBUGP("SCTP_CID_COOKIE_ACK\n"); + i =3D 7; break; + case SCTP_CID_SHUTDOWN_COMPLETE:=20 + DEBUGP("SCTP_CID_SHUTDOWN_COMPLETE\n"); + i =3D 8; break; + default: + /* Other chunks like DATA, SACK, HEARTBEAT and + its ACK do not cause a change in state */ + DEBUGP("Unknown chunk type, Will stay in %s\n",=20 + sctp_conntrack_names[cur_state]); + return cur_state; + } + + DEBUGP("dir: %d cur_state: %s chunk_type: %d new_state: %s\n",=20 + dir, sctp_conntrack_names[cur_state], chunk_type, + sctp_conntrack_names[sctp_conntracks[dir][i][cur_state]]); + + return sctp_conntracks[dir][i][cur_state]; +} + +/* Returns verdict for packet, or -1 for invalid. */ +static int sctp_packet(struct ip_conntrack *conntrack, + const struct sk_buff *skb, + enum ip_conntrack_info ctinfo) +{ + enum sctp_conntrack newconntrack, oldsctpstate; + sctp_sctphdr_t sctph; + sctp_chunkhdr_t sch; + u_int32_t offset, count; + char map[256 / sizeof (char)] =3D {0}; + + DEBUGP(__FUNCTION__); + DEBUGP("\n"); + + if (skb_copy_bits(skb, skb->nh.iph->ihl * 4, &sctph, sizeof(sctph)) !=3D = 0) + return -1; + + if (do_basic_checks(conntrack, skb, map) !=3D 0) + return -1; + + /* Check the verification tag (Sec 8.5) */ + if (!test_bit(SCTP_CID_INIT, (void *)map) + && !test_bit(SCTP_CID_SHUTDOWN_COMPLETE, (void *)map) + && !test_bit(SCTP_CID_COOKIE_ECHO, (void *)map) + && !test_bit(SCTP_CID_ABORT, (void *)map) + && !test_bit(SCTP_CID_SHUTDOWN_ACK, (void *)map) + && (sctph.vtag !=3D conntrack->proto.sctp.vtag[CTINFO2DIR(ctinfo)])) { + DEBUGP("Verification tag check failed\n"); + return -1; + } + + oldsctpstate =3D newconntrack =3D SCTP_CONNTRACK_MAX; + for_each_sctp_chunk (skb, sch, offset, count) { + WRITE_LOCK(&sctp_lock); + + /* Special cases of Verification tag check (Sec 8.5.1) */ + if (sch.type =3D=3D SCTP_CID_INIT) { + /* Sec 8.5.1 (A) */ + if (sctph.vtag !=3D 0) { + WRITE_UNLOCK(&sctp_lock); + return -1; + } + } else if (sch.type =3D=3D SCTP_CID_ABORT) { + /* Sec 8.5.1 (B) */ + if (!(sctph.vtag =3D=3D conntrack->proto.sctp.vtag[CTINFO2DIR(ctinfo)]) + && !(sctph.vtag =3D=3D conntrack->proto.sctp.vtag + [1 - CTINFO2DIR(ctinfo)])) { + WRITE_UNLOCK(&sctp_lock); + return -1; + } + } else if (sch.type =3D=3D SCTP_CID_SHUTDOWN_COMPLETE) { + /* Sec 8.5.1 (C) */ + if (!(sctph.vtag =3D=3D conntrack->proto.sctp.vtag[CTINFO2DIR(ctinfo)]) + && !(sctph.vtag =3D=3D conntrack->proto.sctp.vtag + [1 - CTINFO2DIR(ctinfo)]=20 + && (sch.flags & 1))) { + WRITE_UNLOCK(&sctp_lock); + return -1; + } + } else if (sch.type =3D=3D SCTP_CID_COOKIE_ECHO) { + /* Sec 8.5.1 (D) */ + if (!(sctph.vtag =3D=3D conntrack->proto.sctp.vtag[CTINFO2DIR(ctinfo)])= ) { + WRITE_UNLOCK(&sctp_lock); + return -1; + } + } + + oldsctpstate =3D conntrack->proto.sctp.state; + newconntrack =3D new_state(CTINFO2DIR(ctinfo), oldsctpstate, sch.type); + + /* Invalid */ + if (newconntrack =3D=3D SCTP_CONNTRACK_MAX) { + DEBUGP("ip_conntrack_sctp: Invalid dir=3D%i ctype=3D%u conntrack=3D%u\n= ", + CTINFO2DIR(ctinfo), sch.type, oldsctpstate); + WRITE_UNLOCK(&sctp_lock); + return -1; + } + + /* If it is an INIT or an INIT ACK note down the vtag */ + if (sch.type =3D=3D SCTP_CID_INIT=20 + || sch.type =3D=3D SCTP_CID_INIT_ACK) { + sctp_inithdr_t inithdr; + + if (skb_copy_bits(skb, offset + sizeof (sctp_chunkhdr_t), + &inithdr, sizeof(inithdr)) !=3D 0) { + WRITE_UNLOCK(&sctp_lock); + return -1; + } + DEBUGP("Setting vtag %x for dir %d\n",=20 + inithdr.init_tag, CTINFO2DIR(ctinfo)); + conntrack->proto.sctp.vtag[IP_CT_DIR_ORIGINAL] =3D inithdr.init_tag; + } + + conntrack->proto.sctp.state =3D newconntrack; + WRITE_UNLOCK(&sctp_lock); + } + + ip_ct_refresh(conntrack, *sctp_timeouts[newconntrack]); + + if (oldsctpstate =3D=3D SCTP_CONNTRACK_COOKIE_ECHOED + && CTINFO2DIR(ctinfo) =3D=3D IP_CT_DIR_REPLY + && newconntrack =3D=3D SCTP_CONNTRACK_ESTABLISHED) { + DEBUGP("Setting assured bit\n"); + set_bit(IPS_ASSURED_BIT, &conntrack->status); + } + + return NF_ACCEPT; +} + +/* Called when a new connection for this protocol found. */ +static int sctp_new(struct ip_conntrack *conntrack,=20 + const struct sk_buff *skb) +{ + enum sctp_conntrack newconntrack; + sctp_sctphdr_t sctph; + sctp_chunkhdr_t sch; + u_int32_t offset, count; + char map[256 / sizeof (char)] =3D {0}; + + DEBUGP(__FUNCTION__); + DEBUGP("\n"); + + if (skb_copy_bits(skb, skb->nh.iph->ihl * 4, &sctph, sizeof(sctph)) !=3D = 0) + return -1; + + if (do_basic_checks(conntrack, skb, map) !=3D 0) + return -1; + + /* If an OOTB packet has any of these chunks discard (Sec 8.4) */ + if ((test_bit (SCTP_CID_ABORT, (void *)map)) + || (test_bit (SCTP_CID_SHUTDOWN_COMPLETE, (void *)map)) + || (test_bit (SCTP_CID_COOKIE_ACK, (void *)map))) { + return -1; + } + + newconntrack =3D SCTP_CONNTRACK_MAX; + for_each_sctp_chunk (skb, sch, offset, count) { + /* Don't need lock here: this conntrack not in circulation yet */ + newconntrack =3D new_state (IP_CT_DIR_ORIGINAL,=20 + SCTP_CONNTRACK_NONE, sch.type); + + /* Invalid: delete conntrack */ + if (newconntrack =3D=3D SCTP_CONNTRACK_MAX) { + DEBUGP("ip_conntrack_sctp: invalid new deleting.\n"); + return 0; + } + + /* Copy the vtag into the state info */ + if (sch.type =3D=3D SCTP_CID_INIT) { + if (sctph.vtag =3D=3D 0) { + sctp_inithdr_t inithdr; + + if (skb_copy_bits(skb, offset + sizeof (sctp_chunkhdr_t),=20 + &inithdr, sizeof(inithdr)) !=3D 0) { + return -1; + } + + DEBUGP("Setting vtag %x for new conn\n",=20 + inithdr.init_tag); + + conntrack->proto.sctp.vtag[IP_CT_DIR_REPLY] =3D=20 + inithdr.init_tag; + } else { + /* Sec 8.5.1 (A) */ + return -1; + } + } + /* If it is a shutdown ack OOTB packet, we expect a return + shutdown complete, otherwise an ABORT Sec 8.4 (5) and (8) */ + else { + DEBUGP("Setting vtag %x for new conn OOTB\n",=20 + sctph.vtag); + conntrack->proto.sctp.vtag[IP_CT_DIR_REPLY] =3D sctph.vtag; + } + + conntrack->proto.sctp.state =3D newconntrack; + } + + return 1; +} + +static int sctp_exp_matches_pkt(struct ip_conntrack_expect *exp, + const struct sk_buff *skb) +{ + /* To be implemented */ + return 0; +} + +struct ip_conntrack_protocol ip_conntrack_protocol_sctp =3D {=20 + .list =3D { NULL, NULL },=20 + .proto =3D IPPROTO_SCTP,=20 + .name =3D "sctp", + .pkt_to_tuple =3D sctp_pkt_to_tuple,=20 + .invert_tuple =3D sctp_invert_tuple,=20 + .print_tuple =3D sctp_print_tuple,=20 + .print_conntrack =3D sctp_print_conntrack, + .packet =3D sctp_packet,=20 + .new =3D sctp_new,=20 + .destroy =3D NULL,=20 + .exp_matches_pkt =3D sctp_exp_matches_pkt,=20 + .me =3D THIS_MODULE=20 +}; + +#ifdef CONFIG_SYSCTL +static ctl_table ip_ct_sysctl_table[] =3D { + { + .ctl_name =3D NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_CLOSED, + .procname =3D "ip_conntrack_sctp_timeout_closed", + .data =3D &ip_ct_sctp_timeout_closed, + .maxlen =3D sizeof(unsigned int), + .mode =3D 0644, + .proc_handler =3D &proc_dointvec_jiffies, + }, + { + .ctl_name =3D NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_COOKIE_WAIT, + .procname =3D "ip_conntrack_sctp_timeout_cookie_wait", + .data =3D &ip_ct_sctp_timeout_cookie_wait, + .maxlen =3D sizeof(unsigned int), + .mode =3D 0644, + .proc_handler =3D &proc_dointvec_jiffies, + }, + { + .ctl_name =3D NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_COOKIE_ECHOED, + .procname =3D "ip_conntrack_sctp_timeout_cookie_echoed", + .data =3D &ip_ct_sctp_timeout_cookie_echoed, + .maxlen =3D sizeof(unsigned int), + .mode =3D 0644, + .proc_handler =3D &proc_dointvec_jiffies, + }, + { + .ctl_name =3D NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_ESTABLISHED, + .procname =3D "ip_conntrack_sctp_timeout_established", + .data =3D &ip_ct_sctp_timeout_established, + .maxlen =3D sizeof(unsigned int), + .mode =3D 0644, + .proc_handler =3D &proc_dointvec_jiffies, + }, + { + .ctl_name =3D NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_SHUTDOWN_SENT, + .procname =3D "ip_conntrack_sctp_timeout_shutdown_sent", + .data =3D &ip_ct_sctp_timeout_shutdown_sent, + .maxlen =3D sizeof(unsigned int), + .mode =3D 0644, + .proc_handler =3D &proc_dointvec_jiffies, + }, + { + .ctl_name =3D NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_SHUTDOWN_RECD, + .procname =3D "ip_conntrack_sctp_timeout_shutdown_recd", + .data =3D &ip_ct_sctp_timeout_shutdown_recd, + .maxlen =3D sizeof(unsigned int), + .mode =3D 0644, + .proc_handler =3D &proc_dointvec_jiffies, + }, + { + .ctl_name =3D NET_IPV4_NF_CONNTRACK_SCTP_TIMEOUT_SHUTDOWN_ACK_SENT, + .procname =3D "ip_conntrack_sctp_timeout_shutdown_ack_sent", + .data =3D &ip_ct_sctp_timeout_shutdown_ack_sent, + .maxlen =3D sizeof(unsigned int), + .mode =3D 0644, + .proc_handler =3D &proc_dointvec_jiffies, + }, + { .ctl_name =3D 0 } +}; + +static ctl_table ip_ct_netfilter_table[] =3D { + { + .ctl_name =3D NET_IPV4_NETFILTER, + .procname =3D "netfilter", + .mode =3D 0555, + .child =3D ip_ct_sysctl_table, + }, + { .ctl_name =3D 0 } +}; + +static ctl_table ip_ct_ipv4_table[] =3D { + { + .ctl_name =3D NET_IPV4, + .procname =3D "ipv4", + .mode =3D 0555, + .child =3D ip_ct_netfilter_table, + }, + { .ctl_name =3D 0 } +}; + +static ctl_table ip_ct_net_table[] =3D { + { + .ctl_name =3D CTL_NET, + .procname =3D "net", + .mode =3D 0555,=20 + .child =3D ip_ct_ipv4_table, + }, + { .ctl_name =3D 0 } +}; + +static struct ctl_table_header *ip_ct_sysctl_header; +#endif + +int __init init(void) +{ + int ret; + + ret =3D ip_conntrack_protocol_register(&ip_conntrack_protocol_sctp); + if (ret) { + printk("ip_conntrack_proto_sctp: protocol register failed\n"); + goto out; + } + +#ifdef CONFIG_SYSCTL + ip_ct_sysctl_header =3D register_sysctl_table(ip_ct_net_table, 0); + if (ip_ct_sysctl_header =3D=3D NULL) { + printk("ip_conntrack_proto_sctp: can't register to sysctl.\n"); + goto cleanup; + } +#endif + + return ret; + + cleanup: +#ifdef CONFIG_SYSCTL + ip_conntrack_protocol_unregister(&ip_conntrack_protocol_sctp); +#endif + out: + DEBUGP("SCTP conntrack module loading %s\n",=20 + ret ? "failed": "succeeded"); + return ret; +} + +void __exit fini(void) +{ + ip_conntrack_protocol_unregister(&ip_conntrack_protocol_sctp); +#ifdef CONFIG_SYSCTL + unregister_sysctl_table(ip_ct_sysctl_header); +#endif + DEBUGP("SCTP conntrack module unloaded\n"); +} + +module_init(init); +module_exit(fini); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Kiran Kumar Immidi"); +MODULE_DESCRIPTION("Netfilter connection tracking protocol helper for SCTP= "); --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --6e7ZaeXHKrTJCxdu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBDXbKXaXGVTD0i/8RAuE0AKCpndyX/rb5mdL8ryi/8ZIk8a8V4gCfWeme AXWAfdrWrFUBmvMdhd9nWIY= =w/3I -----END PGP SIGNATURE----- --6e7ZaeXHKrTJCxdu-- From davem@redhat.com Sun Aug 1 19:23:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 19:23:07 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i722MxAj014040 for ; Sun, 1 Aug 2004 19:23:02 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i722Lle1017554; Sun, 1 Aug 2004 22:21:47 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i722Lla12942; Sun, 1 Aug 2004 22:21:47 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i722L3XV020332; Sun, 1 Aug 2004 22:21:04 -0400 Date: Sun, 1 Aug 2004 19:20:41 -0700 From: "David S. Miller" To: Adrian Bunk Cc: marcelo.tosatti@cyclades.com, shemminger@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.4 patch] CONFIG_NET_SCH_NETEM Configure.help entry Message-Id: <20040801192041.48bbc395.davem@redhat.com> In-Reply-To: <20040801142759.GQ2746@fs.tum.de> References: <20040731142658.GA6497@logos.cnet> <20040801142759.GQ2746@fs.tum.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7399 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Applied, thanks Adrian. From davem@redhat.com Sun Aug 1 19:23:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 19:23:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i722NdHk014131 for ; Sun, 1 Aug 2004 19:23:39 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i722MWe1017665; Sun, 1 Aug 2004 22:22:32 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i722MWa13003; Sun, 1 Aug 2004 22:22:32 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i722LmUX020510; Sun, 1 Aug 2004 22:21:49 -0400 Date: Sun, 1 Aug 2004 19:21:26 -0700 From: "David S. Miller" To: Adrian Bunk Cc: shemminger@osdl.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.6 patch] update NET_SCH_NETEM help text Message-Id: <20040801192126.064ad0ac.davem@redhat.com> In-Reply-To: <20040801143307.GR2746@fs.tum.de> References: <20040801143307.GR2746@fs.tum.de> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7400 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 1 Aug 2004 16:33:07 +0200 Adrian Bunk wrote: > The patch below contains the following changes for the NET_SCH_NETEM > help text: > - correct the module name > - "If unsure, say N." Also applied, thanks. From davem@redhat.com Sun Aug 1 19:29:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 19:29:31 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i722TNCa014826 for ; Sun, 1 Aug 2004 19:29:23 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i722TEe1019278; Sun, 1 Aug 2004 22:29:14 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i722TEa14187; Sun, 1 Aug 2004 22:29:14 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i722SVQB023174; Sun, 1 Aug 2004 22:28:31 -0400 Date: Sun, 1 Aug 2004 19:28:09 -0700 From: "David S. Miller" To: Harald Welte Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com, immidi_kiran@yahoo.com Subject: Re: [PATCH 2.6] NETFILTER: new ip_conntrack_sctp Message-Id: <20040801192809.5ab29c25.davem@redhat.com> In-Reply-To: <20040801230338.GE18758@sunbeam2> References: <20040801230338.GE18758@sunbeam2> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 2 Aug 2004 01:03:38 +0200 Harald Welte wrote: > Incremental to all other patches so far Not really. Harald you really need to fixup your diff scripts wrt. handling non-netfilter files. Every diff you've sent me in this whole set against linux/sysctl.h has rejected, including this one. In this instance, none of the tcp-window-tracking sysctls were in the sysctl.h file you diffed against. I fixed this up by hand, so don't worry about this instance. From werner@almesberger.net Sun Aug 1 19:51:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 19:51:19 -0700 (PDT) Received: from host.almesberger.net (almesberger.net [63.105.73.238]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i722pCle015454 for ; Sun, 1 Aug 2004 19:51:13 -0700 Received: from almesberger.net (vpnwa-home [10.200.0.2]) by host.almesberger.net (8.11.6/8.9.3) with ESMTP id i722pA432049; Sun, 1 Aug 2004 19:51:10 -0700 Received: (from werner@localhost) by almesberger.net (8.11.6/8.11.6) id i722p2T12467; Sun, 1 Aug 2004 23:51:02 -0300 Date: Sun, 1 Aug 2004 23:51:02 -0300 From: Werner Almesberger To: Suparna Bhattacharya Cc: netdev@oss.sgi.com Subject: net-AIO and real-time TCP (blue sky research) Message-ID: <20040801235102.K1276@almesberger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 7402 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: werner@almesberger.net Precedence: bulk X-list: netdev Hi Suparna, I'm copying this to netdev, because people there may get a good chuckle out of this outlandish idea as well :-) At OLS we were chatting about using AIO also for networking. While this concept didn't seem to rank particularly high on the lunacy scale, it didn't appear overly useful either. About the only possibly interesting new functionality, besides the possibility to connect this with some eccentric TCP offloading and zero-copy scheme, would be - when applied to TCP - to make unACKed data in the out-of-order buffer available to user space. Now, it occurred to me that this may lead to something a lot more exciting: a step towards making TCP real-time capable. I'm using the term "real-time" loosely here, as in "there's a deadline, but we're flexible". I haven't followed what's going on at IETF in that area for a while, and I'm sure plenty of other people must have thought of similar schemes before, but since this seems nicer and maybe even simpler than some, let me describe it anyway. First of all, one of the main complaints of the real-time networking people is that TCP stubbornly insists on retransmitting every single segment until it is absolutely certain that the segment has been received, even if the real-time application has long since moved on. Now, with net-AIO, the application could already get all the data that has arrived after a lost segment. That's a good start, but TCP will still try to retransmit. So the next step would be to have a means to indicate that we've lost interest in the outcome of a pending AIO operation, and - as a side effect - communicate this also to TCP, so that TCP can stop trying, and do something more useful instead. Let's call this operation aio_forget(). For disk IO, this may work just like aio_cancel(). Now, aio_forget() would be a great tool for making TCP blissfully ignorant of any losses, actually making it very TCP-unfriendly. So the next step would be to record the fact that we've just forgotten some segments, but still need to make the peer aware of the fact that there (may) have been losses, and to slow down accordingly. Obviously, if we have reason to believe that the peer already knows of a loss in the general vicinity, no action is needed. Reliably communicating a loss isn't trivial, but there should be good background material in the context of ECN. Of course, if ECN is available, we may just use that. Otherwise, we may have to force a retransmission, to be sure that the peer has noticed. (And, if the forgotten segment(s) should arrive while TCP is trying to indicate a loss, it should stop doing so.) Now, assuming we have a solution for indicating losses that is satisfying both in terms of congestion control and in terms of efficiency, there are still a few things that would be nice to have, that this approach doesn't solve: - message boundaries and segment-message alignment. Not being able to use messages just because a few of their bytes ended up in a lost (and then aio_forgotten) segment would be just too bad. In some cases, it may be possible to just set the MSS to a suitable value. Also, recovering message boundaries after a loss may be tricky. - there's no direct provision for allowing adaptive coding. Of course, this is a fairly orthogonal problem. - as time passes, the sender may want to remove or substitute data it had already enqueued, e.g because there is less bandwidth than originally anticipated. So there may be a place for aio_forget() at the sender side too. Now, why could this scheme be "nicer" than just inventing some new protocol that is designed to do all these things ? The main thing that "looks good" is that this mechanism could use all of TCP, and may not even need major maintenance if some minor aspect of TCP congestion control gets changed. Anyway, this may be peculiar enough for someone to spin the idea a little further. In the worst case, I might just have provided additional evidence that, if you just search long enough, there's a perfectly plausible problem for every solution :-) - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina werner@almesberger.net / /_http://www.almesberger.net/____________________________________________/ From davem@redhat.com Sun Aug 1 19:53:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 01 Aug 2004 19:53:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i722r2QQ015700 for ; Sun, 1 Aug 2004 19:53:02 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i722qfe1023684; Sun, 1 Aug 2004 22:52:41 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i722qfa17865; Sun, 1 Aug 2004 22:52:41 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11/8.12.10) with SMTP id i722pwgP031055; Sun, 1 Aug 2004 22:51:58 -0400 Date: Sun, 1 Aug 2004 19:51:35 -0700 From: "David S. Miller" To: Kazunori Miyazawa Cc: herbert@gondor.apana.org.au, netdev@oss.sgi.com, usagi-core@linux-ipv6.org, kazunori@miyazawa.org Subject: Re: [PATCH][IPv6] separation xfrm_lookup from ip6_dst_lookup Message-Id: <20040801195135.16734846.davem@redhat.com> In-Reply-To: <20040730171205.114f22ba.kazunori@miyazawa.org> References: <20040730171205.114f22ba.kazunori@miyazawa.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7403 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 30 Jul 2004 17:12:05 +0900 Kazunori Miyazawa wrote: > I consider copying flowi(fl_rt) uses too much stack at the moment. > I'll re-send the fixed patch again. I agree, and let's defer this patch until we resolve that. It is simple to fix, I think. From herbert@gondor.apana.org.au Mon Aug 2 00:42:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Aug 2004 00:43:21 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i727gWcJ028544 for ; Mon, 2 Aug 2004 00:42:33 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BrXSX-0000qR-00; Mon, 02 Aug 2004 17:42:14 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BrXS7-0004Gy-00; Mon, 02 Aug 2004 17:41:47 +1000 Date: Mon, 2 Aug 2004 17:41:47 +1000 To: Kazunori Miyazawa Cc: davem@redhat.com, netdev@oss.sgi.com, usagi-core@linux-ipv6.org, Alexey Kuznetsov Subject: Re: [PATCH][IPv6] separation xfrm_lookup from ip6_dst_lookup Message-ID: <20040802074147.GA16381@gondor.apana.org.au> References: <20040730171205.114f22ba.kazunori@miyazawa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040730171205.114f22ba.kazunori@miyazawa.org> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7404 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev On Fri, Jul 30, 2004 at 05:12:05PM +0900, Kazunori Miyazawa wrote: > > This patch separates xfrm_lookup from ip6_dst_lookup > to support srcrt correctly. ip6_dst_lookup should be > called with next hop. however xfrm_lookup should be > called with final destination. It fixes them. Thanks for the patch. This raises an interesting question. Is it really correct to look at the first hop address when doing the route lookup? The problem is that if we use the first-hop address as the dst when doing the route lookup then we may end up with incorrect MTU information. This is because the MTU to the final destination may well be smaller than the MTU to the first hop. It seems that Alexey thought about this six years ago according to the rthdr comment in icmpv6_rcv(). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From herbert@gondor.apana.org.au Mon Aug 2 02:32:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Aug 2004 02:32:16 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i729W5sL030546 for ; Mon, 2 Aug 2004 02:32:07 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BrZAh-0001VE-00; Mon, 02 Aug 2004 19:31:56 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BrZAf-00058H-00; Mon, 02 Aug 2004 19:31:53 +1000 Date: Mon, 2 Aug 2004 19:31:53 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [1/2] [IPSEC] Remove unnecessary inet_ecn.h inclusions Message-ID: <20040802093153.GA19706@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: This is a couple of clean-ups stemming from the xfrm_output change. I should've removed the inet_ecn.h inclusions in that change as the ECN code has been moved to xfrm[46]_output.c. This patch does exactly that. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p1 ===== net/ipv4/ah4.c 1.38 vs edited ===== --- 1.38/net/ipv4/ah4.c 2004-07-30 21:16:40 +10:00 +++ edited/net/ipv4/ah4.c 2004-08-02 17:44:36 +10:00 @@ -1,6 +1,5 @@ #include #include -#include #include #include #include ===== net/ipv4/esp4.c 1.53 vs edited ===== --- 1.53/net/ipv4/esp4.c 2004-07-12 20:00:21 +10:00 +++ edited/net/ipv4/esp4.c 2004-08-02 17:44:49 +10:00 @@ -1,6 +1,5 @@ #include #include -#include #include #include #include ===== net/ipv4/ipcomp.c 1.28 vs edited ===== --- 1.28/net/ipv4/ipcomp.c 2004-07-12 20:00:21 +10:00 +++ edited/net/ipv4/ipcomp.c 2004-08-02 17:44:55 +10:00 @@ -18,7 +18,6 @@ #include #include #include -#include #include #include #include ===== net/ipv4/xfrm4_tunnel.c 1.13 vs edited ===== --- 1.13/net/ipv4/xfrm4_tunnel.c 2004-07-12 20:00:21 +10:00 +++ edited/net/ipv4/xfrm4_tunnel.c 2004-08-02 17:44:30 +10:00 @@ -7,7 +7,6 @@ #include #include #include -#include int xfrm4_tunnel_check_size(struct sk_buff *skb) { ===== net/ipv6/ah6.c 1.38 vs edited ===== --- 1.38/net/ipv6/ah6.c 2004-08-02 07:15:03 +10:00 +++ edited/net/ipv6/ah6.c 2004-08-02 17:45:20 +10:00 @@ -26,7 +26,6 @@ #include #include -#include #include #include #include ===== net/ipv6/esp6.c 1.34 vs edited ===== --- 1.34/net/ipv6/esp6.c 2004-08-02 07:15:03 +10:00 +++ edited/net/ipv6/esp6.c 2004-08-02 17:45:23 +10:00 @@ -26,7 +26,6 @@ #include #include -#include #include #include #include ===== net/ipv6/ipcomp6.c 1.19 vs edited ===== --- 1.19/net/ipv6/ipcomp6.c 2004-08-02 07:15:03 +10:00 +++ edited/net/ipv6/ipcomp6.c 2004-08-02 17:45:25 +10:00 @@ -32,7 +32,6 @@ */ #include #include -#include #include #include #include --GvXjxJ+pjyke8COw-- From herbert@gondor.apana.org.au Mon Aug 2 02:35:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Aug 2004 02:35:17 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i729ZAXZ030888 for ; Mon, 2 Aug 2004 02:35:11 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BrZDg-0001Ws-00; Mon, 02 Aug 2004 19:35:00 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BrZDg-00059H-00; Mon, 02 Aug 2004 19:35:00 +1000 Date: Mon, 2 Aug 2004 19:35:00 +1000 To: "David S. Miller" , netdev@oss.sgi.com Subject: [2/2] [IPSEC] Move xfrm[46]_tunnel_check_size into xfrm[46]_output.c Message-ID: <20040802093500.GA19747@gondor.apana.org.au> References: <20040802093153.GA19706@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20040802093153.GA19706@gondor.apana.org.au> User-Agent: Mutt/1.5.6+20040523i From: Herbert Xu X-archive-position: 7406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This patch moves xfrm[46]_tunnel_check_size() into xfrm[46]_output.c where it can be made static since it's only used there. While moving the icmp.h inclusions over I also discovered that the tunnel files are missing an inclusion of net/protocol.h. So I've added them as well. Signed-off-by: Herbert Xu Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p2 ===== include/net/xfrm.h 1.62 vs edited ===== --- 1.62/include/net/xfrm.h 2004-08-02 07:15:02 +10:00 +++ edited/include/net/xfrm.h 2004-08-02 18:02:32 +10:00 @@ -821,12 +821,10 @@ extern int xfrm4_output(struct sk_buff **pskb); extern int xfrm4_tunnel_register(struct xfrm_tunnel *handler); extern int xfrm4_tunnel_deregister(struct xfrm_tunnel *handler); -extern int xfrm4_tunnel_check_size(struct sk_buff *skb); extern int xfrm6_rcv(struct sk_buff **pskb, unsigned int *nhoffp); extern int xfrm6_output(struct sk_buff **pskb); extern int xfrm6_tunnel_register(struct xfrm6_tunnel *handler); extern int xfrm6_tunnel_deregister(struct xfrm6_tunnel *handler); -extern int xfrm6_tunnel_check_size(struct sk_buff *skb); extern u32 xfrm6_tunnel_alloc_spi(xfrm_address_t *saddr); extern void xfrm6_tunnel_free_spi(xfrm_address_t *saddr); extern u32 xfrm6_tunnel_spi_lookup(xfrm_address_t *saddr); ===== net/ipv4/xfrm4_output.c 1.1 vs edited ===== --- 1.1/net/ipv4/xfrm4_output.c 2004-07-11 04:53:15 +10:00 +++ edited/net/ipv4/xfrm4_output.c 2004-08-02 17:58:15 +10:00 @@ -13,6 +13,7 @@ #include #include #include +#include /* Add encapsulation header. * @@ -65,6 +66,30 @@ top_iph->protocol = IPPROTO_IPIP; memset(&(IPCB(skb)->opt), 0, sizeof(struct ip_options)); +} + +static int xfrm4_tunnel_check_size(struct sk_buff *skb) +{ + int mtu, ret = 0; + struct dst_entry *dst; + struct iphdr *iph = skb->nh.iph; + + if (IPCB(skb)->flags & IPSKB_XFRM_TUNNEL_SIZE) + goto out; + + IPCB(skb)->flags |= IPSKB_XFRM_TUNNEL_SIZE; + + if (!(iph->frag_off & htons(IP_DF))) + goto out; + + dst = skb->dst; + mtu = dst_pmtu(dst) - dst->header_len - dst->trailer_len; + if (skb->len > mtu) { + icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); + ret = -EMSGSIZE; + } +out: + return ret; } int xfrm4_output(struct sk_buff **pskb) ===== net/ipv4/xfrm4_tunnel.c 1.14 vs edited ===== --- 1.14/net/ipv4/xfrm4_tunnel.c 2004-08-02 17:53:26 +10:00 +++ edited/net/ipv4/xfrm4_tunnel.c 2004-08-02 18:06:32 +10:00 @@ -6,31 +6,7 @@ #include #include #include -#include - -int xfrm4_tunnel_check_size(struct sk_buff *skb) -{ - int mtu, ret = 0; - struct dst_entry *dst; - struct iphdr *iph = skb->nh.iph; - - if (IPCB(skb)->flags & IPSKB_XFRM_TUNNEL_SIZE) - goto out; - - IPCB(skb)->flags |= IPSKB_XFRM_TUNNEL_SIZE; - - if (!(iph->frag_off & htons(IP_DF))) - goto out; - - dst = skb->dst; - mtu = dst_pmtu(dst) - dst->header_len - dst->trailer_len; - if (skb->len > mtu) { - icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); - ret = -EMSGSIZE; - } -out: - return ret; -} +#include static int ipip_output(struct sk_buff **pskb) { ===== net/ipv6/xfrm6_output.c 1.1 vs edited ===== --- 1.1/net/ipv6/xfrm6_output.c 2004-07-30 12:17:21 +10:00 +++ edited/net/ipv6/xfrm6_output.c 2004-08-02 18:01:03 +10:00 @@ -11,6 +11,7 @@ #include #include +#include #include #include #include @@ -66,6 +67,23 @@ top_iph->hop_limit = iph->hop_limit; ipv6_addr_copy(&top_iph->saddr, (struct in6_addr *)&x->props.saddr); ipv6_addr_copy(&top_iph->daddr, (struct in6_addr *)&x->id.daddr); +} + +static int xfrm6_tunnel_check_size(struct sk_buff *skb) +{ + int mtu, ret = 0; + struct dst_entry *dst = skb->dst; + + mtu = dst_pmtu(dst) - sizeof(struct ipv6hdr); + if (mtu < IPV6_MIN_MTU) + mtu = IPV6_MIN_MTU; + + if (skb->len > mtu) { + icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb->dev); + ret = -EMSGSIZE; + } + + return ret; } int xfrm6_output(struct sk_buff **pskb) ===== net/ipv6/xfrm6_tunnel.c 1.4 vs edited ===== --- 1.4/net/ipv6/xfrm6_tunnel.c 2004-08-02 07:15:03 +10:00 +++ edited/net/ipv6/xfrm6_tunnel.c 2004-08-02 18:07:06 +10:00 @@ -27,8 +27,8 @@ #include #include #include -#include #include +#include #include #include @@ -342,25 +342,6 @@ } EXPORT_SYMBOL(xfrm6_tunnel_free_spi); - -int xfrm6_tunnel_check_size(struct sk_buff *skb) -{ - int mtu, ret = 0; - struct dst_entry *dst = skb->dst; - - mtu = dst_pmtu(dst) - sizeof(struct ipv6hdr); - if (mtu < IPV6_MIN_MTU) - mtu = IPV6_MIN_MTU; - - if (skb->len > mtu) { - icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb->dev); - ret = -EMSGSIZE; - } - - return ret; -} - -EXPORT_SYMBOL(xfrm6_tunnel_check_size); static int xfrm6_tunnel_output(struct sk_buff **pskb) { ===== net/xfrm/xfrm_export.c 1.2 vs edited ===== --- 1.2/net/xfrm/xfrm_export.c 2004-06-18 16:20:58 +10:00 +++ edited/net/xfrm/xfrm_export.c 2004-08-02 17:58:32 +10:00 @@ -35,7 +35,6 @@ EXPORT_SYMBOL(xfrm4_rcv); EXPORT_SYMBOL(xfrm4_tunnel_register); EXPORT_SYMBOL(xfrm4_tunnel_deregister); -EXPORT_SYMBOL(xfrm4_tunnel_check_size); EXPORT_SYMBOL(xfrm_register_type); EXPORT_SYMBOL(xfrm_unregister_type); EXPORT_SYMBOL(xfrm_get_type); --82I3+IH0IqGh5yIs-- From ptsjohol@cc.jyu.fi Mon Aug 2 02:58:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Aug 2004 02:58:20 -0700 (PDT) Received: from posti5.jyu.fi (posti5.jyu.fi [130.234.4.34]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i729wCVX002631 for ; Mon, 2 Aug 2004 02:58:13 -0700 Received: from silmu.st.jyu.fi (IDENT:KCtRHLQSWRfY1ggLLWY2hN3kjBDFjO1g@silmu.st.jyu.fi [130.234.4.64]) by posti5.jyu.fi (8.12.8/8.12.8/antispam) with ESMTP id i729vicn005376; Mon, 2 Aug 2004 12:57:45 +0300 Date: Mon, 2 Aug 2004 12:57:41 +0300 (EEST) From: Pasi Sjoholm X-X-Sender: ptsjohol@silmu.st.jyu.fi To: Francois Romieu cc: Robert Olsson , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: <20040731143330.A25736@electric-eye.fr.zoreil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at posti5.jyu.fi; Mon, 02 Aug 2004 12:57:47 +0300 X-archive-position: 7407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ptsjohol@cc.jyu.fi Precedence: bulk X-list: netdev On Sat, 31 Jul 2004, Francois Romieu wrote: > Pasi Sjoholm : > [interesting report] >> The hardest part is to tell where the problem is but I think that >> rtl8139_poll-function would be good place to start looking for the bug? >> readprofile didn't tell much.. Where to go next? I'm not so good >> programmer that I could find the right place to fix.. > In case it could make a difference: did you check if CONFIG_8139_OLD_RX_RESET > changes the behavior or not ? Yep, I tried that one also, didn't help a thing. > If it does not, I'd welcome a test report + log with the two attached patch > applied. The first one is just a placebo but the second one could help. We are making some sort of a progress but not enough. Patch r8139-20.patch didn't help. I made some printk(...)-debug messages and that part of a code was never ran. With both patch applied and RTL8139DEBUG = 1 I couldn't make the driver crash but without DEBUG it did crash. I assume that it has something to with fact that syslog did take so much io-bandwidth. (a couple of minutes log was ~1GB =)) But without: -- @@ -2024,17 +2024,17 @@ static int rtl8139_rx(struct net_device cur_rx = (cur_rx + rx_size + 4 + 3) & ~3; RTL_W16 (RxBufPtr, (u16) (cur_rx - 16)); + } - /* Clear out errors and receive interrupts */ - status = RTL_R16 (IntrStatus) & RxAckBits; - if (likely(status != 0)) { - if (unlikely(status & (RxFIFOOver | RxOverflow))) { - tp->stats.rx_errors++; - if (status & RxFIFOOver) - tp->stats.rx_fifo_errors++; - } - RTL_W16_F (IntrStatus, RxAckBits); + /* Clear out errors and receive interrupts */ + status = RTL_R16 (IntrStatus) & RxAckBits; + if (likely(status != 0)) { + if (unlikely(status & (RxFIFOOver | RxOverflow))) { + tp->stats.rx_errors++; + if (status & RxFIFOOver) + tp->stats.rx_fifo_errors++; } + RTL_W16_F (IntrStatus, RxAckBits); } done: -- the driver crashed... even with debug-option was turned on. Everytime the ksoftirqd started to take cpu-time there were this line in the logs: -- Aug 2 12:10:37 139_interrupt: eth0:..... -- Notice the 139... it should read rtl8139_interrupt: Here is a snapshot from the log file when driver is crashing: Full logfile is available from: http://www.cc.jyu.fi/~ptsjohol/syslog-debug.gz -- Aug 2 12:10:37 rtl8139_rx: eth0: In rtl8139_rx(), current 03ac BufAddr 036c, free to 039c, Cmd 0c. Aug 2 12:10:37 rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0000. Aug 2 12:10:37 rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0001. Aug 2 12:10:37 rtl8139_rx: eth0: In rtl8139_rx(), current 0484 BufAddr 0444, free to 0474, Cmd 0c. Aug 2 12:10:37 rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0000. Aug 2 12:10:37 139_interrupt: eth0: exiting interrupt, intr_status=0x0010. Aug 2 12:10:37 rtl8139_rx: eth0: In rtl8139_rx(), current 04d0 BufAddr 04cc, free to 04c0, Cmd 0d. Aug 2 12:10:37 rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0010. Aug 2 12:10:37 rtl8139_rx: eth0: In rtl8139_rx(), current 04d0 BufAddr 04cc, free to 04c0, Cmd 0d. Aug 2 12:10:37 rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0010. Aug 2 12:10:37 rtl8139_rx: eth0: In rtl8139_rx(), current 04d0 BufAddr 04cc, free to 04c0, Cmd 0d. ...... ...... Aug 2 12:12:11 rtl8139_rx: eth0: In rtl8139_rx(), current 04d0 BufAddr 04cc, free to 04c0, Cmd 0d. Aug 2 12:12:11 rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0050. Aug 2 12:12:11 rtl8139_rx: eth0: In rtl8139_rx(), current 04d0 BufAddr 04cc, free to 04c0, Cmd 0d. Aug 2 12:12:11 rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0050. Aug 2 12:12:11 rtl8139_rx: eth0: In rtl8139_rx(), current 04d0 BufAddr 04cc, free to 04c0, Cmd 0d. Aug 2 12:12:11 rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0050. -- -- Pasi Sjöholm From ptsjohol@cc.jyu.fi Mon Aug 2 03:03:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Aug 2004 03:03:44 -0700 (PDT) Received: from posti6.jyu.fi (posti6.jyu.fi [130.234.4.43]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72A3cR6003493 for ; Mon, 2 Aug 2004 03:03:39 -0700 Received: from silmu.st.jyu.fi (IDENT:oxRA6s6O4mJuvi+sWEjRqL5K3wIrdnnK@silmu.st.jyu.fi [130.234.4.64]) by posti6.jyu.fi (8.12.8/8.12.8/antispam) with ESMTP id i72A3Iob001597; Mon, 2 Aug 2004 13:03:18 +0300 Date: Mon, 2 Aug 2004 13:03:15 +0300 (EEST) From: Pasi Sjoholm X-X-Sender: ptsjohol@silmu.st.jyu.fi To: Francois Romieu cc: Robert Olsson , H?ctor Mart?n , Linux-Kernel , , , , Subject: Re: ksoftirqd uses 99% CPU triggered by network traffic (maybe RLT-8139 related) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at posti6.jyu.fi; Mon, 02 Aug 2004 13:03:19 +0300 X-archive-position: 7408 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ptsjohol@cc.jyu.fi Precedence: bulk X-list: netdev I forgot to mention that it was quite hard to crash the driver with that /* Clear out errors and receive interrupts */-patch. Took about 15minutes everytime, when normally it takes about 2mins. On Mon, 2 Aug 2004, Pasi Sjoholm wrote: > With both patch applied and RTL8139DEBUG = 1 I couldn't make the driver > crash but without DEBUG it did crash. I assume that it has something to > with fact that syslog did take so much io-bandwidth. (a couple of minutes log > was ~1GB =)) > > But without: > > -- > @@ -2024,17 +2024,17 @@ static int rtl8139_rx(struct net_device > > cur_rx = (cur_rx + rx_size + 4 + 3) & ~3; > RTL_W16 (RxBufPtr, (u16) (cur_rx - 16)); > + } > > - /* Clear out errors and receive interrupts */ > - status = RTL_R16 (IntrStatus) & RxAckBits; > - if (likely(status != 0)) { > - if (unlikely(status & (RxFIFOOver | RxOverflow))) > { > - tp->stats.rx_errors++; > - if (status & RxFIFOOver) > - tp->stats.rx_fifo_errors++; > - } > - RTL_W16_F (IntrStatus, RxAckBits); > + /* Clear out errors and receive interrupts */ > + status = RTL_R16 (IntrStatus) & RxAckBits; > + if (likely(status != 0)) { > + if (unlikely(status & (RxFIFOOver | RxOverflow))) { > + tp->stats.rx_errors++; > + if (status & RxFIFOOver) > + tp->stats.rx_fifo_errors++; > } > + RTL_W16_F (IntrStatus, RxAckBits); > } > > done: > -- > > the driver crashed... even with debug-option was turned on. > Everytime the ksoftirqd started to take cpu-time there were this line in > the logs: From ak@suse.de Mon Aug 2 04:46:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Aug 2004 04:46:48 -0700 (PDT) Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72BkfUC009561 for ; Mon, 2 Aug 2004 04:46:41 -0700 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id B3C839A8D29; Mon, 2 Aug 2004 13:45:07 +0200 (CEST) Date: Mon, 2 Aug 2004 13:45:06 +0200 From: Andi Kleen To: "David S. Miller" Cc: Jeff Garzik , tmattox@gmail.com, hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: [RFC,PATCH] fastroute dead code... Message-ID: <20040802114506.GC25951@wotan.suse.de> References: <20040730060348.GA22854@havoc.gtf.org> <20040730193515.GA11365@havoc.gtf.org> <20040730131004.2be1274d.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040730131004.2be1274d.davem@redhat.com> X-archive-position: 7409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Fri, Jul 30, 2004 at 01:10:04PM -0700, David S. Miller wrote: > On Fri, 30 Jul 2004 15:35:15 -0400 > Jeff Garzik wrote: > > > It is dead code, as-is, in the kernel. It would require patches to > > actually work at all. > > > > It is impossible that fastrouting is being actively used, without patches. > > I totally agree. And people can always resurrect it from the > repository history or an old tarball if they wish. > > I think it should be killed entirely, and that's what I'm going > to do. The s390 people used to use it for local forwarding between partitions. I don't know if they still do however. -Andi > From bruce@cs.usyd.edu.au Mon Aug 2 06:41:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Aug 2004 06:41:24 -0700 (PDT) Received: from staff.cs.usyd.edu.au (staff.cs.usyd.edu.au [129.78.8.1]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i72DfF2n018446 for ; Mon, 2 Aug 2004 06:41:17 -0700 Received: from nlp0.cs.usyd.edu.au. [129.78.10.52] by staff.cs.usyd.edu.au.; Mon, 02 Aug 2004 23:41:09 +1000 Received: from nlp0.cs.usyd.edu.au (localhost.cs.usyd.edu.au [127.0.0.1]) by nlp0.cs.usyd.edu.au (8.12.8/8.12.8) with ESMTP id i72Df9Yo021571 for ; Mon, 2 Aug 2004 23:41:09 +1000 Received: (from bruce@localhost) by nlp0.cs.usyd.edu.au (8.12.8/8.12.8/Submit) id i72Df9TP021569 for netdev@oss.sgi.com; Mon, 2 Aug 2004 23:41:09 +1000 Message-Id: <200408021341.i72Df9TP021569@nlp0.cs.usyd.edu.au> Date: Mon, 02 Aug 2004 23:29:20 +1000 From: bruce@it.usyd.edu.au (Bruce Janson) Subject: Re: 2.6.7 kernel boot-time configuration of a non-modular tulip driver To: netdev@oss.sgi.com Cc: bruce@it.usyd.edu.au X-archive-position: 7410 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bruce@it.usyd.edu.au Precedence: bulk X-list: netdev Hi Randy, Thanks for your reply. From rddunlap@osdl.org Mon Aug 02 03:43:31 2004 ... To: bruce@it.usyd.edu.au (Bruce Janson) Cc: netdev ... (moving this to netdev mailing list) ... [OK, but please Cc me explicitly as I don't subscribe to netdev.] On Sun, 01 Aug 2004 00:48:22 +1000 Bruce Janson wrote: | I have a linux 2.6.7 kernel which contains a compiled-in tulip driver. | I would like to be able to boot the kernel with parameters that | will allow control of the tulip device. On some ethernet devices | this used to be possible via (something like): | | ether=0,0,1,0,eth0 | | which would pass the four numeric parameters (as, I think, dev->irq, | dev->ioaddr, dev->mem_start and dev->mem_end) to the net driver that | controlled eth0. A convention adopted by some net drivers then allowed | dev->mem_start to be interpretted as a set of flags that would control | device characteristics (e.g. full-duplex vs half-duplex mode). | In .../linux-2.6.7/drivers/net/tulip/tulip_core.c:1587: | | if (dev->mem_start & MEDIA_MASK) | tp->default_port = dev->mem_start & MEDIA_MASK; | | suggests that this might still work. However, I have been unable | to force dev->mem_start in that driver to become non-zero via any | kernel boot-time parameters. My limited understanding of the code | that precedes the above lines in that file suggests that the "dev" | structure is not what it used to be... The driver never calls netdev_boot_setup_check(), which is what would give the driver its command line parameters. Did this work in early 2.6.x? There have been several changes in this area. ... No idea. This is the first in the 2.6 kernel series that I have tried. The driver can't do a simple call to netdev_boot_setup_check() because that will overwrite dev-> {irq, base_addr, mem_start, mem_end}, and those values come from PCI config space for PCI drivers. The driver could create a fake for that purpose, but it's more likely that ethtool or mii-tool should be used to change media/speed etc... Although now that I look at the driver source code, I don't see ethtool or mii-tool support for those options. ... Yes (tried that too :-(). | ../linux-2.6.7/Documentation/kernel-parameters.txt:402 still | mentions "ether=..." but marks it as obsolete, replaced by | the equivalent "netdev=...". Elsewhere in that file, the entry | for "netdev=..." describes what appears to be the functionality | that I seek. | | So, is it still possible to perform the same sort of control | operations on a tulip driver via kernel boot-time parameters | as one can do via module load-time parameters? If so, how? The current tulip-core driver supports setting only the default transceiver (media type) on the kernel boot/command line when the driver is built into the kernel image (using mem_start, as you noted above). ... Sorry, I don't follow the above. Would you mind giving me an example, please, of how for the tulip driver I might set the default transceiver (media type) on the kernel boot/command line when the driver is built into the kernel image? Regards, bruce. From shinemohamed_j@naturesoft.net Mon Aug 2 06:54:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Aug 2004 06:54:10 -0700 (PDT) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72Drw4i019218 for ; Mon, 2 Aug 2004 06:54:03 -0700 Received: from shine.naturesoft.com ([192.168.0.84]) by naturesoft.net with esmtp (Exim 3.35 #1) id 1BrcyI-0005qE-00; Mon, 02 Aug 2004 19:05:22 +0530 Subject: [TRIVIAL PATCH]mistake in the comment in include/linux/wireless.h From: Shine Mohamed Jabbar Reply-To: shinemohamed_j@naturesoft.net To: davem@redhat.com Cc: jt@hpl.hp.com, netdev@oss.sgi.com Content-Type: multipart/mixed; boundary="=-kVZOS8vuCIva4VAmkT5m" Organization: Naturesoft Message-Id: <1091454063.25300.109.camel@shine.naturesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 02 Aug 2004 19:11:03 +0530 X-archive-position: 7411 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shinemohamed_j@naturesoft.net Precedence: bulk X-list: netdev --=-kVZOS8vuCIva4VAmkT5m Content-Type: text/plain Content-Transfer-Encoding: 7bit [Resend - forgot to cc to netdev ML] Hi Dave, There is a mistake in the comment given in the include/linux/wireless.h. The given patch will fix it. Please apply if its useful. Regards, Shine Mohamed Jabbar --=-kVZOS8vuCIva4VAmkT5m Content-Description: Content-Disposition: attachment; filename=diff.patch Content-Type: text/x-patch; charset=UTF-8 Content-Transfer-Encoding: 7bit --- linux-2.6.8-rc2-bk11/include/linux/wireless.h.orig 2004-08-02 17:39:11.891418904 +0530 +++ linux-2.6.8-rc2-bk11/include/linux/wireless.h 2004-08-02 17:35:56.309151928 +0530 @@ -47,12 +47,12 @@ * # include/net/iw_handler.h * * Note as well that /proc/net/wireless implementation has now moved in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Wireless Events (2002 -> onward) : * -------------------------------- * Events are defined at the end of this file, and implemented in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Other comments : * -------------- --=-kVZOS8vuCIva4VAmkT5m-- From yoshfuji@linux-ipv6.org Mon Aug 2 06:59:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 02 Aug 2004 06:59:26 -0700 (PDT) Received: from yue.st-paulia.net ([203.178.140.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i72DxJVW019590 for ; Mon, 2 Aug 2004 06:59:19 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.st-paulia.net (Postfix) with ESMTP id BEE3233CE5; Mon, 2 Aug 2004 22:59:40 +0900 (JST) Date: Mon, 02 Aug 2004 06:59:40 -0700 (PDT) Message-Id: <20040802.065940.86004622.yoshfuji@linux-ipv6.org> To: suckfish@ihug.co.nz Cc: davem@redhat.com, pekkas@netcore.fi, linux-kernel@vger.kernel.org, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] Trivial ipv6 fix. From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <1091434328.16469.5.camel@localhost.localdomain> References: <1091434328.16469.5.camel@localhost.localdomain> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 7412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <1091434328.16469.5.camel@localhost.localdomain> (at Mon, 02 Aug 2004 20:12:08 +1200), Ralph Loader says: > ipv6_addr_hash doesn't do what it's comment says. The comment was > probably what was intended, not that it'll make much difference in > practice. Oops, David, please apply this. > Signed-off-by: Ralph Loader Signed-off-by: Hideaki YOSHIFUJI ===== include/net/addrconf.h 1.17 vs edited ===== --- 1.17/include/net/addrconf.h 2004-07-29 02:00:50 +09:00 +++ edited/include/net/addrconf.h 2004-08-02 22:57:38 +09:00 @@ -178,8 +178,8 @@ * This will include the IEEE address token on links that support it. */ - word = addr->s6_addr[2] ^ addr->s6_addr32[3]; - word ^= (word>>16); + word = addr->s6_addr32[2] ^ addr->s6_addr32[3]; + word ^= (word >> 16); word ^= (word >> 8); return ((word ^ (word >> 4))