From owner-netdev@oss.sgi.com Wed Nov  1 00:21:37 2000
Received:  by oss.sgi.com id <S553933AbQKAIV1>;
	Wed, 1 Nov 2000 00:21:27 -0800
Received: from battlejitney.wdhq.scyld.com ([216.254.93.178]:39151 "EHLO
        vaio.greennet") by oss.sgi.com with ESMTP id <S553742AbQKAIVD>;
	Wed, 1 Nov 2000 00:21:03 -0800
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id DAA11594;
	Wed, 1 Nov 2000 03:23:38 -0500
Date:   Wed, 1 Nov 2000 03:23:38 -0500 (EST)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     Paul Gortmaker <p_gortmaker@yahoo.com>
cc:     Jeff Garzik <jgarzik@mandrakesoft.com>,
        pavel rabel <pavel@web.sajt.cz>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] NE2000
In-Reply-To: <39FFAA94.4D389E85@yahoo.com>
Message-ID: <Pine.LNX.4.10.10011010315070.11540-100000@vaio.greennet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Wed, 1 Nov 2000, Paul Gortmaker wrote:

> Jeff Garzik wrote:
> > Paul Gortmaker wrote:
> > > There is no urgency in trying to squeeze a patch like this in the back
> > > door of a 2.4.0 release.  For example, there are people out there now
> > > who are using the ne.c driver to run both ISA and PCI cards in the same
> > > box without having to use 2 different drivers.  We can wait until 2.5.0
> > > to break their .config file.
> > 
> > IMNSHO this is a bug, though...
..
> If you want to roll it into the merge (and can get it past Linus) then
> please feel free to do so - I'll be glad to cross it off my list sooner
> as opposed to later.

If the ne* drivers are going to be updated, you might want to add in the
full-duplex support of the latest ne2k-pci.c driver at
    ftp://www.scyld.com/pub/network/ne2k-pci.c

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993


From owner-netdev@oss.sgi.com Wed Nov  1 05:30:20 2000
Received:  by oss.sgi.com id <S553946AbQKANaB>;
	Wed, 1 Nov 2000 05:30:01 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:37389 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S553944AbQKAN3j>;
	Wed, 1 Nov 2000 05:29:39 -0800
Received: from mandrakesoft.com ([66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id IAA11009;
	Wed, 1 Nov 2000 08:28:17 -0500
Message-ID: <3A001A53.1A5BB6E0@mandrakesoft.com>
Date:   Wed, 01 Nov 2000 08:27:47 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18pre18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Paul Gortmaker <p_gortmaker@yahoo.com>
CC:     pavel rabel <pavel@web.sajt.cz>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Donald Becker <becker@scyld.com>
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.21.0010300344130.6792-100000@web.sajt.cz> <39FC83CD.B10BF08D@mandrakesoft.com> <39FD3CB6.2F641BBF@yahoo.com> <39FDCC17.4C8B8074@mandrakesoft.com> <39FFAA94.4D389E85@yahoo.com>
Content-Type: multipart/mixed;
 boundary="------------63C6B08DCC457D46D72A79F1"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This is a multi-part message in MIME format.
--------------63C6B08DCC457D46D72A79F1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul,

Ok, here's what I have.  Included are your changes, as well as

drivers/net/ne.c:
* use probe_irq_on/off instead of autoirq_xxx (autoirq is going away)
* request_region first thing in ne_probe1, before any hardware
interaction takes place.  Eliminates any potential resource races.  Also
eliminates a call to check_region.
* Trim trailing whitespace

drivers/net/ne2k-pci.c:
* Merge Becker version 1.02 ne2k-pci.c, which adds forced full duplex
support, and also several cosmetic changes where merely serve to bring
the kernel's ne2k-pci.c closer to Becker's version (ie. makes the diff
smaller).
* Just call BUG() if we don't have a net_device in ne2k_pci_remove_one
* Correct pci_module_init return code handling

As an aside, for 2.5.x, would it be possible to merge all the common
ne2000 code (block_input/output, etc.) from the various ne2k drivers? 
As it stands there exists ne.c, ne2.c, ne2k-pci.c, and pcnet_cs.c, all
of which do pretty much the same thing at their core.  [and AFAICS, all
but pcnet_cs might easily call a common ne2k library]

Regards,

	Jeff


-- 
Jeff Garzik             | "Mind if I drive?"  -Sam
Building 1024           | "Not if you don't mind me clawing at the
MandrakeSoft            |  dash and shrieking like a cheerleader."
                        |                     -Max
--------------63C6B08DCC457D46D72A79F1
Content-Type: text/plain; charset=us-ascii;
 name="ne.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ne.patch"

Index: drivers/net/ne.c
===================================================================
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/ne.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 ne.c
--- drivers/net/ne.c	2000/10/31 21:21:49	1.1.1.4
+++ drivers/net/ne.c	2000/11/01 13:24:36
@@ -29,21 +29,22 @@
     occur after memory is allocated for dev->priv. Deallocated memory
     last in cleanup_modue()
     Richard Guenther    : Added support for ISAPnP cards
-    
+    Paul Gortmaker	: Discontinued PCI support - use ne2k-pci.c instead.
+
 */
 
 /* Routines for the NatSemi-based designs (NE[12]000). */
 
-static const char *version =
-    "ne.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov)\n";
+static const char version1[] =
+"ne.c:v1.10 9/23/94 Donald Becker (becker@scyld.com)\n";
+static const char version2[] =
+"Last modified Nov 1, 2000 by Paul Gortmaker\n";
 
 
 #include <linux/module.h>
-#include <linux/config.h>
 #include <linux/kernel.h>
 #include <linux/sched.h>
 #include <linux/errno.h>
-#include <linux/pci.h>
 #include <linux/isapnp.h>
 #include <linux/init.h>
 #include <linux/delay.h>
@@ -70,28 +71,11 @@
 
 /* A zero-terminated list of I/O addresses to be probed at boot. */
 #ifndef MODULE
-static unsigned int netcard_portlist[] __initdata = { 
+static unsigned int netcard_portlist[] __initdata = {
 	0x300, 0x280, 0x320, 0x340, 0x360, 0x380, 0
 };
 #endif
 
-#ifdef CONFIG_PCI
-/* Ack! People are making PCI ne2000 clones! Oh the horror, the horror... */
-static struct { unsigned short vendor, dev_id; char *name; }
-pci_clone_list[] __initdata = {
-	{PCI_VENDOR_ID_REALTEK,		PCI_DEVICE_ID_REALTEK_8029,		"Realtek 8029" },
-	{PCI_VENDOR_ID_WINBOND2,	PCI_DEVICE_ID_WINBOND2_89C940,		"Winbond 89C940" },
-	{PCI_VENDOR_ID_COMPEX,		PCI_DEVICE_ID_COMPEX_RL2000,		"Compex ReadyLink 2000" },
-	{PCI_VENDOR_ID_KTI,		PCI_DEVICE_ID_KTI_ET32P2,		"KTI ET32P2" },
-	{PCI_VENDOR_ID_NETVIN,		PCI_DEVICE_ID_NETVIN_NV5000SC,		"NetVin NV5000" },
-	{PCI_VENDOR_ID_VIA,		PCI_DEVICE_ID_VIA_82C926,		"VIA 82C926 Amazon" },
-	{PCI_VENDOR_ID_SURECOM,		PCI_DEVICE_ID_SURECOM_NE34,		"SureCom NE34"},
-	{0,}
-};
-
-static int probe_pci = 1;
-#endif
-
 static struct { unsigned short vendor, function; char *name; }
 isapnp_clone_list[] __initdata = {
 	{ISAPNP_VENDOR('E','D','I'), ISAPNP_FUNCTION(0x0216),		"NN NE2000" },
@@ -114,7 +98,9 @@
     {"ET-100","ET-200", {0x00, 0x45, 0x54}}, /* YANG and YA clone */
     {"COMPEX","COMPEX16",{0x00,0x80,0x48}}, /* Broken ISA Compex cards */
     {"E-LAN100", "E-LAN200", {0x00, 0x00, 0x5d}}, /* Broken ne1000 clones */
-    {"PCM-4823", "PCM-4823", {0x00, 0xc0, 0x6c}}, /* Broken Advantech MoBo */    
+    {"PCM-4823", "PCM-4823", {0x00, 0xc0, 0x6c}}, /* Broken Advantech MoBo */
+    {"REALTEK", "RTL8019", {0x00, 0x00, 0xe8}}, /* no-name with Realtek chip */
+    {"LCS-8834", "LCS-8836", {0x04, 0x04, 0x37}}, /* ShinyNet (SET) */
     {0,}
 };
 #endif
@@ -132,15 +118,9 @@
 #define NESM_START_PG	0x40	/* First page of TX buffer */
 #define NESM_STOP_PG	0x80	/* Last page +1 of RX ring */
 
-/* Non-zero only if the current card is a PCI with BIOS-set IRQ. */
-static unsigned int pci_irq_line = 0;
-
 int ne_probe(struct net_device *dev);
 static int ne_probe1(struct net_device *dev, int ioaddr);
 static int ne_probe_isapnp(struct net_device *dev);
-#ifdef CONFIG_PCI
-static int ne_probe_pci(struct net_device *dev);
-#endif
 
 static int ne_open(struct net_device *dev);
 static int ne_close(struct net_device *dev);
@@ -175,16 +155,9 @@
 	E2010	 starts at 0x100 and ends at 0x4000.
 	E2010-x starts at 0x100 and ends at 0xffff.  */
 
-/*
- * Note that at boot, this probe only picks up one card at a time, even for
- * multiple PCI ne2k cards. Use "ether=0,0,eth1" if you have a second PCI
- * ne2k card.  This keeps things consistent regardless of the bus type of
- * the card.
- */
-
 int __init ne_probe(struct net_device *dev)
 {
-	int base_addr = dev ? dev->base_addr : 0;
+	unsigned int base_addr = dev ? dev->base_addr : 0;
 
 	/* First check any supplied i/o locations. User knows best. <cough> */
 	if (base_addr > 0x1ff)	/* Check a single specified location. */
@@ -192,12 +165,6 @@
 	else if (base_addr != 0)	/* Don't probe at all. */
 		return -ENXIO;
 
-#ifdef CONFIG_PCI
-	/* Then look for any installed PCI clones */
-	if (probe_pci && pci_present() && (ne_probe_pci(dev) == 0))
-		return 0;
-#endif
-
 	/* Then look for any installed ISAPnP clones */
 	if (isapnp_present() && (ne_probe_isapnp(dev) == 0))
 		return 0;
@@ -206,8 +173,6 @@
 	/* Last resort. The semi-risky ISA auto-probe. */
 	for (base_addr = 0; netcard_portlist[base_addr] != 0; base_addr++) {
 		int ioaddr = netcard_portlist[base_addr];
-		if (check_region(ioaddr, NE_IO_EXTENT))
-			continue;
 		if (ne_probe1(dev, ioaddr) == 0)
 			return 0;
 	}
@@ -216,47 +181,10 @@
 	return -ENODEV;
 }
 
-#ifdef CONFIG_PCI
-static int __init ne_probe_pci(struct net_device *dev)
-{
-	int i;
-
-	for (i = 0; pci_clone_list[i].vendor != 0; i++) {
-		struct pci_dev *pdev = NULL;
-		unsigned int pci_ioaddr = 0;
-
-		while ((pdev = pci_find_device(pci_clone_list[i].vendor, pci_clone_list[i].dev_id, pdev))) {
-			if (pci_enable_device(pdev))
-				continue;
-			pci_ioaddr = pci_resource_start (pdev, 0);
-			/* Avoid already found cards from previous calls */
-			if (check_region(pci_ioaddr, NE_IO_EXTENT))
-				continue;
-			pci_irq_line = pdev->irq;
-			if (pci_irq_line) break;	/* Found it */
-		}
-		if (!pdev)
-			continue;
-		printk(KERN_INFO "ne.c: PCI BIOS reports %s at i/o %#x, irq %d.\n",
-				pci_clone_list[i].name,
-				pci_ioaddr, pci_irq_line);
-		printk("*\n* Use of the PCI-NE2000 driver with this card is recommended!\n*\n");
-		if (ne_probe1(dev, pci_ioaddr) != 0) {	/* Shouldn't happen. */
-			printk(KERN_ERR "ne.c: Probe of PCI card at %#x failed.\n", pci_ioaddr);
-			pci_irq_line = 0;
-			return -ENXIO;
-		}
-		pci_irq_line = 0;
-		return 0;
-	}
-	return -ENODEV;
-}
-#endif  /* CONFIG_PCI */
-
 static int __init ne_probe_isapnp(struct net_device *dev)
 {
 	int i;
-	
+
 	for (i = 0; isapnp_clone_list[i].vendor != 0; i++) {
 		struct pci_dev *idev = NULL;
 
@@ -269,14 +197,18 @@
 				continue;
 			if (idev->activate(idev))
 				continue;
-			pci_irq_line = idev->irq_resource[0].start;
 			/* if no irq, search for next */
-			if (!pci_irq_line)
+			if (idev->irq_resource[0].start == 0)
 				continue;
 			/* found it */
-			if (ne_probe1(dev, idev->resource[0].start) != 0) {	/* Shouldn't happen. */
-				printk(KERN_ERR "ne.c: Probe of ISAPnP card at %#lx failed.\n",
-				       idev->resource[0].start);
+			dev->base_addr = idev->resource[0].start;
+			dev->irq = idev->irq_resource[0].start;
+			printk(KERN_INFO "ne.c: ISAPnP reports %s at i/o %#lx, irq %d.\n",
+				isapnp_clone_list[i].name,
+
+				dev->base_addr, dev->irq);
+			if (ne_probe1(dev, dev->base_addr) != 0) {	/* Shouldn't happen. */
+				printk(KERN_ERR "ne.c: Probe of ISAPnP card at %#lx failed.\n", dev->base_addr);
 				return -ENXIO;
 			}
 			ei_status.priv = (unsigned long)idev;
@@ -284,9 +216,6 @@
 		}
 		if (!idev)
 			continue;
-		printk(KERN_INFO "ne.c: ISAPnP reports %s at i/o %#lx, irq %d.\n",
-				isapnp_clone_list[i].name,
-				dev->base_addr, dev->irq);
 		return 0;
 	}
 
@@ -301,11 +230,17 @@
 	const char *name = NULL;
 	int start_page, stop_page;
 	int neX000, ctron, copam, bad_card;
-	int reg0 = inb_p(ioaddr);
+	int reg0, ret;
 	static unsigned version_printed = 0;
+
+	if (!request_region(ioaddr, NE_IO_EXTENT, dev->name))
+		return -EBUSY;
 
-	if (reg0 == 0xFF)
-		return -ENODEV;
+	reg0 = inb_p(ioaddr);
+	if (reg0 == 0xFF) {
+		ret = -ENODEV;
+		goto err_out;
+	}
 
 	/* Do a preliminary verification that we have a 8390. */
 	{
@@ -318,12 +253,13 @@
 		if (inb_p(ioaddr + EN0_COUNTER0) != 0) {
 			outb_p(reg0, ioaddr);
 			outb_p(regd, ioaddr + 0x0d);	/* Restore the old values. */
-			return -ENODEV;
+			ret = -ENODEV;
+			goto err_out;
 		}
 	}
 
 	if (ei_debug  &&  version_printed++ == 0)
-		printk(version);
+		printk(KERN_INFO "%s" KERN_INFO "%s", version1, version2);
 
 	printk(KERN_INFO "NE*000 ethercard probe at %#3x:", ioaddr);
 
@@ -350,10 +286,11 @@
 				break;
 			} else {
 				printk(" not found (no reset ack).\n");
-				return -ENODEV;
+				ret = -ENODEV;
+				goto err_out;
 			}
 		}
-	
+
 		outb_p(0xff, ioaddr + EN0_ISR);		/* Ack all intr. */
 	}
 
@@ -362,7 +299,7 @@
 	   We can't reliably read the SAPROM address without this.
 	   (I learned the hard way!). */
 	{
-		struct {unsigned char value, offset; } program_seq[] = 
+		struct {unsigned char value, offset; } program_seq[] =
 		{
 			{E8390_NODMA+E8390_PAGE0+E8390_STOP, E8390_CMD}, /* Select page 0*/
 			{0x48,	EN0_DCFG},	/* Set byte-wide (0x48) access. */
@@ -390,20 +327,10 @@
 			wordlength = 1;
 	}
 
-	/* At this point, wordlength *only* tells us if the SA_prom is doubled
-	   up or not because some broken PCI cards don't respect the byte-wide
-	   request in program_seq above, and hence don't have doubled up values.
-	   These broken cards would otherwise be detected as an ne1000.  */
-
 	if (wordlength == 2)
+	{
 		for (i = 0; i < 16; i++)
 			SA_prom[i] = SA_prom[i+i];
-
-	if (pci_irq_line || ioaddr >= 0x400)
-		wordlength = 2;		/* Catch broken PCI cards mentioned above. */
-
-	if (wordlength == 2) 
-	{
 		/* We must set the 8390 for word mode. */
 		outb_p(0x49, ioaddr + EN0_DCFG);
 		start_page = NESM_START_PG;
@@ -416,13 +343,12 @@
 	neX000 = (SA_prom[14] == 0x57  &&  SA_prom[15] == 0x57);
 	ctron =  (SA_prom[0] == 0x00 && SA_prom[1] == 0x00 && SA_prom[2] == 0x1d);
 	copam =  (SA_prom[14] == 0x49 && SA_prom[15] == 0x00);
-	
 
 	/* Set up the rest of the parameters. */
 	if (neX000 || bad_card || copam) {
 		name = (wordlength == 2) ? "NE2000" : "NE1000";
 	}
-	else if (ctron) 
+	else if (ctron)
 	{
 		name = (wordlength == 2) ? "Ctron-8" : "Ctron-16";
 		start_page = 0x01;
@@ -433,13 +359,13 @@
 #ifdef SUPPORT_NE_BAD_CLONES
 		/* Ack!  Well, there might be a *bad* NE*000 clone there.
 		   Check for total bogus addresses. */
-		for (i = 0; bad_clone_list[i].name8; i++) 
+		for (i = 0; bad_clone_list[i].name8; i++)
 		{
 			if (SA_prom[0] == bad_clone_list[i].SAprefix[0] &&
 				SA_prom[1] == bad_clone_list[i].SAprefix[1] &&
-				SA_prom[2] == bad_clone_list[i].SAprefix[2]) 
+				SA_prom[2] == bad_clone_list[i].SAprefix[2])
 			{
-				if (wordlength == 2) 
+				if (wordlength == 2)
 				{
 					name = bad_clone_list[i].name16;
 				} else {
@@ -448,31 +374,30 @@
 				break;
 			}
 		}
-		if (bad_clone_list[i].name8 == NULL) 
+		if (bad_clone_list[i].name8 == NULL)
 		{
 			printk(" not found (invalid signature %2.2x %2.2x).\n",
 				SA_prom[14], SA_prom[15]);
-			return -ENXIO;
+			ret = -ENXIO;
+			goto err_out;
 		}
 #else
 		printk(" not found.\n");
-		return -ENXIO;
+		ret = -ENXIO;
+		goto err_out;
 #endif
 	}
-
-	if (pci_irq_line)
-		dev->irq = pci_irq_line;
 
-	if (dev->irq < 2) 
+	if (dev->irq < 2)
 	{
-		autoirq_setup(0);
+		unsigned long cookie = probe_irq_on();
 		outb_p(0x50, ioaddr + EN0_IMR);	/* Enable one interrupt. */
 		outb_p(0x00, ioaddr + EN0_RCNTLO);
 		outb_p(0x00, ioaddr + EN0_RCNTHI);
 		outb_p(E8390_RREAD+E8390_START, ioaddr); /* Trigger it... */
 		mdelay(10);		/* wait 10ms for interrupt to propagate */
 		outb_p(0x00, ioaddr + EN0_IMR); 		/* Mask it again. */
-		dev->irq = autoirq_report(0);
+		dev->irq = probe_irq_off(cookie);
 		if (ei_debug > 2)
 			printk(" autoirq is %d\n", dev->irq);
 	} else if (dev->irq == 2)
@@ -482,31 +407,27 @@
 
 	if (! dev->irq) {
 		printk(" failed to detect IRQ line.\n");
-		return -EAGAIN;
+		ret = -EAGAIN;
+		goto err_out;
 	}
 
 	/* Allocate dev->priv and fill in 8390 specific dev fields. */
-	if (ethdev_init(dev)) 
+	if (ethdev_init(dev))
 	{
         	printk (" unable to get memory for dev->priv.\n");
-        	return -ENOMEM;
+        	ret = -ENOMEM;
+		goto err_out;
 	}
-   
+
 	/* Snarf the interrupt now.  There's no point in waiting since we cannot
 	   share and the board will usually be enabled. */
-
-	{
-		int irqval = request_irq(dev->irq, ei_interrupt,
-				 pci_irq_line ? SA_SHIRQ : 0, name, dev);
-		if (irqval) {
-			printk (" unable to get IRQ %d (irqval=%d).\n", dev->irq, irqval);
-			kfree(dev->priv);
-			dev->priv = NULL;
-			return -EAGAIN;
-		}
+	ret = request_irq(dev->irq, ei_interrupt, 0, name, dev);
+	if (ret) {
+		printk (" unable to get IRQ %d (errno=%d).\n", dev->irq, ret);
+		goto err_out_kfree;
 	}
+
 	dev->base_addr = ioaddr;
-	request_region(ioaddr, NE_IO_EXTENT, name);
 
 	for(i = 0; i < ETHER_ADDR_LEN; i++) {
 		printk(" %2.2x", SA_prom[i]);
@@ -536,6 +457,13 @@
 	dev->stop = &ne_close;
 	NS8390_init(dev, 0);
 	return 0;
+
+err_out_kfree:
+	kfree(dev->priv);
+	dev->priv = NULL;
+err_out:
+	release_region(ioaddr, NE_IO_EXTENT);
+	return ret;
 }
 
 static int ne_open(struct net_device *dev)
@@ -589,7 +517,7 @@
 
 	/* This *shouldn't* happen. If it does, it's the last thing you'll see */
 
-	if (ei_status.dmaing) 
+	if (ei_status.dmaing)
 	{
 		printk(KERN_EMERG "%s: DMAing conflict in ne_get_8390_hdr "
 			"[DMAstat:%d][irqlock:%d].\n",
@@ -628,7 +556,7 @@
 	char *buf = skb->data;
 
 	/* This *shouldn't* happen. If it does, it's the last thing you'll see */
-	if (ei_status.dmaing) 
+	if (ei_status.dmaing)
 	{
 		printk(KERN_EMERG "%s: DMAing conflict in ne_block_input "
 			"[DMAstat:%d][irqlock:%d].\n",
@@ -642,10 +570,10 @@
 	outb_p(ring_offset & 0xff, nic_base + EN0_RSARLO);
 	outb_p(ring_offset >> 8, nic_base + EN0_RSARHI);
 	outb_p(E8390_RREAD+E8390_START, nic_base + NE_CMD);
-	if (ei_status.word16) 
+	if (ei_status.word16)
 	{
 		insw(NE_BASE + NE_DATAPORT,buf,count>>1);
-		if (count & 0x01) 
+		if (count & 0x01)
 		{
 			buf[count-1] = inb(NE_BASE + NE_DATAPORT);
 #ifdef NE_SANITY_CHECK
@@ -662,7 +590,7 @@
 	   this message you either 1) have a slightly incompatible clone
 	   or 2) have noise/speed problems with your bus. */
 
-	if (ei_debug > 1) 
+	if (ei_debug > 1)
 	{
 		/* DMA termination address check... */
 		int addr, tries = 20;
@@ -697,12 +625,12 @@
 	/* Round the count up for word writes.  Do we need to do this?
 	   What effect will an odd byte count have on the 8390?
 	   I should check someday. */
-	   
+
 	if (ei_status.word16 && (count & 0x01))
 		count++;
 
 	/* This *shouldn't* happen. If it does, it's the last thing you'll see */
-	if (ei_status.dmaing) 
+	if (ei_status.dmaing)
 	{
 		printk(KERN_EMERG "%s: DMAing conflict in ne_block_output."
 			"[DMAstat:%d][irqlock:%d]\n",
@@ -722,7 +650,7 @@
 	   Crynwr packet driver -- the NatSemi method doesn't work.
 	   Actually this doesn't always work either, but if you have
 	   problems with your NEx000 this is better than nothing! */
-	   
+
 	outb_p(0x42, nic_base + EN0_RCNTLO);
 	outb_p(0x00,   nic_base + EN0_RCNTHI);
 	outb_p(0x42, nic_base + EN0_RSARLO);
@@ -752,8 +680,8 @@
 #ifdef NE_SANITY_CHECK
 	/* This was for the ALPHA version only, but enough people have
 	   been encountering problems so it is still here. */
-	
-	if (ei_debug > 1) 
+
+	if (ei_debug > 1)
 	{
 		/* DMA termination address check... */
 		int addr, tries = 20;
@@ -765,7 +693,7 @@
 				break;
 		} while (--tries > 0);
 
-		if (tries <= 0) 
+		if (tries <= 0)
 		{
 			printk(KERN_WARNING "%s: Tx packet transfer address mismatch,"
 				"%#4.4x (expected) vs. %#4.4x (actual).\n",
@@ -801,10 +729,6 @@
 MODULE_PARM(irq, "1-" __MODULE_STRING(MAX_NE_CARDS) "i");
 MODULE_PARM(bad, "1-" __MODULE_STRING(MAX_NE_CARDS) "i");
 
-#ifdef CONFIG_PCI
-MODULE_PARM(probe_pci, "i");
-#endif
-
 /* This is set up so that no ISA autoprobe takes place. We can't guarantee
 that the ne2k probe is the last 8390 based probe to take place (as it
 is at boot) and so the probe will get confused by any other 8390 cards.
@@ -833,7 +757,7 @@
 		if (io[this_dev] != 0)
 			printk(KERN_WARNING "ne.c: No NE*000 card found at i/o = %#x\n", io[this_dev]);
 		else
-			printk(KERN_NOTICE "ne.c: No PCI cards found. Use \"io=0xNNN\" value(s) for ISA cards.\n");
+			printk(KERN_NOTICE "ne.c: You must supply \"io=0xNNN\" value(s) for ISA cards.\n");
 		unload_8390_module();
 		return -ENXIO;
 	}
Index: drivers/net/ne2k-pci.c
===================================================================
RCS file: /cvsroot/gkernel/linux_2_4/drivers/net/ne2k-pci.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 ne2k-pci.c
--- drivers/net/ne2k-pci.c	2000/10/22 21:55:54	1.1.1.3
+++ drivers/net/ne2k-pci.c	2000/11/01 13:24:36
@@ -2,30 +2,49 @@
 /*
 	A Linux device driver for PCI NE2000 clones.
 
-	Authorship and other copyrights:
-	1992-1998 by Donald Becker, NE2000 core and various modifications.
+	Authors and other copyright holders:
+	1992-2000 by Donald Becker, NE2000 core and various modifications.
 	1995-1998 by Paul Gortmaker, core modifications and PCI support.
-
 	Copyright 1993 assigned to the United States Government as represented
 	by the Director, National Security Agency.
-
-	This software may be used and distributed according to the terms
-	of the GNU Public License, incorporated herein by reference.
 
-	The author may be reached as becker@CESDIS.gsfc.nasa.gov, or C/O
-	Center of Excellence in Space Data and Information Sciences
-	Code 930.5, Goddard Space Flight Center, Greenbelt MD 20771
+	This software may be used and distributed according to the terms of
+	the GNU General Public License (GPL), incorporated herein by reference.
+	Drivers based on or derived from this code fall under the GPL and must
+	retain the authorship, copyright and license notice.  This file is not
+	a complete program and may only be used when the entire operating
+	system is licensed under the GPL.
+
+	The author may be reached as becker@scyld.com, or C/O
+	Scyld Computing Corporation
+	410 Severn Ave., Suite 210
+	Annapolis MD 21403
 
-	People are making PCI ne2000 clones! Oh the horror, the horror...
-
 	Issues remaining:
-	No full-duplex support.
+	People are making PCI ne2000 clones! Oh the horror, the horror...
+	Limited full-duplex support.
 */
 
-/* Our copyright info must remain in the binary. */
-static const char *version =
-"ne2k-pci.c:vpre-1.00e 5/27/99 D. Becker/P. Gortmaker http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html\n";
+/* These identify the driver base version and may not be removed. */
+static const char version1[] =
+"ne2k-pci.c:v1.02 10/19/2000 D. Becker/P. Gortmaker\n";
+static const char version2[] =
+"  http://www.scyld.com/network/ne2k-pci.html\n";
+
+/* The user-configurable values.
+   These may be modified when a driver module is loaded.*/
+
+static int debug = 1;			/* 1 normal messages, 0 quiet .. 7 verbose. */
+
+#define MAX_UNITS 8				/* More are supported, limit only on options */
+/* Used to pass the full-duplex flag, etc. */
+static int full_duplex[MAX_UNITS];
+static int options[MAX_UNITS];
 
+/* Force a non std. amount of memory.  Units are 256 byte pages. */
+/* #define PACKETBUF_MEMSIZE	0x40 */
+
+
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/sched.h>
@@ -48,8 +67,11 @@
 #define outsl outsl_ns
 #endif
 
-/* Set statically or when loading the driver module. */
-static int debug = 1;
+MODULE_AUTHOR("Donald Becker / Paul Gortmaker");
+MODULE_DESCRIPTION("PCI NE2000 clone driver");
+MODULE_PARM(debug, "i");
+MODULE_PARM(options, "1-" __MODULE_STRING(MAX_UNITS) "i");
+MODULE_PARM(full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i");
 
 /* Some defines that people can play with if so inclined. */
 
@@ -59,19 +81,16 @@
 /* Do we implement the read before write bugfix ? */
 /* #define NE_RW_BUGFIX */
 
-/* Do we have a non std. amount of memory? (in units of 256 byte pages) */
-/* #define PACKETBUF_MEMSIZE	0x40 */
-
-#define ne2k_flags reg0			/* Rename an existing field to store flags! */
-
-/* Only the low 8 bits are usable for non-init-time flags! */
+/* Flags.  We rename an existing ei_status field to store flags! */
+/* Thus only the low 8 bits are usable for non-init-time flags. */
+#define ne2k_flags reg0
 enum {
-	HOLTEK_FDX=1, 		/* Full duplex -> set 0x80 at offset 0x20. */
-	ONLY_16BIT_IO=2, ONLY_32BIT_IO=4,	/* Chip can do only 16/32-bit xfers. */
+	ONLY_16BIT_IO=8, ONLY_32BIT_IO=4,	/* Chip can do only 16/32-bit xfers. */
+	FORCE_FDX=0x20,						/* User override. */
+	REALTEK_FDX=0x40, HOLTEK_FDX=0x80,
 	STOP_PG_0x60=0x100,
 };
 
-
 enum ne2k_pci_chipsets {
 	CH_RealTek_RTL_8029 = 0,
 	CH_Winbond_89C940,
@@ -90,7 +109,7 @@
 	char *name;
 	int flags;
 } pci_clone_list[] __devinitdata = {
-	{"RealTek RTL-8029", 0},
+	{"RealTek RTL-8029", REALTEK_FDX},
 	{"Winbond 89C940", 0},
 	{"Compex RL2000", 0},
 	{"KTI ET32P2", 0},
@@ -145,7 +164,8 @@
 
 
 
-/* No room in the standard 8390 structure for extra info we need. */
+/* There is no room in the standard 8390 structure for extra info we need,
+   so we build a meta/outer-wrapper structure.. */
 struct ne2k_pci_card {
 	struct net_device *dev;
 	struct pci_dev *pci_dev;
@@ -171,33 +191,35 @@
 				     const struct pci_device_id *ent)
 {
 	struct net_device *dev;
-	int i, irq, reg0, start_page, stop_page;
+	int i;
 	unsigned char SA_prom[32];
-	int chip_idx = ent->driver_data;
-	static unsigned version_printed = 0;
+	int start_page, stop_page;
+	int irq, reg0, chip_idx = ent->driver_data;
+	static unsigned int fnd_cnt;
 	long ioaddr;
-	
-	if (version_printed++ == 0)
-		printk(KERN_INFO "%s", version);
+	int flags = pci_clone_list[chip_idx].flags;
+
+	if (fnd_cnt++ == 0)
+		printk(KERN_INFO "%s" KERN_INFO "%s", version1, version2);
 
 	ioaddr = pci_resource_start (pdev, 0);
 	irq = pdev->irq;
-	
+
 	if (!ioaddr || ((pci_resource_flags (pdev, 0) & IORESOURCE_IO) == 0)) {
 		printk (KERN_ERR "ne2k-pci: no I/O resource at PCI BAR #0\n");
 		return -ENODEV;
 	}
-	
+
 	i = pci_enable_device (pdev);
 	if (i)
 		return i;
-	
+
 	if (request_region (ioaddr, NE_IO_EXTENT, "ne2k-pci") == NULL) {
 		printk (KERN_ERR "ne2k-pci: I/O resource 0x%x @ 0x%lx busy\n",
 			NE_IO_EXTENT, ioaddr);
 		return -EBUSY;
 	}
-	
+
 	reg0 = inb(ioaddr);
 	if (reg0 == 0xFF)
 		goto err_out_free_res;
@@ -222,7 +244,7 @@
 		printk (KERN_ERR "ne2k-pci: cannot allocate ethernet device\n");
 		goto err_out_free_res;
 	}
-	
+
 	/* Reset card. Who knows what dain-bramaged state it was left in. */
 	{
 		unsigned long reset_start_time = jiffies;
@@ -238,7 +260,7 @@
 				printk("ne2k-pci: Card failure (no reset ack).\n");
 				goto err_out_free_netdev;
 			}
-		
+
 		outb(0xff, ioaddr + EN0_ISR);		/* Ack all intr. */
 	}
 
@@ -269,7 +291,7 @@
 
 	/* Note: all PCI cards have at least 16 bit access, so we don't have
 	   to check for 8 bit cards.  Most cards permit 32 bit access. */
-	if (pci_clone_list[chip_idx].flags & ONLY_32BIT_IO) {
+	if (flags & ONLY_32BIT_IO) {
 		for (i = 0; i < 4 ; i++)
 			((u32 *)SA_prom)[i] = le32_to_cpu(inl(ioaddr + NE_DATAPORT));
 	} else
@@ -280,8 +302,7 @@
 	outb(0x49, ioaddr + EN0_DCFG);
 	start_page = NESM_START_PG;
 
-	stop_page =
-		pci_clone_list[chip_idx].flags&STOP_PG_0x60 ? 0x60 : NESM_STOP_PG;
+	stop_page = flags & STOP_PG_0x60 ? 0x60 : NESM_STOP_PG;
 
 	/* Set up the rest of the parameters. */
 	dev->irq = irq;
@@ -305,7 +326,11 @@
 	ei_status.tx_start_page = start_page;
 	ei_status.stop_page = stop_page;
 	ei_status.word16 = 1;
-	ei_status.ne2k_flags = pci_clone_list[chip_idx].flags;
+	ei_status.ne2k_flags = flags;
+	if (fnd_cnt < MAX_UNITS) {
+		if (full_duplex[fnd_cnt] > 0  ||  (options[fnd_cnt] & FORCE_FDX))
+			ei_status.ne2k_flags |= FORCE_FDX;
+	}
 
 	ei_status.rx_start_page = start_page + TX_PAGES;
 #ifdef PACKETBUF_MEMSIZE
@@ -331,20 +356,27 @@
 
 }
 
-static int
-ne2k_pci_open(struct net_device *dev)
+static int ne2k_pci_open(struct net_device *dev)
 {
 	MOD_INC_USE_COUNT;
 	if (request_irq(dev->irq, ei_interrupt, SA_SHIRQ, dev->name, dev)) {
 		MOD_DEC_USE_COUNT;
 		return -EAGAIN;
 	}
+	/* Set full duplex for the chips that we know about. */
+	if (ei_status.ne2k_flags & FORCE_FDX) {
+		long ioaddr = dev->base_addr;
+		if (ei_status.ne2k_flags & REALTEK_FDX) {
+			outb(0xC0 + E8390_NODMA, ioaddr + NE_CMD); /* Page 3 */
+			outb(inb(ioaddr + 0x20) | 0x80, ioaddr + 0x20);
+		} else if (ei_status.ne2k_flags & HOLTEK_FDX)
+			outb(inb(ioaddr + 0x20) | 0x80, ioaddr + 0x20);
+	}
 	ei_open(dev);
 	return 0;
 }
 
-static int
-ne2k_pci_close(struct net_device *dev)
+static int ne2k_pci_close(struct net_device *dev)
 {
 	ei_close(dev);
 	free_irq(dev->irq, dev);
@@ -354,8 +386,7 @@
 
 /* Hard reset the card.  This used to pause for the same period that a
    8390 reset command required, but that shouldn't be necessary. */
-static void
-ne2k_pci_reset_8390(struct net_device *dev)
+static void ne2k_pci_reset_8390(struct net_device *dev)
 {
 	unsigned long reset_start_time = jiffies;
 
@@ -380,8 +411,7 @@
    we don't need to be concerned with ring wrap as the header will be at
    the start of a page, so we optimize accordingly. */
 
-static void
-ne2k_pci_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr, int ring_page)
+static void ne2k_pci_get_8390_hdr(struct net_device *dev, struct e8390_pkt_hdr *hdr, int ring_page)
 {
 
 	long nic_base = dev->base_addr;
@@ -418,8 +448,8 @@
    The NEx000 doesn't share the on-board packet memory -- you have to put
    the packet out through the "remote DMA" dataport using outb. */
 
-static void
-ne2k_pci_block_input(struct net_device *dev, int count, struct sk_buff *skb, int ring_offset)
+static void ne2k_pci_block_input(struct net_device *dev, int count,
+				 struct sk_buff *skb, int ring_offset)
 {
 	long nic_base = dev->base_addr;
 	char *buf = skb->data;
@@ -461,9 +491,8 @@
 	ei_status.dmaing &= ~0x01;
 }
 
-static void
-ne2k_pci_block_output(struct net_device *dev, int count,
-		const unsigned char *buf, const int start_page)
+static void ne2k_pci_block_output(struct net_device *dev, int count,
+				  const unsigned char *buf, const int start_page)
 {
 	long nic_base = NE_BASE;
 	unsigned long dma_start;
@@ -520,8 +549,8 @@
 	dma_start = jiffies;
 
 	while ((inb(nic_base + EN0_ISR) & ENISR_RDC) == 0)
-		if (jiffies - dma_start > 2) { 			/* Avoid clock roll-over. */
-			printk("%s: timeout waiting for Tx RDC.\n", dev->name);
+		if (jiffies - dma_start > 2) {			/* Avoid clock roll-over. */
+			printk(KERN_WARNING "%s: timeout waiting for Tx RDC.\n", dev->name);
 			ne2k_pci_reset_8390(dev);
 			NS8390_init(dev,1);
 			break;
@@ -536,12 +565,10 @@
 static void __devexit ne2k_pci_remove_one (struct pci_dev *pdev)
 {
 	struct net_device *dev = pci_get_drvdata(pdev);
-	
-	if (!dev) {
-		printk (KERN_ERR "bug! ne2k_pci_remove_one called w/o net_device\n");
-		return;
-	}
-	
+
+	if (!dev)
+		BUG();
+
 	unregister_netdev(dev);
 	release_region(dev->base_addr, NE_IO_EXTENT);
 	kfree(dev);
@@ -560,18 +587,12 @@
 static int __init ne2k_pci_init(void)
 {
 	int rc;
-	
+
 	if (load_8390_module("ne2k-pci.c"))
 		return -ENOSYS;
-	
-	rc = pci_module_init (&ne2k_driver);
-	
-	/* XXX should this test CONFIG_HOTPLUG like pci_module_init? */
 
-	/* YYY No. If we're returning non-zero, we're being unloaded
-	 * 	   immediately. dwmw2 
-	 */
-	if (rc <= 0)
+	rc = pci_module_init (&ne2k_driver);
+	if (rc)
 		unload_8390_module();
 
 	return rc;
@@ -586,16 +607,3 @@
 
 module_init(ne2k_pci_init);
 module_exit(ne2k_pci_cleanup);
-
-
-/*
- * Local variables:
- *  compile-command: "gcc -DMODVERSIONS  -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/ -c ne2k-pci.c"
- *  alt-compile-command: "gcc -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -I/usr/src/linux/drivers/net/ -c ne2k-pci.c"
- *  c-indent-level: 4
- *  c-basic-offset: 4
- *  tab-width: 4
- *  version-control: t
- *  kept-new-versions: 5
- * End:
- */

--------------63C6B08DCC457D46D72A79F1--


From owner-netdev@oss.sgi.com Wed Nov  1 06:02:40 2000
Received:  by oss.sgi.com id <S553951AbQKAOCV>;
	Wed, 1 Nov 2000 06:02:21 -0800
Received: from u-199.karlsruhe.ipdial.viaginterkom.de ([62.180.18.199]:39951
        "EHLO u-199.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com
	with ESMTP id <S553947AbQKAOCM>; Wed, 1 Nov 2000 06:02:12 -0800
Received: (ralf@lappi) by lappi.waldorf-gmbh.de id <S869089AbQKAOCE>;
        Wed, 1 Nov 2000 15:02:04 +0100
Date:   Wed, 1 Nov 2000 15:02:03 +0100
From:   Ralf Baechle <ralf@uni-koblenz.de>
To:     linux-mips@oss.sgi.com, netdev@oss.sgi.com,
        Trevor Hurst <trev@sgi.com>,
        Quentin Arce <qarce@pc-griffin2.engr.sgi.com>
Subject: ADMIN: SPAM
Message-ID: <20001101150203.C7375@bacchus.dhis.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
X-Accept-Language: de,en,fr
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

I take this new spam to a oss mailing list as the reason to explain the
anti-spam measures I've taken on oss:

 - oss uses ORBS and MAPS to decide about acceptable email.
 - in addition I put the ISP and relaying sites involved in spam sent via
   oss into a manually maintained blacklist.
 - I try to manually clean some of the list archives of spam.

Given the growing size of the various blacklists I'd like legitimate senders
of email to oss to complain to me (use ralf@uni-koblenz.de or ralf@gnu.org)
and we'll find a solution.

  Ralf

From owner-netdev@oss.sgi.com Wed Nov  1 12:18:42 2000
Received:  by oss.sgi.com id <S553960AbQKAUSW>;
	Wed, 1 Nov 2000 12:18:22 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:51720 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553957AbQKAUR6>;
	Wed, 1 Nov 2000 12:17:58 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA08262; Wed, 1 Nov 2000 23:17:36 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011012017.XAA08262@ms2.inr.ac.ru>
Subject: Re: [ANN] 1st release of USAGI IPv6 environment
To:     usagi-core@linux-ipv6.ORG
Date:   Wed, 1 Nov 2000 23:17:36 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <m3u29sqsc0.wl@shaku.sfc.wide.ad.jp> from "usagi-core" at Nov 1, 0 06:45:01 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 214       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> We are glad to announce the 1st release of USAGI Project.

Please, use "-u" option, when doing diffs.

Also, take more attention to formatting. Or changes to icmp.c
were written by some robot? 8)

Alexey

From owner-netdev@oss.sgi.com Wed Nov  1 13:45:13 2000
Received:  by oss.sgi.com id <S553725AbQKAVox>;
	Wed, 1 Nov 2000 13:44:53 -0800
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:49669 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S553719AbQKAVoj>; Wed, 1 Nov 2000 13:44:39 -0800
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.11.0+3.3W/8.11.1/Debian 8.11.0-6) with ESMTP id eA1Lh1C11884;
	Thu, 2 Nov 2000 06:43:01 +0900
To:     kuznet@ms2.inr.ac.ru
Cc:     usagi-core@linux-ipv6.ORG, netdev@oss.sgi.com
Subject: Re: [ANN] 1st release of USAGI IPv6 environment
In-Reply-To: <200011012017.XAA08262@ms2.inr.ac.ru>
References: <m3u29sqsc0.wl@shaku.sfc.wide.ad.jp>
	<200011012017.XAA08262@ms2.inr.ac.ru>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20001102064300J.yoshfuji@ecei.tohoku.ac.jp>
Date:   Thu, 02 Nov 2000 06:43:00 +0900
From:   Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) 
        <yoshfuji@ecei.tohoku.ac.jp>
X-Dispatcher: imput version 990905(IM130)
Lines:  16
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In article <200011012017.XAA08262@ms2.inr.ac.ru> (at Wed, 1 Nov 2000 23:17:36 +0300 (MSK)), kuznet@ms2.inr.ac.ru says:

> Please, use "-u" option, when doing diffs.

It might be ok for kernel and libc, but I'd like to know why.


> Also, take more attention to formatting. Or changes to icmp.c
> were written by some robot? 8)

What do yo mean?  Tabbing, spacing and/or whatever?

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@linux-ipv6.org>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Thu Nov  2 01:37:21 2000
Received:  by oss.sgi.com id <S553790AbQKBJhK>;
	Thu, 2 Nov 2000 01:37:10 -0800
Received: from smtp1.mail.yahoo.com ([128.11.69.60]:38923 "HELO
        smtp1.mail.yahoo.com") by oss.sgi.com with SMTP id <S553773AbQKBJgv>;
	Thu, 2 Nov 2000 01:36:51 -0800
Received: from ppp024.muskoka.com (HELO gromit.hairy.org) (199.212.175.54)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 2 Nov 2000 09:36:45 -0000
X-Apparently-From: <p?gortmaker@yahoo.com>
Message-ID: <3A0127BC.61EC9575@yahoo.com>
Date:   Thu, 02 Nov 2000 03:37:16 -0500
From:   Paul Gortmaker <p_gortmaker@yahoo.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.17 i486)
MIME-Version: 1.0
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
CC:     linux-net@vger.kernel.org, netdev@oss.sgi.com,
        Donald Becker <becker@scyld.com>
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.21.0010300344130.6792-100000@web.sajt.cz> <39FC83CD.B10BF08D@mandrakesoft.com> <39FD3CB6.2F641BBF@yahoo.com> <39FDCC17.4C8B8074@mandrakesoft.com> <39FFAA94.4D389E85@yahoo.com> <3A001A53.1A5BB6E0@mandrakesoft.com>
Content-Type: multipart/mixed; boundary="------------30BBA37A5651EC53DFDFA24"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This is a multi-part message in MIME format.

--------------30BBA37A5651EC53DFDFA24
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[CC trimmed a bit]

Jeff Garzik wrote:

> drivers/net/ne.c:
> * use probe_irq_on/off instead of autoirq_xxx (autoirq is going away)

Would be nice to get verification from someone with an older (non-PnP)
card that this doesn't break the irq detection.  Is the game plan to
do similar for other drivers before 2.5.x as well?

> * request_region first thing in ne_probe1, before any hardware
> interaction takes place.  Eliminates any potential resource races.  Also
> eliminates a call to check_region.

Implementation note - For a lot of the drivers it makes sense to keep
around the resource returned by request_region so that we can set the
name after the probe has taken place (ie when we know what the card is.)
I've included a diff for drivers/net/wd.c as an example of what I 
thought looks clean.  If I know that the death of check_region is also 
a pre 2.4.0 goal then I will supply a diff for the other 17 or so 8390
based drivers...

On a related note, there are a handful of drivers that register ioports
(and IRQ) with the name dev->name (e.g. eth0) as opposed to a more 
meaningful model name (e.g. "3c503/16"). And some drivers do one for
ioports, and the other for IRQ!!  We should aim for consistency on this,
and IMHO supplying the model name of the hardware is the more
informative of the two (and also in keeping with the rest of the 
kernel drivers).

Oh, and while I'm asking about opinions on 2.4.0 goals, what about
the replacement of #ifdef MODULE driver init code with module_init(...)?

> As an aside, for 2.5.x, would it be possible to merge all the common
> ne2000 code (block_input/output, etc.) from the various ne2k drivers?
> As it stands there exists ne.c, ne2.c, ne2k-pci.c, and pcnet_cs.c, all
> of which do pretty much the same thing at their core.  [and AFAICS, all
> but pcnet_cs might easily call a common ne2k library]

Possible - yes.  Worthwhile - not so sure.  As it is, 8390.o is the
source of much grief in drivers/net/Makefile from what I read recently ;-)
We will worry about 2.5.x later.

Paul.

--------------30BBA37A5651EC53DFDFA24
Content-Type: text/plain; charset=us-ascii; name="wd-diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="wd-diff"

--- 2400-t8/linux-g/drivers/net/wd.c~	Wed Jun 28 11:38:32 2000
+++ 2400-t8/linux-g/drivers/net/wd.c	Tue Sep 19 03:29:52 2000
@@ -89,19 +89,33 @@
 int __init wd_probe(struct net_device *dev)
 {
 	int i;
+	struct resource *r;
 	int base_addr = dev ? dev->base_addr : 0;
 
-	if (base_addr > 0x1ff)		/* Check a single specified location. */
-		return wd_probe1(dev, base_addr);
+	if (base_addr > 0x1ff) {	/* Check a user specified location. */
+		r = request_region(base_addr, WD_IO_EXTENT, "wd-probe");
+		if ( r == NULL)
+			return -EBUSY;
+		i = wd_probe1(dev, base_addr);
+		if (i != 0)  
+			release_resource(r);
+		else
+			r->name = ei_status.name;
+		return i;
+	}
 	else if (base_addr != 0)	/* Don't probe at all. */
 		return -ENXIO;
 
 	for (i = 0; wd_portlist[i]; i++) {
 		int ioaddr = wd_portlist[i];
-		if (check_region(ioaddr, WD_IO_EXTENT))
+		r = request_region(ioaddr, WD_IO_EXTENT, "wd-probe");
+		if (r == NULL)
 			continue;
-		if (wd_probe1(dev, ioaddr) == 0)
+		if (wd_probe1(dev, ioaddr) == 0) {
+			r->name = ei_status.name;
 			return 0;
+		}
+		release_resource(r);
 	}
 
 	return -ENODEV;
@@ -268,8 +282,6 @@
 	}
 
 	/* OK, were are certain this is going to work.  Setup the device. */
-	request_region(ioaddr, WD_IO_EXTENT, model_name);
-
 	ei_status.name = model_name;
 	ei_status.word16 = word16;
 	ei_status.tx_start_page = WD_START_PG;

--------------30BBA37A5651EC53DFDFA24--




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


From owner-netdev@oss.sgi.com Thu Nov  2 01:37:30 2000
Received:  by oss.sgi.com id <S553792AbQKBJhV>;
	Thu, 2 Nov 2000 01:37:21 -0800
Received: from smtp3.mail.yahoo.com ([128.11.68.135]:61964 "HELO
        smtp1b.mail.yahoo.com") by oss.sgi.com with SMTP id <S553783AbQKBJhC>;
	Thu, 2 Nov 2000 01:37:02 -0800
Received: from ppp024.muskoka.com (HELO gromit.hairy.org) (199.212.175.54)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 2 Nov 2000 09:36:53 -0000
X-Apparently-From: <p?gortmaker@yahoo.com>
Message-ID: <3A012AE4.41EFDC71@yahoo.com>
Date:   Thu, 02 Nov 2000 03:50:44 -0500
From:   Paul Gortmaker <p_gortmaker@yahoo.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.17 i486)
MIME-Version: 1.0
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
CC:     linux-net@vger.kernel.org, netdev@oss.sgi.com
Subject: 8390 based driver cleanup
Content-Type: multipart/mixed; boundary="------------53068E414BBCD1567C10D5C5"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This is a multi-part message in MIME format.

--------------53068E414BBCD1567C10D5C5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Jeff,

While we are in cleanup mode, the last vestiges of the 8390
autoload hackery can be swept away as well.  You may have to
patch with fuzz if your ne.c and ne2k-pci.c are already with
the other patch we've bounced around (or just delete the
[un]load_8390_module() by hand) as this was against test10-pre6.

Thanks,
Paul.

--------------53068E414BBCD1567C10D5C5
Content-Type: text/plain; charset=us-ascii; name="2400-t10-p6-no-8390-load-diff1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="2400-t10-p6-no-8390-load-diff1"

diff -ur 2400-t10-p6/linux/drivers/net-old/3c503.c 2400-t10-p6/linux/drivers/net/3c503.c
--- 2400-t10-p6/linux/drivers/net-old/3c503.c	Mon Sep 11 03:55:09 2000
+++ 2400-t10-p6/linux/drivers/net/3c503.c	Tue Oct 31 19:11:45 2000
@@ -645,9 +645,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("3c503.c"))
-		return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_EL2_CARDS; this_dev++) {
 		struct net_device *dev = &dev_el2[this_dev];
 		dev->irq = irq[this_dev];
@@ -663,7 +660,6 @@
 			if (found != 0) {	/* Got at least one. */
 				return 0;
 			}
-			unload_8390_module();
 			return -ENXIO;
 		}
 		found++;
@@ -686,7 +682,6 @@
 			kfree(priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
 
diff -ur 2400-t10-p6/linux/drivers/net-old/ac3200.c 2400-t10-p6/linux/drivers/net/ac3200.c
--- 2400-t10-p6/linux/drivers/net-old/ac3200.c	Mon Sep 11 03:55:09 2000
+++ 2400-t10-p6/linux/drivers/net/ac3200.c	Tue Oct 31 19:14:21 2000
@@ -368,9 +368,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("ac3200.c"))
-			return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_AC32_CARDS; this_dev++) {
 		struct net_device *dev = &dev_ac32[this_dev];
 		dev->irq = irq[this_dev];
@@ -384,7 +381,6 @@
 			if (found != 0) {	/* Got at least one. */
 				return 0;
 			}
-			unload_8390_module();
 			return -ENXIO;
 		}
 		found++;
@@ -410,7 +406,6 @@
 			kfree(priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
 
diff -ur 2400-t10-p6/linux/drivers/net-old/apne.c 2400-t10-p6/linux/drivers/net/apne.c
--- 2400-t10-p6/linux/drivers/net-old/apne.c	Wed Jun 28 11:38:16 2000
+++ 2400-t10-p6/linux/drivers/net/apne.c	Tue Oct 31 19:18:26 2000
@@ -570,13 +570,9 @@
 {
 	int err;
 
-	if (load_8390_module("apne.c"))
-		return -ENOSYS;
-
 	if ((err = register_netdev(&apne_dev))) {
 		if (err == -EIO)
 			printk("No PCMCIA NEx000 ethernet card found.\n");
-		unload_8390_module();
 		return (err);
 	}
 	return (0);
@@ -591,8 +587,6 @@
 	free_irq(IRQ_AMIGA_PORTS, &apne_dev);
 
 	pcmcia_reset();
-
-	unload_8390_module();
 
 	apne_owned = 0;
 }
diff -ur 2400-t10-p6/linux/drivers/net-old/ariadne2.c 2400-t10-p6/linux/drivers/net/ariadne2.c
--- 2400-t10-p6/linux/drivers/net-old/ariadne2.c	Sat Oct 28 14:35:30 2000
+++ 2400-t10-p6/linux/drivers/net/ariadne2.c	Tue Oct 31 19:18:38 2000
@@ -401,13 +401,9 @@
 {
     int err;
 
-    if (load_8390_module("ariadne2.c"))
-	return -ENOSYS;
-
     if ((err = register_netdev(&ariadne2_dev))) {
 	if (err == -EIO)
 	    printk("No AriadNE2 ethernet card found.\n");
-	unload_8390_module();
 	return err;
     }
     return 0;
@@ -418,7 +414,6 @@
     free_irq(IRQ_AMIGA_PORTS, &ariadne2_dev);
     release_mem_region(ZTWO_PADDR(ariadne2_dev.base_addr), NE_IO_EXTENT*2);
     unregister_netdev(&ariadne2_dev);
-    unload_8390_module();
 }
 
 #endif	/* MODULE */
diff -ur 2400-t10-p6/linux/drivers/net-old/e2100.c 2400-t10-p6/linux/drivers/net/e2100.c
--- 2400-t10-p6/linux/drivers/net-old/e2100.c	Sat Oct 28 14:35:31 2000
+++ 2400-t10-p6/linux/drivers/net/e2100.c	Tue Oct 31 19:14:30 2000
@@ -407,9 +407,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("e2100.c"))
-		return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_E21_CARDS; this_dev++) {
 		struct net_device *dev = &dev_e21[this_dev];
 		dev->irq = irq[this_dev];
@@ -426,7 +423,6 @@
 			if (found != 0) {	/* Got at least one. */
 				return 0;
 			}
-			unload_8390_module();
 			return -ENXIO;
 		}
 		found++;
@@ -449,7 +445,6 @@
 			kfree(priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
 
diff -ur 2400-t10-p6/linux/drivers/net-old/es3210.c 2400-t10-p6/linux/drivers/net/es3210.c
--- 2400-t10-p6/linux/drivers/net-old/es3210.c	Sat Oct 28 14:35:31 2000
+++ 2400-t10-p6/linux/drivers/net/es3210.c	Tue Oct 31 19:10:50 2000
@@ -401,9 +401,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("es3210.c"))
-		return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_ES_CARDS; this_dev++) {
 		struct net_device *dev = &dev_es3210[this_dev];
 		dev->irq = irq[this_dev];
@@ -417,7 +414,6 @@
 			if (found != 0) {	/* Got at least one. */
 				return 0;
 			}
-			unload_8390_module();
 			return -ENXIO;
 		}
 		found++;
@@ -440,6 +436,5 @@
 			kfree(priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
diff -ur 2400-t10-p6/linux/drivers/net-old/hp-plus.c 2400-t10-p6/linux/drivers/net/hp-plus.c
--- 2400-t10-p6/linux/drivers/net-old/hp-plus.c	Wed Jun 28 11:38:23 2000
+++ 2400-t10-p6/linux/drivers/net/hp-plus.c	Tue Oct 31 19:14:51 2000
@@ -433,9 +433,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("hp-plus.c"))
-		return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_HPP_CARDS; this_dev++) {
 		struct net_device *dev = &dev_hpp[this_dev];
 		dev->irq = irq[this_dev];
@@ -450,7 +447,6 @@
 			if (found != 0) {	/* Got at least one. */
 				return 0;
 			}
-			unload_8390_module();
 			return -ENXIO;
 		}
 		found++;
@@ -474,7 +470,6 @@
 			kfree(priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
 
diff -ur 2400-t10-p6/linux/drivers/net-old/hp.c 2400-t10-p6/linux/drivers/net/hp.c
--- 2400-t10-p6/linux/drivers/net-old/hp.c	Wed Jun 28 11:38:23 2000
+++ 2400-t10-p6/linux/drivers/net/hp.c	Tue Oct 31 19:14:41 2000
@@ -404,9 +404,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("hp.c"))
-		return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_HP_CARDS; this_dev++) {
 		struct net_device *dev = &dev_hp[this_dev];
 		dev->irq = irq[this_dev];
@@ -421,7 +418,6 @@
 			if (found != 0) {	/* Got at least one. */
 				return 0;
 			}
-			unload_8390_module();
 			return -ENXIO;
 		}
 		found++;
@@ -445,7 +441,6 @@
 			kfree(priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
 
diff -ur 2400-t10-p6/linux/drivers/net-old/lne390.c 2400-t10-p6/linux/drivers/net/lne390.c
--- 2400-t10-p6/linux/drivers/net-old/lne390.c	Sat Oct 28 14:35:33 2000
+++ 2400-t10-p6/linux/drivers/net/lne390.c	Tue Oct 31 19:11:01 2000
@@ -394,9 +394,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("lne390.c"))
-		return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_LNE_CARDS; this_dev++) {
 		struct net_device *dev = &dev_lne[this_dev];
 		dev->irq = irq[this_dev];
@@ -410,7 +407,6 @@
 			if (found != 0) {	/* Got at least one. */
 				return 0;
 			}
-			unload_8390_module();
 			return -ENXIO;
 		}
 		found++;
@@ -434,7 +430,6 @@
 			kfree(priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
 
diff -ur 2400-t10-p6/linux/drivers/net-old/ne.c 2400-t10-p6/linux/drivers/net/ne.c
--- 2400-t10-p6/linux/drivers/net-old/ne.c	Tue Jul 11 02:29:10 2000
+++ 2400-t10-p6/linux/drivers/net/ne.c	Tue Oct 31 19:12:07 2000
@@ -836,9 +836,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("ne.c"))
-		return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_NE_CARDS; this_dev++) {
 		struct net_device *dev = &dev_ne[this_dev];
 		dev->irq = irq[this_dev];
@@ -856,7 +853,6 @@
 			printk(KERN_WARNING "ne.c: No NE*000 card found at i/o = %#x\n", io[this_dev]);
 		else
 			printk(KERN_NOTICE "ne.c: No PCI cards found. Use \"io=0xNNN\" value(s) for ISA cards.\n");
-		unload_8390_module();
 		return -ENXIO;
 	}
 	return 0;
@@ -879,7 +875,6 @@
 			kfree(priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
 
diff -ur 2400-t10-p6/linux/drivers/net-old/ne2k-pci.c 2400-t10-p6/linux/drivers/net/ne2k-pci.c
--- 2400-t10-p6/linux/drivers/net-old/ne2k-pci.c	Fri Oct 27 17:46:08 2000
+++ 2400-t10-p6/linux/drivers/net/ne2k-pci.c	Tue Oct 31 19:14:11 2000
@@ -559,29 +559,13 @@
 
 static int __init ne2k_pci_init(void)
 {
-	int rc;
-	
-	if (load_8390_module("ne2k-pci.c"))
-		return -ENOSYS;
-	
-	rc = pci_module_init (&ne2k_driver);
-	
-	/* XXX should this test CONFIG_HOTPLUG like pci_module_init? */
-
-	/* YYY No. If we're returning non-zero, we're being unloaded
-	 * 	   immediately. dwmw2 
-	 */
-	if (rc <= 0)
-		unload_8390_module();
-
-	return rc;
+	return (pci_module_init(&ne2k_driver));
 }
 
 
 static void __exit ne2k_pci_cleanup(void)
 {
-	pci_unregister_driver (&ne2k_driver);
-	unload_8390_module();
+	pci_unregister_driver(&ne2k_driver);
 }
 
 module_init(ne2k_pci_init);
diff -ur 2400-t10-p6/linux/drivers/net-old/ne3210.c 2400-t10-p6/linux/drivers/net/ne3210.c
--- 2400-t10-p6/linux/drivers/net-old/ne3210.c	Sat Oct 28 14:35:33 2000
+++ 2400-t10-p6/linux/drivers/net/ne3210.c	Tue Oct 31 19:11:11 2000
@@ -381,9 +381,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("ne3210.c"))
-		return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_NE3210_CARDS; this_dev++) {
 		struct net_device *dev = &dev_ne3210[this_dev];
 		dev->irq = irq[this_dev];
@@ -397,7 +394,6 @@
 			if (found != 0) {	/* Got at least one. */
 				return 0;
 			}
-			unload_8390_module();
 			return -ENXIO;
 		}
 		found++;
@@ -421,7 +417,6 @@
 			kfree(priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
 
diff -ur 2400-t10-p6/linux/drivers/net-old/oaknet.c 2400-t10-p6/linux/drivers/net/oaknet.c
--- 2400-t10-p6/linux/drivers/net-old/oaknet.c	Wed Jun 28 11:38:25 2000
+++ 2400-t10-p6/linux/drivers/net/oaknet.c	Tue Oct 31 19:47:23 2000
@@ -664,25 +664,10 @@
  */
 static int __init oaknet_init_module (void)
 {
-	int status;
-
-	/*
-	 * We're dependent on the 8390 generic driver module, make
-	 * sure its symbols are loaded.
-	 */
-
-	if (load_8390_module("oaknet.c"))
-		return (-ENOSYS);
-
 	if (oaknet_devs != NULL)
 		return (-EBUSY);
 
-	status = oaknet_init()
-
-	if (status != 0)
-		unload_8390_module();
-
-	return (status);
+	return (oaknet_init());
 }
 
 /*
@@ -704,7 +689,6 @@
 
 	oaknet_devs = NULL;
 
-	unload_8390_module();
 }
 
 module_init(oaknet_init_module);
diff -ur 2400-t10-p6/linux/drivers/net-old/smc-mca.c 2400-t10-p6/linux/drivers/net/smc-mca.c
--- 2400-t10-p6/linux/drivers/net-old/smc-mca.c	Wed Jun 28 11:38:27 2000
+++ 2400-t10-p6/linux/drivers/net/smc-mca.c	Tue Oct 31 19:14:59 2000
@@ -455,9 +455,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("wd.c"))
-		return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_ULTRAMCA_CARDS; this_dev++) {
 		struct net_device *dev = &dev_ultra[this_dev];
 		dev->irq = irq[this_dev];
@@ -468,7 +465,6 @@
 			if (found != 0) {	/* Got at least one. */
 				return 0;
 			}
-			unload_8390_module();
 			printk(KERN_NOTICE "smc-mca.c: No SMC Ultra card found (i/o = 0x%x).\n", io[this_dev]);
 			return -ENXIO;
 		}
@@ -493,7 +489,6 @@
 			kfree(priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
 
diff -ur 2400-t10-p6/linux/drivers/net-old/smc-ultra.c 2400-t10-p6/linux/drivers/net/smc-ultra.c
--- 2400-t10-p6/linux/drivers/net-old/smc-ultra.c	Wed Jun 28 11:38:27 2000
+++ 2400-t10-p6/linux/drivers/net/smc-ultra.c	Tue Oct 31 19:12:19 2000
@@ -445,9 +445,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("smc-ultra.c"))
-		return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_ULTRA_CARDS; this_dev++) {
 		struct net_device *dev = &dev_ultra[this_dev];
 		dev->irq = irq[this_dev];
@@ -460,7 +457,6 @@
 		if (register_netdev(dev) != 0) {
 			printk(KERN_WARNING "smc-ultra.c: No SMC Ultra card found (i/o = 0x%x).\n", io[this_dev]);
 			if (found != 0) return 0;	/* Got at least one. */
-			unload_8390_module();
 			return -ENXIO;
 		}
 		found++;
@@ -484,7 +480,6 @@
 			kfree(dev->priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
 
diff -ur 2400-t10-p6/linux/drivers/net-old/smc-ultra32.c 2400-t10-p6/linux/drivers/net/smc-ultra32.c
--- 2400-t10-p6/linux/drivers/net-old/smc-ultra32.c	Wed Jun 28 11:38:27 2000
+++ 2400-t10-p6/linux/drivers/net/smc-ultra32.c	Tue Oct 31 19:11:55 2000
@@ -378,9 +378,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("smc-ultra32.c"))
-		return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_ULTRA32_CARDS; this_dev++) {
 		struct net_device *dev = &dev_ultra[this_dev];
 		dev->init = ultra32_probe;
@@ -388,7 +385,6 @@
 			if (found > 0) { /* Got at least one. */
 				return 0;
 			}
-			unload_8390_module();
 			printk(KERN_WARNING "smc-ultra32.c: No SMC Ultra32 found.\n");
 			return -ENXIO;
 		}
@@ -412,6 +408,5 @@
 			kfree(priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
diff -ur 2400-t10-p6/linux/drivers/net-old/stnic.c 2400-t10-p6/linux/drivers/net/stnic.c
--- 2400-t10-p6/linux/drivers/net-old/stnic.c	Fri Aug 11 03:09:40 2000
+++ 2400-t10-p6/linux/drivers/net/stnic.c	Tue Oct 31 19:20:26 2000
@@ -105,9 +105,6 @@
   if (! MACH_SE)
     return -ENODEV;
 
-  if (load_8390_module ("stnic.c"))
-    return -ENOSYS;
-
   /* New style probing API */
   dev = init_etherdev (0, 0);
   stnic_dev = dev;
@@ -313,6 +310,4 @@
 }
 
 module_init(stnic_probe);
-/* No cleanup routine - if there were one, it should do a:
-   unload_8390_module()
-*/
+/* No cleanup routine. */
diff -ur 2400-t10-p6/linux/drivers/net-old/wd.c 2400-t10-p6/linux/drivers/net/wd.c
--- 2400-t10-p6/linux/drivers/net-old/wd.c	Sat Oct 28 14:35:41 2000
+++ 2400-t10-p6/linux/drivers/net/wd.c	Tue Oct 31 19:11:22 2000
@@ -464,9 +464,6 @@
 {
 	int this_dev, found = 0;
 
-	if (load_8390_module("wd.c"))
-                return -ENOSYS;
-
 	for (this_dev = 0; this_dev < MAX_WD_CARDS; this_dev++) {
 		struct net_device *dev = &dev_wd[this_dev];
 		dev->irq = irq[this_dev];
@@ -483,7 +480,6 @@
 			if (found != 0) {	/* Got at least one. */
 				return 0;
 			}
-			unload_8390_module();
 			return -ENXIO;
 		}
 		found++;
@@ -507,7 +503,6 @@
 			kfree(priv);
 		}
 	}
-	unload_8390_module();
 }
 #endif /* MODULE */
 

--------------53068E414BBCD1567C10D5C5--




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


From owner-netdev@oss.sgi.com Thu Nov  2 01:52:10 2000
Received:  by oss.sgi.com id <S553796AbQKBJwA>;
	Thu, 2 Nov 2000 01:52:00 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:15109 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S553783AbQKBJvg>;
	Thu, 2 Nov 2000 01:51:36 -0800
Received: from mandrakesoft.com ([66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id EAA32141;
	Thu, 2 Nov 2000 04:50:02 -0500
Message-ID: <3A0138AC.44C17308@mandrakesoft.com>
Date:   Thu, 02 Nov 2000 04:49:32 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18pre18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Paul Gortmaker <p_gortmaker@yahoo.com>
CC:     linux-net@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: 8390 based driver cleanup
References: <3A012AE4.41EFDC71@yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> While we are in cleanup mode, the last vestiges of the 8390
> autoload hackery can be swept away as well.  You may have to
> patch with fuzz if your ne.c and ne2k-pci.c are already with
> the other patch we've bounced around (or just delete the
> [un]load_8390_module() by hand) as this was against test10-pre6.

Thanks, applied.

Any reason why we can't remove [un]load_8390_module from 8390.h?

	Jeff


-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune

From owner-netdev@oss.sgi.com Thu Nov  2 02:20:50 2000
Received:  by oss.sgi.com id <S553795AbQKBKUk>;
	Thu, 2 Nov 2000 02:20:40 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:35077 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S553711AbQKBKU1>;
	Thu, 2 Nov 2000 02:20:27 -0800
Received: from mandrakesoft.com ([66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id FAA00566;
	Thu, 2 Nov 2000 05:20:09 -0500
Message-ID: <3A013FBB.BFF9D3CE@mandrakesoft.com>
Date:   Thu, 02 Nov 2000 05:19:39 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18pre18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Paul Gortmaker <p_gortmaker@yahoo.com>
CC:     linux-net@vger.kernel.org, netdev@oss.sgi.com,
        Donald Becker <becker@scyld.com>
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.21.0010300344130.6792-100000@web.sajt.cz> <39FC83CD.B10BF08D@mandrakesoft.com> <39FD3CB6.2F641BBF@yahoo.com> <39FDCC17.4C8B8074@mandrakesoft.com> <39FFAA94.4D389E85@yahoo.com> <3A001A53.1A5BB6E0@mandrakesoft.com> <3A0127BC.61EC9575@yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Paul Gortmaker wrote:
> Jeff Garzik wrote:
> > drivers/net/ne.c:
> > * use probe_irq_on/off instead of autoirq_xxx (autoirq is going away)
> 
> Would be nice to get verification from someone with an older (non-PnP)
> card that this doesn't break the irq detection.  Is the game plan to
> do similar for other drivers before 2.5.x as well?

Have you seen the auto_irq.c code?  :)  I don't see how it could
possibly break, but ya never know...

Anyway, to answer your question, yes, Linus has ok'd the elimination of
auto_irq.c.  It's used in maybe ~10 drivers throughout the kernel, but
it is linked into every single kernel built.  I created a patch that
conditionally linked auto_irq.o in your kernel (or as a module), and
Linus said to just get rid of it :)


> > * request_region first thing in ne_probe1, before any hardware
> > interaction takes place.  Eliminates any potential resource races.  Also
> > eliminates a call to check_region.
> 
> Implementation note - For a lot of the drivers it makes sense to keep
> around the resource returned by request_region so that we can set the
> name after the probe has taken place (ie when we know what the card is.)
> I've included a diff for drivers/net/wd.c as an example of what I
> thought looks clean.  If I know that the death of check_region is also
> a pre 2.4.0 goal then I will supply a diff for the other 17 or so 8390
> based drivers...

Definitely a goal.  IMHO its a bug if the driver touches the hardware at
all before properly "locking" the region first, with locking in this
case defined as calling request_region.


> On a related note, there are a handful of drivers that register ioports
> (and IRQ) with the name dev->name (e.g. eth0) as opposed to a more
> meaningful model name (e.g. "3c503/16"). And some drivers do one for
> ioports, and the other for IRQ!!  We should aim for consistency on this,
> and IMHO supplying the model name of the hardware is the more
> informative of the two (and also in keeping with the rest of the
> kernel drivers).

For ISA, it's more informative.  For PCI, it's less informative because
the requested resource appears in /proc/ioports underneath the parent
PCI device.

However, the only overriding reason to put dev->name into request_region
was for hotplug reasons, because it was otherwise impossible to build an
association between a hardware bus device and its respective network
interface.  With my 'Update hotplug' patch recently posted to lkml, that
restriction is gone.  Assuming that patch is taken, I have no problem
with standardizing on model name instead of dev->name.  I agree there
should be consistency.


> Oh, and while I'm asking about opinions on 2.4.0 goals, what about
> the replacement of #ifdef MODULE driver init code with module_init(...)?

I'm strongly in favor of it, but I have yet to put some time into
thinking of a clean way to do it for ISA drivers.  If you have an idea,
let's hear it.

The big problem is the differences between kernel and module init. 
Modules get their info MODULE_PARM, and have no ordering constraints. 
Built-in drivers, on the other hand, need to obey the constraints of the
ether=xxx cmd line.

Further, I prefer that drivers use init_etherdev to allocate both their
netdevice and their struct private at the same time.  This removes a lot
of unused static gunk in existing ISA drivers.  I -think- that you can
call init_etherdev(NULL,priv_size) and still get things right WRT
ether=xxx, but I'm not totally sure.

You may have to abandon init_etherdev altogether, allocating the
netdevice+priv yourself, and calling ethdev_setup/register_netdev/etc.
manually.


> > As an aside, for 2.5.x, would it be possible to merge all the common
> > ne2000 code (block_input/output, etc.) from the various ne2k drivers?
> > As it stands there exists ne.c, ne2.c, ne2k-pci.c, and pcnet_cs.c, all
> > of which do pretty much the same thing at their core.  [and AFAICS, all
> > but pcnet_cs might easily call a common ne2k library]
> 
> Possible - yes.  Worthwhile - not so sure.  As it is, 8390.o is the
> source of much grief in drivers/net/Makefile from what I read recently ;-)
> We will worry about 2.5.x later.

True, true.  :)


> --- 2400-t8/linux-g/drivers/net/wd.c~   Wed Jun 28 11:38:32 2000
> +++ 2400-t8/linux-g/drivers/net/wd.c    Tue Sep 19 03:29:52 2000

Thanks, applied.

-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune

From owner-netdev@oss.sgi.com Thu Nov  2 10:49:03 2000
Received:  by oss.sgi.com id <S553794AbQKBSsw>;
	Thu, 2 Nov 2000 10:48:52 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:27143 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553692AbQKBSsj>;
	Thu, 2 Nov 2000 10:48:39 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA25085; Thu, 2 Nov 2000 21:48:09 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011021848.VAA25085@ms2.inr.ac.ru>
Subject: Re: [ANN] 1st release of USAGI IPv6 environment
To:     yoshfuji@ecei.tohoku.ac.jp (Hideaki YOSHIFUJI)
Date:   Thu, 2 Nov 2000 21:48:08 +0300 (MSK)
Cc:     usagi-core@linux-ipv6.ORG, netdev@oss.sgi.com
In-Reply-To: <20001102064300J.yoshfuji@ecei.tohoku.ac.jp> from "Hideaki YOSHIFUJI" at Nov 2, 0 06:43:00 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 532       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> It might be ok for kernel and libc, but I'd like to know why.

Just look and compare outputs.

If you are not looking _into_ patches, it does not matter.
But I (and, seems, other people) work with patches directly.

> What do yo mean?  Tabbing, spacing and/or whatever?

Well, tabbing is OK. Even too much of tabbing. 8)

Look into your version of ipv6/icmp.c. It is clear.
Probably, you occasionally passed it though some preprocessor
deleting all the empty lines and moving braces to unpredictable
positions. 8)

Alexey

From owner-netdev@oss.sgi.com Thu Nov  2 16:39:05 2000
Received:  by oss.sgi.com id <S553803AbQKCAiz>;
	Thu, 2 Nov 2000 16:38:55 -0800
Received: from battlejitney.wdhq.scyld.com ([216.254.93.178]:32496 "EHLO
        vaio.greennet") by oss.sgi.com with ESMTP id <S553801AbQKCAis>;
	Thu, 2 Nov 2000 16:38:48 -0800
Received: from localhost (becker@localhost)
	by vaio.greennet (8.9.3/8.8.7) with ESMTP id TAA16876;
	Thu, 2 Nov 2000 19:40:21 -0500
Date:   Thu, 2 Nov 2000 19:40:21 -0500 (EST)
From:   Donald Becker <becker@scyld.com>
X-Sender: becker@vaio.greennet
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
cc:     Paul Gortmaker <p_gortmaker@yahoo.com>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [patch] NE2000
In-Reply-To: <3A013FBB.BFF9D3CE@mandrakesoft.com>
Message-ID: <Pine.LNX.4.10.10011021935530.11540-100000@vaio.greennet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Thu, 2 Nov 2000, Jeff Garzik wrote:
> Paul Gortmaker wrote:
> > On a related note, there are a handful of drivers that register ioports
> > (and IRQ) with the name dev->name (e.g. eth0) as opposed to a more
> > meaningful model name (e.g. "3c503/16"). And some drivers do one for
...
> For ISA, it's more informative.  For PCI, it's less informative because
> the requested resource appears in /proc/ioports underneath the parent
> PCI device.

Using dev->name is much more meaningful.
I switched over all of my drivers to use dev->name a few years ago.

> However, the only overriding reason to put dev->name into request_region
> was for hotplug reasons, because it was otherwise impossible to build an

Most people with multiple network adapters use the same board type.  Seeing
a list of identical board names isn't very useful when you are trying to do
something like map interrupt counts to interface statistics.


Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993


From owner-netdev@oss.sgi.com Thu Nov  2 16:54:15 2000
Received:  by oss.sgi.com id <S553793AbQKCAyF>;
	Thu, 2 Nov 2000 16:54:05 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:3590 "EHLO havoc.gtf.org")
	by oss.sgi.com with ESMTP id <S553802AbQKCAxo>;
	Thu, 2 Nov 2000 16:53:44 -0800
Received: from mandrakesoft.com ([66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id TAA13228;
	Thu, 2 Nov 2000 19:52:07 -0500
Message-ID: <3A020C19.4C4B3F66@mandrakesoft.com>
Date:   Thu, 02 Nov 2000 19:51:37 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Donald Becker <becker@scyld.com>
CC:     Paul Gortmaker <p_gortmaker@yahoo.com>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.10.10011021935530.11540-100000@vaio.greennet>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Donald Becker wrote:
> > However, the only overriding reason to put dev->name into request_region
> > was for hotplug reasons, because it was otherwise impossible to build an
> 
> Most people with multiple network adapters use the same board type.  Seeing
> a list of identical board names isn't very useful when you are trying to do
> something like map interrupt counts to interface statistics.

You're talking about request_irq not request_region here, and
/proc/ioports isn't as "actively useful" as /proc/interrupts.

But you do have a point -- It sounds more informative to have dev->name
in /proc/ioports for the multiple ISA adapters case as well.  Seeing
"3c509" twice in /proc/ioports is not as informative (IMHO) as knowing
that eth0 is at 0x300 and eth1 is at 0x320.  Further, using dev->name in
request_region means that we have consistency with request_irq usage.

The only downside to using dev->name is that some drivers currently
touch the hardware before they have an interface name, but that is not a
real problem at all.

	Jeff


-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune

From owner-netdev@oss.sgi.com Thu Nov  2 20:00:55 2000
Received:  by oss.sgi.com id <S553806AbQKCEAq>;
	Thu, 2 Nov 2000 20:00:46 -0800
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:26128 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S553800AbQKCEAc>;
	Thu, 2 Nov 2000 20:00:32 -0800
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.9.3) with ESMTP id VAA23136;
	Thu, 2 Nov 2000 21:54:17 -0700
Message-ID: <3A0244F9.D896A13B@candelatech.com>
Date:   Thu, 02 Nov 2000 21:54:17 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Donald Becker <becker@scyld.com>
CC:     Jeff Garzik <jgarzik@mandrakesoft.com>,
        Paul Gortmaker <p_gortmaker@yahoo.com>,
        linux-net@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.10.10011021935530.11540-100000@vaio.greennet>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Donald Becker wrote:
> 
> On Thu, 2 Nov 2000, Jeff Garzik wrote:
> > Paul Gortmaker wrote:
> > > On a related note, there are a handful of drivers that register ioports
> > > (and IRQ) with the name dev->name (e.g. eth0) as opposed to a more
> > > meaningful model name (e.g. "3c503/16"). And some drivers do one for
> ...
> > For ISA, it's more informative.  For PCI, it's less informative because
> > the requested resource appears in /proc/ioports underneath the parent
> > PCI device.
> 
> Using dev->name is much more meaningful.
> I switched over all of my drivers to use dev->name a few years ago.

I noticed while writing some hashed device lookup-by-name code that
names can be changed at run time.  Would that affect the decision
any?

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Sat Nov  4 14:40:52 2000
Received:  by oss.sgi.com id <S553926AbQKDWkb>;
	Sat, 4 Nov 2000 14:40:31 -0800
Received: from finch-post-12.mail.demon.net ([194.217.242.41]:26642 "EHLO
        finch-post-12.mail.demon.net") by oss.sgi.com with ESMTP
	id <S553923AbQKDWkI>; Sat, 4 Nov 2000 14:40:08 -0800
Received: from pnd-pc.demon.co.uk ([158.152.18.190])
	by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
	id 13sByn-0009J8-0C; Sat, 4 Nov 2000 22:40:06 +0000
Received: from localhost (peterd@localhost)
	by pnd-pc.demon.co.uk (8.9.3/8.9.3) with ESMTP id OAA11792;
	Sat, 4 Nov 2000 14:01:25 GMT
Date:   Sat, 4 Nov 2000 14:01:24 +0000 (GMT)
From:   Peter Denison <peterd@pnd-pc.demon.co.uk>
To:     Paul Gortmaker <p_gortmaker@yahoo.com>
cc:     Jeff Garzik <jgarzik@mandrakesoft.com>,
        pavel rabel <pavel@web.sajt.cz>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [patch] NE2000
In-Reply-To: <39FD3CB6.2F641BBF@yahoo.com>
Message-ID: <Pine.LNX.4.21.0011041353040.10339-100000@pnd-pc.demon.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, 30 Oct 2000, Paul Gortmaker wrote:

[snip discussion about removing PCI code from ne.c]

> [ I've several other 8390 related patches I've been sitting on - trying
> to not contribute to the delay of 2.4.0 unless explicitly asked, such
> as the 8390.h get_module_symbol deletion.  Other 8390 patches I have 
> are a separated Tx timeout for 8390.c, kill off dev->rmem_start/end 
> and use ioremap() where required, and replace old check/request_region()
> with code that makes use of the newer resource structures. ]

	I'd thought it was quite important to get drivers doing
ioremap() properly before 2.4.0, since the whinging messages along the
lines of "io mapaddr 0x????? not valid at ..." are only really going to be
tolerated in a development kernel, and will look a bit shoddy in 2.4.0.
	The complaining has been there for quite a while, so we really
should have got our finger out and done the ioremap() thing (or at least
used isa_xxx functions) where needed. I agree, however, that thinking
seriously hard before delaying 2.4.0 now is a Good Thing (TM).

-- 
Peter Denison <peterd@pnd-pc.demon.co.uk>
Linux Driver for Promise DC4030VL cards.
See http://www.pnd-pc.demon.co.uk/promise/promise.html for details


From owner-netdev@oss.sgi.com Sat Nov  4 16:38:34 2000
Received:  by oss.sgi.com id <S553934AbQKEAiY>;
	Sat, 4 Nov 2000 16:38:24 -0800
Received: from sirppi.helsinki.fi ([128.214.205.27]:41995 "EHLO
        sirppi.helsinki.fi") by oss.sgi.com with ESMTP id <S553924AbQKEAiD>;
	Sat, 4 Nov 2000 16:38:03 -0800
Received: from localhost (amlaukka@localhost)
	by sirppi.helsinki.fi (8.10.1/8.10.1) with ESMTP id eA50bhx12035;
	Sun, 5 Nov 2000 02:37:53 +0200 (EET)
X-Authentication-Warning: sirppi.helsinki.fi: amlaukka owned process doing -bs
Date:   Sun, 5 Nov 2000 02:37:42 +0200 (EET)
From:   Aki M Laukkanen <amlaukka@cc.helsinki.fi>
To:     usagi-core <usagi-core@linux-ipv6.org>
cc:     netdev@oss.sgi.com
Subject: Re: [ANN] 1st release of USAGI IPv6 environment
In-Reply-To: <m3u29sqsc0.wl@shaku.sfc.wide.ad.jp>
Message-ID: <Pine.OSF.4.20.0011050154290.5793-100000@sirppi.helsinki.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Wed, 1 Nov 2000, usagi-core wrote:
> We are glad to announce the 1st release of USAGI Project. The "USAGI"
> means UniverSAl playGround for Ipv6. It is the IPv6 development project
> for Linux operating systems mainly.

Great to hear about this project. Looked at the site.
Would you like to elaborate on some of the goals?

* Anycast
* Routing header

* IPSec 

http://www.freeswan.org/ is the project implementing IPSec etc.
on Linux. They do not yet have IPv6 support but I think it's in the 
plans. If you're going to work on IPSec, you might want to cooperate
with them.

* Mobile IPv6

The GO Project at Helsinki University of Technology is implementing
IP Mobility support for IPv6.

http://vesper.tky.hut.fi/mip/

You seem to have evaluated the Linux stack with some kind of evaluation
suite (pointer?). However the kernel used was 2.2.15. Have you run the
same tests on 2.4.0-testxx?

> features such as IPsec and NDP are missing or miss-implemented.

NDP? Does it refer to Neighbor Discovery?

Btw. to get more familiar with IPv6 and the Linux implementation of it,
I started evaluating the stack with by checking each requirement in
RFC to how it was done in the code. This far I've only done RFC 2460.
The full report is available at:

http://www.cs.helsinki.fi/u/amlaukka/rfc2460.eval

I would appreciate if Dave, Alexei or Andi could look at it and 
comment on it. I'm sure you are keeping such a list already and
I'd like to know, to what extent this is duplicated effort. If
you think this is needed, I could proceed to ND, SAA etc?

Basically the old RFC 1883 (or thereabouts) shows only in the
user-space exported structures ipv6hdr and rt0_hdr. The code in
kernel does not reflect the priority vs. traffic class and bitmap
fields anymore. The attached patch changes these but it seems more
of a policy issue to leave them as is:

diff -urN linux-2.4.0-test10/include/linux/ipv6.h linux-2.4.0-test10.ipv6/include/linux/ipv6.h
--- linux-2.4.0-test10/include/linux/ipv6.h	Tue Oct  3 22:02:03 2000
+++ linux-2.4.0-test10.ipv6/include/linux/ipv6.h	Sat Nov  4 22:55:10 2000
@@ -67,7 +67,7 @@
 
 struct rt0_hdr {
 	struct ipv6_rt_hdr	rt_hdr;
-	__u32			bitmap;		/* strict/loose bit map */
+	__u32			reserved;
 	struct in6_addr		addr[0];
 
 #define rt0_type		rt_hdr.type;
@@ -76,22 +76,20 @@
 /*
  *	IPv6 fixed header
  *
- *	BEWARE, it is incorrect. The first 4 bits of flow_lbl
- *	are glued to priority now, forming "class".
  */
 
 struct ipv6hdr {
 #if defined(__LITTLE_ENDIAN_BITFIELD)
-	__u8			priority:4,
-				version:4;
+	__u32			flow_lbl:20,
+		                traffic_class:8,
+		                version:4;
 #elif defined(__BIG_ENDIAN_BITFIELD)
-	__u8			version:4,
-				priority:4;
+	__u32			version:4,
+		                traffic_class:8,
+		                flow_lbl:20;
 #else
 #error	"Please fix <asm/byteorder.h>"
 #endif
-	__u8			flow_lbl[3];
-
 	__u16			payload_len;
 	__u8			nexthdr;
 	__u8			hop_limit;
diff -urN linux-2.4.0-test10/net/ipv6/exthdrs.c linux-2.4.0-test10.ipv6/net/ipv6/exthdrs.c
--- linux-2.4.0-test10/net/ipv6/exthdrs.c	Sun Jan  9 07:36:21 2000
+++ linux-2.4.0-test10.ipv6/net/ipv6/exthdrs.c	Sat Nov  4 23:26:07 2000
@@ -345,7 +345,7 @@
 	memcpy(opt->srcrt, hdr, sizeof(*hdr));
 	irthdr = (struct rt0_hdr*)opt->srcrt;
 	/* Obsolete field, MBZ, when originated by us */
-	irthdr->bitmap = 0;
+	irthdr->reserved = 0;
 	opt->srcrt->segments_left = n;
 	for (i=0; i<n; i++)
 		memcpy(irthdr->addr+i, rthdr->addr+(n-1-i), 16);


(Disclaimer: I didn't actually try to compile the code).

Another issue which seems like a genuine bug is the handling reassembling
the fragmented packets. In some cases skb seems to be freed twice (I checked
all of icmp5_param_prob() usages):

--- linux-2.4.0-test10/net/ipv6/reassembly.c	Sat Jul 15 00:02:20 2000
+++ linux-2.4.0-test10.ipv6/net/ipv6/reassembly.c	Sun Nov  5 01:31:43 2000
@@ -365,7 +365,7 @@
 
 	if ((unsigned int)end >= 65536) {
 		icmpv6_param_prob(skb,ICMPV6_HDR_FIELD, (u8*)&fhdr->frag_off); 
-		goto err;
+		return;
 	}
 
 	/* Is this the final fragment? */
@@ -383,16 +383,9 @@
 		 * Required by the RFC.
 		 */
 		if (end & 0x7) {
-			printk(KERN_DEBUG "fragment not rounded to 8bytes\n");
-
-			/*
-			   It is not in specs, but I see no reasons
-			   to send an error in this case. --ANK
-			 */
-			if (offset == 0)
-				icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, 
-						  &skb->nh.ipv6h->payload_len);
-			goto err;
+			icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, 
+					  &skb->nh.ipv6h->payload_len);
+			return;
 		}
 		if (end > fq->len) {
 			/* Some bits beyond end -> corruption. */

I didn't quite understand that offset == 0 test?

-- 
D.


From owner-netdev@oss.sgi.com Sat Nov  4 21:09:08 2000
Received:  by oss.sgi.com id <S553942AbQKEFI6>;
	Sat, 4 Nov 2000 21:08:58 -0800
Received: from demai05.mw.mediaone.net ([24.131.1.56]:20623 "EHLO
        demai05.mw.mediaone.net") by oss.sgi.com with ESMTP
	id <S553936AbQKEFIh>; Sat, 4 Nov 2000 21:08:37 -0800
Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170])
	by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id AAA22879
	for <netdev@oss.sgi.com>; Sun, 5 Nov 2000 00:08:31 -0500 (EST)
Received: (from root@localhost)
	by deimos.ceddec.com (8.9.3/8.9.3) id AAA00782
	for netdev@oss.sgi.com; Sun, 5 Nov 2000 00:06:30 -0500
Date:   Sun, 5 Nov 2000 00:06:30 -0500
From:   Tom Zerucha <tz@execpc.com>
To:     netdev@oss.sgi.com
Subject: Wierd problem with 2.4.0-test10 (probably earlier)
Message-ID: <20001105000630.A776@deimos.mw.mediaone.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

I haven't done a test, but I can't access www.tdwaterhouse.com, nor
cgi.myccinfo.com with the second (>) set in the following diff list:

< # CONFIG_IP_MULTIPLE_TABLES is not set
< # CONFIG_IP_ROUTE_MULTIPATH is not set
< # CONFIG_IP_ROUTE_TOS is not set
---
> CONFIG_IP_MULTIPLE_TABLES=y
> CONFIG_IP_ROUTE_FWMARK=y
> CONFIG_IP_ROUTE_NAT=y
> CONFIG_IP_ROUTE_MULTIPATH=y
> CONFIG_IP_ROUTE_TOS=y

< # CONFIG_INET_ECN is not set
---
> CONFIG_INET_ECN=y

< # CONFIG_NET_DIVERT is not set
---
> CONFIG_NET_DIVERT=y

The problem is that the connect() call doesn't do anything - to any
port.  tcpdump shows other activity but NO packets out the correct
port for the above sites.  Most other sites seem to work fine, and I'm
using NAT, so my iMac will route to the sites fine.  I just cannot
initiate a connection from the linux box itself.

email if you need other details.  I'll try to narrow it down.

From owner-netdev@oss.sgi.com Sat Nov  4 22:05:08 2000
Received:  by oss.sgi.com id <S553945AbQKEGE6>;
	Sat, 4 Nov 2000 22:04:58 -0800
Received: from demai05.mw.mediaone.net ([24.131.1.56]:28836 "EHLO
        demai05.mw.mediaone.net") by oss.sgi.com with ESMTP
	id <S553941AbQKEGEh>; Sat, 4 Nov 2000 22:04:37 -0800
Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170])
	by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id BAA12776
	for <netdev@oss.sgi.com>; Sun, 5 Nov 2000 01:04:35 -0500 (EST)
Received: (from root@localhost)
	by deimos.ceddec.com (8.9.3/8.9.3) id BAA00598
	for netdev@oss.sgi.com; Sun, 5 Nov 2000 01:02:02 -0500
Date:   Sun, 5 Nov 2000 01:02:02 -0500
From:   Tom Zerucha <tz@execpc.com>
To:     netdev@oss.sgi.com
Subject: CONFIG_INET_ECN creates problems
Message-ID: <20001105010202.A582@deimos.mw.mediaone.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

CONFIG_INET_ECN prevents me from accessing www.tdwaterhouse.com and
myccinfo.com

In an earlier message I mentioned three settings that were different
between working and nonworking.  It ended up being this one.

the connect calls don't work - traceroutes expire at some point before
the destination is reached.  NAT routing is not affected.


From owner-netdev@oss.sgi.com Sun Nov  5 12:47:14 2000
Received:  by oss.sgi.com id <S553958AbQKEUrE>;
	Sun, 5 Nov 2000 12:47:04 -0800
Received: from anchor-post-34.mail.demon.net ([194.217.242.92]:60687 "EHLO
        anchor-post-34.mail.demon.net") by oss.sgi.com with ESMTP
	id <S553953AbQKEUqu>; Sun, 5 Nov 2000 12:46:50 -0800
Received: from pnd-pc.demon.co.uk ([158.152.18.190])
	by anchor-post-34.mail.demon.net with esmtp (Exim 2.12 #1)
	id 13sWgi-000NH6-0Y; Sun, 5 Nov 2000 20:46:48 +0000
Received: from localhost (peterd@localhost)
	by pnd-pc.demon.co.uk (8.9.3/8.9.3) with ESMTP id IAA18671;
	Sun, 5 Nov 2000 08:18:57 GMT
Date:   Sun, 5 Nov 2000 08:18:57 +0000 (GMT)
From:   Peter Denison <peterd@pnd-pc.demon.co.uk>
To:     Tom Zerucha <tz@execpc.com>
cc:     netdev@oss.sgi.com
Subject: Re: CONFIG_INET_ECN creates problems
In-Reply-To: <20001105010202.A582@deimos.mw.mediaone.net>
Message-ID: <Pine.LNX.4.21.0011050816110.10339-100000@pnd-pc.demon.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sun, 5 Nov 2000, Tom Zerucha wrote:

> CONFIG_INET_ECN prevents me from accessing www.tdwaterhouse.com and
> myccinfo.com
> 
> In an earlier message I mentioned three settings that were different
> between working and nonworking.  It ended up being this one.
> 
> the connect calls don't work - traceroutes expire at some point before
> the destination is reached.  NAT routing is not affected.

	I found similar results, though in my case, with ECN turned on, a
large number of sites were just sending RSTs straight back when I tried to
connect. Turn off ECN and everything works fine. Maybe there should be a
note in the config option help about it not working on the Internet at
large. I just turned it on because it sounded cool and harmless. ;-)

-- 
Peter Denison <peterd@pnd-pc.demon.co.uk>
Linux Driver for Promise DC4030VL cards.
See http://www.pnd-pc.demon.co.uk/promise/promise.html for details


From owner-netdev@oss.sgi.com Sun Nov  5 16:36:25 2000
Received:  by oss.sgi.com id <S553973AbQKFAgP>;
	Sun, 5 Nov 2000 16:36:15 -0800
Received: from wirespeed.solidum.com ([207.35.224.226]:49608 "EHLO solidum.com")
	by oss.sgi.com with ESMTP id <S553971AbQKFAfy>;
	Sun, 5 Nov 2000 16:35:54 -0800
Received: from phobos.solidum.com (phobos.solidum.com [192.168.1.13])
	by solidum.com (8.8.7/8.8.7) with ESMTP id TAA19162
	for <netdev@oss.sgi.com>; Sun, 5 Nov 2000 19:35:52 -0500
Message-Id: <200011060035.TAA19162@solidum.com>
To:     netdev@oss.sgi.com
Subject: Re: CONFIG_INET_ECN creates problems 
In-Reply-To: Your message of "Sun, 05 Nov 2000 08:18:57 GMT."
             <Pine.LNX.4.21.0011050816110.10339-100000@pnd-pc.demon.co.uk> 
Mime-Version: 1.0 (generated by tm-edit 1.5)
Content-Type: text/plain; charset=US-ASCII
Date:   Sun, 05 Nov 2000 19:35:52 -0500
From:   Michael Richardson <mcr@solidum.com>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


>>>>> "Peter" == Peter Denison <peterd@pnd-pc.demon.co.uk> writes:
    Peter> I found similar results, though in my case, with ECN turned on, a
    Peter> large number of sites were just sending RSTs straight back when I
    Peter> tried to connect. Turn off ECN and everything works fine. Maybe
    Peter> there should be a note in the config option help about it not
    Peter> working on the Internet at large. I just turned it on because it
    Peter> sounded cool and harmless. ;-)

  It would be good if any experiences with this, in particular, sites
involved could be summarized. Is this a bug in the ECN, or is this due to 
buggy remote implementations. The ECN WG, and I think Jamal who implemented
this (?) would want to know about deployment problems.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
	mailto:mcr@sandelman.ottawa.on.ca	mailto:mcr@solidum.com



  

From owner-netdev@oss.sgi.com Sun Nov  5 17:33:55 2000
Received:  by oss.sgi.com id <S553975AbQKFBdp>;
	Sun, 5 Nov 2000 17:33:45 -0800
Received: from mail.cyberus.ca ([209.195.95.1]:31157 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S553972AbQKFBde>;
	Sun, 5 Nov 2000 17:33:34 -0800
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id UAA15726;
	Sun, 5 Nov 2000 20:33:24 -0500 (EST)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id UAA02699;
	Sun, 5 Nov 2000 20:33:33 -0500 (EST)
Date:   Sun, 5 Nov 2000 20:33:33 -0500 (EST)
From:   jamal <hadi@cyberus.ca>
To:     Michael Richardson <mcr@solidum.com>
cc:     netdev@oss.sgi.com
Subject: Re: CONFIG_INET_ECN creates problems 
In-Reply-To: <200011060035.TAA19162@solidum.com>
Message-ID: <Pine.GSO.4.20.0011051948220.2665-100000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



On Sun, 5 Nov 2000, Michael Richardson wrote:

> 
>   It would be good if any experiences with this, in particular, sites
> involved could be summarized. Is this a bug in the ECN, or is this due to 
> buggy remote implementations. The ECN WG, and I think Jamal who implemented
> this (?) would want to know about deployment problems.
> 

Sorry for the lengthy reply.

Dax Kelson <dax@gurulabs.com> did extensive tests with Linux on the net to
try and isolate which sites were anti-ECN. Those tests were repeated by
J Padhye<jitu@ciri.org>. You can look at the results at:

http://www.aciri.org/tbit/ecn.daxlist.txt.gz

There actually has been a lot of activity happening ....
And infact, we (Linux), have greatly influenced the way the RFC is
evolving. If the (old) IETF moto of "we believe in running code .."
is alive then you just need to look at ECN and Linux (to appreciate Dave
Clark's wisdom). 

ECN is going to move from Experimental to Standard soon.

* The problem are so far pointing to firewalls, content switches/ load
balancers, and  intrusion detection systems which block the two ECN bits
in the TCP header.

The old RFCs defined the two ECN bits as "reserved".
English, as any other natural language, is ambigous. However translating
that to mean "not allowed" beats me. 

Summary: these boxes which block ECN are broken. 
Summary 2: we know that these broken boxes exist. What do you do about it?
Certainly, Linux users opening problem reports to the vendors helps a
lot. The vendors listen to their customers. There is going to be 'noise'
at the IETF on this as well.

There are several behaviors we have seen so far from these boxes:

1) send a RST to SYN with ECN enabled bits 

Some of the positively Id-ed boxes which do this:
	- CISCOs PIX firewall and CISCOs local director

--- CISCO has acted very positively and fixed this problem.

>From a posting by Dax:
http://marc.theaimsgroup.com/?l=linux-kernel&m=97154562227096&w=1

Not sure how many sites have deployed the fix.

2) They just swallow the SYN ;-<

Positively Id-ed in this category are Raptor firewalls.
	- I am pursuing this since my workplace uses Raptor firewalls.

3)  some smart-ass intrusion detection systems eg article at:

http://www.securityfocus.com/frames/?focus=ids&content=/focus/ids/articles/portscan.html
titled "Intrusion Detection Level Analysis of Nmap and Queso"

claims:

"[QUESO] is easy to identify, if you see [these two Reserved bits and the
SYN bit] set in the 13th byte of the TCP header, you know that someone has
malicious intentions for your network." 

Now imagine how many intrusion detection systems are lsitening to that
opinion and infact using it to block ECN packets.

4) According to Sally's web page:

AIX 4.3.2.0-4.3.3.0, IRIX 6.2- 6.5, Solaris 2.6 - 2.7, 
or Linux 2.1.122 - 2.2.14 of possible systems (as id-ed by nmap) that
might be causing this.
I know that old netfilter/ipchains has these problems. I doubt if it was
anywhere around Linux 2.1.122 - 2.2.14; maybe someone could clarify.

I doubt very much if these systems were running as servers; they were
probably configured as firewalls.

Summary3: We have to do something about this if ECN is to be deployed. 
So far there is a proposal by Sally Floyd and company which neither Alexey
nor Davem are thrilled about. I know i am not. 

Hopefully, this clears some air.

cheers,
jamal


From owner-netdev@oss.sgi.com Mon Nov  6 00:06:46 2000
Received:  by oss.sgi.com id <S553976AbQKFIGh>;
	Mon, 6 Nov 2000 00:06:37 -0800
Received: from smtp2.mail.yahoo.com ([128.11.68.32]:39696 "HELO
        smtp2.mail.yahoo.com") by oss.sgi.com with SMTP id <S553979AbQKFIGa>;
	Mon, 6 Nov 2000 00:06:30 -0800
Received: from ppp119.muskoka.com (HELO gromit.hairy.org) (199.212.175.149)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 6 Nov 2000 08:06:28 -0000
X-Apparently-From: <p?gortmaker@yahoo.com>
Message-ID: <3A0663E1.35A49246@yahoo.com>
Date:   Mon, 06 Nov 2000 02:55:13 -0500
From:   Paul Gortmaker <p_gortmaker@yahoo.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.17 i486)
MIME-Version: 1.0
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
CC:     Donald Becker <becker@scyld.com>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: dev->name in /proc/ioports (was: Re: [patch] NE2000)
References: <Pine.LNX.4.10.10011021935530.11540-100000@vaio.greennet> <3A020C19.4C4B3F66@mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Jeff Garzik wrote:
> 
> Donald Becker wrote:
> > Most people with multiple network adapters use the same board type.  Seeing
> > a list of identical board names isn't very useful when you are trying to do
> > something like map interrupt counts to interface statistics.
> 
> You're talking about request_irq not request_region here, and
> /proc/ioports isn't as "actively useful" as /proc/interrupts.
> 
> But you do have a point -- It sounds more informative to have dev->name
> in /proc/ioports for the multiple ISA adapters case as well.  Seeing
> "3c509" twice in /proc/ioports is not as informative (IMHO) as knowing
> that eth0 is at 0x300 and eth1 is at 0x320.  Further, using dev->name in
> request_region means that we have consistency with request_irq usage.

Something to consider (while still restricting this discussion to ISA
junk), you can always get ethN <---> irq/ioport mapping via. SIOCGIFMAP.
But the only reliable way to query the kernel as to what compiled in ISA
net driver is installed is by a model name in /proc/[ioports,interrupts]
(Yes, I know, a minor issue...)

Also, the trend for /proc/ioports (and interrupts) in other parts of the
kernel still appears to be based on hardware/model names and not kernel
device names, e.g. serial and not ttyS*, BusLogic BT-XXX and not scsi0,
soundblaster and not /dev/audio, etc. -- hence 3c509 and not eth0 would
be consistent?

> The only downside to using dev->name is that some drivers currently
> touch the hardware before they have an interface name, but that is not a
> real problem at all.

Yes, not a problem  - these can be handled with something like:

 struct resource *r;
 if ((r = request_region(..., "foo-probe")) == NULL) return -EBUSY;
 ret = foo_probe(...);
 if (ret != 0) release_resource(r);
 else r->name = dev->name;
 return ret;

Paul.


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

From owner-netdev@oss.sgi.com Mon Nov  6 00:06:46 2000
Received:  by oss.sgi.com id <S553981AbQKFIGh>;
	Mon, 6 Nov 2000 00:06:37 -0800
Received: from smtp1.mail.yahoo.com ([128.11.69.60]:55822 "HELO
        smtp1.mail.yahoo.com") by oss.sgi.com with SMTP id <S553976AbQKFIGU>;
	Mon, 6 Nov 2000 00:06:20 -0800
Received: from ppp119.muskoka.com (HELO gromit.hairy.org) (199.212.175.149)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 6 Nov 2000 08:06:17 -0000
X-Apparently-From: <p?gortmaker@yahoo.com>
Message-ID: <3A0651AB.357DD5B4@yahoo.com>
Date:   Mon, 06 Nov 2000 01:37:31 -0500
From:   Paul Gortmaker <p_gortmaker@yahoo.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.17 i486)
MIME-Version: 1.0
To:     Peter Denison <peterd@pnd-pc.demon.co.uk>
CC:     Jeff Garzik <jgarzik@mandrakesoft.com>,
        pavel rabel <pavel@web.sajt.cz>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.21.0011041353040.10339-100000@pnd-pc.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Peter Denison wrote:
> 
> On Mon, 30 Oct 2000, Paul Gortmaker wrote:
> 
> > Other 8390 patches I have
> > are a separated Tx timeout for 8390.c, kill off dev->rmem_start/end
> > and use ioremap() where required, and replace old check/request_region()
> > with code that makes use of the newer resource structures. ]
> 
>         I'd thought it was quite important to get drivers doing
> ioremap() properly before 2.4.0, since the whinging messages along the
> lines of " ..." are only really going to be
> tolerated in a development kernel, and will look a bit shoddy in 2.4.0.

The ioremap patch I did for 8390 based cards was circa Dec 1999, and the
impression I got at the time was that the isa_xxx stuff was good enough
for 2.4.0 - the cleanup could wait until 2.5.x - and so I shelved it.
I may dust it off and merge the EISA part of it since isa_xxx in
an EISA driver looks kind of silly though.

>         The complaining has been there for quite a while, so we really
> should have got our finger out and done the ioremap() thing (or at least
> used isa_xxx functions) where needed. I agree, however, that thinking
> seriously hard before delaying 2.4.0 now is a Good Thing (TM).

If you have some reports of drivers still causing "io mapaddr 0x?????
not valid" then please share them - in particular at least the driver
name.

Thanks,
Paul.



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


From owner-netdev@oss.sgi.com Mon Nov  6 01:41:49 2000
Received:  by oss.sgi.com id <S553983AbQKFJli>;
	Mon, 6 Nov 2000 01:41:38 -0800
Received: from lsne-cable-1-p21.vtxnet.ch ([212.147.5.21]:14344 "EHLO
        almesberger.net") by oss.sgi.com with ESMTP id <S553980AbQKFJlX>;
	Mon, 6 Nov 2000 01:41:23 -0800
Received: (from almesber@localhost)
	by almesberger.net (8.9.3/8.9.3) id KAA24622;
	Mon, 6 Nov 2000 10:40:34 +0100
Date:   Mon, 6 Nov 2000 10:40:34 +0100
From:   Werner Almesberger <Werner.Almesberger@epfl.ch>
To:     jamal <hadi@cyberus.ca>
Cc:     netdev@oss.sgi.com
Subject: Re: CONFIG_INET_ECN creates problems
Message-ID: <20001106104034.L3223@almesberger.net>
References: <200011060035.TAA19162@solidum.com> <Pine.GSO.4.20.0011051948220.2665-100000@shell.cyberus.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.20.0011051948220.2665-100000@shell.cyberus.ca>; from hadi@cyberus.ca on Sun, Nov 05, 2000 at 08:33:33PM -0500
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

jamal wrote:
> So far there is a proposal by Sally Floyd and company which neither Alexey
> nor Davem are thrilled about. I know i am not. 

You mean the "try once, and if anything goes wrong for whatever reason,
assume it's ECN's fault" approach ?

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/

From owner-netdev@oss.sgi.com Mon Nov  6 01:52:38 2000
Received:  by oss.sgi.com id <S553985AbQKFJw2>;
	Mon, 6 Nov 2000 01:52:28 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:42250 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S553982AbQKFJwJ>;
	Mon, 6 Nov 2000 01:52:09 -0800
Received: from mandrakesoft.com ([66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id EAA02416;
	Mon, 6 Nov 2000 04:51:47 -0500
Message-ID: <3A067F15.2E474B36@mandrakesoft.com>
Date:   Mon, 06 Nov 2000 04:51:17 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Paul Gortmaker <p_gortmaker@yahoo.com>
CC:     Donald Becker <becker@scyld.com>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: dev->name in /proc/ioports (was: Re: [patch] NE2000)
References: <Pine.LNX.4.10.10011021935530.11540-100000@vaio.greennet> <3A020C19.4C4B3F66@mandrakesoft.com> <3A0663E1.35A49246@yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Paul Gortmaker wrote:
> Something to consider (while still restricting this discussion to ISA
> junk), you can always get ethN <---> irq/ioport mapping via. SIOCGIFMAP.
> But the only reliable way to query the kernel as to what compiled in ISA
> net driver is installed is by a model name in /proc/[ioports,interrupts]
> (Yes, I know, a minor issue...)

I always use 'dmesg' for this...


> Also, the trend for /proc/ioports (and interrupts) in other parts of the
> kernel still appears to be based on hardware/model names and not kernel
> device names, e.g. serial and not ttyS*, BusLogic BT-XXX and not scsi0,
> soundblaster and not /dev/audio, etc. -- hence 3c509 and not eth0 would
> be consistent?

Especially for interrupts, it would be much smarter for the other
devices to indicate their device, since that allows you to differentiate
between adapters of the same type.

	Jeff


-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune

From owner-netdev@oss.sgi.com Mon Nov  6 01:58:48 2000
Received:  by oss.sgi.com id <S553987AbQKFJ6i>;
	Mon, 6 Nov 2000 01:58:38 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:49418 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S553984AbQKFJ6X>;
	Mon, 6 Nov 2000 01:58:23 -0800
Received: from mandrakesoft.com ([66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id EAA02554;
	Mon, 6 Nov 2000 04:57:55 -0500
Message-ID: <3A0680A3.6CC44E7E@mandrakesoft.com>
Date:   Mon, 06 Nov 2000 04:57:55 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Peter Denison <peterd@pnd-pc.demon.co.uk>
CC:     Paul Gortmaker <p_gortmaker@yahoo.com>,
        pavel rabel <pavel@web.sajt.cz>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.21.0011041353040.10339-100000@pnd-pc.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Peter Denison wrote:
> 
> On Mon, 30 Oct 2000, Paul Gortmaker wrote:
> 
> [snip discussion about removing PCI code from ne.c]
> 
> > [ I've several other 8390 related patches I've been sitting on - trying
> > to not contribute to the delay of 2.4.0 unless explicitly asked, such
> > as the 8390.h get_module_symbol deletion.  Other 8390 patches I have
> > are a separated Tx timeout for 8390.c, kill off dev->rmem_start/end
> > and use ioremap() where required, and replace old check/request_region()
> > with code that makes use of the newer resource structures. ]
> 
>         I'd thought it was quite important to get drivers doing
> ioremap() properly before 2.4.0, since the whinging messages along the
> lines of "io mapaddr 0x????? not valid at ..." are only really going to be
> tolerated in a development kernel, and will look a bit shoddy in 2.4.0.
>         The complaining has been there for quite a while, so we really
> should have got our finger out and done the ioremap() thing (or at least
> used isa_xxx functions) where needed. I agree, however, that thinking
> seriously hard before delaying 2.4.0 now is a Good Thing (TM).

I think isa_ioremap is good enough for 2.4.x... If the driver works, I
don't want to touch it.  But if you are in there touching the code
anyway, and doing testing anyway, you might as well fix it to do ioremap
correctly...

On another topic completely, I want to start moving drivers over to
doing MMIO instead of PIO, where possibly, in 2.5.x.  I am pretty sure
some if not most PCI NE2K clones can do MMIO.  Any known NE2K MMIO
bugs?   [again, this is 2.5.x material, so its not around the corner]

	Jeff


-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune

From owner-netdev@oss.sgi.com Mon Nov  6 04:57:08 2000
Received:  by oss.sgi.com id <S553994AbQKFM46>;
	Mon, 6 Nov 2000 04:56:58 -0800
Received: from mail.cyberus.ca ([209.195.95.1]:41375 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S553991AbQKFM4n>;
	Mon, 6 Nov 2000 04:56:43 -0800
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id HAA08746;
	Mon, 6 Nov 2000 07:56:33 -0500 (EST)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id HAA03366;
	Mon, 6 Nov 2000 07:56:40 -0500 (EST)
Date:   Mon, 6 Nov 2000 07:56:39 -0500 (EST)
From:   jamal <hadi@cyberus.ca>
To:     Werner Almesberger <Werner.Almesberger@epfl.ch>
cc:     netdev@oss.sgi.com
Subject: Re: CONFIG_INET_ECN creates problems
In-Reply-To: <20001106104034.L3223@almesberger.net>
Message-ID: <Pine.GSO.4.20.0011060750001.3358-100000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



On Mon, 6 Nov 2000, Werner Almesberger wrote:

> jamal wrote:
> > So far there is a proposal by Sally Floyd and company which neither Alexey
> > nor Davem are thrilled about. I know i am not. 
> 
> You mean the "try once, and if anything goes wrong for whatever reason,
> assume it's ECN's fault" approach ?

Yeah. Full text at:

http://www.aciri.org/floyd/papers/ECN.Oct2000.txt

cheers,
jamal


From owner-netdev@oss.sgi.com Mon Nov  6 06:51:18 2000
Received:  by oss.sgi.com id <S553996AbQKFOvI>;
	Mon, 6 Nov 2000 06:51:08 -0800
Received: from horus.its.uow.edu.au ([130.130.68.25]:59853 "EHLO
        horus.its.uow.edu.au") by oss.sgi.com with ESMTP id <S553992AbQKFOuv>;
	Mon, 6 Nov 2000 06:50:51 -0800
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by horus.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id BAA01540;
	Tue, 7 Nov 2000 01:50:44 +1100 (EST)
Message-ID: <3A06C552.4062884C@uow.edu.au>
Date:   Tue, 07 Nov 2000 01:50:58 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>
CC:     Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Strange accept() behaviour in 2.2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

I wrote a silly little server and client.  They're at

	http://www.uow.edu.au/~andrewm/wsws.tar.gz

The server just forks a bunch of children which wait in accept().
The client hammers the socket with connections to give all the
servers a fright.

The strange thing is the throughput:

Servers                 conn/sec
  1                     1666
  2                     666
  3                     476
  4                     476
  5                     476
  6                     1666
  7                     1666
  8                     1428
  9                     1428
  10                    1428
  50                    588
  100                   40

This is with 2.2.18-pre19-SMP on UP.  x86.  Does the same thing
with a uniprocessor build.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 5
model name      : Celeron (Covington)
stepping        : 1
cpu MHz         : 400.000920
cache size      : 0 KB				/* huh? */
fdiv_bug        : no
hlt_bug         : no
sep_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr
bogomips        : 799.54


Why is the accept() rate 3-4 times lower at 2, 3, 4 and 5 servers?

Can anyone else reproduce this?

Just run

	./wsws 2224 <nServers> &
	time ./wswc 0 2224 10000

From owner-netdev@oss.sgi.com Mon Nov  6 08:38:48 2000
Received:  by oss.sgi.com id <S553997AbQKFQii>;
	Mon, 6 Nov 2000 08:38:38 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:40968 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553860AbQKFQiT>;
	Mon, 6 Nov 2000 08:38:19 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA19711; Mon, 6 Nov 2000 19:38:02 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011061638.TAA19711@ms2.inr.ac.ru>
Subject: Re: CONFIG_INET_ECN creates problems
To:     hadi@cyberus.CA (jamal)
Date:   Mon, 6 Nov 2000 19:38:02 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <Pine.GSO.4.20.0011051948220.2665-100000@shell.cyberus.ca> from "jamal" at Nov 6, 0 04:45:01 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 437       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> So far there is a proposal by Sally Floyd and company which neither Alexey
> nor Davem are thrilled about. I know i am not. 

I am thrilled.

And I have to say honestly: when some daring hero will prepare
patch implementing this new bug, it is pretty useless to submit it to me.
When I am thrilled in such extent, I used to lose patches
in backlogs silently. This happens without any intention,
just occasionally. 8)8)

Alexey

From owner-netdev@oss.sgi.com Mon Nov  6 09:14:29 2000
Received:  by oss.sgi.com id <S554000AbQKFROJ>;
	Mon, 6 Nov 2000 09:14:09 -0800
Received: from gadolinium.btinternet.com ([194.73.73.111]:54961 "EHLO
        gadolinium.btinternet.com") by oss.sgi.com with ESMTP
	id <S553863AbQKFRNu>; Mon, 6 Nov 2000 09:13:50 -0800
Received: from [213.1.195.70] (helo=trinity.local)
	by gadolinium.btinternet.com with esmtp (Exim 3.03 #83)
	id 13spq1-0005rE-00; Mon, 06 Nov 2000 17:13:42 +0000
Received: from neo.local (davej@neo.local [172.16.0.4])
	by trinity.local (8.9.3/8.9.3) with ESMTP id RAA07751;
	Mon, 6 Nov 2000 17:03:45 GMT
From:   davej@suse.de
Date:   Mon, 6 Nov 2000 17:03:32 +0000 (GMT)
X-Sender: davej@neo.local
To:     Andrew Morton <andrewm@uow.edu.au>
cc:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>,
        Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: Strange accept() behaviour in 2.2
In-Reply-To: <3A06C552.4062884C@uow.edu.au>
Message-ID: <Pine.LNX.4.21.0011061702410.18587-100000@neo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, 7 Nov 2000, Andrew Morton wrote:

> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 5
> model name      : Celeron (Covington)
> stepping        : 1
> cpu MHz         : 400.000920
> cache size      : 0 KB				/* huh? */

Original Celeron's were cacheless. You either have one of these,
or you have your cache switched off in the BIOS.

regards,

Davej.

-- 
| Dave Jones <davej@suse.de>  http://www.suse.de/~davej
| SuSE Labs


From owner-netdev@oss.sgi.com Mon Nov  6 10:21:20 2000
Received:  by oss.sgi.com id <S554004AbQKFSVK>;
	Mon, 6 Nov 2000 10:21:10 -0800
Received: from zikova.cvut.cz ([147.32.235.100]:47366 "EHLO zikova.cvut.cz")
	by oss.sgi.com with ESMTP id <S554001AbQKFSUt>;
	Mon, 6 Nov 2000 10:20:49 -0800
Received: from vcnet.vc.cvut.cz (vcnet.vc.cvut.cz [147.32.240.61])
	by zikova.cvut.cz (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id TAA16792;
	Mon, 6 Nov 2000 19:18:44 +0100
Received: from VCNET/SpoolDir by vcnet.vc.cvut.cz (Mercury 1.21);
    6 Nov 100 19:18:45 MET-1MEST
Received: from SpoolDir by VCNET (Mercury 1.30); 6 Nov 100 19:18:39 MET-1MEST
From:   "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
Organization:  CC CTU Prague
To:     davem@redhat.com
Date:          Mon, 6 Nov 2000 19:18:35 MET-1
MIME-Version:  1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject:       2.4.0-test10 and tcp_input.c(1203)
CC:     netdev@oss.sgi.com
X-mailer: Pegasus Mail v3.40
Message-ID: <C1998006285@vcnet.vc.cvut.cz>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi Dave, hi others,
  do you have any idea what
  
KERNEL: assertion (cnt <= tp->packets_out) failed at tcp_input.c(1203):tcp_mark_head_lost

means? Except named activity, at 10:03:40 (exactly) there is entry
in apache logfile, that someone from 147.32.84.37 (nmap says 
Linux 2.1.122-2.2.14) accessed some files on www.dialogselect.com
(nmap says Raptor Firewall 6 on Solaris 2.6/2.6-2.7/7) (vana itself
runs application proxy (written in php4) for accessing Dialog Corp. 
services from Czech Republic).

  Machine hardware is dual PIII/450, 256MB RAM, 18GB IDE, tulip on 10BaseT.
Kernel was compiled with gcc-2.95.2.
                                            Thanks,
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz
                                                    
Nov  6 10:03:38 vana named[872]: approved AXFR from [195.113.31.125].3405 for "dialog.cvut.cz"
Nov  6 10:03:38 vana named[872]: zone transfer (AXFR) of "dialog.cvut.cz" (IN) to [195.113.31.125].3405
Nov  6 10:03:40 vana kernel: KERNEL: assertion (cnt <= tp->packets_out) failed at tcp_input.c(1203):tcp_mark_head_lost
Nov  6 10:03:40 vana last message repeated 2 times
Nov  6 10:10:01 vana PAM_unix[8097]: (cron) session opened for user root by (uid=0)

From owner-netdev@oss.sgi.com Mon Nov  6 11:22:21 2000
Received:  by oss.sgi.com id <S554006AbQKFTWC>;
	Mon, 6 Nov 2000 11:22:02 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:50184 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553872AbQKFTVy>;
	Mon, 6 Nov 2000 11:21:54 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA20755; Mon, 6 Nov 2000 22:21:34 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011061921.WAA20755@ms2.inr.ac.ru>
Subject: Re: 2.4.0-test10 and tcp_input.c(1203)
To:     VANDROVE@vc.cvut.cz (Petr Vandrovec)
Date:   Mon, 6 Nov 2000 22:21:34 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <C1998006285@vcnet.vc.cvut.cz> from "Petr Vandrovec" at Nov 6, 0 09:45:01 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 497       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

>   do you have any idea what
>   
> KERNEL: assertion (cnt <= tp->packets_out) failed at tcp_input.c(1203):tcp_mark_head_lost
> 
> means? 

Like all the messages starting of this prefix, it means serious bug.


In this case it is harmless. If you, not changing anything more,
add to that line:

	if (tp->fackets_out > tp->packets_out)
		printk("Yes, it is\n");

and will see that each assertion is followed by this message,
you will remove the last doubts in its harmlessness. 8)

Alexey

From owner-netdev@oss.sgi.com Mon Nov  6 12:23:43 2000
Received:  by oss.sgi.com id <S554027AbQKFUXc>;
	Mon, 6 Nov 2000 12:23:32 -0800
Received: from smtp3.mail.yahoo.com ([128.11.68.135]:60681 "HELO
        smtp1b.mail.yahoo.com") by oss.sgi.com with SMTP id <S554025AbQKFUX1>;
	Mon, 6 Nov 2000 12:23:27 -0800
Received: from ppp068.muskoka.com (HELO gromit.hairy.org) (199.212.175.98)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 6 Nov 2000 20:23:24 -0000
X-Apparently-From: <p?gortmaker@yahoo.com>
Message-ID: <3A06F281.73D6AF2@yahoo.com>
Date:   Mon, 06 Nov 2000 13:03:45 -0500
From:   Paul Gortmaker <p_gortmaker@yahoo.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.18pre18 i486)
MIME-Version: 1.0
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
CC:     Donald Becker <becker@scyld.com>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: dev->name in /proc/ioports (was: Re: [patch] NE2000)
References: <Pine.LNX.4.10.10011021935530.11540-100000@vaio.greennet> <3A020C19.4C4B3F66@mandrakesoft.com> <3A0663E1.35A49246@yahoo.com> <3A067F15.2E474B36@mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Jeff Garzik wrote:
> 
> Paul Gortmaker wrote:
> > But the only reliable way to query the kernel as to what compiled in ISA
                 ^^^^^^^^
> > net driver is installed is by a model name in /proc/[ioports,interrupts]
> > (Yes, I know, a minor issue...)
> 
> I always use 'dmesg' for this...

It isn't reliable - some installs did a "dmesg -c" at boot IIRC, or the
ring buf may have already wrapped with crud like VFS disk change
messages.

> > Also, the trend for /proc/ioports (and interrupts) in other parts of the
> > kernel still appears to be based on hardware/model names and not kernel
> > device names, e.g. serial and not ttyS*, BusLogic BT-XXX and not scsi0,
> > soundblaster and not /dev/audio, etc. -- hence 3c509 and not eth0 would
> > be consistent?
> 
> Especially for interrupts, it would be much smarter for the other
> devices to indicate their device, since that allows you to differentiate
> between adapters of the same type.

Ok - I still think consistency is a worthwhile goal.  So I guess we 
(in 2.5.x) will have to extend the scope of settling on the device name 
outside of drivers/net (assuming nobody else has sufficient reasons to 
stick with model names instead).

Paul.



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


From owner-netdev@oss.sgi.com Mon Nov  6 12:24:12 2000
Received:  by oss.sgi.com id <S554030AbQKFUYC>;
	Mon, 6 Nov 2000 12:24:02 -0800
Received: from smtp3.mail.yahoo.com ([128.11.68.135]:25098 "HELO
        smtp1b.mail.yahoo.com") by oss.sgi.com with SMTP id <S554026AbQKFUXs>;
	Mon, 6 Nov 2000 12:23:48 -0800
Received: from ppp068.muskoka.com (HELO gromit.hairy.org) (199.212.175.98)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 6 Nov 2000 20:23:41 -0000
X-Apparently-From: <p?gortmaker@yahoo.com>
Message-ID: <3A070B6F.1481CC5F@yahoo.com>
Date:   Mon, 06 Nov 2000 14:50:07 -0500
From:   Paul Gortmaker <p_gortmaker@yahoo.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.18pre18 i486)
MIME-Version: 1.0
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
CC:     linux-net@vger.kernel.org, netdev@oss.sgi.com, becker@scyld.com
Subject: Re: MMIO ne2k-pci? (was Re: [patch] NE2000)
References: <Pine.LNX.4.21.0011041353040.10339-100000@pnd-pc.demon.co.uk> <3A0680A3.6CC44E7E@mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Jeff Garzik wrote:

> On another topic completely, I want to start moving drivers over to
> doing MMIO instead of PIO, where possibly, in 2.5.x.  I am pretty sure
> some if not most PCI NE2K clones can do MMIO.  Any known NE2K MMIO
> bugs?   [again, this is 2.5.x material, so its not around the corner]

I imagine this is one of those "dont know until you try it" type deals.
I'd be disappointed if at least one of the clones didn't break in some
mysterious and unexplainable way. ;-)  IIRC, Donald recently mentioned
something about one of the el-cheapo chipsets (not ne2k-pci) doing 
something strange when using MMIO - but I can't find the message now...

You wouldn't be able to share an 8390.o anymore - I guess you would
have to play the usual #undef games with inb etc. at the top of 8390.c 
then compile with -DUSE_MMIO and then bundle 8390.o with ne2k-pci.o

Have to keep in mind that PCI ne2k clones still have an 8390 at their
core - an SMP unfriendly chunk of history that is similar in vintage 
to other long forgotten relics like the 3c501.  Given the above, is it
really worth the grief of going MMIO?   [Anyone that intentionally buys
one of these for a SMP box or a server deserves a boot to the head IMHO]

Paul.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


From owner-netdev@oss.sgi.com Mon Nov  6 13:01:42 2000
Received:  by oss.sgi.com id <S554035AbQKFVBd>;
	Mon, 6 Nov 2000 13:01:33 -0800
Received: from Cantor.suse.de ([194.112.123.193]:39438 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S554031AbQKFVBR>;
	Mon, 6 Nov 2000 13:01:17 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id CC5A71E133; Mon,  6 Nov 2000 22:01:15 +0100 (MET)
Received: from gruyere.muc.suse.de (unknown [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 83D483E476; Mon,  6 Nov 2000 22:01:15 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id 13AA22F300; Mon,  6 Nov 2000 22:01:15 +0100 (MET)
Date:   Mon, 6 Nov 2000 22:01:15 +0100
From:   Andi Kleen <ak@suse.de>
To:     "David S. Miller" <davem@redhat.com>,
        "A.N.Kuznetsov" <kuznet@ms2.inr.ac.ru>
Cc:     netdev@oss.sgi.com
Subject: Karn's rule in Linux TCP
Message-ID: <20001106220115.A26879@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


Hi,

I was rereading old text files and found the old description of the Solaris 2.5 TCP bugs
for slow links from Sun. I think one of them affect 2.4 (and probably 2.2) too:

When the initial RTT estimate is too low then there will be no segments going through
without any retransmits. On a connection with no timestamps all RTT estimates for
retransmitted packets are ignored due to Karn's rule. Unfortunately this means that
when the initial RTT is too low it'll never get a new estimate, because all
packets that arrive at the other end were already retransmitted. The connection
gets lots of faulty retransmits forever. Oops.

On connections with timestamps the problem does not happen because we use all packets,
retransmitted or not, for the RTT estimates. Connections without timestamps lose
badly though (and I think Windows 9x still defaults to no timestamps) 

Normally that only affects links with a RTT>3s, but with a saved rtt it could be 
much lower when the rtt suddenly increases after it was saved. 

Sun's solution was described as:

``
Our solution is to keep the RTO RTT update still conservative, but now
update the RTO after no more than one receive window's worth of valid
RTT's. Further, when an invalid RTT is seen--an ACK of a retransmitted
segment, for example--any valid RTT information is fed into the RTO
algorithm.
''

I am not sure what they mean with "any valid RTT information", because in this
situation all RTTs are invalid due to Karn's rule. Also updating the RTO earlier
also does not work because of the same problem (so either this description is
wrong or Solaris still has the bug ;)

The only recovery is to ignore Karn's rule after some time and feed use the RTO,
even when you're not sure if it was for the retransmitted packet or not. After
a few retansmits the backoff is already long enough that you can be probably
assume that the previous retransmitted packet has already left the network.
So one way to solve it would be to turn off the Karn filter after a few
retransmits in tcp_ack_no_tstamp().  The hard to tune thing is how many
retransmits it should wait. It depends what are good practical upper boundaries
for packet live times in the real internet.

Any suggestions on that?  Any other ideas? 

-Andi

From owner-netdev@oss.sgi.com Mon Nov  6 18:21:14 2000
Received:  by oss.sgi.com id <S553719AbQKGCVE>;
	Mon, 6 Nov 2000 18:21:04 -0800
Received: from 64.124.41.10.napster.com ([64.124.41.10]:9222 "EHLO
        foobar.napster.com") by oss.sgi.com with ESMTP id <S553663AbQKGCUz>;
	Mon, 6 Nov 2000 18:20:55 -0800
Received: from wagner.napster.com (mail.napster.com [63.108.185.112])
	by foobar.napster.com (8.9.3/8.9.3) with ESMTP id SAA17377;
	Mon, 6 Nov 2000 18:20:06 -0800
Received: from napster.com (gw.napster.com [63.108.185.120])
	by wagner.napster.com (8.9.3/8.9.3) with SMTP id SAA14813;
	Mon, 6 Nov 2000 18:20:49 -0800
Message-ID: <3A076701.F437F88B@napster.com>
Date:   Mon, 06 Nov 2000 18:20:49 -0800
From:   Jordan Mendelson <jordy@napster.com>
Organization: Napster, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     davem@redhat.com, kuznet@ms2.inr.ac.ru, ak@muc.de,
        netdev@oss.sgi.com
Subject: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


We are seeing a performance slowdown between Windows PPP users and
servers running 2.4.0-test10. Attached is a tcpdump log of the
connection. The machines is without TCP ECN support. The Windows machine
is running Windows 98 SE 4.10.2222 A dialed up over PPP w/ TCP header
compression. The Linux machine is connected directly to the Internet via
a 6509. There is a possibility that we are hitting a bandwidth cap on
outgoing traffic.


18:51:33.282286 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: S
3013389:3013389(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
18:51:33.282395 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: S
2198113890:2198113890(0) ack 3013390 win 5840 <mss 1460,nop,nop,sackOK>
(DF)
18:51:33.509532 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
1:1(0) ack 1 win 8576 (DF)
18:51:33.510360 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
1:1(0) ack 1 win 65280 (DF)
18:51:33.510416 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: P
1:44(43) ack 1 win 65280 (DF)
18:51:33.510457 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: .
1:1(0) ack 44 win 5840 (DF)
18:51:33.988330 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
1:21(20) ack 44 win 5840 (DF)
18:51:33.988474 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
21:557(536) ack 44 win 5840 (DF)
18:51:36.987336 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
1:21(20) ack 44 win 5840 (DF)
18:51:37.177772 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: P
44:56(12) ack 21 win 65260 (DF)
18:51:37.177794 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
21:557(536) ack 44 win 5840 (DF)
18:51:37.177806 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
557:1093(536) ack 56 win 5840 (DF)
18:51:39.845046 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: P
44:456(412) ack 21 win 65260 (DF)
18:51:39.845071 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: .
1093:1093(0) ack 456 win 6432 <nop,nop, sack 1 {44:56} > (DF)
18:51:43.177329 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
21:557(536) ack 456 win 6432 (DF)
18:51:43.538219 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
456:456(0) ack 557 win 65280 (DF)
18:51:43.538275 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
557:1093(536) ack 456 win 6432 (DF)
18:51:43.538292 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
1093:1629(536) ack 456 win 6432 (DF)
18:51:55.537346 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
557:1093(536) ack 456 win 6432 (DF)
18:51:55.841360 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
456:456(0) ack 1093 win 65280 (DF)
18:51:55.841384 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
1093:1629(536) ack 456 win 6432 (DF)
18:51:55.841393 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
1629:1849(220) ack 456 win 6432 (DF)
18:52:19.837335 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
1093:1629(536) ack 456 win 6432 (DF)
18:52:20.153776 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
456:456(0) ack 1629 win 65280 (DF)
18:52:20.153803 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
1629:1849(220) ack 456 win 6432 (DF)
18:53:08.147334 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
1629:1849(220) ack 456 win 6432 (DF)
18:53:08.475911 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
456:456(0) ack 1849 win 65060 (DF)
18:53:08.475947 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
1849:1871(22) ack 456 win 6432 (DF)
18:54:44.467332 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
1849:1871(22) ack 456 win 6432 (DF)
18:54:44.824187 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
456:456(0) ack 1871 win 65038 (DF)
18:54:44.824256 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
1871:1893(22) ack 456 win 6432 (DF)
18:54:55.212750 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: P
456:506(50) ack 1871 win 65038 (DF)
18:54:55.212767 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: .
1893:1893(0) ack 506 win 6432 (DF)
18:54:55.571337 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
1893:2429(536) ack 506 win 6432 (DF)
18:54:57.394879 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: P
456:506(50) ack 1871 win 65038 (DF)
18:54:57.394894 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: .
2429:2429(0) ack 506 win 6432 <nop,nop, sack 1 {456:506} > (DF)


Here are some numbers from /proc/sys/net/ipv4:

$ cat /proc/sys/net/ipv4/tcp_rmem
4096	87380	174760

$ cat /proc/sys/net/ipv4/tcp_wmem 
4096	16384	131072

$ cat /proc/sys/net/ipv4/tcp_sack
1

$ cat /proc/sys/net/ipv4/tcp_fack
1

$ cat /proc/sys/net/ipv4/tcp_dsack
1

$ cat /proc/sys/net/ipv4/tcp_window_scaling 
1

$ cat /proc/sys/net/ipv4/tcp_syncookies     
0

$ cat /proc/sys/net/ipv4/tcp_timestamps 
1



Jordan

From owner-netdev@oss.sgi.com Mon Nov  6 19:45:45 2000
Received:  by oss.sgi.com id <S553792AbQKGDp0>;
	Mon, 6 Nov 2000 19:45:26 -0800
Received: from 64.124.41.10.napster.com ([64.124.41.10]:38408 "EHLO
        foobar.napster.com") by oss.sgi.com with ESMTP id <S553769AbQKGDpM>;
	Mon, 6 Nov 2000 19:45:12 -0800
Received: from wagner.napster.com (mail.napster.com [63.108.185.112])
	by foobar.napster.com (8.9.3/8.9.3) with ESMTP id TAA21220;
	Mon, 6 Nov 2000 19:44:18 -0800
Received: from napster.com (gw.napster.com [63.108.185.120])
	by wagner.napster.com (8.9.3/8.9.3) with SMTP id TAA18903;
	Mon, 6 Nov 2000 19:44:58 -0800
Message-ID: <3A077AB9.74FE8BF2@napster.com>
Date:   Mon, 06 Nov 2000 19:44:57 -0800
From:   Jordan Mendelson <jordy@napster.com>
Organization: Napster, Inc.
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     davem@redhat.com, kuznet@ms2.inr.ac.ru, ak@muc.de,
        netdev@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
References: <3A076701.F437F88B@napster.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Jordan Mendelson wrote:
> 
> We are seeing a performance slowdown between Windows PPP users and
> servers running 2.4.0-test10. Attached is a tcpdump log of the
> connection. The machines is without TCP ECN support. The Windows machine
> is running Windows 98 SE 4.10.2222 A dialed up over PPP w/ TCP header
> compression. The Linux machine is connected directly to the Internet via
> a 6509. There is a possibility that we are hitting a bandwidth cap on
> outgoing traffic.


Just some updates. This problem does not appear to happen under 2.2.16.
The dump for 2.2.16 is almost the same except we send an mss back of 536
and not 1460 (remote mtu vs local mtu).

Here is the head of a tcpdump with the same client, but this time with a
2.2.16 machine instead of a 2.4.0-test10 machine:

19:26:23.593114 eth0 < 209.179.248.69.1260 > 64.124.41.136.8888: S
5061245:5061245(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
19:26:23.593237 eth0 > 64.124.41.136.8888 > 209.179.248.69.1260: S
119520695:119520695(0) ack 5061246 win 32696 <mss 536,nop,nop,sackOK>
(DF)
19:26:23.824394 eth0 < 209.179.248.69.1260 > 64.124.41.136.8888: .
1:1(0) ack 1 win 65280 (DF)
19:26:23.824398 eth0 < 209.179.248.69.1260 > 64.124.41.136.8888: .
1:1(0) ack 1 win 8576 (DF)
19:26:23.825249 eth0 < 209.179.248.69.1260 > 64.124.41.136.8888: P
1:44(43) ack 1 win 65280 (DF)
19:26:23.825283 eth0 > 64.124.41.136.8888 > 209.179.248.69.1260: .
1:1(0) ack 44 win 32696 (DF)
19:26:25.245845 eth0 > 64.124.41.136.8888 > 209.179.248.69.1260: P
1:21(20) ack 44 win 32696 (DF)
19:26:25.245956 eth0 > 64.124.41.136.8888 > 209.179.248.69.1260: P
21:342(321) ack 44 win 32696 (DF)
19:26:25.466759 eth0 < 209.179.248.69.1260 > 64.124.41.136.8888: .
44:44(0) ack 342 win 64939 (DF)
19:26:25.466792 eth0 > 64.124.41.136.8888 > 209.179.248.69.1260: P
342:878(536) ack 44 win 32696 (DF)
19:26:25.466800 eth0 > 64.124.41.136.8888 > 209.179.248.69.1260: P
878:1401(523) ack 44 win 32696 (DF)
19:26:25.467562 eth0 < 209.179.248.69.1260 > 64.124.41.136.8888: P
44:56(12) ack 342 win 64939 (DF)
19:26:25.480104 eth0 > 64.124.41.136.8888 > 209.179.248.69.1260: .
1401:1401(0) ack 56 win 32696 (DF)
19:26:25.763509 eth0 < 209.179.248.69.1260 > 64.124.41.136.8888: P
56:456(400) ack 878 win 65280 (DF)
19:26:25.766253 eth0 < 209.179.248.69.1260 > 64.124.41.136.8888: .
456:456(0) ack 1401 win 64757 (DF)
19:26:26.070115 eth0 > 64.124.41.136.8888 > 209.179.248.69.1260: .
1401:1401(0) ack 456 win 32296 (DF)
19:26:26.431515 eth0 > 64.124.41.136.8888 > 209.179.248.69.1260: P
1401:1413(12) ack 456 win 32696 (DF)
19:26:26.432141 eth0 > 64.124.41.136.8888 > 209.179.248.69.1260: P
1413:1684(271) ack 456 win 32696 (DF)
19:26:26.657631 eth0 < 209.179.248.69.1260 > 64.124.41.136.8888: .
456:456(0) ack 1684 win 65280 (DF)
19:26:26.657663 eth0 > 64.124.41.136.8888 > 209.179.248.69.1260: P
1684:1817(133) ack 456 win 32696 (DF)
19:26:26.952825 eth0 < 209.179.248.69.1260 > 64.124.41.136.8888: .
456:456(0) ack 1817 win 65147 (DF)
19:26:31.086138 eth0 < 209.179.248.69.1260 > 64.124.41.136.8888: P
456:506(50) ack 1817 win 65147 (DF)

> 18:51:33.282286 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: S
> 3013389:3013389(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
> 18:51:33.282395 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: S
> 2198113890:2198113890(0) ack 3013390 win 5840 <mss 1460,nop,nop,sackOK>
> (DF)
> 18:51:33.509532 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
> 1:1(0) ack 1 win 8576 (DF)
> 18:51:33.510360 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
> 1:1(0) ack 1 win 65280 (DF)
> 18:51:33.510416 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: P
> 1:44(43) ack 1 win 65280 (DF)
> 18:51:33.510457 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: .
> 1:1(0) ack 44 win 5840 (DF)
> 18:51:33.988330 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 1:21(20) ack 44 win 5840 (DF)
> 18:51:33.988474 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 21:557(536) ack 44 win 5840 (DF)
> 18:51:36.987336 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 1:21(20) ack 44 win 5840 (DF)
> 18:51:37.177772 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: P
> 44:56(12) ack 21 win 65260 (DF)
> 18:51:37.177794 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 21:557(536) ack 44 win 5840 (DF)
> 18:51:37.177806 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 557:1093(536) ack 56 win 5840 (DF)
> 18:51:39.845046 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: P
> 44:456(412) ack 21 win 65260 (DF)
> 18:51:39.845071 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: .
> 1093:1093(0) ack 456 win 6432 <nop,nop, sack 1 {44:56} > (DF)
> 18:51:43.177329 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 21:557(536) ack 456 win 6432 (DF)
> 18:51:43.538219 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
> 456:456(0) ack 557 win 65280 (DF)
> 18:51:43.538275 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 557:1093(536) ack 456 win 6432 (DF)
> 18:51:43.538292 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 1093:1629(536) ack 456 win 6432 (DF)
> 18:51:55.537346 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 557:1093(536) ack 456 win 6432 (DF)
> 18:51:55.841360 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
> 456:456(0) ack 1093 win 65280 (DF)
> 18:51:55.841384 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 1093:1629(536) ack 456 win 6432 (DF)
> 18:51:55.841393 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 1629:1849(220) ack 456 win 6432 (DF)
> 18:52:19.837335 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 1093:1629(536) ack 456 win 6432 (DF)
> 18:52:20.153776 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
> 456:456(0) ack 1629 win 65280 (DF)
> 18:52:20.153803 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 1629:1849(220) ack 456 win 6432 (DF)
> 18:53:08.147334 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 1629:1849(220) ack 456 win 6432 (DF)
> 18:53:08.475911 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
> 456:456(0) ack 1849 win 65060 (DF)
> 18:53:08.475947 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 1849:1871(22) ack 456 win 6432 (DF)
> 18:54:44.467332 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 1849:1871(22) ack 456 win 6432 (DF)
> 18:54:44.824187 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: .
> 456:456(0) ack 1871 win 65038 (DF)
> 18:54:44.824256 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 1871:1893(22) ack 456 win 6432 (DF)
> 18:54:55.212750 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: P
> 456:506(50) ack 1871 win 65038 (DF)
> 18:54:55.212767 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: .
> 1893:1893(0) ack 506 win 6432 (DF)
> 18:54:55.571337 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: P
> 1893:2429(536) ack 506 win 6432 (DF)
> 18:54:57.394879 eth0 < 209.179.248.69.1238 > 64.124.41.177.8888: P
> 456:506(50) ack 1871 win 65038 (DF)
> 18:54:57.394894 eth0 > 64.124.41.177.8888 > 209.179.248.69.1238: .
> 2429:2429(0) ack 506 win 6432 <nop,nop, sack 1 {456:506} > (DF)

Jordan

From owner-netdev@oss.sgi.com Mon Nov  6 20:44:16 2000
Received:  by oss.sgi.com id <S553794AbQKGEoG>;
	Mon, 6 Nov 2000 20:44:06 -0800
Received: from pizda.ninka.net ([216.101.162.242]:22913 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S553783AbQKGEnr>;
	Mon, 6 Nov 2000 20:43:47 -0800
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id UAA01723;
	Mon, 6 Nov 2000 20:29:14 -0800
Date:   Mon, 6 Nov 2000 20:29:14 -0800
Message-Id: <200011070429.UAA01723@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     jordy@napster.com
CC:     kuznet@ms2.inr.ac.ru, ak@muc.de, netdev@oss.sgi.com,
        linux-kernel@vger.kernel.org
In-reply-to: <3A077AB9.74FE8BF2@napster.com> (message from Jordan Mendelson on
	Mon, 06 Nov 2000 19:44:57 -0800)
Subject: Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
References: <3A076701.F437F88B@napster.com> <3A077AB9.74FE8BF2@napster.com>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date:   Mon, 06 Nov 2000 19:44:57 -0800
   From: Jordan Mendelson <jordy@napster.com>

   Just some updates. This problem does not appear to happen under
   2.2.16.  The dump for 2.2.16 is almost the same except we send an
   mss back of 536 and not 1460 (remote mtu vs local mtu).

MSS advertized makes no difference, it controls not what sized
payloads we send, which is determined in this case by PMTU and thus
both Linux 2.2.x and 2.4.x send equally sized limited packets.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Mon Nov  6 22:27:57 2000
Received:  by oss.sgi.com id <S553908AbQKGG1q>;
	Mon, 6 Nov 2000 22:27:46 -0800
Received: from pizda.ninka.net ([216.101.162.242]:14210 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S553900AbQKGG1T>;
	Mon, 6 Nov 2000 22:27:19 -0800
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id WAA02326;
	Mon, 6 Nov 2000 22:12:44 -0800
Date:   Mon, 6 Nov 2000 22:12:44 -0800
Message-Id: <200011070612.WAA02326@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     ak@suse.de
CC:     kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com
In-reply-to: <20001106220115.A26879@gruyere.muc.suse.de> (message from Andi
	Kleen on Mon, 6 Nov 2000 22:01:15 +0100)
Subject: Re: Karn's rule in Linux TCP
References:  <20001106220115.A26879@gruyere.muc.suse.de>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date: Mon, 6 Nov 2000 22:01:15 +0100
   From: Andi Kleen <ak@suse.de>

   So one way to solve it would be to turn off the Karn filter after a few
   retransmits in tcp_ack_no_tstamp().  The hard to tune thing is how many
   retransmits it should wait. It depends what are good practical
   upper boundaries for packet live times in the real internet.

If you spent some time implementing this and trying to tune
it, I would accept such a patch.

   Any suggestions on that?  Any other ideas? 

This is certainly tcp-impl (or end2end, but not both) material, please
Andi discuss your findings on one of those two lists, I bet you will
get a precise response from those in the know :-)

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Tue Nov  7 01:05:57 2000
Received:  by oss.sgi.com id <S553923AbQKGJFr>;
	Tue, 7 Nov 2000 01:05:47 -0800
Received: from isis.its.uow.edu.au ([130.130.68.21]:64149 "EHLO
        isis.its.uow.edu.au") by oss.sgi.com with ESMTP id <S553907AbQKGJFd>;
	Tue, 7 Nov 2000 01:05:33 -0800
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by isis.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id UAA17802;
	Tue, 7 Nov 2000 20:05:19 +1100 (EST)
Message-ID: <3A07C5DF.1CACF511@uow.edu.au>
Date:   Tue, 07 Nov 2000 20:05:35 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     davej@suse.de
CC:     "netdev@oss.sgi.com" <netdev@oss.sgi.com>,
        Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: Strange accept() behaviour in 2.2
References: <3A06C552.4062884C@uow.edu.au> <Pine.LNX.4.21.0011061702410.18587-100000@neo.local>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

davej@suse.de wrote:
> 
> On Tue, 7 Nov 2000, Andrew Morton wrote:
> 
> > processor       : 0
> > vendor_id       : GenuineIntel
> > cpu family      : 6
> > model           : 5
> > model name      : Celeron (Covington)
> > stepping        : 1
> > cpu MHz         : 400.000920
> > cache size      : 0 KB                                /* huh? */
> 
> Original Celeron's were cacheless. You either have one of these,
> or you have your cache switched off in the BIOS.

As an experiment I went into BIOS and selected "Internal
cache: Disabled" and it then took about 30 seconds to
uncompress the kernel. It normally takes ~1 second.

I guess American Megatrends think that "Internal Cache"
is an appropriate name for an offboard L2. Shrug.

Surprising amount of difference for an offboard cache
though.

From owner-netdev@oss.sgi.com Tue Nov  7 14:47:22 2000
Received:  by oss.sgi.com id <S553767AbQKGWrC>;
	Tue, 7 Nov 2000 14:47:02 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:36104 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S553764AbQKGWqr>;
	Tue, 7 Nov 2000 14:46:47 -0800
Received: from mandrakesoft.com (adsl-20-73-115.asm.bellsouth.net [66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id RAA17746;
	Tue, 7 Nov 2000 17:46:01 -0500
Message-ID: <3A08862A.CF5D146A@mandrakesoft.com>
Date:   Tue, 07 Nov 2000 17:46:02 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18pre18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Paul Gortmaker <p_gortmaker@yahoo.com>
CC:     linux-net@vger.kernel.org, netdev@oss.sgi.com, becker@scyld.com
Subject: Re: MMIO ne2k-pci? (was Re: [patch] NE2000)
References: <Pine.LNX.4.21.0011041353040.10339-100000@pnd-pc.demon.co.uk> <3A0680A3.6CC44E7E@mandrakesoft.com> <3A070B6F.1481CC5F@yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Paul Gortmaker wrote:
> 
> Jeff Garzik wrote:
> 
> > On another topic completely, I want to start moving drivers over to
> > doing MMIO instead of PIO, where possibly, in 2.5.x.  I am pretty sure
> > some if not most PCI NE2K clones can do MMIO.  Any known NE2K MMIO
> > bugs?   [again, this is 2.5.x material, so its not around the corner]
> 
> I imagine this is one of those "dont know until you try it" type deals.
> I'd be disappointed if at least one of the clones didn't break in some
> mysterious and unexplainable way. ;-)  IIRC, Donald recently mentioned
> something about one of the el-cheapo chipsets (not ne2k-pci) doing
> something strange when using MMIO - but I can't find the message now...

No doubt :)  The weird wacky and wonderful world of PC hardware.


> You wouldn't be able to share an 8390.o anymore - I guess you would
> have to play the usual #undef games with inb etc. at the top of 8390.c
> then compile with -DUSE_MMIO and then bundle 8390.o with ne2k-pci.o

For the core module, I would prefer to do what pcnet_cs does -- provide
both PIO and MMIO support in the same binary.  We can then have each
module do the standard -DUSE_MMIO thing, without having to worry about
conditional linking, or conditional compilation of an outside module.

(note - the above paragraph assumes that the ne logic can be split
cleanly into a separate ne_core.c...)


> Have to keep in mind that PCI ne2k clones still have an 8390 at their
> core - an SMP unfriendly chunk of history that is similar in vintage
> to other long forgotten relics like the 3c501.  Given the above, is it
> really worth the grief of going MMIO?   [Anyone that intentionally buys
> one of these for a SMP box or a server deserves a boot to the head IMHO]

MMIO does give you a bit of a performance boost, even if it is only to
card registers...  I think mmio reads/writes are lighter weight even on
the older 386's and 486's too.

	Jeff


-- 
Jeff Garzik             | "When I do this, my computer freezes."
Building 1024           |          -user
MandrakeSoft            | "Don't do that."
                        |          -level 1

From owner-netdev@oss.sgi.com Tue Nov  7 15:35:22 2000
Received:  by oss.sgi.com id <S553787AbQKGXfN>;
	Tue, 7 Nov 2000 15:35:13 -0800
Received: from test.inspired.net.au ([216.122.33.55]:39401 "EHLO
        test.inspired.net.au") by oss.sgi.com with ESMTP id <S553771AbQKGXeu>;
	Tue, 7 Nov 2000 15:34:50 -0800
Received: from inspired.net.au (inspired.net.au [203.58.81.130])
	by test.inspired.net.au (8.9.3/8.9.3) with ESMTP id XAA04669;
	Tue, 7 Nov 2000 23:34:38 GMT
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id KAA02009;
	Wed, 8 Nov 2000 10:34:32 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda02002; Tue Nov  7 23:34:31 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id KAA28509;
	Wed, 8 Nov 2000 10:34:30 +1100
Received: from dialup03.syd.inspired.net.au(202.76.141.202), claiming to be "mechtron.com.au"
 via SMTP by thucydides-eth1.inspired.net.au, id smtpda28223; Tue Nov  7 23:34:20 2000
Received: from Spooler by mechtron.com.au (Mercury/32 v3.01a) ID MO000738;
  8 Nov 00 10:35:23 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:31:41 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2) by mechtron.com.au (Mercury/32 v3.01a) with ESMTP ID MG000723;
   8 Nov 00 10:31:34 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2 [10.0.0.2]) by sydservernt1.ADVSECSYD with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id VGDLBHPM; Wed, 8 Nov 2000 10:33:08 +1100
Received: by sydservernt1.ADVSECSYD (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download)
	 id MSG11082000-103105-1841.MMD@ADVSECSYD; Wed, 8 Nov 2000 10:31:05 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:28:23 +1100
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id HAA28060
	for <pat@rallypro.com.au>; Tue, 7 Nov 2000 07:24:42 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda28055; Mon Nov  6 20:24:32 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id HAA16540
	for <pat@rallypro.com.au>; Tue, 7 Nov 2000 07:24:32 +1100
Received: from vger.kernel.org(199.183.24.194)
 via SMTP by thucydides-eth0-6.inspired.net.au, id smtpda16535; Mon Nov  6 20:24:29 2000
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S129272AbQKFUXo>; Mon, 6 Nov 2000 15:23:44 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S129580AbQKFUXf>; Mon, 6 Nov 2000 15:23:35 -0500
Received: from smtp3.mail.yahoo.com ([128.11.68.135]:60425 "HELO
	smtp1b.mail.yahoo.com") by vger.kernel.org with SMTP
	id <S129272AbQKFUX2>; Mon, 6 Nov 2000 15:23:28 -0500
Received: from ppp068.muskoka.com (HELO gromit.hairy.org) (199.212.175.98)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 6 Nov 2000 20:23:24 -0000
X-Apparently-From: <p?gortmaker@yahoo.com>
Message-ID: <3A06F281.73D6AF2@yahoo.com>
Date: 	Mon, 06 Nov 2000 13:03:45 -0500
From:   Paul Gortmaker <p_gortmaker@yahoo.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.18pre18 i486)
MIME-Version: 1.0
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
CC:     Donald Becker <becker@scyld.com>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: dev->name in /proc/ioports (was: Re: [patch] NE2000)
References: <Pine.LNX.4.10.10011021935530.11540-100000@vaio.greennet> <3A020C19.4C4B3F66@mandrakesoft.com> <3A0663E1.35A49246@yahoo.com> <3A067F15.2E474B36@mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: 	linux-net@vger.kernel.org
X-UIDL: nO)!!M4@!!R!@e9g=%e9
Status: U
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Jeff Garzik wrote:
> 
> Paul Gortmaker wrote:
> > But the only reliable way to query the kernel as to what compiled in ISA
                 ^^^^^^^^
> > net driver is installed is by a model name in /proc/[ioports,interrupts]
> > (Yes, I know, a minor issue...)
> 
> I always use 'dmesg' for this...

It isn't reliable - some installs did a "dmesg -c" at boot IIRC, or the
ring buf may have already wrapped with crud like VFS disk change
messages.

> > Also, the trend for /proc/ioports (and interrupts) in other parts of the
> > kernel still appears to be based on hardware/model names and not kernel
> > device names, e.g. serial and not ttyS*, BusLogic BT-XXX and not scsi0,
> > soundblaster and not /dev/audio, etc. -- hence 3c509 and not eth0 would
> > be consistent?
> 
> Especially for interrupts, it would be much smarter for the other
> devices to indicate their device, since that allows you to differentiate
> between adapters of the same type.

Ok - I still think consistency is a worthwhile goal.  So I guess we 
(in 2.5.x) will have to extend the scope of settling on the device name 
outside of drivers/net (assuming nobody else has sufficient reasons to 
stick with model names instead).

Paul.



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org



From owner-netdev@oss.sgi.com Tue Nov  7 15:35:42 2000
Received:  by oss.sgi.com id <S553805AbQKGXfW>;
	Tue, 7 Nov 2000 15:35:22 -0800
Received: from test.inspired.net.au ([216.122.33.55]:44009 "EHLO
        test.inspired.net.au") by oss.sgi.com with ESMTP id <S553786AbQKGXfH>;
	Tue, 7 Nov 2000 15:35:07 -0800
Received: from inspired.net.au (inspired.net.au [203.58.81.130])
	by test.inspired.net.au (8.9.3/8.9.3) with ESMTP id XAA04786;
	Tue, 7 Nov 2000 23:34:59 GMT
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id KAA02029;
	Wed, 8 Nov 2000 10:34:52 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda02020; Tue Nov  7 23:34:42 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id KAA28524;
	Wed, 8 Nov 2000 10:34:42 +1100
Received: from dialup03.syd.inspired.net.au(202.76.141.202), claiming to be "mechtron.com.au"
 via SMTP by thucydides-eth1.inspired.net.au, id smtpda28223; Tue Nov  7 23:34:34 2000
Received: from Spooler by mechtron.com.au (Mercury/32 v3.01a) ID MO005752;
  8 Nov 00 10:35:37 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:31:39 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2) by mechtron.com.au (Mercury/32 v3.01a) with ESMTP ID MG000002;
   8 Nov 00 10:31:10 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2 [10.0.0.2]) by sydservernt1.ADVSECSYD with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id VGDLBHMZ; Wed, 8 Nov 2000 10:32:44 +1100
Received: by sydservernt1.ADVSECSYD (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download)
	 id MSG11082000-103046-1784.MMD@ADVSECSYD; Wed, 8 Nov 2000 10:30:46 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:28:28 +1100
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id TAA15103
	for <pat@rallypro.com.au>; Mon, 6 Nov 2000 19:10:22 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda15101; Mon Nov  6 08:10:13 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id TAA10223
	for <pat@rallypro.com.au>; Mon, 6 Nov 2000 19:10:17 +1100
Received: from vger.kernel.org(199.183.24.194)
 via SMTP by thucydides-eth0-6.inspired.net.au, id smtpda10179; Mon Nov  6 08:10:08 2000
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S130330AbQKFIG6>; Mon, 6 Nov 2000 03:06:58 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S130305AbQKFIGh>; Mon, 6 Nov 2000 03:06:37 -0500
Received: from smtp2.mail.yahoo.com ([128.11.68.32]:39952 "HELO
	smtp2.mail.yahoo.com") by vger.kernel.org with SMTP
	id <S130307AbQKFIGb>; Mon, 6 Nov 2000 03:06:31 -0500
Received: from ppp119.muskoka.com (HELO gromit.hairy.org) (199.212.175.149)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 6 Nov 2000 08:06:28 -0000
X-Apparently-From: <p?gortmaker@yahoo.com>
Message-ID: <3A0663E1.35A49246@yahoo.com>
Date: 	Mon, 06 Nov 2000 02:55:13 -0500
From:   Paul Gortmaker <p_gortmaker@yahoo.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.17 i486)
MIME-Version: 1.0
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
CC:     Donald Becker <becker@scyld.com>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: dev->name in /proc/ioports (was: Re: [patch] NE2000)
References: <Pine.LNX.4.10.10011021935530.11540-100000@vaio.greennet> <3A020C19.4C4B3F66@mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: 	linux-net@vger.kernel.org
X-UIDL: e*Qd9@V^!!C3md9/*I!!
Status: U
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Jeff Garzik wrote:
> 
> Donald Becker wrote:
> > Most people with multiple network adapters use the same board type.  Seeing
> > a list of identical board names isn't very useful when you are trying to do
> > something like map interrupt counts to interface statistics.
> 
> You're talking about request_irq not request_region here, and
> /proc/ioports isn't as "actively useful" as /proc/interrupts.
> 
> But you do have a point -- It sounds more informative to have dev->name
> in /proc/ioports for the multiple ISA adapters case as well.  Seeing
> "3c509" twice in /proc/ioports is not as informative (IMHO) as knowing
> that eth0 is at 0x300 and eth1 is at 0x320.  Further, using dev->name in
> request_region means that we have consistency with request_irq usage.

Something to consider (while still restricting this discussion to ISA
junk), you can always get ethN <---> irq/ioport mapping via. SIOCGIFMAP.
But the only reliable way to query the kernel as to what compiled in ISA
net driver is installed is by a model name in /proc/[ioports,interrupts]
(Yes, I know, a minor issue...)

Also, the trend for /proc/ioports (and interrupts) in other parts of the
kernel still appears to be based on hardware/model names and not kernel
device names, e.g. serial and not ttyS*, BusLogic BT-XXX and not scsi0,
soundblaster and not /dev/audio, etc. -- hence 3c509 and not eth0 would
be consistent?

> The only downside to using dev->name is that some drivers currently
> touch the hardware before they have an interface name, but that is not a
> real problem at all.

Yes, not a problem  - these can be handled with something like:

 struct resource *r;
 if ((r = request_region(..., "foo-probe")) == NULL) return -EBUSY;
 ret = foo_probe(...);
 if (ret != 0) release_resource(r);
 else r->name = dev->name;
 return ret;

Paul.


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org



From owner-netdev@oss.sgi.com Tue Nov  7 15:35:42 2000
Received:  by oss.sgi.com id <S553772AbQKGXfW>;
	Tue, 7 Nov 2000 15:35:22 -0800
Received: from test.inspired.net.au ([216.122.33.55]:43497 "EHLO
        test.inspired.net.au") by oss.sgi.com with ESMTP id <S553774AbQKGXfH>;
	Tue, 7 Nov 2000 15:35:07 -0800
Received: from inspired.net.au (inspired.net.au [203.58.81.130])
	by test.inspired.net.au (8.9.3/8.9.3) with ESMTP id XAA04784;
	Tue, 7 Nov 2000 23:34:58 GMT
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id KAA02030;
	Wed, 8 Nov 2000 10:34:52 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda02021; Tue Nov  7 23:34:43 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id KAA28525;
	Wed, 8 Nov 2000 10:34:42 +1100
Received: from dialup03.syd.inspired.net.au(202.76.141.202), claiming to be "mechtron.com.au"
 via SMTP by thucydides-eth1.inspired.net.au, id smtpdb28223; Tue Nov  7 23:34:38 2000
Received: from Spooler by mechtron.com.au (Mercury/32 v3.01a) ID MO005753;
  8 Nov 00 10:35:41 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:31:39 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2) by mechtron.com.au (Mercury/32 v3.01a) with ESMTP ID MG000003;
   8 Nov 00 10:31:12 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2 [10.0.0.2]) by sydservernt1.ADVSECSYD with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id VGDLBHM9; Wed, 8 Nov 2000 10:32:45 +1100
Received: by sydservernt1.ADVSECSYD (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download)
	 id MSG11082000-103046-1788.MMD@ADVSECSYD; Wed, 8 Nov 2000 10:30:46 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:28:34 +1100
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id HAA28068
	for <pat@rallypro.com.au>; Tue, 7 Nov 2000 07:24:51 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda28066; Mon Nov  6 20:24:43 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id HAA16548
	for <pat@rallypro.com.au>; Tue, 7 Nov 2000 07:24:43 +1100
Received: from vger.kernel.org(199.183.24.194)
 via SMTP by thucydides-eth0-6.inspired.net.au, id smtpda16535; Mon Nov  6 20:24:33 2000
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S129580AbQKFUYF>; Mon, 6 Nov 2000 15:24:05 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S129758AbQKFUXz>; Mon, 6 Nov 2000 15:23:55 -0500
Received: from smtp3.mail.yahoo.com ([128.11.68.135]:25866 "HELO
	smtp1b.mail.yahoo.com") by vger.kernel.org with SMTP
	id <S129580AbQKFUXt>; Mon, 6 Nov 2000 15:23:49 -0500
Received: from ppp068.muskoka.com (HELO gromit.hairy.org) (199.212.175.98)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 6 Nov 2000 20:23:41 -0000
X-Apparently-From: <p?gortmaker@yahoo.com>
Message-ID: <3A070B6F.1481CC5F@yahoo.com>
Date: 	Mon, 06 Nov 2000 14:50:07 -0500
From:   Paul Gortmaker <p_gortmaker@yahoo.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.18pre18 i486)
MIME-Version: 1.0
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
CC:     linux-net@vger.kernel.org, netdev@oss.sgi.com, becker@scyld.com
Subject: Re: MMIO ne2k-pci? (was Re: [patch] NE2000)
References: <Pine.LNX.4.21.0011041353040.10339-100000@pnd-pc.demon.co.uk> <3A0680A3.6CC44E7E@mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: 	linux-net@vger.kernel.org
X-UIDL: __[d9eVTd9*KYd9G4c!!
Status: U
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Jeff Garzik wrote:

> On another topic completely, I want to start moving drivers over to
> doing MMIO instead of PIO, where possibly, in 2.5.x.  I am pretty sure
> some if not most PCI NE2K clones can do MMIO.  Any known NE2K MMIO
> bugs?   [again, this is 2.5.x material, so its not around the corner]

I imagine this is one of those "dont know until you try it" type deals.
I'd be disappointed if at least one of the clones didn't break in some
mysterious and unexplainable way. ;-)  IIRC, Donald recently mentioned
something about one of the el-cheapo chipsets (not ne2k-pci) doing 
something strange when using MMIO - but I can't find the message now...

You wouldn't be able to share an 8390.o anymore - I guess you would
have to play the usual #undef games with inb etc. at the top of 8390.c 
then compile with -DUSE_MMIO and then bundle 8390.o with ne2k-pci.o

Have to keep in mind that PCI ne2k clones still have an 8390 at their
core - an SMP unfriendly chunk of history that is similar in vintage 
to other long forgotten relics like the 3c501.  Given the above, is it
really worth the grief of going MMIO?   [Anyone that intentionally buys
one of these for a SMP box or a server deserves a boot to the head IMHO]

Paul.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org



From owner-netdev@oss.sgi.com Tue Nov  7 15:36:12 2000
Received:  by oss.sgi.com id <S554012AbQKGXfw>;
	Tue, 7 Nov 2000 15:35:52 -0800
Received: from test.inspired.net.au ([216.122.33.55]:51177 "EHLO
        test.inspired.net.au") by oss.sgi.com with ESMTP id <S553771AbQKGXfs>;
	Tue, 7 Nov 2000 15:35:48 -0800
Received: from inspired.net.au (inspired.net.au [203.58.81.130])
	by test.inspired.net.au (8.9.3/8.9.3) with ESMTP id XAA04872;
	Tue, 7 Nov 2000 23:35:23 GMT
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id KAA02060;
	Wed, 8 Nov 2000 10:35:13 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda02049; Tue Nov  7 23:35:06 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id KAA28614;
	Wed, 8 Nov 2000 10:35:04 +1100
Received: from dialup03.syd.inspired.net.au(202.76.141.202), claiming to be "mechtron.com.au"
 via SMTP by thucydides-eth1.inspired.net.au, id smtpda28223; Tue Nov  7 23:34:58 2000
Received: from Spooler by mechtron.com.au (Mercury/32 v3.01a) ID MO005757;
  8 Nov 00 10:36:01 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:31:39 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2) by mechtron.com.au (Mercury/32 v3.01a) with ESMTP ID MG000007;
   8 Nov 00 10:31:13 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2 [10.0.0.2]) by sydservernt1.ADVSECSYD with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id VGDLBHNB; Wed, 8 Nov 2000 10:32:46 +1100
Received: by sydservernt1.ADVSECSYD (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download)
	 id MSG11082000-103047-1790.MMD@ADVSECSYD; Wed, 8 Nov 2000 10:30:47 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:28:34 +1100
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id TAA15096
	for <pat@rallypro.com.au>; Mon, 6 Nov 2000 19:10:12 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda15093; Mon Nov  6 08:10:03 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id TAA10217
	for <pat@rallypro.com.au>; Mon, 6 Nov 2000 19:10:07 +1100
Received: from vger.kernel.org(199.183.24.194)
 via SMTP by thucydides-eth0-6.inspired.net.au, id smtpda10179; Mon Nov  6 08:09:58 2000
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S130311AbQKFIGg>; Mon, 6 Nov 2000 03:06:36 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S130304AbQKFIGZ>; Mon, 6 Nov 2000 03:06:25 -0500
Received: from smtp1.mail.yahoo.com ([128.11.69.60]:55566 "HELO
	smtp1.mail.yahoo.com") by vger.kernel.org with SMTP
	id <S130289AbQKFIGU>; Mon, 6 Nov 2000 03:06:20 -0500
Received: from ppp119.muskoka.com (HELO gromit.hairy.org) (199.212.175.149)
  by smtp.mail.vip.suc.yahoo.com with SMTP; 6 Nov 2000 08:06:17 -0000
X-Apparently-From: <p?gortmaker@yahoo.com>
Message-ID: <3A0651AB.357DD5B4@yahoo.com>
Date: 	Mon, 06 Nov 2000 01:37:31 -0500
From:   Paul Gortmaker <p_gortmaker@yahoo.com>
X-Mailer: Mozilla 3.04 (X11; I; Linux 2.2.17 i486)
MIME-Version: 1.0
To:     Peter Denison <peterd@pnd-pc.demon.co.uk>
CC:     Jeff Garzik <jgarzik@mandrakesoft.com>,
        pavel rabel <pavel@web.sajt.cz>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.21.0011041353040.10339-100000@pnd-pc.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: 	linux-net@vger.kernel.org
X-UIDL: Vf~!!5MOd9,a%e98)C!!
Status: U
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Peter Denison wrote:
> 
> On Mon, 30 Oct 2000, Paul Gortmaker wrote:
> 
> > Other 8390 patches I have
> > are a separated Tx timeout for 8390.c, kill off dev->rmem_start/end
> > and use ioremap() where required, and replace old check/request_region()
> > with code that makes use of the newer resource structures. ]
> 
>         I'd thought it was quite important to get drivers doing
> ioremap() properly before 2.4.0, since the whinging messages along the
> lines of " ..." are only really going to be
> tolerated in a development kernel, and will look a bit shoddy in 2.4.0.

The ioremap patch I did for 8390 based cards was circa Dec 1999, and the
impression I got at the time was that the isa_xxx stuff was good enough
for 2.4.0 - the cleanup could wait until 2.5.x - and so I shelved it.
I may dust it off and merge the EISA part of it since isa_xxx in
an EISA driver looks kind of silly though.

>         The complaining has been there for quite a while, so we really
> should have got our finger out and done the ioremap() thing (or at least
> used isa_xxx functions) where needed. I agree, however, that thinking
> seriously hard before delaying 2.4.0 now is a Good Thing (TM).

If you have some reports of drivers still causing "io mapaddr 0x?????
not valid" then please share them - in particular at least the driver
name.

Thanks,
Paul.



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org



From owner-netdev@oss.sgi.com Tue Nov  7 15:37:02 2000
Received:  by oss.sgi.com id <S554007AbQKGXgm>;
	Tue, 7 Nov 2000 15:36:42 -0800
Received: from test.inspired.net.au ([216.122.33.55]:57065 "EHLO
        test.inspired.net.au") by oss.sgi.com with ESMTP id <S554064AbQKGXgX>;
	Tue, 7 Nov 2000 15:36:23 -0800
Received: from inspired.net.au (inspired.net.au [203.58.81.130])
	by test.inspired.net.au (8.9.3/8.9.3) with ESMTP id XAA04925;
	Tue, 7 Nov 2000 23:35:39 GMT
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id KAA02084;
	Wed, 8 Nov 2000 10:35:32 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda02080; Tue Nov  7 23:35:29 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id KAA28644;
	Wed, 8 Nov 2000 10:35:29 +1100
Received: from dialup03.syd.inspired.net.au(202.76.141.202), claiming to be "mechtron.com.au"
 via SMTP by thucydides-eth1.inspired.net.au, id smtpdb28223; Tue Nov  7 23:35:24 2000
Received: from Spooler by mechtron.com.au (Mercury/32 v3.01a) ID MO005761;
  8 Nov 00 10:36:27 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:31:39 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2) by mechtron.com.au (Mercury/32 v3.01a) with ESMTP ID MG000705;
   8 Nov 00 10:31:16 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2 [10.0.0.2]) by sydservernt1.ADVSECSYD with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id VGDLBHNT; Wed, 8 Nov 2000 10:32:51 +1100
Received: by sydservernt1.ADVSECSYD (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download)
	 id MSG11082000-103049-1801.MMD@ADVSECSYD; Wed, 8 Nov 2000 10:30:49 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:28:23 +1100
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id JAA32630
	for <pat@rallypro.com.au>; Wed, 8 Nov 2000 09:48:32 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda32628; Tue Nov  7 22:48:27 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id JAA23456
	for <pat@rallypro.com.au>; Wed, 8 Nov 2000 09:48:28 +1100
Received: from vger.kernel.org(199.183.24.194)
 via SMTP by thucydides-eth0-6.inspired.net.au, id smtpda23449; Tue Nov  7 22:48:14 2000
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S130155AbQKGWqy>; Tue, 7 Nov 2000 17:46:54 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S130202AbQKGWqr>; Tue, 7 Nov 2000 17:46:47 -0500
Received: from panic.ohr.gatech.edu ([130.207.47.194]:35848 "EHLO
	havoc.gtf.org") by vger.kernel.org with ESMTP id <S130155AbQKGWqg>;
	Tue, 7 Nov 2000 17:46:36 -0500
Received: from mandrakesoft.com (adsl-20-73-115.asm.bellsouth.net [66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id RAA17746;
	Tue, 7 Nov 2000 17:46:01 -0500
Message-ID: <3A08862A.CF5D146A@mandrakesoft.com>
Date: 	Tue, 07 Nov 2000 17:46:02 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18pre18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Paul Gortmaker <p_gortmaker@yahoo.com>
CC:     linux-net@vger.kernel.org, netdev@oss.sgi.com, becker@scyld.com
Subject: Re: MMIO ne2k-pci? (was Re: [patch] NE2000)
References: <Pine.LNX.4.21.0011041353040.10339-100000@pnd-pc.demon.co.uk> <3A0680A3.6CC44E7E@mandrakesoft.com> <3A070B6F.1481CC5F@yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: 	linux-net@vger.kernel.org
X-UIDL: LbW!!<V4e9R+I!!:X\!!
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Paul Gortmaker wrote:
> 
> Jeff Garzik wrote:
> 
> > On another topic completely, I want to start moving drivers over to
> > doing MMIO instead of PIO, where possibly, in 2.5.x.  I am pretty sure
> > some if not most PCI NE2K clones can do MMIO.  Any known NE2K MMIO
> > bugs?   [again, this is 2.5.x material, so its not around the corner]
> 
> I imagine this is one of those "dont know until you try it" type deals.
> I'd be disappointed if at least one of the clones didn't break in some
> mysterious and unexplainable way. ;-)  IIRC, Donald recently mentioned
> something about one of the el-cheapo chipsets (not ne2k-pci) doing
> something strange when using MMIO - but I can't find the message now...

No doubt :)  The weird wacky and wonderful world of PC hardware.


> You wouldn't be able to share an 8390.o anymore - I guess you would
> have to play the usual #undef games with inb etc. at the top of 8390.c
> then compile with -DUSE_MMIO and then bundle 8390.o with ne2k-pci.o

For the core module, I would prefer to do what pcnet_cs does -- provide
both PIO and MMIO support in the same binary.  We can then have each
module do the standard -DUSE_MMIO thing, without having to worry about
conditional linking, or conditional compilation of an outside module.

(note - the above paragraph assumes that the ne logic can be split
cleanly into a separate ne_core.c...)


> Have to keep in mind that PCI ne2k clones still have an 8390 at their
> core - an SMP unfriendly chunk of history that is similar in vintage
> to other long forgotten relics like the 3c501.  Given the above, is it
> really worth the grief of going MMIO?   [Anyone that intentionally buys
> one of these for a SMP box or a server deserves a boot to the head IMHO]

MMIO does give you a bit of a performance boost, even if it is only to
card registers...  I think mmio reads/writes are lighter weight even on
the older 386's and 486's too.

	Jeff


-- 
Jeff Garzik             | "When I do this, my computer freezes."
Building 1024           |          -user
MandrakeSoft            | "Don't do that."
                        |          -level 1
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org



From owner-netdev@oss.sgi.com Tue Nov  7 15:37:32 2000
Received:  by oss.sgi.com id <S554344AbQKGXhM>;
	Tue, 7 Nov 2000 15:37:12 -0800
Received: from test.inspired.net.au ([216.122.33.55]:2794 "EHLO
        test.inspired.net.au") by oss.sgi.com with ESMTP id <S554292AbQKGXhE>;
	Tue, 7 Nov 2000 15:37:04 -0800
Received: from inspired.net.au (inspired.net.au [203.58.81.130])
	by test.inspired.net.au (8.9.3/8.9.3) with ESMTP id XAA04871;
	Tue, 7 Nov 2000 23:35:23 GMT
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id KAA02061;
	Wed, 8 Nov 2000 10:35:13 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda02050; Tue Nov  7 23:35:07 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id KAA28619;
	Wed, 8 Nov 2000 10:35:06 +1100
Received: from dialup03.syd.inspired.net.au(202.76.141.202), claiming to be "mechtron.com.au"
 via SMTP by thucydides-eth1.inspired.net.au, id smtpdb28223; Tue Nov  7 23:34:53 2000
Received: from Spooler by mechtron.com.au (Mercury/32 v3.01a) ID MO005756;
  8 Nov 00 10:35:57 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:31:39 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2) by mechtron.com.au (Mercury/32 v3.01a) with ESMTP ID MG000006;
   8 Nov 00 10:31:12 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2 [10.0.0.2]) by sydservernt1.ADVSECSYD with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id VGDLBHNC; Wed, 8 Nov 2000 10:32:46 +1100
Received: by sydservernt1.ADVSECSYD (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download)
	 id MSG11082000-103047-1791.MMD@ADVSECSYD; Wed, 8 Nov 2000 10:30:47 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:28:33 +1100
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id UAA17076
	for <pat@rallypro.com.au>; Mon, 6 Nov 2000 20:59:02 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda17071; Mon Nov  6 09:59:01 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id UAA16342
	for <pat@rallypro.com.au>; Mon, 6 Nov 2000 20:59:06 +1100
Received: from vger.kernel.org(199.183.24.194)
 via SMTP by thucydides-eth0-6.inspired.net.au, id smtpdb16283; Mon Nov  6 09:58:55 2000
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S129094AbQKFJ6g>; Mon, 6 Nov 2000 04:58:36 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S129145AbQKFJ60>; Mon, 6 Nov 2000 04:58:26 -0500
Received: from panic.ohr.gatech.edu ([130.207.47.194]:49162 "EHLO
	havoc.gtf.org") by vger.kernel.org with ESMTP id <S129094AbQKFJ6N>;
	Mon, 6 Nov 2000 04:58:13 -0500
Received: from mandrakesoft.com ([66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id EAA02554;
	Mon, 6 Nov 2000 04:57:55 -0500
Message-ID: <3A0680A3.6CC44E7E@mandrakesoft.com>
Date: 	Mon, 06 Nov 2000 04:57:55 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Peter Denison <peterd@pnd-pc.demon.co.uk>
CC:     Paul Gortmaker <p_gortmaker@yahoo.com>,
        pavel rabel <pavel@web.sajt.cz>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: [patch] NE2000
References: <Pine.LNX.4.21.0011041353040.10339-100000@pnd-pc.demon.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: 	linux-net@vger.kernel.org
X-UIDL: D4j!!m+Ne98f?!!A-+!!
Status: U
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Peter Denison wrote:
> 
> On Mon, 30 Oct 2000, Paul Gortmaker wrote:
> 
> [snip discussion about removing PCI code from ne.c]
> 
> > [ I've several other 8390 related patches I've been sitting on - trying
> > to not contribute to the delay of 2.4.0 unless explicitly asked, such
> > as the 8390.h get_module_symbol deletion.  Other 8390 patches I have
> > are a separated Tx timeout for 8390.c, kill off dev->rmem_start/end
> > and use ioremap() where required, and replace old check/request_region()
> > with code that makes use of the newer resource structures. ]
> 
>         I'd thought it was quite important to get drivers doing
> ioremap() properly before 2.4.0, since the whinging messages along the
> lines of "io mapaddr 0x????? not valid at ..." are only really going to be
> tolerated in a development kernel, and will look a bit shoddy in 2.4.0.
>         The complaining has been there for quite a while, so we really
> should have got our finger out and done the ioremap() thing (or at least
> used isa_xxx functions) where needed. I agree, however, that thinking
> seriously hard before delaying 2.4.0 now is a Good Thing (TM).

I think isa_ioremap is good enough for 2.4.x... If the driver works, I
don't want to touch it.  But if you are in there touching the code
anyway, and doing testing anyway, you might as well fix it to do ioremap
correctly...

On another topic completely, I want to start moving drivers over to
doing MMIO instead of PIO, where possibly, in 2.5.x.  I am pretty sure
some if not most PCI NE2K clones can do MMIO.  Any known NE2K MMIO
bugs?   [again, this is 2.5.x material, so its not around the corner]

	Jeff


-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org



From owner-netdev@oss.sgi.com Tue Nov  7 15:38:12 2000
Received:  by oss.sgi.com id <S554171AbQKGXiC>;
	Tue, 7 Nov 2000 15:38:02 -0800
Received: from test.inspired.net.au ([216.122.33.55]:6634 "EHLO
        test.inspired.net.au") by oss.sgi.com with ESMTP id <S554192AbQKGXhm>;
	Tue, 7 Nov 2000 15:37:42 -0800
Received: from inspired.net.au (inspired.net.au [203.58.81.130])
	by test.inspired.net.au (8.9.3/8.9.3) with ESMTP id XAA04827;
	Tue, 7 Nov 2000 23:35:07 GMT
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id KAA02045;
	Wed, 8 Nov 2000 10:35:02 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda02038; Tue Nov  7 23:34:54 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id KAA28535;
	Wed, 8 Nov 2000 10:34:54 +1100
Received: from dialup03.syd.inspired.net.au(202.76.141.202), claiming to be "mechtron.com.au"
 via SMTP by thucydides-eth1.inspired.net.au, id smtpda28223; Tue Nov  7 23:34:47 2000
Received: from Spooler by mechtron.com.au (Mercury/32 v3.01a) ID MO005755;
  8 Nov 00 10:35:51 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:31:39 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2) by mechtron.com.au (Mercury/32 v3.01a) with ESMTP ID MG000005;
   8 Nov 00 10:31:12 +1100
Received: from sydservernt1.ADVSECSYD (10.0.0.2 [10.0.0.2]) by sydservernt1.ADVSECSYD with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id VGDLBHND; Wed, 8 Nov 2000 10:32:47 +1100
Received: by sydservernt1.ADVSECSYD (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download)
	 id MSG11082000-103047-1792.MMD@ADVSECSYD; Wed, 8 Nov 2000 10:30:47 +1100
Received: from spooler by mechtron.com.au (Mercury/32 v3.01a); 8 Nov 00 10:28:34 +1100
Received: (from uucp@localhost)
	by inspired.net.au (8.8.7/8.8.7) id UAA16958
	for <pat@rallypro.com.au>; Mon, 6 Nov 2000 20:53:02 +1100
Received: from thucydides-eth0-6.inspired.net.au(210.9.63.165), claiming to be "thucydides.inspired.net.au"
 via SMTP by mail.inspired.net.au, id smtpda16953; Mon Nov  6 09:52:58 2000
Received: (from uucp@localhost)
	by thucydides.inspired.net.au (8.9.1/8.9.1) id UAA15994
	for <pat@rallypro.com.au>; Mon, 6 Nov 2000 20:53:03 +1100
Received: from vger.kernel.org(199.183.24.194)
 via SMTP by thucydides-eth0-6.inspired.net.au, id smtpda15956; Mon Nov  6 09:52:55 2000
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S129079AbQKFJwQ>; Mon, 6 Nov 2000 04:52:16 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S129109AbQKFJwG>; Mon, 6 Nov 2000 04:52:06 -0500
Received: from panic.ohr.gatech.edu ([130.207.47.194]:41994 "EHLO
	havoc.gtf.org") by vger.kernel.org with ESMTP id <S129079AbQKFJv6>;
	Mon, 6 Nov 2000 04:51:58 -0500
Received: from mandrakesoft.com ([66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id EAA02416;
	Mon, 6 Nov 2000 04:51:47 -0500
Message-ID: <3A067F15.2E474B36@mandrakesoft.com>
Date: 	Mon, 06 Nov 2000 04:51:17 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Paul Gortmaker <p_gortmaker@yahoo.com>
CC:     Donald Becker <becker@scyld.com>, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Re: dev->name in /proc/ioports (was: Re: [patch] NE2000)
References: <Pine.LNX.4.10.10011021935530.11540-100000@vaio.greennet> <3A020C19.4C4B3F66@mandrakesoft.com> <3A0663E1.35A49246@yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: 	linux-net@vger.kernel.org
X-UIDL: ][L!!;:A!!8e@!!+9He9
Status: U
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Paul Gortmaker wrote:
> Something to consider (while still restricting this discussion to ISA
> junk), you can always get ethN <---> irq/ioport mapping via. SIOCGIFMAP.
> But the only reliable way to query the kernel as to what compiled in ISA
> net driver is installed is by a model name in /proc/[ioports,interrupts]
> (Yes, I know, a minor issue...)

I always use 'dmesg' for this...


> Also, the trend for /proc/ioports (and interrupts) in other parts of the
> kernel still appears to be based on hardware/model names and not kernel
> device names, e.g. serial and not ttyS*, BusLogic BT-XXX and not scsi0,
> soundblaster and not /dev/audio, etc. -- hence 3c509 and not eth0 would
> be consistent?

Especially for interrupts, it would be much smarter for the other
devices to indicate their device, since that allows you to differentiate
between adapters of the same type.

	Jeff


-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org



From owner-netdev@oss.sgi.com Tue Nov  7 17:08:53 2000
Received:  by oss.sgi.com id <S553930AbQKHBIe>;
	Tue, 7 Nov 2000 17:08:34 -0800
Received: from asbestos.linuxcare.com.au ([203.17.0.30]:43260 "HELO
        halfway.linuxcare.com.au") by oss.sgi.com with SMTP
	id <S553947AbQKHBI0>; Tue, 7 Nov 2000 17:08:26 -0800
Received: from linuxcare.com.au (localhost [127.0.0.1])
	by halfway.linuxcare.com.au (Postfix) with ESMTP
	id EA043820C; Tue,  7 Nov 2000 13:03:16 +1100 (EST)
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     jamal <hadi@cyberus.ca>
Cc:     netdev@oss.sgi.com
Subject: Re: CONFIG_INET_ECN creates problems 
In-reply-to: Your message of "Sun, 05 Nov 2000 20:33:33 EDT."
             <Pine.GSO.4.20.0011051948220.2665-100000@shell.cyberus.ca> 
Date:   Tue, 07 Nov 2000 13:03:16 +1100
Message-Id: <20001107020317.EA043820C@halfway.linuxcare.com.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In message <Pine.GSO.4.20.0011051948220.2665-100000@shell.cyberus.ca> you write
:
> 4) According to Sally's web page:
> 
> AIX 4.3.2.0-4.3.3.0, IRIX 6.2- 6.5, Solaris 2.6 - 2.7, 
> or Linux 2.1.122 - 2.2.14 of possible systems (as id-ed by nmap) that
> might be causing this.
> I know that old netfilter/ipchains has these problems. I doubt if it was
> anywhere around Linux 2.1.122 - 2.2.14; maybe someone could clarify.

I know Andi claimed that netfilter's (EXPERIMENTAL) `unclean' match
used to dislike this, but I couldn't see (and checking again, still
can't see) anywhere in the code where that was ever the case.

I can't see anything like this in 2.2; I think someone said we used to
blindly echo the ECN bits, though.

> Summary3: We have to do something about this if ECN is to be deployed. 
> So far there is a proposal by Sally Floyd and company which neither Alexey
> nor Davem are thrilled about. I know i am not. 

Penalizes first SYN failures (quite common from .au) and doesn't solve
the Cisco-sends-RST problem.  We could generalize the Floyd solution
to N transmits (I suggest N >= 2, rather than one, but it's just a
inverse of the ECN sysctl), and use two bits in the route cache: one
to indicate that we've spoken to the host with ECN flags set, and one
to indicate that we've received a RST for an ECN packet.

Bogocode:
	#define IPECN_RT_OK  0x01
	#define IPECN_RT_RST 0x02

	if (sysctl_ecn_disable &&
	    (trans(rt) > sysctl_ecn_disable || IPECN_RT(rt) == IPECN_RT_RST)) {
		... no ECN ...
	} else {
		... ECN ...
	}

Horrible?  Yes.  But it would allow us to ship ECN by default (good),
and still communicate with the world (which is the highest priority).

Rusty.
--
Hacking time.

From owner-netdev@oss.sgi.com Tue Nov  7 17:08:53 2000
Received:  by oss.sgi.com id <S553951AbQKHBIe>;
	Tue, 7 Nov 2000 17:08:34 -0800
Received: from asbestos.linuxcare.com.au ([203.17.0.30]:42492 "HELO
        halfway.linuxcare.com.au") by oss.sgi.com with SMTP
	id <S553930AbQKHBI2>; Tue, 7 Nov 2000 17:08:28 -0800
Received: from linuxcare.com.au (localhost [127.0.0.1])
	by halfway.linuxcare.com.au (Postfix) with ESMTP
	id AA05D820F; Tue,  7 Nov 2000 15:28:57 +1100 (EST)
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     davem@redhat.com
Cc:     netdev@oss.sgi.com
Subject: [PATCH] typo in ip_forward.c: test10-pre7
Date:   Tue, 07 Nov 2000 15:28:57 +1100
Message-Id: <20001107042857.AA05D820F@halfway.linuxcare.com.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

There is no NET_RX_BAD: this is clearly NET_RX_DROP.

Cheers,
Rusty.
diff -urN -I \$.*\$ -X /tmp/kerndiff.PkEnMY --minimal linux-2.4.0-test10-7/net/ipv4/ip_forward.c working-2.4.0-test10-7/net/ipv4/ip_forward.c
--- linux-2.4.0-test10-7/net/ipv4/ip_forward.c	Mon Nov  6 20:34:45 2000
+++ working-2.4.0-test10-7/net/ipv4/ip_forward.c	Tue Nov  7 15:26:50 2000
@@ -136,7 +136,7 @@
 	if (rt->rt_flags & RTCF_NAT) {
 		if (ip_do_nat(skb)) {
 			kfree_skb(skb);
-			return NET_RX_BAD;
+			return NET_RX_DROP;
 		}
 	}
 #endif
diff -urN -I \$.*\$ -X /tmp/kerndiff.PkEnMY --minimal linux-2.4.0-test10-7/net/ipv4/ip_nat_dumb.c working-2.4.0-test10-7/net/ipv4/ip_nat_dumb.c
--- linux-2.4.0-test10-7/net/ipv4/ip_nat_dumb.c	Mon Nov  6 20:34:45 2000
+++ working-2.4.0-test10-7/net/ipv4/ip_nat_dumb.c	Tue Nov  7 15:26:44 2000
@@ -155,6 +155,6 @@
 	return NET_RX_SUCCESS;
 
 truncated:
-	/* should be return NET_RX_BAD; */
+	/* should be return NET_RX_DROP; */
 	return -EINVAL;
 }

--
Hacking time.

From owner-netdev@oss.sgi.com Tue Nov  7 18:07:44 2000
Received:  by oss.sgi.com id <S553960AbQKHCHe>;
	Tue, 7 Nov 2000 18:07:34 -0800
Received: from pizda.ninka.net ([216.101.162.242]:9612 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S553952AbQKHCHd>;
	Tue, 7 Nov 2000 18:07:33 -0800
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id RAA17002;
	Tue, 7 Nov 2000 17:52:32 -0800
Date:   Tue, 7 Nov 2000 17:52:32 -0800
Message-Id: <200011080152.RAA17002@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     rusty@linuxcare.com.au
CC:     netdev@oss.sgi.com
In-reply-to: <20001107042857.AA05D820F@halfway.linuxcare.com.au> (message from
	Rusty Russell on Tue, 07 Nov 2000 15:28:57 +1100)
Subject: Re: [PATCH] typo in ip_forward.c: test10-pre7
References:  <20001107042857.AA05D820F@halfway.linuxcare.com.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   From: Rusty Russell <rusty@linuxcare.com.au>
   Date: Tue, 07 Nov 2000 15:28:57 +1100

   There is no NET_RX_BAD: this is clearly NET_RX_DROP.

NET_RX_BAD was just missing, fixed already in test10-final.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Tue Nov  7 18:23:34 2000
Received:  by oss.sgi.com id <S553771AbQKHCXY>;
	Tue, 7 Nov 2000 18:23:24 -0800
Received: from pizda.ninka.net ([216.101.162.242]:25996 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S553696AbQKHCXF>;
	Tue, 7 Nov 2000 18:23:05 -0800
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id SAA19817;
	Tue, 7 Nov 2000 18:08:19 -0800
Date:   Tue, 7 Nov 2000 18:08:19 -0800
Message-Id: <200011080208.SAA19817@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     rusty@linuxcare.com.au
CC:     hadi@cyberus.ca, netdev@oss.sgi.com
In-reply-to: <20001107020317.EA043820C@halfway.linuxcare.com.au> (message from
	Rusty Russell on Tue, 07 Nov 2000 13:03:16 +1100)
Subject: Re: CONFIG_INET_ECN creates problems
References:  <20001107020317.EA043820C@halfway.linuxcare.com.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   From: Rusty Russell <rusty@linuxcare.com.au>
   Date:   Tue, 07 Nov 2000 13:03:16 +1100

   Penalizes first SYN failures (quite common from .au) and doesn't solve
   the Cisco-sends-RST problem.

Yes it does, and this is one of the biggest problems I have with
the floyd draft.  Any proposed RFC language which advises a TCP
implementation outright to ignore perfectly valid RST packets
is not to be taken seriously.

   We could generalize the Floyd solution
   to N transmits (I suggest N >= 2, rather than one, but it's just a
   inverse of the ECN sysctl), and use two bits in the route cache: one
   to indicate that we've spoken to the host with ECN flags set, and one
   to indicate that we've received a RST for an ECN packet.

Doesn't work through masquerading sites.  DST != same machine nor same
path.  Your scheme also ignores valid RST packets, unacceptable.

   Horrible?  Yes.  But it would allow us to ship ECN by default (good),
   and still communicate with the world (which is the highest priority).

How about we ship it on by default as is? :-)

You may laugh, but I consider it very seriously every day.  Because as
a solution it at least makes sense and will get people to fix their
kit.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Tue Nov  7 19:31:45 2000
Received:  by oss.sgi.com id <S553800AbQKHDbf>;
	Tue, 7 Nov 2000 19:31:35 -0800
Received: from asbestos.linuxcare.com.au ([203.17.0.30]:38638 "HELO
        halfway.linuxcare.com.au") by oss.sgi.com with SMTP
	id <S553728AbQKHDbV>; Tue, 7 Nov 2000 19:31:21 -0800
Received: from linuxcare.com.au (localhost [127.0.0.1])
	by halfway.linuxcare.com.au (Postfix) with ESMTP
	id 3ADCF8120; Wed,  8 Nov 2000 14:31:15 +1100 (EST)
From:   Rusty Russell <rusty@linuxcare.com.au>
To:     "David S. Miller" <davem@redhat.com>
Cc:     hadi@cyberus.ca, netdev@oss.sgi.com
Subject: Re: CONFIG_INET_ECN creates problems 
In-reply-to: Your message of "Tue, 07 Nov 2000 18:08:19 -0800."
             <200011080208.SAA19817@pizda.ninka.net> 
Date:   Wed, 08 Nov 2000 14:31:15 +1100
Message-Id: <20001108033116.3ADCF8120@halfway.linuxcare.com.au>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In message <200011080208.SAA19817@pizda.ninka.net> you write:
>    We could generalize the Floyd solution
>    to N transmits (I suggest N >= 2, rather than one, but it's just a
>    inverse of the ECN sysctl), and use two bits in the route cache: one
>    to indicate that we've spoken to the host with ECN flags set, and one
>    to indicate that we've received a RST for an ECN packet.
> 
> Doesn't work through masquerading sites.  DST != same machine nor same
> path.  Your scheme also ignores valid RST packets, unacceptable.

Actually, I didn't propose ignoring RST packets; I didn't realize that
Floyd suggested this.  That would be completely unacceptable.

`Doesn't work through masquerading sites' is misleading.  In normal
operation, SYNs come from the masqueraded machines to the server: if
the masqueraded client is behind an ECN-fucked router, it doesn't
matter to the server since it won't set CE.

If the server initiates an ident probe back to the masqueraded client
it will talk to the masquerading box, so it might believe that it
supports ECN when it does not.  This doesn't matter.

If a host being masqueraded IS behind an ECN-fucked router, and the
masquerading box does support ECN, and the client attempts to do an
active FTP, and the server still has the entry from an ident probe in
its route cache, it won't work.

Probability of that occurring: fairly low.

`Doesn't work with partially ECN-fucked load-shared sites' is true,
but an even smaller problem.

>    Horrible?  Yes.  But it would allow us to ship ECN by default (good),
>    and still communicate with the world (which is the highest priority).
> 
> How about we ship it on by default as is? :-)

The distributions will all have to disable it.  I'd prefer that not to
be the case.

I repeat:
Bogocode:
	#define IPECN_RT_OK  0x01  /* Set if we ever got CE from them */
	#define IPECN_RT_RST 0x02  /* Set if we ever got a RST from them */

	if (sysctl_ecn_disable &&
	    (trans(rt) > sysctl_ecn_disable || IPECN_RT(rt) == IPECN_RT_RST)) {
		... no ECN ...
	} else {
		... ECN ...
	}

Rusty.
--
Hacking time.

From owner-netdev@oss.sgi.com Tue Nov  7 20:26:25 2000
Received:  by oss.sgi.com id <S553925AbQKHE0P>;
	Tue, 7 Nov 2000 20:26:15 -0800
Received: from mail.cyberus.ca ([209.195.95.1]:4230 "EHLO cyberus.ca")
	by oss.sgi.com with ESMTP id <S553796AbQKHEZx>;
	Tue, 7 Nov 2000 20:25:53 -0800
Received: from shell.cyberus.ca (shell [209.195.95.7])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id XAA11797;
	Tue, 7 Nov 2000 23:25:40 -0500 (EST)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id XAA08455;
	Tue, 7 Nov 2000 23:25:49 -0500 (EST)
Date:   Tue, 7 Nov 2000 23:25:49 -0500 (EST)
From:   jamal <hadi@cyberus.ca>
To:     Rusty Russell <rusty@linuxcare.com.au>
cc:     "David S. Miller" <davem@redhat.com>, netdev@oss.sgi.com,
        kuznet@ms2.inr.ac.ru
Subject: Re: CONFIG_INET_ECN creates problems 
In-Reply-To: <20001108033116.3ADCF8120@halfway.linuxcare.com.au>
Message-ID: <Pine.GSO.4.20.0011072249330.8288-100000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



On Wed, 8 Nov 2000, Rusty Russell wrote:

> I think someone said we used to blindly echo the ECN bits, though.

That was around 2.0.25 days, IIRC. The current implementation/RFC catches
this.

>    We could generalize the Floyd solution
>    to N transmits (I suggest N >= 2, rather than one, but it's just a
>    inverse of the ECN sysctl), and use two bits in the route cache: one
>    to indicate that we've spoken to the host with ECN flags set, and one
>    to indicate that we've received a RST for an ECN packet.

If we are going to help avoid ECN turning into a fiasco like NAT (your
favorite ;->) then we need to hammer now. If we dont:
-The broken boxen will never be fixed. They violate RFCs and do not help
in making a better internet (ECN is a good thing). 
- ECN will never really take off. Why would i wanna wait for 2 SYNs 
before realizing that there's some stupid box in between me and
register.co.uk? I can already see the postings "you get faster page loadup
if you disable ECN"
Yes, the internet is an anarchy, and it's that bad bad wolf your mama
warned you about yadayadayada and we must learn to play well with
others, etc ....

There are several things that could be done:
1) complain to your vendor. Bad mouth them if they dont react.
It happens to be very effective.
2) complain to the sites that you cant get to. Point them to a general
site which shows they are violating some internet principles.

I realize what i am saying might not be as effective as having a dynamic
solution built into the stack... 

> Actually, I didn't propose ignoring RST packets; I didn't realize that
> Floyd suggested this.  That would be completely unacceptable.
> 
> > How about we ship it on by default as is? :-)
> 
> The distributions will all have to disable it.  I'd prefer that not to
> be the case.
> 
> I repeat:
> Bogocode:
> 	#define IPECN_RT_OK  0x01  /* Set if we ever got CE from them */
> 	#define IPECN_RT_RST 0x02  /* Set if we ever got a RST from them */
> 
> 	if (sysctl_ecn_disable &&
> 	    (trans(rt) > sysctl_ecn_disable || IPECN_RT(rt) == IPECN_RT_RST)) {
> 		... no ECN ...
> 	} else {
> 		... ECN ...
> 	}
> 

A route based solution might not be too bad. Your list will probably
grow too big.
What is bad is this extra bagage of trying to "better" understand RSTs
etc 

This is not a very smart idea, but here it is anyways:
- A known list of bad sites sitting somewhere. This is something along 
the same lines as a "known spammers list". The list gets new additions and
removal of repentant sites. some list already exists.

- A tool that will take this list and populate your route table or at
least your favorites amongst them (eg you could choose only hotmail.com).

- a per-route attribute which says the route is not ecn friendly.
You dont bother negotiating ECN with the bad sites.

The list stays public and hopefully will be used to pressure site owners
to deploy fixes.
The kernel fix is very small and you dont screw around with TCP dynamics.

cheers,
jamal


From owner-netdev@oss.sgi.com Wed Nov  8 09:20:00 2000
Received:  by oss.sgi.com id <S554009AbQKHRTk>;
	Wed, 8 Nov 2000 09:19:40 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:24071 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553943AbQKHRTc>;
	Wed, 8 Nov 2000 09:19:32 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA18566; Wed, 8 Nov 2000 20:19:08 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011081719.UAA18566@ms2.inr.ac.ru>
Subject: Re: Karn's rule in Linux TCP
To:     ak@suse.de (Andi Kleen)
Date:   Wed, 8 Nov 2000 20:19:08 +0300 (MSK)
Cc:     davem@redhat.com, netdev@oss.sgi.com
In-Reply-To: <20001106220115.A26879@gruyere.muc.suse.de> from "Andi Kleen" at Nov 6, 0 10:01:15 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 921       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> When the initial RTT estimate is too low then there will be no segments going through
> without any retransmits. On a connection with no timestamps all RTT estimates for
> retransmitted packets are ignored due to Karn's rule. Unfortunately this means that
> when the initial RTT is too low it'll never get a new estimate, because all
> packets that arrive at the other end were already retransmitted. The connection
> gets lots of faulty retransmits forever. Oops.

No oops. This RFC statement simply means that connections with rtt>3sec
are not going to work with TCP.

Partially, it was solved old days in Linux (specially for ultra-slow AX.25
links) with static rtt option on routes.

> Any suggestions on that?  Any other ideas? 

Right idea, in theory. But Andi, where did you find connections with rtt>3sec?
The worst link, which I ever saw was faulty 2400baud line and it had
rtt a bit lower. 8)

Alexey

From owner-netdev@oss.sgi.com Wed Nov  8 10:20:50 2000
Received:  by oss.sgi.com id <S554013AbQKHSUk>;
	Wed, 8 Nov 2000 10:20:40 -0800
Received: from exchng1.shsu.edu ([158.135.1.57]:46853 "EHLO exchng1.SHSU.EDU")
	by oss.sgi.com with ESMTP id <S554008AbQKHSUO>;
	Wed, 8 Nov 2000 10:20:14 -0800
Received: by exchng1.shsu.edu with Internet Mail Service (5.5.2650.21)
	id <WK4ZXLV2>; Wed, 8 Nov 2000 12:19:57 -0600
Message-ID: <AD7116EE9A9ED41189ED000094A1813C3330DF@exchng1.shsu.edu>
From:   "Thompson, Robert Aubrey" <UCS_RAT@exchng1.shsu.edu>
To:     "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>
Subject: neighbour table overflow
Date:   Wed, 8 Nov 2000 12:19:55 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

	I've recently been directed to this list by Alan Cox, after having
some trouble with a Linux Samba server having to many connections.  When
reaching 1025 arp entries(arp -a -n | wc -l), I get neighbour table
overflows and people are unable to reach the server.  I have tried following
the route.c source and tweaking the kernel to allow for a larger arp table
however, I never seemed to be able increase the arp table size.  Any other
tweaks I make(gc, elasticty, and etc.) just caused the machine to overflow
more, however I'm not a kernel wizard and most likely am tuning the wrong
parameters the wrong way :).  Does anyone have a FAQ or any knowledge on
which kernel parms are turnable and what they do/effect.   I currently have
about 1700 machines, and around 800 to 1200 connecting at the same time
depending on the time of day.  If I could increase the arp table just a
little, I think I could fix the error.  Any e-mail with help or suggestions
would be greatly appreciated.  Even a flame or two can be tollerated to help
fix this :).

Sincerely,

Robert A. Thompson
ucs_rat@shsu.edu
	

From owner-netdev@oss.sgi.com Wed Nov  8 12:07:21 2000
Received:  by oss.sgi.com id <S554023AbQKHUHB>;
	Wed, 8 Nov 2000 12:07:01 -0800
Received: from mail.zmailer.org ([194.252.70.162]:59399 "EHLO zmailer.org")
	by oss.sgi.com with ESMTP id <S553986AbQKHUGv>;
	Wed, 8 Nov 2000 12:06:51 -0800
Received: (from localhost user: 'mea' uid#500 fake: STDIN (mea@zmailer.org))
	by mail.zmailer.org id <S2621948AbQKHUGg>;
	Wed, 8 Nov 2000 22:06:36 +0200
Date:	Wed, 8 Nov 2000 22:06:36 +0200
From:	Matti Aarnio <matti.aarnio@zmailer.org>
To:	netdev@oss.sgi.com
Subject: IPv6 ND autoconfig buglet
Message-ID: <20001108220636.K13151@mea-ext.zmailer.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Kernel 2.4.0test10+vlan0.0.14/mea

Playing in one of my (V)LANs without global reachability.

Couple days ago I had a router advertising IPv6 global prefix
8888::0/64 EUI-64 -- then I recycled that box to elsewere, and
put another box with different advertisement prefix.

The old one doesn't seem to disappear...

$ /sbin/ifconfig vlan0003
vlan0003  Link encap:Ethernet  HWaddr 00:10:4B:6B:BE:C0  
          inet6 addr: 3ffe:2610:2:fff0:210:4bff:fe6b:bec0/64 Scope:Global
          inet6 addr: 8888::210:4bff:fe6b:bec0/64 Scope:Global
          inet6 addr: fe80::210:4bff:fe6b:bec0/10 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

/Matti Aarnio

From owner-netdev@oss.sgi.com Wed Nov  8 12:41:10 2000
Received:  by oss.sgi.com id <S554044AbQKHUlA>;
	Wed, 8 Nov 2000 12:41:00 -0800
Received: from finch-post-10.mail.demon.net ([194.217.242.38]:50180 "EHLO
        finch-post-10.mail.demon.net") by oss.sgi.com with ESMTP
	id <S554037AbQKHUky>; Wed, 8 Nov 2000 12:40:54 -0800
Received: from pnd-pc.demon.co.uk ([158.152.18.190])
	by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
	id 13tc1c-000F9y-0A; Wed, 8 Nov 2000 20:40:52 +0000
Received: from localhost (peterd@localhost)
	by pnd-pc.demon.co.uk (8.9.3/8.9.3) with ESMTP id TAA01489;
	Wed, 8 Nov 2000 19:58:38 GMT
Date:   Wed, 8 Nov 2000 19:58:38 +0000 (GMT)
From:   Peter Denison <peterd@pnd-pc.demon.co.uk>
To:     "Thompson, Robert Aubrey" <UCS_RAT@exchng1.shsu.edu>
cc:     "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>
Subject: Re: neighbour table overflow
In-Reply-To: <AD7116EE9A9ED41189ED000094A1813C3330DF@exchng1.shsu.edu>
Message-ID: <Pine.LNX.4.21.0011081954220.1433-100000@pnd-pc.demon.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Wed, 8 Nov 2000, Thompson, Robert Aubrey wrote:

> 	I've recently been directed to this list by Alan Cox, after having
> some trouble with a Linux Samba server having to many connections.  When
> reaching 1025 arp entries(arp -a -n | wc -l), I get neighbour table
> overflows and people are unable to reach the server.  I have tried following

	I seem to recall something somewhere about running a userspace
arpd, which could presumably remove your limitations.

[pauses while rummaging in docs]

It's marked as obsolete in the kernel (damn!) and is "ARP daemon support
(EXPERIMENTAL)". It does mention about a userspace arpd, but not where to
find it. Might be worth a try?

-- 
Peter Denison <peterd@pnd-pc.demon.co.uk>
Linux Driver for Promise DC4030VL cards.
See http://www.pnd-pc.demon.co.uk/promise/promise.html for details


From owner-netdev@oss.sgi.com Wed Nov  8 12:58:41 2000
Received:  by oss.sgi.com id <S554046AbQKHU6b>;
	Wed, 8 Nov 2000 12:58:31 -0800
Received: from Cantor.suse.de ([194.112.123.193]:37645 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S554043AbQKHU6F>;
	Wed, 8 Nov 2000 12:58:05 -0800
Received: from Hermes.suse.de (Hermes.suse.de [194.112.123.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 9881B1E194; Wed,  8 Nov 2000 21:58:03 +0100 (MET)
Received: from gruyere.muc.suse.de (gruyere.muc.suse.de [10.23.1.2])
	by Hermes.suse.de (Postfix) with ESMTP
	id 671483E48D; Wed,  8 Nov 2000 21:58:03 +0100 (MET)
Received: by gruyere.muc.suse.de (Postfix, from userid 14446)
	id D92092F300; Wed,  8 Nov 2000 21:57:57 +0100 (MET)
Date:   Wed, 8 Nov 2000 21:57:57 +0100
From:   Andi Kleen <ak@suse.de>
To:     kuznet@ms2.inr.ac.ru
Cc:     Andi Kleen <ak@suse.de>, davem@redhat.com, netdev@oss.sgi.com
Subject: Re: Karn's rule in Linux TCP
Message-ID: <20001108215757.A5813@gruyere.muc.suse.de>
References: <20001106220115.A26879@gruyere.muc.suse.de> <200011081719.UAA18566@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200011081719.UAA18566@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Wed, Nov 08, 2000 at 08:19:08PM +0300
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Wed, Nov 08, 2000 at 08:19:08PM +0300, kuznet@ms2.inr.ac.ru wrote:
> 
> > Any suggestions on that?  Any other ideas? 
> 
> Right idea, in theory. But Andi, where did you find connections with rtt>3sec?

A misconfigured VPN with too long queues causes such long rtts when slightly
congested :-( 


-Andi

From owner-netdev@oss.sgi.com Wed Nov  8 13:22:41 2000
Received:  by oss.sgi.com id <S553683AbQKHVWb>;
	Wed, 8 Nov 2000 13:22:31 -0800
Received: from mx1.thebiz.net ([216.238.0.20]:35336 "HELO mx1.thebiz.net")
	by oss.sgi.com with SMTP id <S553669AbQKHVWJ>;
	Wed, 8 Nov 2000 13:22:09 -0800
Received: (qmail 30257 invoked from network); 8 Nov 2000 16:22:07 -0500
Received: from mail1.backend.thebiz.net (HELO mail1.thebiz.net) (172.16.0.179)
  by mx1.backend.thebiz.net with SMTP; 8 Nov 2000 16:22:07 -0500
Received: (qmail 23078 invoked by uid 0); 8 Nov 2000 16:22:05 -0500
Received: from unknown (HELO stu.critical.com) (216.230.227.141)
  by mail.borg.com with SMTP; 8 Nov 2000 16:22:05 -0500
Message-Id: <5.0.0.25.0.20001108161648.009db7d0@mail.borg.com>
X-Sender: stu@mail.borg.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date:   Wed, 08 Nov 2000 16:21:20 -0500
To:     netdev@oss.sgi.com
From:   "Stuart W. Card" <stu@critical.com>
Subject: Fwd: Re: Karn's rule in Linux TCP
Cc:     fredtims@critical.com, gpalmer@critical.com
Mime-Version: 1.0
Content-Type: multipart/signed;
 boundary="=--=--=--=-=---======-=--=-=-==-------==-==--=-=";
 protocol="application/pgp-signature"; micalg=pgp-sha1
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

--=--=--=--=-=---======-=--=-=-==-------==-==--=-=
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Andi Kleen <ak@suse.de> wrote --

>On Wed, Nov 08, 2000 at 08:19:08PM +0300, kuznet@ms2.inr.ac.ru wrote:
> >
> > > Any suggestions on that?  Any other ideas?
> >
> > Right idea, in theory. But Andi, where did you find connections with 
> rtt>3sec?
>
>A misconfigured VPN with too long queues causes such long rtts when slightly
>congested :-(

Our work for the military, involving very low bandwidth (for instance, 2400 
bps)
links, that often run over geostationary satellites (additional 250 mS per hop
speed of light lag), that require link encryption (typically implemented
using long shift registers, in this case clocking at our very low bit rates),
and that are generally time division duplex, have round trip times that in
the _best_ case are _far_ longer than 3 seconds.

--=--=--=--=-=---======-=--=-=-==-------==-==--=-=
Content-Type: application/pgp-signature

-----BEGIN PGP MESSAGE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBOgnD0FwDuMiQkJ0KEQIqNQCg16P4kZcE+gOa+75BKq+7qf4pAmEAoKij
I4C9wvd5CRKXk5ujlTKaAWXQ
=4gvy
-----END PGP MESSAGE-----

--=--=--=--=-=---======-=--=-=-==-------==-==--=-=--


From owner-netdev@oss.sgi.com Wed Nov  8 13:26:01 2000
Received:  by oss.sgi.com id <S553694AbQKHVZv>;
	Wed, 8 Nov 2000 13:25:51 -0800
Received: from sirppi.helsinki.fi ([128.214.205.27]:12549 "EHLO
        sirppi.helsinki.fi") by oss.sgi.com with ESMTP id <S553682AbQKHVZl>;
	Wed, 8 Nov 2000 13:25:41 -0800
Received: from localhost (amlaukka@localhost)
	by sirppi.helsinki.fi (8.10.1/8.10.1) with ESMTP id eA8LPaA00865;
	Wed, 8 Nov 2000 23:25:37 +0200 (EET)
X-Authentication-Warning: sirppi.helsinki.fi: amlaukka owned process doing -bs
Date:   Wed, 8 Nov 2000 23:25:36 +0200 (EET)
From:   Aki M Laukkanen <amlaukka@cc.helsinki.fi>
To:     Matti Aarnio <matti.aarnio@zmailer.org>
cc:     netdev@oss.sgi.com
Subject: Re: IPv6 ND autoconfig buglet
In-Reply-To: <20001108220636.K13151@mea-ext.zmailer.org>
Message-ID: <Pine.OSF.4.20.0011082303590.6348-100000@sirppi.helsinki.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Wed, 8 Nov 2000, Matti Aarnio wrote:
> Couple days ago I had a router advertising IPv6 global prefix
> 8888::0/64 EUI-64 -- then I recycled that box to elsewere, and
> put another box with different advertisement prefix. 
> The old one doesn't seem to disappear...

If you left the AdvValidLifetime option in radvd to default 
(i.e. infinity) then it shouldn't expire. I haven't gotten as
far as that in the code but with a quick look the prefix
processing code in addrconf_prefix_rcv() seems to do
just that.

And new router advertisement must not invalidate old
information unless they refer to the same prefix, mtu
etc. 

-- 
D.



From owner-netdev@oss.sgi.com Wed Nov  8 14:42:52 2000
Received:  by oss.sgi.com id <S554048AbQKHWml>;
	Wed, 8 Nov 2000 14:42:41 -0800
Received: from kogge.hanse.de ([192.76.134.17]:35856 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553704AbQKHWme>;
	Wed, 8 Nov 2000 14:42:34 -0800
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id XAA15054;
	Wed, 8 Nov 2000 23:42:18 +0100 (CET)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id XAA01293;
	Wed, 8 Nov 2000 23:23:38 +0100
Date:   Wed, 8 Nov 2000 23:23:38 +0100
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200011082223.XAA01293@baty.hanse.de>
To:     davem@redhat.com
cc:     netdev@oss.sgi.com, alan@redhat.com, gorgo@itc.hu
Subject: patch: x25-iface / lapb reliability
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi,

as we have discussed some time ago, the linux network interface
does not preserve the reliable datalink service that upper layers
might expect from a lapb device. As a result of the discussion,
I've prepared the following patch, (against test10). As it changes a
documented kernel interface, it would be nice to include it before
2.4.0-final. The patch does the following:

- It documents the possible problems (packet loss due to backlog congestion
  and packet re-ordering in SMP kernels) in x25-iface.txt and suggests
  work-arounds.
- It changes the kernel interface to the lapb module. Its data_indication()
  method now honors an integer return value. If the return value is
  NET_RX_DROP, the lapb protocol will not confirm the packet (this will
  cause the peer to retransmit the lost packet later).
- The drivers which use the lapb module are modified as required by the
  new lapb return semantics.

I've done several tests with the lapbether driver by simulating
netif_rx() backlog congestion and verified that it works. For the other
drivers, I checked that they compile o.k. (anc cc'ed to the maintainers)


Henner



diff -ur linux/Documentation/networking/lapb-module.txt x25fix/Documentation/networking/lapb-module.txt
--- linux/Documentation/networking/lapb-module.txt	Mon May 10 22:00:10 1999
+++ x25fix/Documentation/networking/lapb-module.txt	Mon Nov  6 21:29:15 2000
@@ -2,6 +2,8 @@
 
 		      Jonathan Naylor 29.12.96
 
+Changed (Henner Eisen, 2000-10-29): int return value for data_indication() 
+
 The LAPB module will be a separately compiled module for use by any parts of
 the Linux operating system that require a LAPB service. This document
 defines the interfaces to, and the services provided by this module. The
@@ -37,7 +39,7 @@
 	void (*connect_indication)(int token, int reason);
 	void (*disconnect_confirmation)(int token, int reason);
 	void (*disconnect_indication)(int token, int reason);
-	void (*data_indication)(int token, struct sk_buff *skb);
+	int  (*data_indication)(int token, struct sk_buff *skb);
 	void (*data_transmit)(int token, struct sk_buff *skb);
 };
 
@@ -240,7 +242,7 @@
 			system.
 
 
-void (*data_indication)(void *token, struct sk_buff *skb);
+int (*data_indication)(void *token, struct sk_buff *skb);
 
 This is called by the LAPB module when data has been received from the
 remote system that should be passed onto the next layer in the protocol
@@ -248,6 +250,10 @@
 module will not perform any more actions on it. The skb->data pointer will
 be pointing to the first byte of data after the LAPB header.
 
+This method should return NET_RX_DROP (as defined in the header
+file include/linux/netdevice.h) if and only if the frame was dropped
+before it could be delivered to the upper layer.
+
 
 void (*data_transmit)(void *token, struct sk_buff *skb);
 
diff -ur linux/Documentation/networking/x25-iface.txt x25fix/Documentation/networking/x25-iface.txt
--- linux/Documentation/networking/x25-iface.txt	Tue Apr 28 23:22:04 1998
+++ x25fix/Documentation/networking/x25-iface.txt	Mon Nov  6 21:29:15 2000
@@ -62,3 +62,62 @@
 First Byte = 0x03
 
 LAPB parameters. To be defined.
+
+
+
+Possible Problems
+=================
+
+(Henner Eisen, 2000-10-28)
+
+The X.25 packet layer protocol depends on a reliable datalink service.
+The LAPB protocol provides such reliable service. But this reliability
+is not preserved by the Linux network device driver interface:
+
+- With Linux 2.4.x (and above) SMP kernels, packet ordering is not
+  preserved. Even if a device driver calls netif_rx(skb1) and later
+  netif_rx(skb2), skb2 might be delivered to the network layer
+  earlier that skb1.
+- Data passed upstream by means of netif_rx() might be dropped by the
+  kernel if the backlog queue is congested.
+
+The X.25 packet layer protocol will detect this and reset the virtual
+call in question. But many upper layer protocols are not designed to
+handle such N-Reset events gracefully. And frequent N-Reset events
+will always degrade performance.
+
+Thus, driver authors should make netif_rx() as reliable as possible:
+
+SMP re-ordering will not occur if the driver's interrupt handler is
+always executed on the same CPU. Thus,
+
+- Driver authors should use irq affinity for the interrupt handler.
+
+The probability of packet loss due to backlog congestion can be
+reduced by the following measures or a combination thereof:
+
+(1) Drivers for kernel versions 2.4.x and above should always check the
+    return value of netif_rx(). If it returns NET_RX_DROP, the
+    driver's LAPB protocol must not confirm reception of the frame
+    to the peer. 
+    This will reliably suppress packet loss. The LAPB protocol will
+    automatically cause the peer to re-transmit the dropped packet
+    later.
+    The lapb module interface was modified to support this. Its
+    data_indication() method should now transparently pass the
+    netif_rx() return value to the (lapb mopdule) caller.
+(2) Drivers for kernel versions 2.2.x should always check the global
+    variable netdev_dropping when a new frame is received. The driver
+    should only call netif_rx() if netdev_dropping is zero. Otherwise
+    the driver should not confirm delivery of the frame and drop it.
+    Alternatively, the driver can queue the frame internally and call
+    netif_rx() later when netif_dropping is 0 again. In that case, delivery
+    confirmation should also be deferred such that the internal queue
+    cannot grow to much.
+    This will not reliably avoid packet loss, but the probability
+    of packet loss in netif_rx() path will be significantly reduced.
+(3) Additionally, driver authors might consider to support
+    CONFIG_NET_HW_FLOWCONTROL. This allows the driver to be woken up
+    when a previously congested backlog queue becomes empty again.
+    The driver could uses this for flow-controlling the peer by means
+    of the LAPB protocol's flow-control service.
diff -ur linux/drivers/net/wan/comx-proto-lapb.c x25fix/drivers/net/wan/comx-proto-lapb.c
--- linux/drivers/net/wan/comx-proto-lapb.c	Tue Jul 18 17:06:39 2000
+++ x25fix/drivers/net/wan/comx-proto-lapb.c	Mon Nov  6 21:29:15 2000
@@ -15,6 +15,9 @@
  * Version 0.80 (99/06/14):
  *		- cleaned up the source code a bit
  *		- ported back to kernel, now works as non-module
+ *
+ * Changed      (00/10/29, Henner Eisen):
+ * 		- comx_rx() / comxlapb_data_indication() return status.
  * 
  */
 
@@ -359,7 +362,7 @@
 	comx_status(ch->dev, ch->line_status);
 }
 
-static void comxlapb_data_indication(void *token, struct sk_buff *skb)
+static int comxlapb_data_indication(void *token, struct sk_buff *skb)
 {
 	struct comx_channel *ch = token; 
 
@@ -373,7 +376,7 @@
 
 	skb->dev = ch->dev;
 	skb->mac.raw = skb->data;
-	comx_rx(ch->dev, skb);
+	return comx_rx(ch->dev, skb);
 }
 
 static void comxlapb_data_transmit(void *token, struct sk_buff *skb)
diff -ur linux/drivers/net/wan/comx.c x25fix/drivers/net/wan/comx.c
--- linux/drivers/net/wan/comx.c	Wed Oct  4 19:21:53 2000
+++ x25fix/drivers/net/wan/comx.c	Mon Nov  6 21:29:15 2000
@@ -46,6 +46,9 @@
  * Version 0.85 (00/08/15):
  * 		- resource release on failure in comx_mkdir
  * 		- fix return value on failure at comx_write_proc
+ *
+ * Changed      (00/10/29, Henner Eisen):
+ * 		- comx_rx() / comxlapb_data_indication() return status.
  */
 
 #define VERSION "0.85"
diff -ur linux/drivers/net/wan/lapbether.c x25fix/drivers/net/wan/lapbether.c
--- linux/drivers/net/wan/lapbether.c	Mon May 22 20:51:40 2000
+++ x25fix/drivers/net/wan/lapbether.c	Mon Nov  6 21:29:15 2000
@@ -16,6 +16,7 @@
  *
  *	History
  *	LAPBETH 001	Jonathan Naylor		Cloned from bpqether.c
+ *	2000-10-29	Henner Eisen	lapb_data_indication() return status.
  */
 
 #include <linux/errno.h>
@@ -185,7 +186,7 @@
 	return 0;
 }
 
-static void lapbeth_data_indication(void *token, struct sk_buff *skb)
+static int lapbeth_data_indication(void *token, struct sk_buff *skb)
 {
 	struct lapbethdev *lapbeth = (struct lapbethdev *)token;
 	unsigned char *ptr;
@@ -198,7 +199,7 @@
 	skb->mac.raw  = skb->data;
 	skb->pkt_type = PACKET_HOST;
 
-	netif_rx(skb);
+	return netif_rx(skb);
 }
 
 /*
diff -ur linux/drivers/net/wan/x25_asy.c x25fix/drivers/net/wan/x25_asy.c
--- linux/drivers/net/wan/x25_asy.c	Mon May 22 20:51:40 2000
+++ x25fix/drivers/net/wan/x25_asy.c	Mon Nov  6 21:29:15 2000
@@ -9,6 +9,9 @@
  *	recommendations. Its primarily for testing purposes. If you wanted
  *	to do CCITT then in theory all you need is to nick the HDLC async
  *	checksum routines from ppp.c
+ *      Changes:
+ *
+ *	2000-10-29	Henner Eisen	lapb_data_indication() return status.
  */
 
 #include <linux/module.h>
@@ -390,9 +393,9 @@
  *	at the net layer.
  */
   
-static void x25_asy_data_indication(void *token, struct sk_buff *skb)
+static int x25_asy_data_indication(void *token, struct sk_buff *skb)
 {
-	netif_rx(skb);
+	return netif_rx(skb);
 }
 
 /*
diff -ur linux/include/linux/lapb.h x25fix/include/linux/lapb.h
--- linux/include/linux/lapb.h	Sun Jan 19 14:47:26 1997
+++ x25fix/include/linux/lapb.h	Mon Nov  6 21:29:15 2000
@@ -28,7 +28,7 @@
 	void (*connect_indication)(void *token, int reason);
 	void (*disconnect_confirmation)(void *token, int reason);
 	void (*disconnect_indication)(void *token, int reason);
-	void (*data_indication)(void *token, struct sk_buff *skb);
+	int  (*data_indication)(void *token, struct sk_buff *skb);
 	void (*data_transmit)(void *token, struct sk_buff *skb);
 };
 
diff -ur linux/net/lapb/lapb_iface.c x25fix/net/lapb/lapb_iface.c
--- linux/net/lapb/lapb_iface.c	Mon Nov  6 21:00:04 2000
+++ x25fix/net/lapb/lapb_iface.c	Wed Nov  8 17:02:25 2000
@@ -12,6 +12,7 @@
  *	History
  *	LAPB 001	Jonathan Naylor	Started Coding
  *	LAPB 002	Jonathan Naylor	New timer architecture.
+ *	2000-10-29	Henner Eisen	lapb_data_indication() return status.
  */
  
 #include <linux/config.h>
@@ -370,14 +371,11 @@
 
 int lapb_data_indication(lapb_cb *lapb, struct sk_buff *skb)
 {
-	int used = 0;
-
 	if (lapb->callbacks.data_indication != NULL) {
-		(lapb->callbacks.data_indication)(lapb->token, skb);
-		used = 1;
+		return (lapb->callbacks.data_indication)(lapb->token, skb);
 	}
-
-	return used;
+	kfree_skb(skb);
+	return NET_RX_CN_HIGH; /* For now; must be != NET_RX_DROP */ 
 }
 
 int lapb_data_transmit(lapb_cb *lapb, struct sk_buff *skb)
diff -ur linux/net/lapb/lapb_in.c x25fix/net/lapb/lapb_in.c
--- linux/net/lapb/lapb_in.c	Tue Feb 10 22:07:49 1998
+++ x25fix/net/lapb/lapb_in.c	Mon Nov  6 21:29:15 2000
@@ -12,6 +12,7 @@
  *	History
  *	LAPB 001	Jonathan Naulor	Started Coding
  *	LAPB 002	Jonathan Naylor	New timer architecture.
+ *	2000-10-29	Henner Eisen	lapb_data_indication() return status.
  */
 
 #include <linux/config.h>
@@ -464,8 +465,21 @@
 				lapb_check_iframes_acked(lapb, frame->nr);
 			}
 			if (frame->ns == lapb->vr) {
+				int cn;
+				cn = lapb_data_indication(lapb, skb);
+				queued = 1;
+				/*
+				 * If upper layer has dropped the frame, we
+				 * basically ignore any further protocol
+				 * processing. This will cause the peer
+				 * to re-transmit the frame later like
+				 * a frame lost on the wire.
+				 */
+				if(cn == NET_RX_DROP){
+					printk(KERN_DEBUG "LAPB: rx congestion\n");
+					break;
+				}
 				lapb->vr = (lapb->vr + 1) % modulus;
-				queued = lapb_data_indication(lapb, skb);
 				lapb->condition &= ~LAPB_REJECT_CONDITION;
 				if (frame->pf) {
 					lapb_enquiry_response(lapb);

From owner-netdev@oss.sgi.com Wed Nov  8 23:24:04 2000
Received:  by oss.sgi.com id <S553750AbQKIHXo>;
	Wed, 8 Nov 2000 23:23:44 -0800
Received: from gleb.nbase.co.il ([194.90.136.56]:37126 "EHLO gleb.nbase.co.il")
	by oss.sgi.com with ESMTP id <S553740AbQKIHXY>;
	Wed, 8 Nov 2000 23:23:24 -0800
Received: (from gleb@localhost)
	by gleb.nbase.co.il (8.11.1/8.11.1/Debian 8.11.0-6) id eA97MTO18807;
	Thu, 9 Nov 2000 09:22:29 +0200
From:   Gleb Natapov <gleb@nbase.co.il>
Date:   Thu, 9 Nov 2000 09:22:28 +0200
To:     "Thompson, Robert Aubrey" <UCS_RAT@exchng1.shsu.edu>
Cc:     "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>
Subject: Re: neighbour table overflow
Message-ID: <20001109092228.C15457@nbase.co.il>
References: <AD7116EE9A9ED41189ED000094A1813C3330DF@exchng1.shsu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AD7116EE9A9ED41189ED000094A1813C3330DF@exchng1.shsu.edu>; from UCS_RAT@exchng1.shsu.edu on Wed, Nov 08, 2000 at 12:19:55PM -0600
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

try do this as root:
# echo 2000 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

The default value of this threshold is 1024 and this is the max size of the arp table.

On Wed, Nov 08, 2000 at 12:19:55PM -0600, Thompson, Robert Aubrey wrote:
> 	I've recently been directed to this list by Alan Cox, after having
> some trouble with a Linux Samba server having to many connections.  When
> reaching 1025 arp entries(arp -a -n | wc -l), I get neighbour table
> overflows and people are unable to reach the server.  I have tried following
> the route.c source and tweaking the kernel to allow for a larger arp table
> however, I never seemed to be able increase the arp table size.  Any other
> tweaks I make(gc, elasticty, and etc.) just caused the machine to overflow
> more, however I'm not a kernel wizard and most likely am tuning the wrong
> parameters the wrong way :).  Does anyone have a FAQ or any knowledge on
> which kernel parms are turnable and what they do/effect.   I currently have
> about 1700 machines, and around 800 to 1200 connecting at the same time
> depending on the time of day.  If I could increase the arp table just a
> little, I think I could fix the error.  Any e-mail with help or suggestions
> would be greatly appreciated.  Even a flame or two can be tollerated to help
> fix this :).
> 
> Sincerely,
> 
> Robert A. Thompson
> ucs_rat@shsu.edu
> 	
--
			Gleb.

From owner-netdev@oss.sgi.com Thu Nov  9 06:37:15 2000
Received:  by oss.sgi.com id <S553791AbQKIOgz>;
	Thu, 9 Nov 2000 06:36:55 -0800
Received: from bay.ein.cz ([212.24.139.122]:22791 "HELO bay.ein.cz")
	by oss.sgi.com with SMTP id <S553775AbQKIOgp>;
	Thu, 9 Nov 2000 06:36:45 -0800
Received: from eagle.int.ein.cz (eagle.int.ein.cz [192.168.3.129])
	by bay.ein.cz (Postfix) with ESMTP id 5AD8E135A4
	for <netdev@oss.sgi.com>; Thu,  9 Nov 2000 15:34:39 +0100 (CET)
Received: from patrik (helo=localhost)
	by eagle.int.ein.cz with local-esmtp (Exim 3.16 #1 (Debian))
	id 13tsmk-0000jz-00
	for <netdev@oss.sgi.com>; Thu, 09 Nov 2000 15:34:38 +0100
Date:   Thu, 9 Nov 2000 15:34:38 +0100 (CET)
From:   Patrik Rak <patrik@ein.cz>
To:     netdev@oss.sgi.com
Subject: Bug in TCP/IP stack in 2.2.17? (fwd)
Message-ID: <Pine.LNX.4.21.0011091529330.2086-110000@eagle.int.ein.cz>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1463779069-1496100968-973780478=:2086"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---1463779069-1496100968-973780478=:2086
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi!

Alan told me I should forward attached message to this list.

Please note that it was the Linux host initiating the SMTP connection that
corrupted the packet and the tcpdump was run directly on this sending
host. The original message is perhaps somewhat unclear about this.

I am really eager to hear your comments about all this.

Thanks.

Patrik

---1463779069-1496100968-973780478=:2086
Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0011091529350.2086@eagle.int.ein.cz>
Content-Description: Bug in TCP/IP stack in 2.2.17? (fwd)

Date: Thu, 2 Nov 2000 16:13:59 +0100 (CET)
From: Patrik Rak <patrik@eagle.int.ein.cz>
To: alan.cox@linux.org
Subject: Bug in TCP/IP stack in 2.2.17?
Message-ID: <Pine.LNX.4.21.0011021553010.4026-101000@eagle.int.ein.cz>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1463779069-292812169-973177357=:4026"
Content-ID: <Pine.LNX.4.21.0011021603430.4026@eagle.int.ein.cz>


---1463779069-292812169-973177357=:4026
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0011021603431.4026@eagle.int.ein.cz>

Hi!

I have a suspicion that there is some bug in TCP/IP stack in 2.2.17
regarding TCP options.

I was tracking down a problem with mail delivery over SMTP. It turned out
that the smtp client attempts to send "EHLO bay.ein.cz<cr><lf>" but the
first 12 bytes of this came out as junk (as seen by tcpdump run on the
same host as the smtp client). Wietse Venema pointed out that it actually
looks like the TCP options stored in the data part of the packet.

I think that the stack might be confused by the fact that the SYN response
doesn't contain any options and they come later in the first ACK.

I include the tcpdump log of the sessions plus its textual version for
your convenience.

Please let me know what your opinion about this issue is.

Thanks.

Patrik Rak

---1463779069-292812169-973177357=:4026
Content-Type: APPLICATION/X-GTAR; NAME="tcpdump-log.tgz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0011021602370.4026@eagle.int.ein.cz>
Content-Description: 
Content-Disposition: ATTACHMENT; FILENAME="tcpdump-log.tgz"

H4sIAB+AAToAA9TbZ1wVx9cH8KEJCoglithyrSAgckHAvRrQqLFTIlZERSWg
CEhTULFEIQZRjEoUSySSiICKfys8ihrRWMEewR6VxK6xxJLoPnPmcmfx5ubM
88L/i+e+iJFsvp9zdmZ3fszujR8/ZUJC5BSXydFh5L/1Ubu6enburCIq+Ljq
/anycvf08KB/qL28vDzc1J1dVSq12t3Tk6hc/2sV1fgkxMWHxKpUJDY6Oh47
TvTf/59+zpdu+96YmPK/nzYnxIj+OeDPd5LqrRnpT/+9P/svOzbcnUv/ubGu
xoL0JqSbfZvupHutq4/ON1k4/eSz2m2tyoldvd8sx8Cx2cbJiUu+JcTY1GyH
qbFFnbqxJwvh50YmJkzuEVebdKN/76aVqan1meww7hohrrWe9gEVdGJnVb7F
+JUp1cf6NyAk/xk9aG7TA9oqF1PLkyqehqp0sO/PqrysV+VY6pn510tO7DiT
kIFUaWVJavb6fkXd/Fp1J49qmT/Rq8gMpOx69isDv6a9GVnUIamP/KFX6BN6
B7llO/LvvTr7tWayrJNTUknMBr+HAXDsWOPWXdoXaM8iSQVrcjuC9TqLELnW
6FxdrySGavRDvc/9P6JeurbXq2trkZX05ysNVZTm14ZVlG2oV/8m9g+GPyTE
zc1VFRkycbJLbGhCfGhsXHhoyOT4cJfx0ZGq3oMHBfqrBodGTYADVP6x0R27
uEgu7p3YP7uqAhNCnVXuapXf+HiVm6urK73YNZ3dNO4eqo6uHvSvDr0HB3aw
rgN1unxXC+t2OxvZWAMjG0ZHNtv5qbbbgd/XIn3o/9/HkCLZ72DKWINKk9lF
ZbW1I1s3tswWRtdl/HTrOn6UvTYfYx2+BPbKUjFb3pOzQyh7fw7GdlgC7OX5
Yvb0as6GUPbnJIx1zAH2UoyYvTCAs1Mp23CANcI6FQNbGcTZQmL3eug3T+am
XvcANueCjr26iaQOm8zYJMomRmDVOt1hrLO42msFvNo8yr7zxVgXR2B/uSdm
/4jg7CPKvjLBTkKnAGAvlApPQpxVOj8JtV++k+o3xqrt9Iix7YXVxjW+z6v9
grIjDlshrLoPsOfKxNV2ncyrnUtZzVUzhHUbC+zZHeJqe5/g1V6j7JvlWLWe
tYE9ZSmudtJAXu1ryh4pwKr1ZNWW/x+qjVcm2NBXdIKNxKr1igK2bIO42ixn
Xm0MZdtFY9V6fcvYWeJqcxbyassp27QJVq1kD+yJh+Jqj1rxau9S1twRq1ba
xdjR4mrPKlfZZ6/fSY5nLBG2K7t4j90TV/vnA15tCGWX3jLF2GOMHSCsNt5I
uTHuo2zAQqzaT7YAe+QLYbXx7U7yaispe/A7rFqfzcAeDhNX6+rEq/V8804a
3A+rtvs4YA9tE1cbqNzGAyhbGIRV230uY5eJqx1jyas9RtncRhjbIwvY0hli
dpFyY+zx1ztpyykThO05G9ifMsXsXuUOVkzZ7WkY26sM2AN9xOx95Vaz+907
aeVaCySb+54Ddpe3jrVeQexWHi/ZBsdCNrd0q5HNp9rawM8hs4L8uIcVks1j
+kI2v3VVSYfWK+YlHalF9e2QzU8kEfLkQbxbSR5YPp9aIQnO9zyrMkCvyu3U
M4ds7mtMSBFVStOxbO5pBnm1lZVeReYgQTa/Mbo6m6d1WQW96rI5yA/SjZBs
7lmLyc14Nj9KYnaPmmICx0I2X5pfnc3TwOq4yAjr9QJkcy//Gtn8KBxHPVPI
5icXanvNrMSyuac5VKTaa6hXyOZxSR84m7tp1F009CfvZXOo82Qlls19f2Ej
62dgZCdCNh+UqO323GUs4/heZMonBhV6cTzMqL44ptqGweiyi2MPTOHtKFvB
2G5itskyzv5E2eZbUfYeYx3FbNP7nC2jbNhGlL3P2A5i9uPVnK2ibGAWxvo1
BXbnGzHr8BdnG8nvpKSZGOtvzVhzMdt1D2cTKLu9B8YGOAG7/a6YDenK2YeU
rfwTCyOfGzG2oZhd0oyzoUSWqjZjbGBDYP9jJGb3Kef2KmU/DkPZvcBuHS5m
H17m7BAjWTrZEmOHTAS2sEDITmuuDFkZZS1OY+vw0CBgtxSL2QHKvO1tLEvr
UzF2eFdgN1WK2ekzOFtCWbPPMHaEN7AFv4jZvCDOVlL2j2xLZLUcORju13+f
qbGXUgixCeKTf337ByNidDtZYPl+b4ncU0eEwQrivE8/hsGx/qaE3GxPiIeJ
LI02Rxv9iTU6WNxohXIlbaZs65+xHDPSD9j8w0I20Vy5ktqZylLFHIwNYnMz
Tzw3Ez2UK2kUZVsfN0aGxWc8DIvtQb0trjC2xUWH5csfCTmw0ci0JA+sEGr9
+7AEFcKwOE7VT3C6YQmgCe6oFZ1/87GK2htBReq2egv7RLaw04pynLSN1kkF
K2E+VlFkf6ioyWX9k6arqLEFIcPqylKvdGx7N/oWnPpMF51S15LYZTbfmAzH
QoS0eFYjQs5U74afQ7QCuaitBdIrzUk0Qh6t0WtdyxYpJqOoPgsipPUCQiZM
DKGJBSzHdhZIr9G3WZU99KqcRb1giJBL6ml7ffa0DhIhvXfC2W8ySq+iYJAg
Qj7sXh0hlwxuAL3qIiTILVchNwBn711MjtDJqfVIzC9rVtSHYyFCDvyoOkIu
AStsFXYDiP4dxrWxtxIhqUY/1GsAETLlBSHDqVK8myAR0ns3q8jKUK8QIf8n
5QNHSHeNm4dGrRchoc7GRdhmdjTb4Mr0MjCy+yFCZqRqu83YQ5AbSPRjprQz
qNAbSKfvqm8gM9V/weiyG0gQZW9uwNgYdl9aViBm3e05G0LZrByMjY0Admme
mPWYzdlIypauwdi4XsB+c1rMajpxNoWyQzIwNp4txUsqxWzPDM7upGxUPMZO
bQXs4mdidqgfZxvZyNL33hg7jd3PFqnF7IxTnE2nbOQnNgibxLJeupGYzS/k
rGk9Wbrwui7CTmc78mkxYrZSObczKeu3FWNnnAD2635CNtkimrPPKescjrEz
nwG7oJWY9VKGbHJ9WUpvgbHJJcB+NUzMfqHM29uUNT6N7cjPZr+cpniL2Uwb
zo5qQHN0KsbOHQLsvP1itvQxZ89TtoE3xs5jvwTP/UTMPlXm7cCG9OJ9i23v
zn8N7JxmQnZWK2XeHqLsyGKMTXkD7OymYtZfmbdhzWWpxx/YrpNLCCxaDof0
Fq39bNGi8ahKIsRkXEiSyUSwNv2B7TqtPQ3L6J1A/RJ18chlGiHXW8mSzQ1j
JB7lLYVGg2brFBsfYld+otxBF4/MzWrEo3nn+A4byEGeZkivP/4M8ahwjNKr
jU/ioR/Dqd4B4lHhZlqj2i1YowLrFLX+vdc8thkalK5XZQfqwT5MopunttdL
X5oj8SitIZz9k2/1KpoIEsSjgVeq49GK5x7Qqy4egdxTjURB57SPQC7jYSR1
OYl5e3Z2K1086ta/Oh6tAGuWGouCeatgXK+k1YhHy+E46rWGeDSVRugbVJmx
AdthS2vEet1sqFeIR8NyP3A86qzp3EXj7vZ+PII6t23AdtjyVrORTTMwsicg
Hqk3abs1ycf2VfLWMCXRoEIv1zOl1ZfrvHPpMLrscr1F2c+Xoux3jJ0qZs8X
cfYuZW0zUJYtikExYvZiPc6+oOwPC1C2iLGjxOzlA5y1bi1Ll6ej7G+MdRGz
VSrOfkLZk8EYm2/GWBsx+/IGZ9dS9k0blGXrwchmQnZ+i7GcbdRGlrKvYJtL
BfuBHTFEzA7sztlFlLXNxNhN7DH18DIxO0M5t2ZtZWnaIIzdvBLYYTPFbD7h
bDJlM80wdss+YIcOFbMVypC9oOybEmwrZ6stsIFvhWyKuTJvI9vJ0pMElN3E
2HAx65nN2SrKft8RY3ewR6n+A8Rs6BzOBreXpeFV2A7R7lXADpouZpcr8/YC
Za3XYmwxe5484J6YLVXm7SB7WdobiLJnGfupmH2qzNsnnWTp2jRTJDLM9IBF
69JjvUXrBFu0aDz6agyNRyET4ixCwQpNNEUWlpPhsIwW79UvURePyu4QEuYh
S3tc6yLx6BKbm4788UK9XsSuTvOCDbp4NCChRjxaGH9IF4/CqfxnPvJQzuFA
a4hHmSZKr/V63ThmY0n1XIhHh9wIgZ+fGQLWpALsodylJlClk7VelbnUs4J4
9Nkewipav8kUiUeV9nD2k+/qVWQFEsSjls2q49G6zN3Qqy4egRwSjERB50oH
Jr/SyV81JjHt/DqU6OLRxK3V8WgdWN8GY1Hwkh2M6yZLJR5RjX6otw/iUc43
2l73OFgi8aiyA6soy1CvEI9iOn7geOSpUas1HnrxCOp85oDtlV1ij7ecLA2M
bBTEo8/U2m7XOWFvPlxqxmbxa4MKvVx/61t9uS5M+AhGl12uEZS91xhlWzD2
pZid2p2zMZQNa4iyKsY+F7OJKzmbTNmJVig7lLH7xGxyX85mUnbBuzoYy16o
cMwUs6kbOXuYsvk3UZb9cu/oLWazwjnbzlOWqvIx9vIPwHaYImb33eHsWspe
mYCxVy4A6+AjZh8e5WwjL1la0RJjr3YB1v6KkE1vrpzbRZQdUVEbYa+1Brb9
UzE7YAFnzbrIUoulKMtOQnvxSUifrgxZMmXvDcDYG6nAtl0sZvOUefuCsofN
MPbX48C26S9mKxw4GynJ0q0iC4S9xXaPWu0XsovMLThbRdl5UzD2tiuwqtti
1kOZt8EaWfqsA8oWMjZUzE5Q5u0Fyl69Zo6wVaOB/XiXmF2mzNvpPWXpTnvs
gdOZTrBopbzQW7Si2KJF49Hq24RUXHf4tCQPrJH22C7DmzRYRheu0i9RF492
NCLkcV9ZKo0yReKR0c/QqMlAnVLfgtj1+mjYVF08Kt1dIx4ta/RIF49AvuiH
9Xo9C+JRQrrSa32LJEfvdVSfBvGo0TZCglVRkXFhYHXyx3o1YrvFJkF6VU6j
XjbEo5Uaba8BaiskHrVhu0fu7/QqygYJ4lHH8dXxKNdzJ/Sqi0cgP8V2BZ3b
sN2jztY8HmWTmEFkV19dPNpxtzoe5YLV/im2K2h0EsZ1/oga8SgbjqNeP4hH
j44T8oQqr6qMkXjUhu0euW8x1CvEo4MFHzgeeWncPTRq1/fjEdTp+Bv2iNiI
vXZoMuKfI+tjDPFoxVZtt3PuGiOXq1E5U/oYVOjl6nW0+nJd1rgvjC67XJ9R
9mAZyp5mbG8xaxvP2deU1RxHWfZOpMmnYtbuJGfN+smSuhRl2ftZJo5ituVM
zrag7PCdGGtMGNtIzNpf4ewgytZZjbI9gDU+L2Y1azi7mbI9Q1F2BWNnidmx
zTnbrr8sbWyNstcZ6ylmF//N2bWUPXLdCGFNZgBrtErMlijnttEAWUpcjbGm
o4AlxWL2wV7OLqLs30Mx1iwdWHmBkF3eTBkys4GytK0+yj5grIOY7a/M22TK
lp/AHrPWYht+74aI2aRRnH1B2XspGGvOMuJbHzG7sRtnIwfJkll3jLVgb8z/
HSZmLyrz9jZlLbphD4Vr5wH7V4SQzTRT5u0oX1lKeYo9D60TC+yb9WK2szJv
5aGy1PUXayQyNLSDRauX1fuLlo8xW7RoPHo4XhdGwNpJrX9fWFr4wzIafkG/
RF08KvuakKRRsmS8xBqJR05sBajkb/XUzyV2s1f4TdLFo4eONeLRqqJgXTya
TuW3icjXLR1eNYd4FFy7Rq+5OSd++pXqERCP3IsIiTpWixgxKyUJe0PFiS0o
lZ/rVRlBvZsQj3bRqQdK7k/GSDxKfAZn/1oLvYpuggTxqNae6ni0paIKetXF
I5APTTdB4lHicyY783hUQWLiTN6e1cWjPm2r49EWsBrOMMF6PQ/jOjKgRjyq
gOOodw7i0Vwzba8rrpoj8SjxBVR0tcxQrxCPLm/6wPGoi8bjnw/XoM43tE6k
W3a3qfT/58ge7AXxaOcubbd3fsV+m3FiWxGV3gYVerkOKa++XFcVrYbR1d5h
KdtzD8Y6szdOKo3EbPERzs6j7N7dKJsIbMUaMbv3Y85mUPbwVox1jQH2fI6Y
PXCKs7mUPbIeY93Y46qzzcTs8U6cvUjZY6kY23UZ+77XXDF75TFnvYJlab8v
xg66CexuNyG72jias4WU3WyBsb7L2VcD5ohZtR9n7UfL0rqD6DcOnjC2rZgd
q5zbdZTNRL8a4DeMfTWgRMxm2HDWdowsFXuiLPs2x85uYrZEGbIMyj58gj2z
848Hdke2mH2gzFvzsbLUBP1qqT+7s+zwEbJrmhVydjZl/UMxNoA9a97uImb7
Z3D2JWW//Bj9fsQAYLcdE7NJyryNDpGlvErsUeBgdgfbJr6DrdmozNvfKXt2
GcomsK9drBOzF5V5mzZJlrokYO/jhB+BRetR8PuL1sFebNGi8chyEts98i3J
A6s0AXsIMzoellH7/+iXqItHWXG0xCmydNoIi0cRbJssa7tOadCL2O1pQ27r
4tHopjXi0foRpbp4BHK4qw3Sq8VZiEcDA5VeG/RaIuWVUb0K4lEMhBFiFKxR
gXWKWv/ea8QkVuUevSqrqFcO8eh5T1olVV51xOLRod/h7C/toFdROUgQj4xt
q+PRrum20KsuHoEcXoG8cu986A6Tu+jkBU1JTJblLg9dPAqfpj2LGhVYmyqw
/ZSIaBjXpruUeEQ1+qGeJ8Sj9cO1vcaosHePDt2Fir6pNNQrxKMWez5sPHJz
1bj98+Ea1LlPhb17FDGFjezOf45svivEo2fF2m4XoG+cRLBkkJVjUKGX67Iz
1Zfr+hFvYHS1v9dStns9lE1jbJqYDWrPWUvK7rZC2Q2MjRKzwbM4a0vZ7WYo
y74JnvWFmB3nwtlOMB9fYjfuCLYpldVBzEYs5uwYyhZdxtjJIcCu1L/xGGBn
+XJ2P2WTczA20h/YFYfEbE45Z71iZCk+GGOjBgH77RExe3YLZwspu8AWZS8x
ViNkc4yUc2sfK0stz2KrVzR7ST/ztJh1jeLsOsr2XISyBYydKGbHKENmGydL
1n0xdgp7P2b5PTG7WJm3GZR9aoyy7H3V5TPEbEldzprHy9LzEuy1mxgv9nWN
q2L2/iPOzqasSRLKsnO7THxuf2iqzNuXlP2kM8bGmjPWWsz2U+ZtdIIsRT7G
NlNjI9mXS3LFbKIybxvMkqW1Rcgug8OOBFi01he+v2jlu7JFi8ajfpG6d4/A
ql2M7TLMfAXLaO2O+iXq4lHBaUK+nidLy+Zi8ShlJnsHnb9Z0CCK2L0YZxOi
i0dx+2vEo7y/XHXxKI3KlWHY7lHjEohH3hNr9BoVuN0ng+rjIB6VZxEyIcE4
fhqz/MOx3aOUTFblEr0qx1FvCcSjgNaEKeO/xuJRfSc4+71/06toCUgQj5r7
VMejfc0C/pe9M4GSojr3eCMoT1AMLgcxasoFgTCOtVfddkWRQUEkDAKyDPYy
jSgwwAybomICgsEFI3FFwQVFQUCjERUB9UXFF4OiRo1rRECfOe8okSCi9Pu+
e2vprm5udUNVzww059SZnmbqd+ve+/3v99VdMa92eITklb/h9R61r6BkZ9B0
thoZv/reE0bY4dH7D7FSbHgGWQf359XrzEVYr5HpGeGRin8HvMswPGo/k+V1
6QxeeNT+VPpEd+TLK4ZHV/0x4PBIiqpaVFKywyOa25m88Gjms7Rmx+ap2a0Y
HvW7i+V2MndW8kw6K/m6YXkpINdvl1tyfWznSKxdNpoA2Pe5s5JvoAHHtSl/
7E+3O9jbAVs/mYedRb3XNW/5Y3d942AXAHbWOB529qmInbbFF/t4y3sd7LOA
fTrOw95I5/1d/ZM/9pCdDnYLYF/rycPOodsJXHWEP/ZXLzjYqhlp0u4wHvYm
Olg7pcofe/7pDnYNYKV1vDjm5hWInZz0xzb80sEaM9Pkd7/jYW/ZithJJ/pj
H3TLdjlgLzyLh52bRGzDCn/s2x852M43pMmVO3gBx210Y4n6r32xSyJulS0A
7BdPc7F/pdhe/tjTXLvtMCtNhDoe9g90+78JM/yxNVc72FsBW9eVi/2ZYjv4
Y28e6mBbz06TjV/w4pjb+yJ2/Kv+2FWu3V4H2Lfmc7HPUOwIf+w3rt1uB+z8
gTzsPNrXNW6dL3ZpR9du77ktTd5UeVOzI8vRaQ2c5HFaW6nTgvDokd6RyC9S
c87pMQdZfTXe1Oz756Ab3XK39xHt8Cj+v+BK70yTI4fwwqPFVPfDYg5lZ6Sj
eNDhx9nh0bxYRnj05Px77PDocCAvHMoLjzq1w/BIPDojrztPmDiqBdCPx/Do
nqn2bhfIOnYYLzxavJ4+5UDPUx4PPJyhMuW4Axhl+R288Gh4FZb+jnWeJzoA
SRgeLaqzwqO/rJqFebXDIyRXDeGFR8N7UfIHTnh0UWT8lydtX2mHRx8ttsMj
ZM0dwguPFm/Gev0kY2E/0OAf8J7D8Oio37O8jlrKC4+GX0CfaGq+vGJ41H1y
wOGREhXNqOIJj/A51yzlhUeLf6I12zVPzSYxPDp2CsutsZznFBfTNmtYh7wU
kOsqe2eQJ+dvwNplczgA+8E93EVbdNeBoaf4Y+/b5WB/Cdhxd3JXV9EZJ0Pu
9scuHOhgOyN2Lg+7ZABdXbXWH7voIAd7NmAv+C0Pu3QwXV21yh+7LOVg6wA7
JcXDPvE2XV11nj/2pVMc7HrAfn0aD7vifLpeab0/dvMjDrbqrjQZ/A0v4Hhy
OmKr5/linzrqBge7BrD/eJiHfYpO0u//vT+2h1u2xt1psqGGh336Grq66k5/
bH1PB7scsM8fzcVuo9hf+WMfdKus8z1pMp3b1/XnWxDb9wZ/7Nuu3S4A7MA5
POyzN9K1YHP8senNDrbDvWlyyPk87Eq61LvPb32xf6p81cHeCthuaV7A8Twd
rrpwgT92uGu3reenScVKHvaFhxB7wXh/7E2u3V4H2EvH8bCr6Otor2H+2Bdc
uz1xUZosO4IXHvX5H3RabYZ4nFaSOi0IjyZ0s0MGZLU9khcebZDRjf5pq/cR
7fDo5F2RyL2PQ8iwjjc1+0O6RK+bM0LbqnOk4xX/6brODo+W3ZkRHj131jw7
PELykkhrTl6lsRgenbTSzWurzu/+4+pNQH8Dw6O5IyORhmfwQlbnFrwZKh9+
RJ/yQs9TvgG8zRgeHf4ty+vGTgdzwqNlO7D0F3fwPNFmJGF4NMiq1MibNX0w
r3Z4hOQ+n3K28K9Y9iMln+KER1dExh+8+vVD7fBo03w7PELWQ5/ytvD/cCdd
udY1IzyiM8GA1w7Do19dy/LaMtkuApVDr5wnunHZTnyiR1/Pl1cMj9r/Za/C
o0G1yQpBEvrWTWLRkShGFSmqeXa1x8eMw2MWvnDNrdhpVRgdHT6SZbaGuyGL
d+FaFgXU+tS1llqfO+sdrFyq1vsBG/0ND/sRnZT86yP9sWenHezDgH3vIi6W
zsLsOtIfe+4gB7sCsJ/05GE/ppOSu1zjj61q7WBfB2xHwsN+8jhdXHWFP7bf
SAf7A2B/zd3s5rOdiO3U0R+b6OxgBy9Jk9Vf8raP+SfdUuqkx/yxsx91sG8B
dtp9POwXh1Hsgf7YZ2c52F5L02TMJVws7Z08MeWP3eyW7VrEHsrDbqR78J/w
ii/2+aOqHKz5RJqsfZW32c3G7ylW8Mf2cKtsBWBbTedhv6ST0ITr/bH1rt12
WZYmHQgPu6ktxR7sj31gi4NdCNiN3/GWh26mB6wc/4Y/9q3XHOzRy9Nk/BNc
7H9TbD9/bNq127mAbXslD7tFRexxn/tiX6h07fa/VqTJH7vwsF+di9hjN/hj
h7t2u2RlmozuxJuZff/76LNWXpTts6ZVUZ8F0dHlx0Qil1Sf318Yh6x/deLN
zP4+hV70ttXeR7Sjo39qkcgJq6FNvZy3rr8FzWhLp5+/1YuRjovqv+1tR0eH
dMyIjtZ+NtGOjk4E8qvVvHX9p3fC6OiYFhl5fXHwA/NOA3ofjI62rrWjI2Sd
PoC3rr9FLX3KlzxP2Qd4OEFlysQLIvSJtlzbkhMdbXsBSz92ieeJRCRhdDSl
txUdvbtrB+bVjo6QPPscTtRbsW0VJSed6GhqZPxpVVOH29FRu2fs6AhZn5/D
i3pbTKQL11ZkREdT8e+AV4PRUa87WF4nTGvNiY62vUif6KB8eaUbix8fbHSE
oVHO0Bo+5oZpvLC3xUxasQ/kqdjbMDpqWMsye9l03rzZFnRlcMtb81JArUd+
YKl17WdLsXLZaiXAnpLiYQ+g484H3O2P/fwDB9sNsA/EediWdMlWi3f9sRtF
B2sAdtFQHrYVDTQjO/2xWz53sBcj9iIe9kCJLiva6I/97hwHex1gt0s8bGs6
lvDzq77Yl6Aps7GfAXbuj7y+o4NpB9rOtf7YrtMd7KA1aXLJszxsG+rBf7ze
Hzv4Mge7HrC31POwban17/C325dmuWVbtTZNWlTysIecidgf3vfH/llwsGsA
O2ELr+/oULoB+Pbn/LGb3CozXkqTZdzJYu1SiP3PMl/sy0e4drscsO9wJ4sd
RiPPbSl/7LlrHWznlyHe4Hagtaf74X/f2h87fqGDXQDYltwOtPZ0R6l/D/TH
LnTttsMr4PG4HWiHz0Ds1rn+2PWu3d4K2Ju4HWhH0OVw313pj93l2q381zS5
4/e8idmbzkafNX6Tx2fdRn0WREdv1DNsm7eR1WoOb2J2r7vRi555k/cR7ejo
swWRyOK302TAJN6e2TW7MKOPOBMADpwX6fjp5ksX2NHRa49mREevT+9uR0dI
3n4hbyP5qrUYHR2acvN64LwWD21eBfSFGB1Vz7OjI2Q19ObtjTOCNtGLvvc8
5ULgvYjR0d+PZXm96+x2nOjojDex9I/p4XmiF5GE0dGdt1jR0ccLlmFe7egI
ycvbciahV5zxN0qudqKjmyPjB7zzw1d2dDTqRmvdGn3KnW15k9BH9Md6PeWd
jOjoZvw74H1Ndz26IhJ5DCifnMCLjs5Yj0/UcVu+vGJ09N6/go2OFHrqiic6
wsfsdiIvOhpBd3NcdGNuxW45HqOj925nme13Ms/VjriPUibnpYBaJy6x1Pr6
9BVYuVStSwE7tjUPe9kQxD78vD/2+o8d7FOAfaUlDxujeyk9tN0fO0N1sKsB
2/pnnk+MVyD2wa/8sbO/dLB/x6f9Px42QSeiPvCJP/YPPRzsQRvS5N8beNha
WggLCiiERa0cbAqwDdwzYkbRTp75B/pj35jhYD8F7NKLedjx9O3s9uX+2B1J
BzvwnTSpbs3DXtMfsbNe9sWu6+KW7d8AW7eG58Fn0B3kp3fyxw462cH2fDdN
np/Kw97UGrFTD/XH3uBWWST4fw3W+c8NU8I73Zh3/rMkSrqkyYJgQNMn67om
S3j+s6qK5fOfS/FPMqKqFFWNSoXIqomTXuVKWa2UFFIpyXKlIhumcBa4JRW+
VdBd6ZWyFhWqBdlUNEnSVSPqfOoidhUmjxorKAARhTPG1NcLkqqLFfWxxJUX
965oGDWmFgp7zDhBVmVVVDXZEMSKsXXjKibXJ2KjawXxLKFLj55d27RBw7ig
34hePfqfCSD4dHG/AWeKwoDznO/wI34JH3t0H9Ad/rNnn+5V1WdWX9pXyLwf
PqgaGJvILiUhCJCqICvwvfUd/akLbYSMf5MuHy001NULo2vH0mtUUqBXXSpF
r4aG0cK4CXVCdkpJ+IvaWvipggmbgmDGwaxjgpCAVFOQokggZTU7pfqJY9g1
IZF1Jesbsi56k1UAQAJiopY9v0RQRZCyDr9DilrKyW92Sh5yfe34rAsqiV6e
lKxSiuFPlCnkEUxCIPA70fOnZJOwpFKjR1KbwMvO68QJ4+jlpAQ1yegilJwI
9RVXrc/4HaQmQimKtdhIZKdUN66hoCs7JayPmFtK7gVNj6hYl7iHKbVxFKVL
RJGJVzuoplyNUUURiaiKKKlm1P2ImsKytEVm0pIUi9FIHol0P683TyYyFLkO
RZ+szZBOYDJJAVk1cmThlU0QMrHkYcslVstMKmUy87JkE4RM4Jl1oGmYopwh
m5iVx72RSZZJqVAJBTbSlRQvZbTJxTavHtMpwGywdVVjYbWuyXhjt65YyZYZ
BWA21BA1y2xEt3WV8WciILMxKyGyMtWCW6JMs4HwTNGFM9BJ4+W6cNNUoUmS
XVee5cgrbN+/9x7dx+bQo6vQlmPYaNsc+uBgbE4Ea06Jjd5UaWE0VTHL5lCx
BFLRIE8mCdSjS9Zle3AgmzqrH7T4EDx6tgf3xhR759FRR0QDZJaOFFUy5Vwp
SZJCfbpBRFnTiKZE3Y92nGwaekaYXLxU1KJiX9lWihyaUlKlUIqpMSvC5zeg
vmM6y1ctPKMmhRH76pYlYckp2DpDirF4iLEv10499pj7zgam540GqJFGhf6C
GBWdiNK2R3WvQ8r+1QMKCSmxpTEyQkq0l2CsT8MW0yhJbGBZXaYVZl6WNQZg
fdSeZSs2ULOt0QwuNlAVRS/8LaWfIEUJ6ULMrllBgrznsSW4HmZE/S6p7uVn
RWbMasOUsNqw2D7q7akVWRqshVQ1k1nYXrdhWIn0LkW2LlQ72inQdVCKDvnU
sd8lj7cXZOsSrd/HYPJwjYJrNFyVcE0QPCnpUEIGXqr1GfsloL50k/1OU014
UoLUhYlwNVifJ2CRwnW59XuMpZidEk3BZM+uYwopli/MH9qlhnaY9KTUYFHx
2SHfQp2VL/x3PlzVcF3kTQmjL80qOaTSfGCqalZJZqcEngMUyf5VW/kYC1cy
uyQ9pZewUhFZyWGe8H1DsfKpEPozO6XR1s9+Vslhnk6Fy7TySdhPj0VAPuRU
Dpl+r8Stp/C0ygL8n3BaLpl+f7qbb089aazEZCtvNAXJqqcUqzvDm9JEq8Qq
MlKWrM8XW3XX4E2J0i0rty/6nWRdUOaKNyV6o8Cs3L4EKzW8onCpOaUnWzTM
i8ZSofUkst+t1HP1FLXyolnfnWqlqLmp5+YJ/bNt0WiLMrZOSRq35+ali+Ba
MtpgV7hqwKRrLvR4FkMquEeZvXUSYvdW6KXqrYiH1heM6trXeit0I7u3Ima9
WaTkvfQlmXajavDKWKDdYEQimV0ko2u2AelE31MDkowiQhLaqBmsyzocM8JK
3GfNCD4b0EDH4WciyfITXEiS0wHBQhCaElSy3SGR3cDVdLeuXrRBE2r6MpeH
N9UMgusc9yYnJbtLww4UsI7yNp/4h+hE7eDgKiGn6dSkSlU2ZKXgprNJSACN
Uw5FAlBMZF9uSRtHAvBTVYqVANx0nlAKCRggAV2GSmhOEiBsWDQECYABmrkv
omUJ7JUEkpACiRcpAfumkCUgR0UCElAV0ry8AGQ4Fk48HWP9bmUJBCoBqD+1
aAnATb2FEkhAEStNQ5JMI1cCqpFfAqpkKjiRTBWj9kfNcDQhS4YiEmLKjaIN
KOc4CUUbQNVKNjJuz5xBbaQwZdAGkdg4qSnl2tGeaSOZYr0cXm1g65LUSqIN
fLtNFKsN66a82tAMtyeUqw14y3B6P3enDQXcg2jIzes9GQyz1gxLAtgNUXYP
gUqg1h3oLFwC1k0huwclKsN7sqSoSvOSQC2LkkKQAM6siJUlEKwEUjjuUqwE
8KYrhdAloNIISZMJvBsWHCGJUckNiKTGUECKzdMIQQGQUkIpx0EBKkBheTWL
iYNwVLWmD7sp5DhIxZ4ihZimrjUrJ5Bi6g5HAjg9qewEgpSAhK61GCdAJTCQ
3RSyE9CpE1B0oinNyAngUDmuAQhBAQqzjLITCFIBOF1DL9YJ4HQNbL5DdgI6
dQKmqkh5wqCm6wRwfoceznCBzIajy04gSAlg/SWKdQI4SyYRvhMwqROQVc3I
M1zQdJ2AzuoueAUkUswGy04gSAXo2G9RrBO4Aq4+QuhOwKROwJB0rVm9CaAE
wnEC2CyXnUDQEsAJwUX1iKIEcEJw+D2imkidgEgMOc8K0abrBAw20TkEBSTZ
coyyEwhSAcQaaSlKAXgTTrMO1wmAAtAJaLqk5HkXbsJOwGB7KYQjAaPRd6TY
15wAis0s1gnYN4XsBOisCYPIOq5TbT5OwJpEHYIC4mydU9kJBKmAhMnyW5QC
8CYcFwjZCcjUCWB/ULOaPYpXPBwnEGcLZMtOIEgJYCdbUQPDKAG8KfyBYY0O
DBuGqqrNygnEw5oakSClnBqxvziBlM6WEhelAPumkJ0AGxgGK88XBjVhJxBn
xhqOBNR9cPekRnQCKvuuqPnTDdb34c+f1ujAsKHp8DrcnJxAkllICArAxqXc
HRSwAmSNlWBRCugksJtCdgJsYFiE9r7gLfOahBOASowlQ5GAxhrMshMIUgJ0
C4hinQD8rdBNCN0J0IFhQyG6XsQimkZ3AmjxeiiLiRNQX/GSLSbeX5wAbhhS
1FIZVMAAoRRLZTQ6MCybEAU1q4Fh1TKRcCRASjZLen9xApo146QoCYzA/+sd
rhMwoyIdFpN1Q8+3krIJS0BiA4chSACLs/wyHLAEzGSRs6RRAvZNIUuADgrI
KjGMZjVHFHfowIoMQQIoLq0sgWAlEE8UOUcUJWDfFLIEaJeorMhSMwuEVFaB
IUhAZGsQyhIIUgLYmBc1Q45uyBkPf4acGaXLhis1XdWV3FEB1SC7OehG0xVV
VnRdj7ofiznqRpdFydAa46gbtZathwleOzhSrZRmTBmehRiudnCr+gSkFE+y
N/l8Fr1n2rFLznvUDapU2U1KRWlnd9t95z/qxlNPe7YxPt3lLryjbmxNmaKi
SFIBm0iDyqimZFEziC5BXOZ+dDYmt1VmlOqsG9xYSDUztBOYTmoVtidICbeU
tvRiYktJ2LCHqDu6CUAnVHlK7lk3GMMYe+tjsm2K5A5d7aadboyzblSrAQyn
edVKs9sVr3lVHDMKwGyoIXp2jzWsUhT3tnm1zUatFBVdVLRCm6KCzrohomaq
mun68kY864aumdLC2P0eT9ChgWrjNlVGGE2V96ybWpFNiQvQpec76ybG9j4n
4bj0cM66sXVED+bMOetGVs3dnnWjiIYum6YmaVH3Y+OddUOVooelFCleCqXg
KSMJKzDBICWO7SekaogZ9R7qWTe4824sFmLwy7VTjz0aOf3Xec+6ASP1nHXj
2KNeqrNuaGyQ8V1wZ90olg8t7Vk3iYzw2L4sawzA+qg9q7ln3WCe7JUWAcQG
qmoSaD4LjA2awFk3tA0zQmnDRKvjcR/09t6zbgwlgBcT/OPyWTfls27KZ92w
c25k63QayZMSvVEQ8p51g99H2WdP6ZkZZ91IBZ51YwruWTd2Xkp91k2mZzEK
7lRulLNuaEQSygKjuHUC477WW4GtufesG9XuFA4qIiFq4Z1cTWI8Ds0olKWa
dEyhNEs1G8eMMsbjcEmqmQoyJMk7Hqez7gLdPuvG28DlG4+bhN8PEoSRgjUe
F8vTWGOXhu94HDbQ+Ie88TijUlWIbOQu1WzqEjBDk0BptrHenyRgshmPxUlg
MLspdAloCkjAVMTcnbuauARqQ1mriRKQS7NWc3+SQCxjbl7BEhiSMTcvPAmY
UVEDCeiKnDs9talLIB6aBEhZAgFLIJVx3FPBEhiRcdxTmBKQCUhAVvXcwwya
sgRSrGUJQQKQUqrsBQKWAHYDpIqVAHaApMKXAIFYqFKVNdFsVq/DWJliKNNT
UQJiaaan7kcSwL7YeLESwL7YeOgSkEX6LiCJdP5KM5KAxNa/hiABKM7aciAU
sARweEUpVgIxSwYhS0BGCShENI3cHRybsgRkVtThSEAqzWrN/UgCeEyvVKwE
8KaaoaFLQKUSMGSJNKvXYRxIk8JZa2BVYlkCQUogXrsH7wL2TSFLQKcS0FSx
eY0LaNYKwBAkgLMHzLIEgpUA3Re2WAnYN4UsAZNKQNE0PXfBclOWgMYqNXgJ
4F4qsdKs2d9fJACpS4kiX4cn4/fDSvE6rNDXYUUCN9CshsZwkx8tlNdhXCYc
L78OBywB3L+xqHEBlADu3xj+uIBCX4dloutS85KAyXoYQpBAgp31XZZAkBLA
EjSKlQAa69VC6BKgr8OyKYp683oXIGyBfAgSiLN5nGUJBCmBGGFeuygJ4E1D
w5eAhkfdG7oskkLWrsiqERV6ogT+v71z65Fltw5znv0rKoBh+WnA+6URxAe2
rBMjguVsJ1IUSVun+uYHPwUIDAWx/dvDRbK6qquqZ4rTXKyqaQ4wOH1mD6fR
3esjucjFj93pJ/L8yZWuzvgXf7foQL1s43mB+LN851auMADQoudWosgxChtv
usUodMwQ/Z0S0kc/7c+tQB8C56+eiv67CKJ28f2Q3xpBDWeEMEEO/cPuPOez
R+g+CiDbV63Cd77jc3Bs4ljsNoz3DKBzH+tzhzf9ZvTg+NyFhdvAnw8gvyLH
lCB8XxNRG0xnOKOwrPsymUfhs0ncmoRRGBrhb01yvyLnOku+MwTaUKeFgEAb
jOIVgWwIwGOduDX5J/j5jyW2JoVfkWPMSrv4qNsmEDiiLUrbuiidHwE/u05F
AE584m9NCnoQ5o0aZtxbsyAX0wZyMWtBJECyeQQSszEeTwXnz8bgcNmJlc7G
QKUZlZk34WVUauaYTEcp5zgbM2BCeVanfx9DM6WuD0ys39wHySWlSsDeYHxU
Khc79nlM5lysDRux6xtY8XMxqJJ82sD6Z75M2utw3OcPK6LLVCard0E+C6UY
XZDXBYi1RSaqH5IzxNCdyGTQBcGNHt1NM3liyC6vtv82EHP2JlxdqBMCL4ho
MTohCJLzJuZw+J0QVXG29WwAMXFg3EUGl2Z6Ykla+UilTKgynLv/6x8mqJQ5
YYTRVVTKYI65oJQ3goWflVmQvDS3O0p8/MlQANKa4LfIH38TlbKJr+nZHOKR
TW5epTzyI33Ou8ijf697bbfvPCrljinJuTJLcgtHGTAlrHSdsaDscHvUi5Qj
Y89b7xaKlOE2D9LvWGQUKYN/rvAwH2mh52DAg88X3IuRmgyUeO4uU5EyjBMm
Xy/tIsrMXIP7oJdeQ6TsO1cUkTJ8WKJM7fh7nevlFkY5OlcIxPNUpGzj/2cK
G021lEtEyr4jWiZSFiBSJv1IvqZI+RKOWCIsipjQUazcVZ0xuqqJSHlw9DXT
gD4jUobIhs0230nmH9BxRMo3jsBHTsaOWu5C9qFIWREijZLu//qHK4qUL1Hx
hkKKKiNSVn3fCCUVUEBlTyEdow9KLJ6b+o5FyuJ0p7bNP/V9N07v49Fl7otE
yi5IxyLlLh5FKZGynxugVILQcnfYxKgbRuHwO0Zjhujz8cymImUYFa7PL16H
GBJvRGjC+dK5wRZEypfQ1+P0YYWvTSg22o9Fysc2PmO2LcAqUo5fVaT8qiJl
HtXH4yj3DZtmVqQMz3oI/z569+RNy7xcpCybm5Z5NZHyYGShTKUtVhQWKfsZ
CUppP/TgvIzyp+hqxfE6FSlDKYl5vja1jxtDZi42fRA3W6hK8mGEUpjndxTK
FOatE0aDqiQYKmyOm5zer0o6he60q0qy4y50rirpX5vQnXZVSV2jfviOSxof
ViVBl/n926OqpICAdggwzRav824BAU2xCvPA3FuoMO+VEOAhF0hCAOYqP2sK
IMC5Q4DOFVVtGQEWlsAQEGChPrUikBUBGZ41CQGYRH//qwIICOkQIJTvCwHI
h3F2/2Cll1QEMiPQhmdLQgDyS8jQkRGQB2LhClhlp/7ALSMgsIQJsHVWSJjw
QggI3p+FWIzA3zShEToC0uUCzBqyeBllEwiAnxrlqKa5hFCvCOREQMZLv5IQ
+HUTVkmREdA+F6DK71HtCAGNVWMKdXn8C5ZBrYsAKHNOqQiAMueEPwrYA2dv
1hqtdrUoCucpcCyy5tSUssi+EAJwBrxNRaBrhIsApx4BQ4XaVzrchoM+CAi0
sfipIpARAciuknOBrhEyAtwjoJjiU3nalhGAgRUlHTaw21DT4ZwInMP/qxQE
/q0J/w8VIcgISI+AEHTmeuYtIxADEgEBExLtikBOBKBsIykdBgRcmwLpMNce
ASbJzO1yW0bgHI7GIiDg3nj5letsVkFAqcR9AUDA/X6BfQEe0mEiGd0XAtdQ
HI6AgCxW/P5CCMBrI6kIQKPvv8JGQPh02Bgl9K72BUC7KiUKAjFcKgI5ETjx
UNaYhEDXCBkBnw4bpY3c1SgAgXrWKAhAmfi5IpAXgStL3BfwEyFWYl9A+HTY
SMrMrvYFjAj+ZAQEIExqpWhOBC5hgSFpX+Df3c//Y1NiX0D4dNhwbsyuVoRM
vBI9PwI6XuNeEciJADxz0r4AIPAPDfq+ACPxILgRhtrFh3jXVwhewoHG/Ed4
4a+fVncLQbQiHeEdKAQvMvQmT8X/XQxxMvWhP+hGvw2UVL0BThVSCNpzqAbu
fpbPJHAx4fzj+h3o3Mf6yQ40vktjhaA/ka0zBJAbh11sUGPETLm6JRMdRVAI
cqGsUJwYcugfpigEJSNM0zUUgnAYAw5l5B/AwdCry6xkXINOuos/cOrCTi38
lz1Qlj0XfxOFIMReDgdBkkLQpeB3z/Q549CZN7flwbvvLArBG1NcUOiAPx7Y
HWVey0mYopKD7aV/eDO+dJTRUhJBkGyf+pPBGSWCkFzIa9GBPvKi4xQDXhu4
ISI3GTjx5HW6fjbgBu7LfSD1/EQ/7WJK08X99BoSQd+9oiwRQPcK5YMrd6/2
FkY55odycMsD6btXr6l4+lj+LWyEZWwsP3vcFS2TCFqQCPJ+LF9RIggVdcNy
1Xw5iY+t8+pdlcXoqsYSQVCjnU9Zh/Q5iaB7tqsIJzgRhnQUieCNI8mVsSPd
PxdCsocSQcEcJpxoyQ/9w/Ukgp4UgUIKDHJFBFygK7ExFYI6WuDzzMLUmxWR
CEKfM7Dg55/8vhun9/Fop5tosxJBF6QjieAtHotJBP3coH/fMqb+5xjbZSWC
dpCQ315TiMYM0efjmU0lgv6I3tPXT8QYEm9u/DZ8cZqyAYmg78NQlMEQLe0X
He3HEkEovGufXUCCX64SwSoRrBLBoPoTUfs3fibfsGlmJYKujdcyiMm7Z+Jf
4+EZF0kETfxrPD5j0xSXCN6NLDM3Xb+7WFFYIuhnJChHXPxqRZkZSdHVCvjL
Y4kgxH77bOY4jBulZ05KPYibLRQF+DA6oe0pmC8cRoOigDMNJYi4RQG+jI/H
k8hhQeK+g5srChg28kUBevRM3ZLGh0UB8IvQET8qCgAEtEOAKDde7Q2BCxoC
Za6nfCUERHjGNARiI3QEJH8TzBqh94YAzpFxj0CZw4KvhEC8sDgNAdfo+z+g
I2AORDoEDLXTYyIbRwA+RBwE5Bfc/VsZAXhdyQjERugIMOsQEErtbhS4oBwW
BAQKXVH6QghAKSZLRQAa+X/HRQCuiH4DZwKbnpTaMgLwglEOCwICZP0Suy+G
wBX2BFIR6BrhIiCJzwUIEzPXkWwcAZyTUrItdlLqVRAQ4QiASkLANfr+h6b5
qUFHgAEC3AhYEt8TAsdwmgIBARsOo1cEciIgBgvYixH4pfu3H/AREB4BJfe2
IgRvKcqRcWlCyVVFICcC+piaC4igkm3wEVAeAaHl8vrvTSBwjtWl+RHQ0fxY
EciIQDuoz1uMADSC8EdGwHgEmKVkX7vD7oUfcbbGVPiuCORE4GxS0+FBI0wE
6IH4dJhTovWuVoSO8GHiTIRErLmtCORCAD47nbovAPa0H/H3BRwCPh1mlnG+
qxUhQKDFqRGKRaoVgZwIwPG7NhUB1YRGyAj4dJhpbthUH7VlBMDugbMoCn+t
LopmRgAqqk0qAlBRbfAR8Okwk5KzXS2KHnU4ApUfAXEOb2dFICcCcMQrbV8g
NvqpQUfAp8OMK0On92ttGQEIRBwEXKhcKgKZETjx1H2B2OgHdASoT4cZnbVf
bRyBM4qDCBAQrCKQF4ErS90XiI0adATCkRmXDjsGlh7iXV0i2F3hnf8I77kN
Cut1j/B2HCAc4R1IBP39Gdcn4/8uhuzMNYUPutFvAyVV74CjhSSC8PEq0/8s
n0kAuubjJnaV5j7WzwVQ9y6NJYKwgXwxTwcQO1A3G3WxwazVk50ZQZWYlwhS
N+RKSt0gfnuUoBAUxP1J90srKAShk8FZzYZ58bXIDBYOPggx6MbaqLB0z9g+
ME89F31jhSBMVXR5heCoS/6cbwi8AKcZ+0cmhWAgyjFELHcv4MNhHRjzWk6t
KdPMatcl3x7ehvkIWTGDIOwFgMDkhk42TPwFL7zkKN/hAlt8pzjqewNsm00V
fAxCjrFBEMKMsycxuQspMb196VEnvYZB0PeuKBUj3ppTZK/w3d5V38IoR+8K
gXiaGgSF68OPz1uCurDhRHFulvZEiwyClAhppKT9WL6iQhBugmUaIyOBD+Ri
V++rThh91VghSC+hNj3jkD6nEIyKdlhLRxjScRSCN5AklWak2+IOhMcKQcWk
FZK4PO32aD2BoOfEYHFyNSU4gbyZxikunKpmMkiCIOk6PnD1Pjf1HQsEVawH
QJv6vhul99Go+DKBoAvRkUCwC0dWyh/oZwZ9Zpwx6/f2mjL7xzHohkE4/I7B
mCH4fDh3d08MchVQFNgHnsxPzAw0p5wtuL8kzAw24A/0XZjF6sLsFx3qx/5A
33E+KzaHX67+wOoPrP7A4A9U0fhHR8/kGzbNrD8QSs4O4fHo3aPxr8kEfyCN
f0026/kDhyPL8vXkVfyBfkaCUsvg1yqKzEjKrlWoSzPxB8JaBc85I2FETUpi
HsXNFuoBzvFMN9KGgv3CYTSoB/DWlWe3s+CX368HiNsW3ZTajibr8/UAxzBc
fP/vsR7gOnqmbj3jw3qA7hfn6wECAvpNM6XV5F7NzSNwRkNAVwQyIzBQHC1G
4F+aQVUYJgKUOwSk2d8owAgaAtNEtCLwHAImrHonIfCnJjRCR4BJh4AgencI
SBR5GiBwLCJPeykEzv0zLUbg39y//ZemAALCOgSInJ4Q2ToCGkWbAwjYItqc
V0IALgJqUxHoGiEjwA7c5QKUczM5Krt1BM5oowCvo0BmBGDPQ6UiAI1glRsZ
AQG5gLJzzpBNIwBhIlAQgLMZpCKQFwGYWl5SEegaISOgPAKGUrOviRCUm6BY
ZGHlnhexyL4SAhf3vp9SEegaISNgPAKKUzuRp20agbitioCAjoBVBHIhcIqv
KwkBuE/o9yVyAUY8AsJlw/uaCF1C2RwCAiqc0awI5EQATvWYVAT+axMaISPA
PAJMM7Y7BJAmQqpOhPIjAO9gWjp8CsGKnw6zkA4Ty6bXhm8ZAQgPg7Mi5ILS
1BWhzAjAJThp+wKxEf6+APPpsLSUk13lAhewXeCUmkERalsRyIsACGFZKgLQ
6C/xEfDpsNRU0V1NhC483PuAgAANd1VUBLIhAIGp488WI+AagUXW/wwVAe7T
YSk52deK0EWEwm0EBEj46xWBnAhAoX3avsA5FNrj7wtwnw5LLoyc3DS9dQRa
nAIJEk6BVARyIgAnkNL2Bc7hBBL+vgD36TCcyCYT8dWmEYCDNig3SlAIjyI3
SrwSApan7gsMGmEiwP15AQWjABOL9R6r+wPB/MgGQ0C+I7xe3CjXPsIL0Yp0
hHfgD7THMJg+Ff93McSXnzn51vuobvq3UvZAMKzBSfDuZ/k8Ar6waRNLKXMf
6ie7z/guje2BYFijz/rbIHzcKMzgRg8i7HQ5givywB5IBYh/tTWH/mGKP1C6
P8pX8QfCEHFCWc0GaY0os63fDXMx/iAW4Uicv5WtiD8Q1L/HB5GeRaIy6w90
o/LdM31ONgTc+EGLjL7z+AM7pqQQ2vX2Hw/rjjJgihHODKVK20P/8DbMd5TZ
UgLB8zWUid7YycYJHOCE9daCw3zkRdu+ChlEVpGbDJx48mYEghBrR/YkJ3cx
Zeg0W3rQT68hEPTdK8ppasBSljmU/173qm9hlCFsIBBbMhUIwiE13mYLG9dt
ELm4K1ooELTSSJc83wbzFQWCsIlGOUZKAi6S62XtvqolGH3VWCAIfhKVQ+n/
rkAQ5sfgWjlKlDEdRyDYgWSEG4NHqn/uhnnyUCBImaXGMmbVoX+4nkLQkyJQ
SBFhEaSMQrC7HA5MWCKasI7vLCk9N/sdKwRhfnp5YInPMvt9N07v41GwSdo/
qxB0QTpSCN7iUZdyCPrJwQkl94fhuYhqpYu6YRQOv2M0Zog+H8/d1ROD3B+Y
PeWaHLioMda6wWXh5GADDkHfh6FcYAKjfftFR/uxQ/DEwnpVvgX46hCMX9Uh
+KoOQR2tf6M5bWjYNLMOQdfGW//45N2TNyPh7Vk+dAjK5mYkvD1LaYfgcGSx
0/KGd1crCjsE/YwExXzllyvKyN/KLVdcw0x17BB0M8jnldqDuLHEiGmJ/IO4
2UJNgA8jlJoAv6lQRqC2ThgNagKg+zw9SODy1QTA1j4dpIrtkjsFodH3X/cl
8u34TsFuSePDmgBQxsIvPqoJAAT0G6z1i6k3ZOMInAkaAmUqw14JAR1mt2kI
/CbMbtER4NwhwIyYljRsHQGOhkCZ47KvhIDtl6OWI/Db0AgdASEdApSIaYn8
xhG4oG3/sTLVPa+EAKzJJCPwvWn+tUFHQB6IC3ithd3XRIgNQj87ArROhDIj
0NlYkhD4WRMaoSMgXS6gyZxPfOMICIqCQJwEVQRyIgCrjDYVAVhltPgIaJ8L
SGXt4rqnrSBgUa6p9mWYZaQJL4QAbPHTVAR+gn/7PToC1iPAwzbtvhA4o5wV
hL/MyxyUeiEEwMRyTUWga4SLgKAeAcYMmyr1t4wAvGicdJgWO+zyQgjADbTJ
uUDXCBkB7hEgkvN9pcMQKicUBNxfOn7lHdZVEIDaoGMqAl0jZAQkIECMNmRf
E6F44CU/AlBACe7GikA2BOB1HVPTYdfo++9KpMPCp8NEE6L2NQrI0EngIMAq
ApkRACVd2r6Aa+QeFtgXED4dJpJRva9RQAXNGQICl6BmqwjkRABei0xF4P+6
f/s9OgLSp8OEC5cP7woBjSVTvp6LyZRfCAEw4PBUBKDRf8JHwKfDhCpuFnsr
NoGAe3dalIJjWIVTtVI0MwJnnbovEBvh7wtIlw6zN2uNIPsqlrbRUZ0fARfy
6qspAtZFQIbcLW1fwDX4/rcl9gWk9ghoK3c2CrTh6BUCAu4vt7VSNDMCcLg9
bV8AZrkN+r4AIfEguCVwx9zSQ7yrOwRprL7Nf4TXa9nWlQvFaEU6wjtwCF5y
CDvuYsjyxdur3wZOql4CZwtZBOk5OvHidz6TAJz2PW9iMWXuY/1cAHXv0tgi
CCcfzbMeCwggNw4L+WbcF5+uyUn34mYtgowKopgbeM2hf5hgEZSEEa3kGhZB
dsQ67XS2oXayTPx1tkqIPxhWfckanJduMeJvbBGEDow9eKYsHpV5i+Co+/+c
cQgmIPLcv7bbdxaLYGRKvRFOrOYLBnZHmWdKC0O4VcIe+ofdQH+jrJhF8Gr6
9Nmzk40T/97b0gM98NLyoLg70XAxUOQmAyeevOPUIgg2g+OzE91hTNG5G7kf
9NNrWAR994pykg66V1ksP3rYvR5vYZQhbHwgjo7lQ/d6HGhuM4QNNUSJJRZB
3xUtswhSIY2G3L0bzFe0CMJbdkWxCMIlkrSIG+3dvoph9FVji6Df5szhFXrf
IngJ93VdOotg3jEdxSJ4A4kxNy6riaBNq8cWQcvcOO6SLHXoH65nEfSkoFgE
/Y3DRdJ38Led45gKPjcdP2/YSTyz+fh9bvY7tgiC1oOJrKQkxOl9PNKpVXje
IqjV2CLYxWMxiyCLK/z5c3/pehdZJPfqom4YhcPvGI0Zos/HM59aBA0NcZJp
ciCpFNounRxswCLo+zAUi+D5HFZWvuJoP7YInmEGcMrQh1WLYLUIVotgcP2Z
6P2To2fyDZtm1iIIrxNO5MrJu9f9NR6ecZFFsPtrPD5j0xS3CA5HFqmnBQ7v
rlYUtgj6GQlKXds5+n+/1HJF3BwbWwRhl/P44PaaT81IlDSLdyO2UBXgwwjl
aiIII17szPgKYTSoCoBK6NMl55RktiqgDc9mj7cFifsObrYqYNDIVwVcRs/U
LWl8WBXQ/eKjqgBAwL5JotTMFctbRuDU3N3kkRcBsv6+2ldDAHZgdCoCsRE6
AlI6BNzkYfHsYSsIQHKKgIAJR9QqAlkRgC7rmooA1IX9ER0BcyDaISDIzBXL
G0aAx9UxBARECL6KQE4ETu4ZTqkIdI3QEeDUIUDEjDlkywi4D/WKUiQPmxu0
WJH8yyDQhkWqNATasEiFjIA9UPsmLGdwB+COEDgGuUR+BOCqb1NzgcwIQK37
JRWBrhEmAvQAFMg3oY2lu0qH4TKxC8o5Ebi8mX+1Oqh1EYCVoLgRshwBWAn6
67ARgowA8wioUE66IwQ6I0V+BJQL+6+8tr4KArCDJVIRgB2sX+EjIDwCghO+
uPp1KwhcCRYCM6UJFYGnEIBCr7Rc4Bhcsti5gENAeQSYTCgA3wQC13AuCgEB
GQ2OFYGMCBgI/1QEoNH3X6EjYDwCRDO2q0VRCJMzyr4AIMDrvkBmBKBTSUuH
B41wEaA+HebG8n2tCPlaM5xcQIQalIpATgT8PdOpCHSNkBHw6TDXVLgUcGcI
4JSaAQLlFGovgcAp7LS0SQjAzvDvQiNkBHw6zCVXdOqS3TICUN2OUiZ35OFt
rQjkRABcsiYVAfcw5AO4CPh0mLtp0Mxlu1tGAD5UlHsljixsj1UEciIAbqC0
fYFTcMni7wtQnw5zqo3aVToMJwxwKkUBgVopmhsB0MKm7QvERvj7Asynw8xa
a/Y1CvBwZAkBAbhdqOYCmREALWzavkBshL8vEI7MuHmQgmLpZYd4V7cIwpHK
02BTIN8RXvhLct0jvDFakY7wDiyC5PhY95Vw7GoQQ4YtXlX8NnBS9RK4UhZB
eQnrid3P8pkE4M09bmIOMfexfi6AundpbBG0NvoKngsg5j7/A5FvRroImV5r
oIIeZWoR5O5XFOfckEP/MMUiKBkxfBWLoMfxgjGAw2dyLFPnHjuqLv7A/cNi
NFwe2E2ei7+xRRDeQfpsB9Y902KLYDtyEHzOOCThKFTPTv+dxyLYMWWt9Ex9
OLAr8Lv8owsNapU11BHWP+wG+htltJRFEN73gZMno0VQnMI59YIDfeTFxkk8
mPDBFhK5ycQJzPXGFkE4UfO0mesupiSfLhk86KfXsAiqOLNB6l7LnKF4r3uV
tzDKEDY+EC9Ti6AXfeUa3tUbFcy4D2JhV7TQImilMUT3g/mKFsGTe7suKEmJ
ZcGnsXJfdcHoqyYWQTik9MCB/ckxfcYiCOWPgK1/pvxjOo5F8AaSUUKPxnQu
jGAPLYJMOqYMlcalWreH61kEPSkGixTw3hSwCJp+7gnjKwwMkFBDZPEHdrXn
Zr9jiyAsgjyyxWeZ/b4bp/fxKMWklmLWIuiCdGQR7OLR9TSFLIJ+cnDFyP0h
HuDzL2gRNHcZ0F1mTrIsnvp4VlOLIFw1I022yYEgVLIl15j4ycEGLIK+D0O5
yMTS4Cz5iqP92CJIz5mcwdUiWC2C1SLY/6z1j++fyTdsmolFsPvZITwevXv0
5iRcbhGkzc1JuJpFcDiy2KkH6N3VisIWQZiRaIK2XCG/2HJFG6JubBGE13N8
/k6jPm4Yp4t3I7ZQFeDDCEWeA2FUSJ6zThgNqgJAPHGmOackc1UBfvpsw62N
cUHivoObqwqARr9tQiOoCuga9QNQXNL4sCrAVwH85lFVQEDAxbbVXE8LYzaO
gEFb+IW/XBHIigC8NpWIwO/cv/1FUwABKt/gFi09NYdsHIEWpUgeEFBliuRf
CQHYbbkkIvAH92//XgIBph0CLtwXb/dtBgG06gpVZIXvlRBQLARrEgLu/fCB
i46ApA4BSmaM4htH4IJyTgQQYGXOibwSAjBxTUXgn5vQCBkBdnABzw23bPEy
yiYQOIX1SgQEzCZq7L4YAjAJEqkIwCTo7xt0BITPBZSVM9ekbxmBc/hAERDQ
YQusIpATAX8GIBWBrhEyAsojIKki+5oIXYJMEwEBFQ6hVARyIgDVvm0qAl0j
ZASMR4BzvT8EzjiLoipsDlYEsiEQywfTcgEefoafC3DiEaDS8n0hcA3hg4AA
7K6SikBeBODZVSoC7nd93QkyAgwQYNZwMj3suHEEWpwVIRnKqyoCORGQ19R0
2DX6Y1MiHeY+HWaGSDN1yW4YAaixYTgTIagGrROhzAjAfCZtXyA2wt8X4D4d
ZoqZ5bVlW0HAWiwE9Fc7Gbc6AqCFJakIQCN4jIyAT4eZkIzvqkYISuQ4ilHc
h0UZo/gLIQDbmJdUBLpGuAgInw4zpqXZVS4ACCDlArzmApkREOGIV9q+gGv0
/X+V2BcQIR0m1ppdlcnBmROCNgqQOgpkRkDY1H0B1+jvmhL7AsKnw9S6edCu
yuT8sSucrTEW1FQVgZwIgJMjbV/ANfpTg78vwOORGRfhxg3+Cw/xrm4RBMHT
0KKZ7wiv35a/rnqEN0Yr0hHegUVQxDqTp+L/LoasXjyZ/jZwUvUSOFrIIqjh
4+3PwGc0CfiA2cQcYu5j/XwAETK1CEIiciYZAsiNw0y+GSPpzC1/2r2NsxZB
QakywvVc8tA/TLAIKuImv+5dXMEiaGSIwfwDuHdJFjs32u30QfxdZagHhzvE
1INh9bn4G1sE4cz+8fpk/HXPtNwiOJqUfM44dD1GJ974O49FMDCl3ghT0gXb
xwO7owyYooJR4npiuID89rAb6G+UqVIWQariQmrHTjZO+CUsd5Qd6IEXOB0P
NchwcQ9clxG5ycHJNRA4tgjCWoJ9/nz1IKbm6qge9NNrWAShe7UolnXfvZLV
u1d2C6MMYcPjaxpbBOHSHsayhQ1VygXG0q5omUWQCWkMVHZ3g/mKFkE/tT5i
JCXwTHB70rp9FYRI/r5qbBGkp/BsGcf0OYsg+IePIcQRxnQci2AHEqNaspHy
nwujzEOLIKdWG66V4of+4XoWQU/KCYsUiNEyFkEecyFv6Y33JzIaCoDyz37H
FsFzvHoAbfb7bpzex6OaXk09bxFUZmQRvMWjKGURhMlBO/hZxtzf/TVTZHLQ
Rd0wCoffMRozRB/Es+omB4NnAobNg1WGT0wOBHOj/hLFsJ8cbMAi6PuwM1Yf
Zr/oaD+2CAId9tkogl+uFsFqEawWwfCzzvs3fibfsGlmLYKd909M3j0Z/xqN
7yRZYBGU8a/R+HqaprxFcDCyMD09+/vuakVhiyCMo0eUigZYrign/im3XHFl
zcQiCP9vn/ca93FjqJwWxjyImy1UBfgwMlhhJE9fOIwGVQFX0txu/0asCrBh
uUDp24T9voObrQqIjf6piVUB47sFuyWND6sC4Lby/9Y8rgoABKxDQCi1uOvc
BAIKyx8Fjoty/qiXQeAUq+6SEIiN0BHg0iHAtZ3Whm0ZAY11YBYG2nIHZl8G
gUuoeU9DIDZCR0BohwAjbF+jgLlfm8mIwCncFFURyIYA/JeHtfPlCLhG3/8m
NEJGQB4ofRPUiBmL4JYRsOHDREDgGEbgikBWBE5hap+GwC9DI3QEpMsFKOUz
V0duGYFjeKsREID1/2IWwVdBgF77G4WWI/DH0AgZAQ25ALea6MltaZtG4BQu
qkVAAMaWOhHKjAB8fjwVAVgChy0JZASsR0BbavY1CsA9ZQQFAR32xSoCORGA
vU6aisD/iQGMi4CkHgFFuZgec9kyApfwoSIgoEI5UkUgJwJwBi05F+gaISPA
PQKCKzY1h2wYAahmUTiLoiKMLxWBnAjAsdxzKgJdI2QEpEeASbuvfQE7Kk/P
iAAPF+pWBLIh0IV+EgJd6OMjENJhYoTcVToMCJxwTl1CBZ6pCORFAKr20vYF
jqFqD39fQPp0mFki7fSm0S0jwMJkCAEB95dNTYczIyAvYcclbRRw//b/GlwE
xIH4dBiqK/dVJgcIXHEWRVmQslQEciIAK3gyFQFo9Dt8BHw6zKRQdl8I8GCo
RkAApli1TC4zAsdT6r5AbIS9L+AQ8Okw40rLfU2EwB2CowiIJ0ArAjkRgGq3
tH2B2Ah7X8Ah4NNhRo02+0qHYUEUZ0XI/aVTXRHKicApvr4kBFyj77/F3xcQ
3UFwLZWiSw/xrm4RJPGTy3+EV6qwN7buEV6IVqQjvAOLoL+x/vhk/N/FkLaL
u9FvAydVL4FThSyC9hKrzOLP8pkEoMbYbqIDnftYPxlA8V0aWwThWeAGlicD
SMI4LOSb0ZLMXHdspJ23CBoiNRGM0cPtUYpDUDJijVrDIdgarMoWGe9fLhN9
3ZAG0Rf9bv7n9IGa9LnoGzsEYRL0yFaYxaIy6xA80vtn+pxvyMJBqJ6c/juP
QzAQBb43LtyI9vGw7hgDoiRUyDDtiLo96gb5DjFWSiDIZHO7hcWDkw0SHueB
Zcf4a1QM6XhzG3zUc6/pc5B47C5TgSAEmX5eIDgIKDmTKj3ootcQCELferpi
9a2y2ALZw771cgujDGHjA7GbGpK+b/U9+IM5xCfChrrkGCrvlvVDCwWCVhoj
ZT+SrygQlOdQU50/H7nakI+v3FcxjL5qLBAEtZdCFwieZFhghdO2CAM6jkCw
A4lRq+nI9s+FsfyxQNBAbs8EE4f+4XoCQU+KwSLlXGRUh0OqIk5xYcn4IoK+
/arDulL+qe9EIHgMAx3a1PfdOB3F47SMYl4gaPlYINjFoywlEIT3DHSs+dN+
uIKOF9H1dFE3jMLhd4zGDNHn49nOCARlEOllmhwIrrlcYhf2k4MNCAR9H2ax
+jD9RUf7sUBQ0HAQJ9/qexUIxq8qEHxVgSCPyr+x1s83bJpZgSA86yH8bPTu
mfjXeIJA0MS/xpv1BIKDkUXMXEvz7mpFYYEgzEiuKIXNsFzBim1ElFuuUGIq
EAT1vH5eINjHjSF6Whb2IG62UBDgwwilMhLCqFxl5AphNCgI8MsC6AUBRxqW
C87stiBx38HNFQQMG0FBQNfo9kzdksaHBQHdL84XBAQErEOAGTk9KLhlBGyY
iSMgADOFL7jwuzIC5yBDS0MgNkJHQEqHALUz6qgtI9CGIwcICLQlqxpeBQHv
PlaJCECjXzfoCBhHgUOA0JlTUltG4BiyBwQEYF2GVAQyIyDDa0tDwDX6/osC
CHD6JpiSanEOuQkEYJsFRSAoY2hUBLIiEP3UaQiAGaZBR8AeKAgErRCL6/I2
gcA5OCUQEIBd/mICwVdB4ERDhpWEADT6C3QEKPG5AJHC7GpF6Bg3CBAQEKHC
qiKQEwHYlm5TEegaISPAAAFutF1enb0JBGi41A8BAR7KjysC2RBgsa4gCQFY
DP0foREyAsIjoKwxu0qH4R1iOAhAYFYEMiMA13+k5QKu0c+bErkAVR4BSa3c
1aIoHOTQOFtj7i/ZujWWGQEv5EpFAOpofoGPgPEIcEHo4jMQW0HgipMLQJjU
XCAzAmCETUuHYyP8dJj5dJhTRfi+JkIq2JTzIwA2HlN3hzMjAKt3afsCsRH+
vgDz6TCz2tB9TYR0uFwIAYFzCPuKQE4E4HDCJRWBrhEyAj4dZtoatq+JkAkS
QQQE4B1jFYGMCPAQqKckBHgMWnwEfDrMFLV8X/sCbShWR0AAaoRqLpAZAThs
lLYv4Br9oSmxL8B8OuwiXO+rUhQ06y1HQcCGs3kVgZwIwF1oafsCg0a4CHCf
DjMm+b5qhOB1HVFqhOBwt6w1QpkRgC4rbV8gNsLeF1DdQXClKWyNLTvEu7pA
EKbrp0GldL4jvPCpyWm8Fz7CC9GKdIR3IBCEw5vseYHgIIaYnt7M86Ab/dYr
qW7+N1ZIHwincDjrf5bPIwDcXjeRR859qJ8Ln+5dGusDAYvrg2dKCh9OoVid
U66n4UOJmsgogj6Qaisk1ULYQ/8wQSCoCfyOWEMgeLYhBvMP34AzL5LEQSQw
3cefcs9yVeHM6umBsey5+BsLBKGG1uYwEKQJBEdn6D/nGwLXiB2wdPvOIxDs
mBLSWLbAzQGUeduQ1JQYw/09U93D2zAfKXP9QCGHIJzAV5cBO/k44WEKWG6Y
73iBZzjHg14XeeMmAyeevHbGIei+1bOcDGPKkuk1rI/66TUcgr57RTlH56/x
a1fvXttbGGUIGx+IasYhyIJiPVPYwK2Ny7uiZQ5BDrEIWxjdYL6iQ9Cf6ECx
CoEcAI7wr9xXKYy+auwQhPMZWVLy9x2C53C/F6SRCGM6jkOwA0kJpfkoVefC
MvbQIUiV+3dtrT7cHq1nEPSctFicsCLuf3C3qRhLsF4Mz3SEvS4TF2Gyz33H
BkGYOYBPAm3u+26U3kejoZO101mDoAvRkUGwC0dTSiAIM4Nrv+KRMfFvi+l6
uqAbBuHddwjGDMHnw7lbNxoKBN27pvMl/lZwShbYhcPMwAsEzV9anU8gmLL6
DhU4vgtDWX1sdXjXv+JQPxYIwkrkSWbowqpAsAoEnxEI6tEzLREI/mYuIuCd
Yp1AsJMHXsLrg0uJ2Fi2d4nvVCcQ7OSBfx9f37+E/52JcjKSB3bf7U1dOI1y
MvhuBo873R+dPFMbRYHyoTxw+prgr8n43TSz8sDpa1osD3xfHDgYURiZao3f
XaKIk5BS4kDoa2mLtUZBilRzFlyjOAVB/0QcyLIubVnhb0hZGDfjQoAugEoW
AvgwwlnqaqOT/auG0bAQgGWY0N51aLOFADY6xvltFeK+c5stBHCN/nMTGvlC
gPN42I7rGB/fJOi+f9k8LgRwCFDyZrlhdnJMfNMIHAehnx0BWuSM7EshcI15
dwoCf9WERvgIKIeAFmy6pLFxBFqUM7IQgKrIGdlXQkCwsNKdhMBfNz7twEeA
GYeAVGJxLcYmEDiFYgAEBEyYb1YEsiIArzMVgR/h334sgIBkDgEX/ZOjIZtG
4BwUsggI6BCMFYGcCMAzq1QEYPnrnxp0BNhBuFyACasnBwQ3jcD1fmU+IwIy
BGRFICcCEKQsFQEI2J/hIyB8LkCJZJPTUVtG4ALL9DgI8GDprwjkRAC2cdtU
BLpGyAgoQMBYxqYe/U0jAKUMKHcIAwJQIFERyImAN1ukItA1QkbAeAQ0N3xx
yetWEGhRfDlQgaSK+HJeCQFfcpGKADTCzwUE8QhIKciuVoQusJeMIhGHk3qn
IhLxl0GgDfpYkYSAawT62B/xEWAeAa453dXuMCBwRblNhcXylopATgSESE2H
26CPxU+HhU+HDbVwZHJPCLi31KLIQiD8TRFZyCshAFWUafsCbaiixN8XECEd
JjTh+NsmEID/x1kRIiHMKwI5EWjhZohUBLpGyAj4dFgbNnfmY8sIqHBuMz8C
oFroArAikAuBM4R+KgJdI1wEpE+HtZLM7msUgJNxKLlAp5apCOREAKrd0vYF
Bo2QEfDpsBaG2X2NAu6d4TgIuN+4VARyInAMgZq2L3AMQYu/LyB9OgzrQWZf
i6ImVB8iIHAKTqOKQE4EQB+bti9wDPpY7H0BHY/MGEUlXC667PDuL1zUw+nd
1cSBFs5fDMpE8x3d9TrO86pHd2O0Ih3dHYgD4UAqHF57Kv7vYkjpxUU23wYi
qkP/sJA6EJbTO5MnfOczCFgaJBLrd6BzH+vnAqh7l8bqQChS4s+e/YYAcuMw
k3Buj4vpVJRNLRRBHci0lgYuxJSH/mGKOlAySgVdQx0IgwTOAA66mnOxOezx
3Mcf3AcP675gmxIPfKTPxd9YHUhOsQt9dgBPUgeePiv0u3smqHHVg6i4fedR
Bwam1Bsxyi4xAgNlXjIkoIFg3B76h91Af6NMFVMHHkPN7o2dfBPdNrzXZQd6
4EWasM4LkimwGkRuMnDiyTtN1YGgsj2RJzkZxpQmM0sGD/rpNdSB8MEqlOs1
AMtTse3Ch93r6RZGGcLGRk31WB3oLyh5tnvtw4YxS6xc2hUtVAdaaSwUNHWD
+YrqQLjb8YjiEwJni5Rr91UQIvn7qrE6EALv0ezhk2P6jDoQ3rlrVD0ijOk4
6sAbSNooJSZeNq4fqgM1HIPjbvg+3B6tpw70nJywOAF7Txl1oI5dI1jcYByH
pB1+JouoA/3SUg7v1mfVgYNodH3vMnUg1yN1YBeOxdSBhN5Pu/Ml/ga6zDKJ
F+nVgbofn/vXGYIxx8qpDSuNY3UgXC9j1ZPB14eQsETBXc7LZgYbUAf6LuyM
1YWRIvbT8kP9WB0Is9lHd1x8bv29qgPjV1UHvqI6kN7J/qZRTgbfTfwvPONA
9jd6pjb+Vd6kqQNpfLeapqw6cDCiaDLdi3h3iaKwOhBmIgZtjaL9gmsUsLUy
VgdC75hxaUtYqujiuNlCKYAPI4UVRqbYJUQrhNGgFAAmt2eTcyoyVwoAgQpr
BO3ptgpx37nNlQIMG0EpQNfo9kzdOsaHpQDdLz4qBQAE7JswrvOc5nNbRoDF
XfP8CLi/bItVxr8KAr7EziQi0DVCR4BLQICQqTRqywhAEoBySpbEiURFICsC
PO5lJiHAw+QZHQGhHQIMwn1PCAgsFbdfJyym4n4ZBHTo1NMQiI2QEZAHSt+E
NmpGILtlBGRI1/MjAMvkl2KuhFdB4Dr4rBYjAI1+aAogIF0uoKkU+xoFdFhx
Q0AAqoKLGXNeAgHa3JWTLkPANfr+8xD+yAhonwtIzdXUnrllBGxYQkVA4BiX
IyoCGRGApW6TigAsexv8iZD1CAhCl9dlbwKBFksXAndeltOFvAoC8FpUKgL/
0/3bTw0uAuZAqEeAMT1zn8qWEThibS/Bu1X3BXIjYHRqLhAb/YCPAPcIEGHt
vnIB92L4GQUBE84fVgRyInBU0UWUggA0avARkIAAN8ryfeUCUNiFIo266mAv
rQjkROAy+PwWIwCNsNNhh4BPh7my0uxrd/gSjvoiIKCCnbkikA0B5p6Jp+4L
uEbf/xF/X8Ah4NNhLqlafvxtEwhcsTTiUAhdTiP+KgiIwXnNxQjAxXIndASo
T4c554ZPjTkbRgC8FwQnF4AV7JoLZEYAzre0qQj87yY0QkbAp8OcSkum6sCN
I3DEGQWgaLuOApkRgEhO2xcYNEJGwKfDzGordzURAimCwdkag0rRujWWGYHT
NXVfIDb6qUFHwKfDTFsrdrUvQOP1bwgI0HBlXUUgJwLXwYi9GAFo9AM6AuHI
DFduKrREHegP766uDoTFMj64VS7f0V0dl+LWPboL0Yp0dHegDgS/nOZPxv9d
DDG1uBv9NhBR9eY3VUgd6M++D07d5zMIwF6VOW2hA537WD8XQN27NFYHwokm
e306gCyMw0K8camtni5LC/eBzaoDueZWcUO1m8jeHiaoAw1hlEi9hjoQfAxX
lDSuVWF6UCD+ZOisuvg7X4LZ3mUTD6PiufgbqwPhhoHOy/7UAJ6mDjT3z/Q5
zRDkd3DYp3ttt+886sCOKS0IMXrBwO4oCzpOSY2S7NA96Ab5G2HFtIGg4hmc
Cs6oDYSJkirr5+hYgYGdB05AnxSZycAIUNeSqTYQzuJb8SQjd/HEZi7ee9BH
r6ENlFes8xMwwF7LnKJ7p2ttyS2MMoSND8TzVBt4VkEjnylsLOfaiKXd0DJt
oBDS+Hq+biBfURsI3ycUl5A/DVdEh/ZuX3XG6KvG2kAL90jncAm9rw08hfkJ
bKYijOc42sAbSEYR17uNnWzysTbQIcWpdqkVOfQP1xMHelIuWKTAaFdGHGhi
5gULBnBQ48xDReHlwYLSczPfsTgQXFjGZiUlIU7v45HO7KDNigPlWBx4i0da
yhwIkwM5mB3ly/uZCjFQ1hzYReHwO0ZjjoUjiGc7NQfCqKDaTJMD+SaUFowu
nRxswBzo+zCU5UcavYRfcbQfmwPPMvw33/J7NQfGr2oOfEVzIB+4/sxMlJPB
dxP/C6+pc/2ZWXMg/4Q5kDfrmAOHI8pMdee7qxSFzYEwE7EovitYpjBlivrL
LVPo5na36dAcCGOIfX4Lq48bQ2YqAR7EzRYqAXwYoZRE+u2kMiWR64TRoBIA
hvI2x30F71cCmLBMcCS3hYj7zm22EmDQyFcCnEbP1C1lfFgJ0P3ifCVAQMA4
BIhyPfCOEIDcWLYoCIh4m3VFICcCNKzBpSEQG6EjIMWbkFbTaWH8lhFw7w7F
GQV4OCVYEciKgAi3X6chADWvDToC5kAUCHOsncozt4wAC7kXAgIsrOpWBLIi
AGuLyQjERugIcOIQEJwvziE3gQCk6hoFARh9zxWBvAhYFrZ2kxCARj9v0BEA
Ct6E0IzuCwGJNRGCd6xOhHIjAIsMJBUBaNTZA/EQYMTnApxJMrWFbBmBeFYc
AYFTCM6KQE4EoArfpCLQNUJGgHkEKFfLS/62gADsjuPcHAxrzW0ZbdoLIQDn
k1QqAtAI9s6QERCAALeS7Csdhg0SKHTJjwDo6uB4WkUgGwI2boAmIWDDZih+
LsCUR0ArZaaFXhtGAMbHC8pECPZjWJ0IZUZA6lDrlITAb9y//Tk+AsYjII0R
u5oIwUFEgrIipGOBRkUgJwJwB2BaOhwbIafD/6F+1a/6Vb/qV/2qX/WrftWv
+lW/6lf9ql/1q37Vr/pVv+pX/apfhb7+P5kW82AAsAQA
---1463779069-292812169-973177357=:4026--

---1463779069-1496100968-973780478=:2086--

From owner-netdev@oss.sgi.com Thu Nov  9 06:38:44 2000
Received:  by oss.sgi.com id <S553815AbQKIOiY>;
	Thu, 9 Nov 2000 06:38:24 -0800
Received: from mean.netppl.fi ([195.242.208.16]:60433 "EHLO mean.netppl.fi")
	by oss.sgi.com with ESMTP id <S553778AbQKIOiO>;
	Thu, 9 Nov 2000 06:38:14 -0800
Received: from evil.netppl.fi (root@evil.netppl.fi [195.242.209.201])
	by mean.netppl.fi (8.9.3/8.9.3) with ESMTP id QAA08193
	for <netdev@oss.sgi.com>; Thu, 9 Nov 2000 16:38:01 +0200
Received: (from pp@localhost)
	by evil.netppl.fi (8.9.3/8.9.3) id QAA32210
	for netdev@oss.sgi.com; Thu, 9 Nov 2000 16:38:01 +0200
Date:   Thu, 9 Nov 2000 16:38:01 +0200
From:   Pekka Pietikainen <pp@evil.netppl.fi>
To:     netdev@oss.sgi.com
Subject: peer 192.168.9.2:5001/1029 shrinks window
Message-ID: <20001109163801.A28797@netppl.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi

I get these when doing TCP transfers with gensink running around 70MB/s
using jumbo frames between two 2.4.0-test10 boxes (with 1MB alteon-based
cards on both ends). 

It's a bit random, when I run the test there's sometimes hundreds of these,
then when I run it again there's no problems at all. 

I put a tcpdump (about 1M) of this in session in 
http://ppieta.home.cern.ch/ppieta/dump.gz 

TCP: peer 192.168.9.2:5001/1029 shrinks window 2050038622:599504:2050638138.
Bad, what else can I say?
TCP: peer 192.168.9.2:5001/1029 shrinks window 2050038622:599504:2050638138.
Bad, what else can I say?
TCP: peer 192.168.9.2:5001/1029 shrinks window 2050047570:590560:2050638138.
Bad, what else can I say?
TCP: peer 192.168.9.2:5001/1029 shrinks window 2050047570:590560:2050638138.
Bad, what else can I say?
TCP: peer 192.168.9.2:5001/1029 shrinks window 2050154946:527920:2050682878.
Bad, what else can I say?
TCP: peer 192.168.9.2:5001/1029 shrinks window 2050163894:518976:2050682878.
Bad, what else can I say?
NET: 8 messages suppressed.
TCP: peer 192.168.9.2:5001/1029 shrinks window 2414348210:599504:2414947726.
Bad, what else can I say?
NET: 13 messages suppressed.
TCP: peer 192.168.9.2:5001/1029 shrinks window 2795713050:706880:2796419942.
Bad, what else can I say?

-- 
Pekka Pietikainen

From owner-netdev@oss.sgi.com Thu Nov  9 09:28:49 2000
Received:  by oss.sgi.com id <S553820AbQKIR2j>;
	Thu, 9 Nov 2000 09:28:39 -0800
Received: from ganymede.or.intel.com ([134.134.248.3]:45073 "EHLO
        ganymede.or.intel.com") by oss.sgi.com with ESMTP
	id <S553647AbQKIR2S>; Thu, 9 Nov 2000 09:28:18 -0800
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id JAA03951;
	Thu, 9 Nov 2000 09:27:06 -0800 (PST)
Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 09 Nov 2000 17:27:05 0000 (GMT)
Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21)
	id <WR8M0PTC>; Thu, 9 Nov 2000 09:27:01 -0800
Message-ID: <07E6E3B8C072D211AC4100A0C9C5758302B2708C@hasmsx52.iil.intel.com>
From:   "Hen, Shmulik" <shmulik.hen@intel.com>
To:     "'Keith Owens'" <kaos@ocs.com.au>,
        "'Andrew Morton[andrewm@uow.edu.au]'"
	 <Andrew.Morton[andrewm@uow.edu.au]>,
        "'Jeff Garzik[jgarzik@mandrakesoft.com]'"
	 <Jeff.Garzik[jgarzik@mandrakesoft.com]>,
        "'Paul Gortmaker[p_gortmaker@yahoo.com]'"
	 <Paul.Gortmaker[p_gortmaker@yahoo.com]>,
        "'Andi Kleen'" <ak@suse.de>, "Dunlap, Randy" <randy.dunlap@intel.com>,
        davem@redhat.com, "'jamal'"
	 <hadi@cyberus.ca>, becker@scyld.com
Cc:     "'LNML'" <linux-net@vger.kernel.org>,
        "'LKML'" <linux-kernel@vger.kernel.org>, netdev@oss.sgi.com
Subject: catch 22 - porting net driver from 2.2 to 2.4
Date:   Thu, 9 Nov 2000 09:26:03 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello,

This is a bit long and I apologize (since there are kdb captures in it).

We are developing an advanced networking services driver (loadable module)
and are having problems porting it to work on 2.4.x kernel.
The driver is supposed to provide services such as fault tolerance, load
balancing, link aggregation and VLAN. It does that by creating a group of
"virtual" adapters that are bound on top of a team of network adapters. This
works great on 2.2 kernels but demonstrated a few problems on 2.4.0-test9

The only problem we have left now has to do with insmod/rmmod. for good
reasons, we cant just call init_etherdev() like base drivers do, so we
created our own version that handles memory and name allocations and calls
register_netdevice() on it's own the same as init_etherdev(). since we've
got several "virtual" adapters that are part of a topology being built
progressively, we can't perform their registrations during module_init() but
rather through an IOCTL and here is our problem:

if we call register_netdevice(), we get the following message:

	RTNL: assertion failed at devinet.c(775):inetdev_event

we figured this is because we neglected rtnl_lock() so instead we try using
register_netdev() to handle this for us but then we get:

	Scheduling in interrupt
	kernel BUG at sched.c:696!
	Entering kdb (current=0xc51a8000, pid 1075) on processor 1 Panic:
invalid operand
	due to panic @ 0xc011aa71

	eax = 0x0000001b ebx = 0x00000020 ecx = 0xc030d80c edx = 0xffffffff 
	esi = 0xc030b5b4 edi = 0xffffffff esp = 0xc51a9d34 eip = 0xc011aa71 
	ebp = 0xc51a9d8c  ss = 0x00000018  cs = 0x00000010 eflags =
0x00010246 
	 ds = 0x00000018  es = 0x00000018 origeax = 0xffffffff &regs =
0xc51a9d00

	[1]kdb> bt
	    EBP       EIP         Function(args)
	0xc51a9d8c 0xc011aa71 schedule+0x935 (0xc2c9e000, 0xc4482520,
0xc51a9e10)
	                               kernel .text 0xc0100000 0xc011a13c
0xc011aa80
	0xc51a9db8 0xc0107b8d __down+0xf5
	                               kernel .text 0xc0100000 0xc0107a98
0xc0107c68
	0xc51a9dcc 0xc0107f43 __down_failed+0xb (0xc51a9de4, 0xd082de5c,
0xc2c9e000, 0xc60a8320, 0xc51a9dfc)
	                               kernel .text 0xc0100000 0xc0107f38
0xc0107f4c
	           0xc023a7a9 stext_lock+0x4919
	                               kernel .text.lock 0xc0235e90
0xc0235e90 0xc023bd80
	0xc51a9dd4 0xc01f2e81 rtnl_lock+0x11 (0xc2c9e000)
	                               kernel .text 0xc0100000 0xc01f2e70
0xc01f2e88
	0xc51a9de4 0xd082de5c [ians]iansInitEtherdev+0x20 (0xc4482520)
	                               ians .text 0xd082d060 0xd082de3c
0xd082de78
		.
		. (boring chain of calls)
		.
	0xc51a9ec4 0xd082dbcd [ians]doControlIoctl+0x15d (0xc2c9e200,
0xc51a9f20, 0x89f0)
	                               ians .text 0xd082d060 0xd082da70
0xd082dc40
	0xc51a9ee4 0xc01ef09f dev_ifsioc+0x33f (0xc51a9f20, 0x89f0,
0xc51a9f20)
	                               kernel .text 0xc0100000 0xc01eed60
0xc01ef0b0
	0xc51a9f40 0xc01ef29d dev_ioctl+0x1ed (0x89f0, 0xbffffa58)
	                               kernel .text 0xc0100000 0xc01ef0b0
0xc01ef300
	0xc51a9f64 0xc021a70c inet_ioctl+0x18c (0xc339d13c, 0x89f0,
0xbffffa58)
	                               kernel .text 0xc0100000 0xc021a580
0xc021a720
	0xc51a9f84 0xc01e8f06 sock_ioctl+0x9e (0xc339d040, 0xc38e0900,
0x89f0, 0xbffffa58)
	                               kernel .text 0xc0100000 0xc01e8e68
0xc01e8f6c
	0xc51a9fbc 0xc014f5fd sys_ioctl+0x26d (0x3, 0x89f0, 0xbffffa58,
0x4000ae60, 0xbffffba4)
	                               kernel .text 0xc0100000 0xc014f390
0xc014f6a0
	           0xc010965f system_call+0x33
	                               kernel .text 0xc0100000 0xc010962c
0xc0109664

We figured that since we are in user context (do_ioctl) and use
spin_lock_bh() to protect us from other concurrent threads, it might
interfere with rtnl_lock() so we remove our lock just before calling
register_netdev() and lock again upon return but then the whole process just
stopped and didn't return to the prompt. from within kdb, we could see that
all CPU's are running in idle but if we try to return to the prompt the
whole system hangs. sometimes it hangs if we try to run ifconfig -a to see
if the virtual adapters appear.

I can't use it without locks, I can't use it with locks and I can't complete
the operation if I remove my own locks - catch 22.


The other problem has to do with rmmod - here we get called in our
cleanup_module function and from it we try to call unregister_netdev() for
each registered virtual adapter.
in this case, we get:

	Scheduling in interrupt
	kernel BUG at sched.c:696!

	Entering kdb (current=0xc38c8000, pid 1602) on processor 0 Panic:
invalid operand
	due to panic @ 0xc011aa71
	eax = 0x0000001b ebx = 0x00000000 ecx = 0xc030d80c edx = 0x00000000
	esi = 0x007ae686 edi = 0xffffffff esp = 0xc38c9e54 eip = 0xc011aa71
	ebp = 0xc38c9eac  ss = 0x00000018  cs = 0x00000010 eflags =
0x00010246
	 ds = 0x00000018  es = 0x00000018 origeax = 0xffffffff &regs =
0xc38c9e20

	[0]kdb> bt
	    EBP       EIP         Function(args)
	0xc38c9eac 0xc011aa71 schedule+0x935 (0xc38c9ec0)
	                               kernel .text 0xc0100000 0xc011a13c
0xc011aa80
	0xc38c9ed4 0xc011a02a schedule_timeout+0x76
	                               kernel .text 0xc0100000 0xc0119fb4
0xc011a04c
	0xc38c9eec 0xc01ef80f unregister_netdevice+0x1c7 (0xc38f9600)
	                               kernel .text 0xc0100000 0xc01ef648
0xc01ef880
	0xc38c9efc 0xc01b834e unregister_netdev+0x12 (0xc38f9600)
	                               kernel .text 0xc0100000 0xc01b833c
0xc01b8360
	0xc38c9f18 0xd082f3b9 [ians]iansUnregisterDev+0xcd (0xc154a4a0, 0x0)
	                               ians .text 0xd082d060 0xd082f2ec
0xd082f458
		.
		. (boring chain of calls)
		.
	0xc38c9f7c 0xd082e29d [ians]cleanup_module+0x69
	                               ians .text 0xd082d060 0xd082e234
0xd082e3cc
	0xc38c9f90 0xc0120620 free_module+0x1c (0xd082d000, 0x0, 0xc38c8000,
0x80563cc)
	                               kernel .text 0xc0100000 0xc0120604
0xc01206a0
	0xc38c9fbc 0xc011f70f sys_delete_module+0x1fb (0xbffffcad, 0x28,
0x6, 0x80563cc, 0x1)
	                               kernel .text 0xc0100000 0xc011f514
0xc011f9e8
	           0xc010965f system_call+0x33
	                               kernel .text 0xc0100000 0xc010962c
0xc0109664

If we replace it with a direct call to unregister_netdevice(), we get stuck
in an infinite loop that says something like:

	waiting for <device> to become free. usage count = 2
	waiting for <device> to become free. usage count = 2
	waiting for <device> to become free. usage count = 2

Trying to debug this I could see that dev->refcnt is involved, so I print
it's value before and after register_netdevice() and again before and after
unregister_netdevice(). oddly I get 0 first and then 1, but before
unregister_netdevice() I get 2 !!!

So again, if I use locks I get stuck and if I don't use locks I get stuck -
catch 22.

Please advise.

	Thanks in advance.

	Shmulik Hen,
      	Software Engineer
	Linux Advanced Networking Services
	Network Communications Group, Israel (NCGj)
	Intel Corporation Ltd.




From owner-netdev@oss.sgi.com Thu Nov  9 09:38:09 2000
Received:  by oss.sgi.com id <S554051AbQKIRhu>;
	Thu, 9 Nov 2000 09:37:50 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:27148 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S553823AbQKIRhk>;
	Thu, 9 Nov 2000 09:37:40 -0800
Received: from mandrakesoft.com (adsl-20-73-115.asm.bellsouth.net [66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id MAA00769;
	Thu, 9 Nov 2000 12:37:21 -0500
Message-ID: <3A0AE0D1.FB12725A@mandrakesoft.com>
Date:   Thu, 09 Nov 2000 12:37:21 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Hen, Shmulik" <shmulik.hen@intel.com>
CC:     "'LNML'" <linux-net@vger.kernel.org>,
        "'LKML'" <linux-kernel@vger.kernel.org>, netdev@oss.sgi.com
Subject: Re: catch 22 - porting net driver from 2.2 to 2.4
References: <07E6E3B8C072D211AC4100A0C9C5758302B2708C@hasmsx52.iil.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

do_ioctl is inside rtnl_lock...

Remember if you need to alter the rules, you can always queue work in
the current context, and have a kernel thread handle the work.  The nice
thing about a kernel thread is that you start with a [almost] clean
state, when it comes to locks.

	Jeff


-- 
Jeff Garzik             |
Building 1024           | Would you like a Twinkie?
MandrakeSoft            |

From owner-netdev@oss.sgi.com Thu Nov  9 10:16:40 2000
Received:  by oss.sgi.com id <S554053AbQKISQa>;
	Thu, 9 Nov 2000 10:16:30 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:266 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553825AbQKISQH>;
	Thu, 9 Nov 2000 10:16:07 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA05422; Thu, 9 Nov 2000 21:15:46 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011091815.VAA05422@ms2.inr.ac.ru>
Subject: Re: peer 192.168.9.2:5001/1029 shrinks window
To:     pp@evil.NETppl.FI (Pekka Pietikainen)
Date:   Thu, 9 Nov 2000 21:15:46 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20001109163801.A28797@netppl.fi> from "Pekka Pietikainen" at Nov 9, 0 05:45:01 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 606       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> I get these when doing TCP transfers with gensink running around 70MB/s
> using jumbo frames between two 2.4.0-test10 boxes (with 1MB alteon-based
> cards on both ends). 
....
> TCP: peer 192.168.9.2:5001/1029 shrinks window 2050038622:599504:2050638138.

Ignore this. This is an inavoidable by-product of window scaling.

Unfortunately this case cannot be distinguished of true window shrinking
reliably, so that the message is not filtered out. If it clogs your logs,
delete all it or, even better, add check sort of:

	if (tp->snd_nxt-(tp->snd_una+tp->snd_wnd) >= (1<<tp->snd_wscale))

Alexey

From owner-netdev@oss.sgi.com Thu Nov  9 12:43:00 2000
Received:  by oss.sgi.com id <S554065AbQKIUmu>;
	Thu, 9 Nov 2000 12:42:50 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:47370 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S554062AbQKIUmc>;
	Thu, 9 Nov 2000 12:42:32 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA06283; Thu, 9 Nov 2000 23:42:17 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011092042.XAA06283@ms2.inr.ac.ru>
Subject: Re: Bug in TCP/IP stack in 2.2.17? (fwd)
To:     patrik@ein.cz (Patrik Rak)
Date:   Thu, 9 Nov 2000 23:42:17 +0300 (MSK)
Cc:     netdev@oss.sgi.com, davem@redhat.com (Dave Miller)
In-Reply-To: <Pine.LNX.4.21.0011091529330.2086-110000@eagle.int.ein.cz> from "Patrik Rak" at Nov 9, 0 05:45:01 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 642       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Please note that it was the Linux host initiating the SMTP connection that
> corrupted the packet and the tcpdump was run directly on this sending
> host. The original message is perhaps somewhat unclear about this.
> 
> I am really eager to hear your comments about all this.

Comment is: YES, alas. It is _big_ bug. We used to do some utter crap,
when receiving crap instead of TCP options. :-(

Just for information: do you know what OS do you talk to?
It does something truly wicked.

[ Dave, fix for 2.4 will be ready tomorrow. For 2.2... I will look,
  what is possible to make there after it will be ready for 2.4. ]

Alexey

From owner-netdev@oss.sgi.com Thu Nov  9 21:08:42 2000
Received:  by oss.sgi.com id <S553782AbQKJFIW>;
	Thu, 9 Nov 2000 21:08:22 -0800
Received: from pizda.ninka.net ([216.101.162.242]:5505 "EHLO pizda.ninka.net")
	by oss.sgi.com with ESMTP id <S553755AbQKJFH6>;
	Thu, 9 Nov 2000 21:07:58 -0800
Received: (from davem@localhost)
	by pizda.ninka.net (8.9.3/8.9.3) id UAA14242;
	Thu, 9 Nov 2000 20:53:03 -0800
Date:   Thu, 9 Nov 2000 20:53:03 -0800
Message-Id: <200011100453.UAA14242@pizda.ninka.net>
From:   "David S. Miller" <davem@redhat.com>
To:     eis@baty.hanse.de
CC:     netdev@oss.sgi.com, alan@redhat.com, gorgo@itc.hu
In-reply-to: <200011082223.XAA01293@baty.hanse.de> (message from Henner Eisen
	on Wed, 8 Nov 2000 23:23:38 +0100)
Subject: Re: patch: x25-iface / lapb reliability
References:  <200011082223.XAA01293@baty.hanse.de>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

   Date:   Wed, 8 Nov 2000 23:23:38 +0100
   From: Henner Eisen <eis@baty.hanse.de>

   I've done several tests with the lapbether driver by simulating
   netif_rx() backlog congestion and verified that it works. For the
   other drivers, I checked that they compile o.k. (anc cc'ed to the
   maintainers)

Patch applied, thanks a lot.

BTW, on the 2.2.x side I would be more than willing to accept
a patch which makes netif_rx() return appropriate error codes
to match  2.4.x.  Then you could solve this cleanly in both
cases.

Later,
David S. Miller
davem@redhat.com

From owner-netdev@oss.sgi.com Fri Nov 10 08:22:48 2000
Received:  by oss.sgi.com id <S553839AbQKJQW1>;
	Fri, 10 Nov 2000 08:22:27 -0800
Received: from bay.ein.cz ([212.24.139.122]:273 "HELO bay.ein.cz")
	by oss.sgi.com with SMTP id <S553784AbQKJQWR>;
	Fri, 10 Nov 2000 08:22:17 -0800
Received: from eagle.int.ein.cz (eagle.int.ein.cz [192.168.3.129])
	by bay.ein.cz (Postfix) with ESMTP
	id E001213593; Fri, 10 Nov 2000 17:22:06 +0100 (CET)
Received: from patrik (helo=localhost)
	by eagle.int.ein.cz with local-esmtp (Exim 3.16 #1 (Debian))
	id 13uGwI-0001NK-00; Fri, 10 Nov 2000 17:22:06 +0100
Date:   Fri, 10 Nov 2000 17:22:06 +0100 (CET)
From:   Patrik Rak <patrik@ein.cz>
To:     kuznet@ms2.inr.ac.ru
Cc:     netdev@oss.sgi.com, Alexander Stanich <astanich@reutershealth.com>
Subject: Re: Bug in TCP/IP stack in 2.2.17? (fwd)
In-Reply-To: <200011092042.XAA06283@ms2.inr.ac.ru>
Message-ID: <Pine.LNX.4.21.0011101719380.2086-100000@eagle.int.ein.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Thu, 9 Nov 2000 kuznet@ms2.inr.ac.ru wrote:

> Just for information: do you know what OS do you talk to?
> It does something truly wicked.

It's SunOS mail 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-5.

If you want more info you can ask Alexander Stanich <astanich@reutershealth.com>
directly (well, as long as your mail gets through - as my Linux is unable 
to talk with his machine, I have to use his backup relay).

Regards,

Patrik


From owner-netdev@oss.sgi.com Fri Nov 10 08:35:58 2000
Received:  by oss.sgi.com id <S553843AbQKJQfs>;
	Fri, 10 Nov 2000 08:35:48 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:39173 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553840AbQKJQfe>;
	Fri, 10 Nov 2000 08:35:34 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA22441; Fri, 10 Nov 2000 19:35:14 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011101635.TAA22441@ms2.inr.ac.ru>
Subject: Re: Bug in TCP/IP stack in 2.2.17? (fwd)
To:     patrik@ein.cz (Patrik Rak)
Date:   Fri, 10 Nov 2000 19:35:14 +0300 (MSK)
Cc:     netdev@oss.sgi.com, astanich@reutershealth.com
In-Reply-To: <Pine.LNX.4.21.0011101719380.2086-100000@eagle.int.ein.cz> from "Patrik Rak" at Nov 10, 0 05:22:06 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 1875      
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> > Just for information: do you know what OS do you talk to?
> > It does something truly wicked.
> 
> It's SunOS mail 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-5.

This is NOT Solaris, no doubts. 8)
Or this poor Solaris is hidden behind some absolutely insane firewall.

> If you want more info you can ask Alexander Stanich <astanich@reutershealth.com>
> directly (well, as long as your mail gets through - as my Linux is unable 
> to talk with his machine, I have to use his backup relay).

Well, I do not think that I have better chances to send him a mail. 8)

BTW, you can test the following patchlet, it is expected to help.

Alexey


--- ../orig/linux/net/ipv4/tcp_output.c	Sun Jun 18 21:24:08 2000
+++ linux/net/ipv4/tcp_output.c	Fri Nov 10 15:07:44 2000
@@ -79,7 +103,7 @@
 	if(skb != NULL) {
 		struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp);
 		struct tcp_skb_cb *tcb = TCP_SKB_CB(skb);
-		int tcp_header_size = tp->tcp_header_len;
+		int tcp_header_size = sizeof(struct tcphdr);
 		struct tcphdr *th;
 		int sysctl_flags;
 
@@ -103,12 +127,17 @@
 				if(!(sysctl_flags & SYSCTL_FLAG_TSTAMPS))
 					tcp_header_size += TCPOLEN_SACKPERM_ALIGNED;
 			}
-		} else if(tp->sack_ok && tp->num_sacks) {
-			/* A SACK is 2 pad bytes, a 2 byte header, plus
-			 * 2 32-bit sequence numbers for each SACK block.
-			 */
-			tcp_header_size += (TCPOLEN_SACK_BASE_ALIGNED +
-					    (tp->num_sacks * TCPOLEN_SACK_PERBLOCK));
+		} else {
+			if(tp->tstamp_ok)
+				tcp_header_size += TCPOLEN_TSTAMP_ALIGNED;
+
+			if(tp->sack_ok && tp->num_sacks) {
+				/* A SACK is 2 pad bytes, a 2 byte header, plus
+				 * 2 32-bit sequence numbers for each SACK block.
+				 */
+				tcp_header_size += (TCPOLEN_SACK_BASE_ALIGNED +
+						    (tp->num_sacks * TCPOLEN_SACK_PERBLOCK));
+			}
 		}
 		th = (struct tcphdr *) skb_push(skb, tcp_header_size);
 		skb->h.th = th;

From owner-netdev@oss.sgi.com Fri Nov 10 08:54:58 2000
Received:  by oss.sgi.com id <S553840AbQKJQys>;
	Fri, 10 Nov 2000 08:54:48 -0800
Received: from mail.reutershealth.com ([204.243.9.36]:28550 "EHLO
        mail.reutershealth.com") by oss.sgi.com with ESMTP
	id <S553763AbQKJQyj>; Fri, 10 Nov 2000 08:54:39 -0800
Received: from reutershealth.com ([192.168.3.13])
	by mail.reutershealth.com (Pro-8.9.3/8.9.3) with ESMTP id LAA08833;
	Fri, 10 Nov 2000 11:55:17 -0500 (EST)
Message-ID: <3A0C2838.99F67A2E@reutershealth.com>
Date:   Fri, 10 Nov 2000 11:54:16 -0500
From:   Alexander Stanich <astanich@reutershealth.com>
Organization: Reuters Health
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To:     Patrik Rak <patrik@ein.cz>
CC:     kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com
Subject: Re: Bug in TCP/IP stack in 2.2.17? (fwd)
References: <Pine.LNX.4.21.0011101719380.2086-100000@eagle.int.ein.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

what kind of wickedness from this way came?
been noticing some flaky behavior on this mail server but haven't had the usual
time/resources to get under the hood.  it's due for an upgrade to solaris8 soon, but
i'd like to know what you saw in the logs.  i've inherited this server from the
previous sys admin so am not sure what weirdness has been done to it.
alex

Patrik Rak wrote:

> On Thu, 9 Nov 2000 kuznet@ms2.inr.ac.ru wrote:
>
> > Just for information: do you know what OS do you talk to?
> > It does something truly wicked.
>
> It's SunOS mail 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-5.
>
> If you want more info you can ask Alexander Stanich <astanich@reutershealth.com>
> directly (well, as long as your mail gets through - as my Linux is unable
> to talk with his machine, I have to use his backup relay).
>
> Regards,
>
> Patrik


From owner-netdev@oss.sgi.com Fri Nov 10 09:09:18 2000
Received:  by oss.sgi.com id <S553842AbQKJRI5>;
	Fri, 10 Nov 2000 09:08:57 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:15622 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553830AbQKJRIb>;
	Fri, 10 Nov 2000 09:08:31 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA22696; Fri, 10 Nov 2000 20:03:02 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011101703.UAA22696@ms2.inr.ac.ru>
Subject: Re: Bug in TCP/IP stack in 2.2.17? (fwd)
To:     astanich@reutershealth.com (Alexander Stanich)
Date:   Fri, 10 Nov 2000 20:03:02 +0300 (MSK)
Cc:     patrik@ein.cz, netdev@oss.sgi.com
In-Reply-To: <3A0C2838.99F67A2E@reutershealth.com> from "Alexander Stanich" at Nov 10, 0 11:54:16 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 2324      
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> what kind of wickedness from this way came?

19:57:07.234813 > 193.233.7.100.32949 > 204.243.9.36.smtp: S [ECN-Echo,CWR] 3045688343:3045688343(0) win 5840/0 <mss 1460,sackOK,timestamp 685566 0,nop,wscale 0> (DF) (ttl 64, id 0)
19:57:07.470542 < 204.243.9.36.smtp > 193.233.7.100.32949: S 534078928:534078928(0) ack 3045688344 win 0/0 (ttl 49, id 63204)
19:57:07.470612 > 193.233.7.100.32949 > 204.243.9.36.smtp: . 1:1(0) ack 1 win 5840/0 (DF) (ttl 64, id 0)
19:57:07.731885 < 204.243.9.36.smtp > 193.233.7.100.32949: . 1:1(0) ack 1 win 10136/10136 <nop,nop,timestamp 8870901 685566,nop,wscale 0,mss 1460> (DF) (ttl 239, id 38803)

Grrr.... These option set is invalid: wscale, mss can be only with SYN.
Timestamps are not allowed if they were not sent with SYN.
Note that it is the only line, where they happen. 8)

19:57:07.783152 < 204.243.9.36.34420 > 193.233.7.100.auth: S 2858361319:2858361319(0) win 8760/0 <mss 1460> (DF) (ttl 239, id 38804)
19:57:07.783211 > 193.233.7.100.auth > 204.243.9.36.34420: S 3045018596:3045018596(0) ack 2858361320 win 5840/0 <mss 1460> (DF) (ttl 64, id 0)
19:57:08.183993 < 204.243.9.36.34420 > 193.233.7.100.auth: . 1:1(0) ack 1 win 8760/0 (DF) (ttl 239, id 38805)
19:57:08.184642 < 204.243.9.36.34420 > 193.233.7.100.auth: P 1:11(10) ack 1 win 8760/0 (DF) (ttl 239, id 38806)
19:57:08.184736 > 193.233.7.100.auth > 204.243.9.36.34420: . 1:1(0) ack 11 win 5840/10 (DF) (ttl 64, id 0)
19:57:08.223365 > 193.233.7.100.auth > 204.243.9.36.34420: P 1:35(34) ack 11 win 5840/0 (DF) (ttl 64, id 0)
19:57:08.889359 < 204.243.9.36.smtp > 193.233.7.100.32949: P 1:99(98) ack 1 win 10220/84 (DF) (ttl 239, id 38809)
19:57:08.889441 > 193.233.7.100.32949 > 204.243.9.36.smtp: . 1:1(0) ack 99 win 5840/98 (DF) (ttl 64, id 0)
19:57:08.890086 < 204.243.9.36.34420 > 193.233.7.100.auth: . 11:11(0) ack 35 win 8760/34 (DF) (ttl 239, id 38807)
19:57:08.892332 < 204.243.9.36.34420 > 193.233.7.100.auth: F 11:11(0) ack 35 win 8760/0 (DF) (ttl 239, id 38808)
19:57:08.893125 > 193.233.7.100.auth > 204.243.9.36.34420: F 35:35(0) ack 12 win 5840/1 (DF) (ttl 64, id 0)
19:57:09.255579 < 204.243.9.36.34420 > 193.233.7.100.auth: . 12:12(0) ack 36 win 8760/1 (DF) (ttl 239, id 38810)
19:57:16.291821 > 193.233.7.100.32949 > 204.243.9.36.smtp: P 1:12(11) ack 99 win 5840/0 (DF) (ttl 64, id 0)

Alexey

From owner-netdev@oss.sgi.com Fri Nov 10 09:11:17 2000
Received:  by oss.sgi.com id <S553846AbQKJRK5>;
	Fri, 10 Nov 2000 09:10:57 -0800
Received: from mail.reutershealth.com ([204.243.9.36]:37510 "EHLO
        mail.reutershealth.com") by oss.sgi.com with ESMTP
	id <S553841AbQKJRKx>; Fri, 10 Nov 2000 09:10:53 -0800
Received: from reutershealth.com ([192.168.3.13])
	by mail.reutershealth.com (Pro-8.9.3/8.9.3) with ESMTP id MAA08988;
	Fri, 10 Nov 2000 12:11:30 -0500 (EST)
Message-ID: <3A0C2C04.1B720C90@reutershealth.com>
Date:   Fri, 10 Nov 2000 12:10:28 -0500
From:   Alexander Stanich <astanich@reutershealth.com>
Organization: Reuters Health
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To:     kuznet@ms2.inr.ac.ru
CC:     Patrik Rak <patrik@ein.cz>, netdev@oss.sgi.com
Subject: Re: Bug in TCP/IP stack in 2.2.17? (fwd)
References: <200011101635.TAA22441@ms2.inr.ac.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

good call on the firewall!
it's behind a cyberguard firewall.  can't stand the thing.
the firewall happens to be doing the handshaking on all incoming TCP connections, been the victim
of several TCP/SYN flood attacks. maybe this is where it flakes?  the firewall intercepts the
client SYN, send the SYN/ACK, waits for the client ACK.  if it gets the ACK it's supposed to open
up a new connection to the server.  maybe it does, but is breaking the connection to the client?
never been fond of this cyberguard, plus it's running an older version of the firewall on some
type of  unixware, UNIX_SV cyberguard 4.2MP 2.1 i386 x86at, which supposedly has been "optimized"
by cyberguard.  god knows what's been done to the tcp stack.
alex

kuznet@ms2.inr.ac.ru wrote:

> Hello!
>
> > > Just for information: do you know what OS do you talk to?
> > > It does something truly wicked.
> >
> > It's SunOS mail 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-5.
>
> This is NOT Solaris, no doubts. 8)
> Or this poor Solaris is hidden behind some absolutely insane firewall.
>
> > If you want more info you can ask Alexander Stanich <astanich@reutershealth.com>
> > directly (well, as long as your mail gets through - as my Linux is unable
> > to talk with his machine, I have to use his backup relay).
>
> Well, I do not think that I have better chances to send him a mail. 8)
>
> BTW, you can test the following patchlet, it is expected to help.
>
> Alexey
>
> --- ../orig/linux/net/ipv4/tcp_output.c Sun Jun 18 21:24:08 2000
> +++ linux/net/ipv4/tcp_output.c Fri Nov 10 15:07:44 2000
> @@ -79,7 +103,7 @@
>         if(skb != NULL) {
>                 struct tcp_opt *tp = &(sk->tp_pinfo.af_tcp);
>                 struct tcp_skb_cb *tcb = TCP_SKB_CB(skb);
> -               int tcp_header_size = tp->tcp_header_len;
> +               int tcp_header_size = sizeof(struct tcphdr);
>                 struct tcphdr *th;
>                 int sysctl_flags;
>
> @@ -103,12 +127,17 @@
>                                 if(!(sysctl_flags & SYSCTL_FLAG_TSTAMPS))
>                                         tcp_header_size += TCPOLEN_SACKPERM_ALIGNED;
>                         }
> -               } else if(tp->sack_ok && tp->num_sacks) {
> -                       /* A SACK is 2 pad bytes, a 2 byte header, plus
> -                        * 2 32-bit sequence numbers for each SACK block.
> -                        */
> -                       tcp_header_size += (TCPOLEN_SACK_BASE_ALIGNED +
> -                                           (tp->num_sacks * TCPOLEN_SACK_PERBLOCK));
> +               } else {
> +                       if(tp->tstamp_ok)
> +                               tcp_header_size += TCPOLEN_TSTAMP_ALIGNED;
> +
> +                       if(tp->sack_ok && tp->num_sacks) {
> +                               /* A SACK is 2 pad bytes, a 2 byte header, plus
> +                                * 2 32-bit sequence numbers for each SACK block.
> +                                */
> +                               tcp_header_size += (TCPOLEN_SACK_BASE_ALIGNED +
> +                                                   (tp->num_sacks * TCPOLEN_SACK_PERBLOCK));
> +                       }
>                 }
>                 th = (struct tcphdr *) skb_push(skb, tcp_header_size);
>                 skb->h.th = th;


From owner-netdev@oss.sgi.com Fri Nov 10 09:50:08 2000
Received:  by oss.sgi.com id <S553859AbQKJRt6>;
	Fri, 10 Nov 2000 09:49:58 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:45575 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553847AbQKJRtk>;
	Fri, 10 Nov 2000 09:49:40 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id UAA23246; Fri, 10 Nov 2000 20:49:18 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011101749.UAA23246@ms2.inr.ac.ru>
Subject: Re: Bug in TCP/IP stack in 2.2.17? (fwd)
To:     astanich@reutershealth.com (Alexander Stanich)
Date:   Fri, 10 Nov 2000 20:49:18 +0300 (MSK)
Cc:     patrik@ein.cz, netdev@oss.sgi.com
In-Reply-To: <3A0C2C04.1B720C90@reutershealth.com> from "Alexander Stanich" at Nov 10, 0 12:10:28 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 616       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> the firewall happens to be doing the handshaking on all incoming TCP connections, been the victim
> of several TCP/SYN flood attacks. maybe this is where it flakes?  the firewall intercepts the
> client SYN, send the SYN/ACK, waits for the client ACK.  if it gets the ACK it's supposed to open
> up a new connection to the server. 

I heard that such beasts exist, but believed that it is rather joke.
Hmm... not a joke, indeed. Bad joke to be more exact. 8)

Apparently, it tries to relay options received in server's SYN-ACK.
It is too late to drink mineral water, when kidneys dilapidated. 8)8)

Alexey

From owner-netdev@oss.sgi.com Fri Nov 10 09:57:18 2000
Received:  by oss.sgi.com id <S553864AbQKJR5I>;
	Fri, 10 Nov 2000 09:57:08 -0800
Received: from mail.reutershealth.com ([204.243.9.36]:903 "EHLO
        mail.reutershealth.com") by oss.sgi.com with ESMTP
	id <S553845AbQKJR4v>; Fri, 10 Nov 2000 09:56:51 -0800
Received: from reutershealth.com ([192.168.3.13])
	by mail.reutershealth.com (Pro-8.9.3/8.9.3) with ESMTP id MAA09484;
	Fri, 10 Nov 2000 12:57:32 -0500 (EST)
Message-ID: <3A0C36D2.2C502478@reutershealth.com>
Date:   Fri, 10 Nov 2000 12:56:35 -0500
From:   Alexander Stanich <astanich@reutershealth.com>
Organization: Reuters Health
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To:     kuznet@ms2.inr.ac.ru
CC:     patrik@ein.cz, netdev@oss.sgi.com
Subject: Re: Bug in TCP/IP stack in 2.2.17? (fwd)
References: <200011101749.UAA23246@ms2.inr.ac.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

bit of a mess, yes ;^p

kuznet@ms2.inr.ac.ru wrote:

> Hello!
>
> > the firewall happens to be doing the handshaking on all incoming TCP connections, been the victim
> > of several TCP/SYN flood attacks. maybe this is where it flakes?  the firewall intercepts the
> > client SYN, send the SYN/ACK, waits for the client ACK.  if it gets the ACK it's supposed to open
> > up a new connection to the server.
>
> I heard that such beasts exist, but believed that it is rather joke.
> Hmm... not a joke, indeed. Bad joke to be more exact. 8)
>
> Apparently, it tries to relay options received in server's SYN-ACK.
> It is too late to drink mineral water, when kidneys dilapidated. 8)8)
>
> Alexey


From owner-netdev@oss.sgi.com Fri Nov 10 10:17:58 2000
Received:  by oss.sgi.com id <S554078AbQKJSRi>;
	Fri, 10 Nov 2000 10:17:38 -0800
Received: from eagle.deardorff.com ([209.245.27.50]:33037 "EHLO
        eagle.deardorff.com") by oss.sgi.com with ESMTP id <S553848AbQKJSRY>;
	Fri, 10 Nov 2000 10:17:24 -0800
Received: from localhost (gws@localhost)
	by eagle.deardorff.com (8.11.1/8.11.1) with ESMTP id eAAIHM331950
	for <netdev@oss.sgi.com>; Fri, 10 Nov 2000 13:17:22 -0500
Date:   Fri, 10 Nov 2000 13:17:21 -0500 (EST)
From:   Greg Simpson <gws@eagle.deardorff.com>
To:     netdev@oss.sgi.com
Subject: colliding ip detection!
In-Reply-To: <3A0C2838.99F67A2E@reutershealth.com>
Message-ID: <Pine.LNX.4.10.10011101305010.28069-100000@eagle.deardorff.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing


One of my friends was just complaining to me about how his inetd was
acting up.. '2.2.16 #97 Fri Jun 16 19:45:30 PDT 2000 i486 unknown'.

(#97? I don't have any idea why.. :)

Of course, when he took it offline and noticed that it was still returning
pings, he realized that he was using the same ip address as another
machine outside of his group. This reminded me that on other networks I
have been on, I have found someone else using the same ip address.

M$-windows of course pops up a friendly dialog box, indicating that the ip
has been detected in use by someone else, and courteously disables that
ethernet interface for you :) :)

The question:

linux does not seem to indicate if anyone else answers arp requests for
its own ip's (correct me if i am wrong); how does one tell if the ip is in
use [short of unplugging the box or querying someone else's arp tables :)
:)]?

I would think a syslog entry would be most helpful to a lot of people on
dhcp-run networks!

-g


From owner-netdev@oss.sgi.com Fri Nov 10 10:55:58 2000
Received:  by oss.sgi.com id <S554075AbQKJSzj>;
	Fri, 10 Nov 2000 10:55:39 -0800
Received: from alcove.wittsend.com ([130.205.0.20]:25093 "EHLO
        alcove.wittsend.com") by oss.sgi.com with ESMTP id <S553849AbQKJSzT>;
	Fri, 10 Nov 2000 10:55:19 -0800
Received: (from mhw@localhost)
	by alcove.wittsend.com (8.9.3/8.9.3) id OAA06673;
	Fri, 10 Nov 2000 14:54:14 -0500
Date:   Fri, 10 Nov 2000 14:54:14 -0500
From:   "Michael H. Warfield" <mhw@wittsend.com>
To:     Greg Simpson <gws@eagle.deardorff.com>
Cc:     netdev@oss.sgi.com
Subject: Re: colliding ip detection!
Message-ID: <20001110145414.A4310@alcove.wittsend.com>
Mail-Followup-To: Greg Simpson <gws@eagle.deardorff.com>,
	netdev@oss.sgi.com
References: <3A0C2838.99F67A2E@reutershealth.com> <Pine.LNX.4.10.10011101305010.28069-100000@eagle.deardorff.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.2i
In-Reply-To: <Pine.LNX.4.10.10011101305010.28069-100000@eagle.deardorff.com>; from gws@eagle.deardorff.com on Fri, Nov 10, 2000 at 01:17:21PM -0500
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Nov 10, 2000 at 01:17:21PM -0500, Greg Simpson wrote:

> One of my friends was just complaining to me about how his inetd was
> acting up.. '2.2.16 #97 Fri Jun 16 19:45:30 PDT 2000 i486 unknown'.

> (#97? I don't have any idea why.. :)

> Of course, when he took it offline and noticed that it was still returning
> pings, he realized that he was using the same ip address as another
> machine outside of his group. This reminded me that on other networks I
> have been on, I have found someone else using the same ip address.

> M$-windows of course pops up a friendly dialog box, indicating that the ip
> has been detected in use by someone else, and courteously disables that
> ethernet interface for you :) :)

	M$ farts out prodigeous numbers of broadcast packets and expects
to seen prodigeous numbers of broadcast packets.  It spots the fact that
someone else sends out a packet with your IP address in the src address.
(at least that's one way they detect it).  Amusing random acts of terrorism
can result including some spectacular denial of service attacks (think
about it for a second).

> The question:

> linux does not seem to indicate if anyone else answers arp requests for
> its own ip's (correct me if i am wrong); how does one tell if the ip is in
> use [short of unplugging the box or querying someone else's arp tables :)
> :)]?

	Detecting the arp replies would not work on a switched network.
You generally need to see another system (one with a MAC address you
don't own) claiming to be an IP address which you claim.  On a switched
network, this generally must be a broadcast packet and you examine the
source IP and source MAC (consider the case where YOU have two network
cards on the same cable - this can be a non-trivial exercise with
unexpected surprises).

	Keying off of arp replies or broadcast packet source addresses
opens up some nasty DoS attacks.  I could just flood the network with
fake packets claiming to be different MAC addresses and IP addresses of
systems I want to shut down.  Do it with Windows named datagrams (UDP port
137) and older windows systems just fall over very nicely and hit the floor.
It's tougher to do with newer Windows systems and there are much more fun
games you can play with the name caches instead.

> I would think a syslog entry would be most helpful to a lot of people on
> dhcp-run networks!

	Dhcpd (at least the ISC one) attempts to ping the address before
assigning a lease.  If it gets a ping response, the address is flagged
as "abandoned" in the leases file.  Hijacked addresses are thus avoided
and not leased out.  Then, when you find your leases file full of abandoned
entries, you get to track down the guilty parties and deliver a rubber hose
IP release datagram to them.  Repeatedly.  :-)

> -g

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!


From owner-netdev@oss.sgi.com Fri Nov 10 11:32:18 2000
Received:  by oss.sgi.com id <S554080AbQKJTb6>;
	Fri, 10 Nov 2000 11:31:58 -0800
Received: from eagle.deardorff.com ([209.245.27.50]:30990 "EHLO
        eagle.deardorff.com") by oss.sgi.com with ESMTP id <S553868AbQKJTbn>;
	Fri, 10 Nov 2000 11:31:43 -0800
Received: from localhost (gws@localhost)
	by eagle.deardorff.com (8.11.1/8.11.1) with ESMTP id eAAJVcS00799;
	Fri, 10 Nov 2000 14:31:38 -0500
Date:   Fri, 10 Nov 2000 14:31:38 -0500 (EST)
From:   Greg Simpson <gws@eagle.deardorff.com>
To:     "Michael H. Warfield" <mhw@wittsend.com>
cc:     netdev@oss.sgi.com
Subject: Re: colliding ip detection!
In-Reply-To: <20001110145414.A4310@alcove.wittsend.com>
Message-ID: <Pine.LNX.4.10.10011101401400.28069-100000@eagle.deardorff.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

[Pardon for the lengthy reply. I just finished composing it, and scrolled
up to see how much babble had found its way into the body.. =)]

> 	M$ farts out prodigeous numbers of broadcast packets and expects
> to seen prodigeous numbers of broadcast packets.  It spots the fact that
> someone else sends out a packet with your IP address in the src address.

It seems like if we see a packet src'd from our own ip, but not from us,
we should report it though, doesn't it? It's either a spoof [bad] or a
conflict [bad]. Either way, bad|bad = bad -> I want to know about it :)

> (at least that's one way they detect it).  Amusing random acts of terrorism
> can result including some spectacular denial of service attacks (think
> about it for a second).

Been there, done that. Laughed hard, ran fast. =) [wouldn't recommend
trying it unless you can 'create' a temporary mac address :)]

It made me question the wisdom of automagically ifconfig'ing the int
down.. but I still want to know when this happens :)

> > linux does not seem to indicate if anyone else answers arp requests for
> > its own ip's (correct me if i am wrong); how does one tell if the ip is in
> > use [short of unplugging the box or querying someone else's arp tables :)
> > :)]?
> 
> 	Detecting the arp replies would not work on a switched network.

Yeah, but consider this. I am not asking to know for sure if the ip is NOT
in use (you assume that when you ifconfig the int with an ip!). I am
asking to know under *some* conditions that it IS in use..
Those people with winblows boxen =) DO feel they have as much of a right
to use the network as you, and their magically disabled boxen point
fingers back at your linux box :) 

Say there is a switched network, and the switch gets confused, and only
keeps the most recent arp entry. Somebody doesn't work, and it has to be
tracked down. Say one of the boxes is a winbox, sending out broadcasts.
In that case, we would realize from our syslog/etc that we are hearing the
other machine's broadcasts, and maybe the operator should be notified.

So, I guess ip collision detection wouldn't work if:
 - the machines are separated by a switch
AND
 - both are not sending out broadcast [both non-ms, no samba]

Wouldn't you say that in most cases it WOULD work, though?

> You generally need to see another system (one with a MAC address you
> don't own) claiming to be an IP address which you claim.  On a switched
> network, this generally must be a broadcast packet and you examine the
> source IP and source MAC (consider the case where YOU have two network
> cards on the same cable - this can be a non-trivial exercise with
> unexpected surprises).

Well.. ok, so we have to walk down a list and try to match against our own
MAC's. Big performance hit per every packet we tx that we also rx. Well,
does every packet we tx come back into rx? I thought that would only
happen if you have ipaliases setup.. maybe vlans..

> 	Keying off of arp replies or broadcast packet source addresses
> opens up some nasty DoS attacks.  I could just flood the network with
> fake packets claiming to be different MAC addresses and IP addresses of
> systems I want to shut down.  Do it with Windows named datagrams (UDP port
> 137) and older windows systems just fall over very nicely and hit the floor.
> It's tougher to do with newer Windows systems and there are much more fun
> games you can play with the name caches instead.

Yeah, but this isn't about a creating a DoS. This is about detecting a
possible DoS (that we either created unintentionally by using the same ip
as someone else, or that someone else created by using our ip), detecting
a real DoS (someone on a network sourcing packets to net_broadcast using
every ip in the subnet, as you indicated), or just helping save the
forehead of some sysadmin (like my friend) that can't figure out why his
box is acting wacky :)

I also wouldn't suggest ifconfig'ing the int down upon receipt of a
flagged packet, but like I said.. see next line :)

> > I would think a syslog entry would be most helpful to a lot of people on
> > dhcp-run networks!
> 
> 	Dhcpd (at least the ISC one) attempts to ping the address before
> assigning a lease.  If it gets a ping response, the address is flagged
> as "abandoned" in the leases file.  Hijacked addresses are thus avoided
> and not leased out.  Then, when you find your leases file full of abandoned
> entries, you get to track down the guilty parties and deliver a rubber hose
> IP release datagram to them.  Repeatedly.  :-)

Yeah, but on a college network, you can't expect to win an argument, even
if you are right. Not everyone has the luxury of power, or ISC dhcpd :)
[How many embedded/network appliances have built-in dhcp servers now?]

-g


From owner-netdev@oss.sgi.com Fri Nov 10 13:30:38 2000
Received:  by oss.sgi.com id <S553873AbQKJVaS>;
	Fri, 10 Nov 2000 13:30:18 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:28690 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S553857AbQKJVaO>;
	Fri, 10 Nov 2000 13:30:14 -0800
Received: (from garzik@localhost)
	by havoc.gtf.org (8.9.3/8.9.3) id QAA13369;
	Fri, 10 Nov 2000 16:29:51 -0500
Date:   Fri, 10 Nov 2000 16:29:51 -0500
Message-Id: <200011102129.QAA13369@havoc.gtf.org>
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
To:     linux-kernel@vger.kernel.org
CC:     torvalds@transmeta.com, netdev@oss.sgi.com
Subject: PATCH: 8139too kernel thread
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

(note Linus, not for applying...)

Here is a patch, against 2.4.0-test11-pre2, that I wanted to forward
to the lists for comment.

Many of the ethernet drivers have timer routines, which are
called every three-five seconds or so.  These timer routines
typically do stuff related to media selection or checking, and call
mdio_{read,write} to interact with the phy.

I have converted the timer routine over to a kernel thread, to
gain some flexibility.  Most importantly we can sleep in the kernel
thread.. sometimes media selection takes a long time.  Also, figuring
out locking gets easier.  For the primary case I see, mdio_xxx usage
in timer and ioctl, converting to a kernel thread means we can grab
rtnl_lock in the thread and be totally identical with ioctl's locking
and sleeping rules.

Bonus features:  user can kill the thread to stop media pinging, can't
do this in most drivers.  And, if we want to do spiffy background
stuff, the framework will already be in place.

The main motivation for this scheme is that there are corner cases
all over the place (in other drivers) where code exists basically
because a timer is less flexible than a kthread.  Or, the timer does
evil stuff like delays for a -really- long time while doing media
selection, and it should be in a kthread anyway.

The only disadvantage to this scheme is the added cost of a kernel
thread over a kernel timer.  I think this is an ok cost, because this
is a low-impact thread that sleeps a lot..

Finally, there are some unrelated changes in the patch presented below.
Just ignore those :)


Index: linux_2_4/drivers/net/8139too.c
diff -u linux_2_4/drivers/net/8139too.c:1.1.1.7 linux_2_4/drivers/net/8139too.c:1.1.1.7.2.5
--- linux_2_4/drivers/net/8139too.c:1.1.1.7	Thu Nov  9 18:09:11 2000
+++ linux_2_4/drivers/net/8139too.c	Fri Nov 10 12:51:09 2000
@@ -134,6 +134,9 @@
 
 */
 
+#define __KERNEL_SYSCALLS__ 1
+
+#include <linux/config.h>
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/pci.h>
@@ -142,17 +145,20 @@
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
 #include <linux/delay.h>
+#include <linux/unistd.h>
 #include <asm/io.h>
 
 
-#define RTL8139_VERSION "0.9.11"
-#define RTL8139_MODULE_NAME "8139too"
-#define RTL8139_DRIVER_NAME   RTL8139_MODULE_NAME " Fast Ethernet driver " RTL8139_VERSION
-#define PFX RTL8139_MODULE_NAME ": "
+#define RTL8139_VERSION "0.9.12cvs"
+#define MODNAME "8139too"
+#define RTL8139_DRIVER_NAME   MODNAME " Fast Ethernet driver " RTL8139_VERSION
+#define PFX MODNAME ": "
 
 
-/* define to 1 to enable PIO instead of MMIO */
-#undef USE_IO_OPS
+/* enable PIO instead of MMIO, if CONFIG_8139TOO_PIO is selected */
+#ifdef CONFIG_8139TOO_PIO
+#define USE_IO_OPS 1
+#endif
 
 /* define to 1 to enable copious debugging info */
 #undef RTL8139_DEBUG
@@ -179,6 +185,8 @@
 #endif
 
 
+static int errno;
+
 /* A few user-configurable values. */
 /* media options */
 static int media[] = {-1, -1, -1, -1, -1, -1, -1, -1};
@@ -502,7 +510,6 @@
 	int drv_flags;
 	struct pci_dev *pci_dev;
 	struct net_device_stats stats;
-	struct timer_list timer;	/* Media selection timer. */
 	unsigned char *rx_ring;
 	unsigned int cur_rx;	/* Index into the Rx buffer of next Rx pkt. */
 	unsigned int tx_flag;
@@ -524,6 +531,9 @@
 	unsigned int mediasense:1;	/* Media sensing in progress. */
 	spinlock_t lock;
 	chip_t chipset;
+	wait_queue_head_t thr_wait;
+	int thr_shutdown;
+	pid_t thr_pid;
 };
 
 MODULE_AUTHOR ("Jeff Garzik <jgarzik@mandrakesoft.com>");
@@ -538,7 +548,7 @@
 static int mdio_read (struct net_device *dev, int phy_id, int location);
 static void mdio_write (struct net_device *dev, int phy_id, int location,
 			int val);
-static void rtl8139_timer (unsigned long data);
+static int rtl8139_thread (void *data);
 static void rtl8139_tx_timeout (struct net_device *dev);
 static void rtl8139_init_ring (struct net_device *dev);
 static int rtl8139_start_xmit (struct sk_buff *skb,
@@ -867,7 +876,8 @@
 	tp->pci_dev = pdev;
 	tp->board = ent->driver_data;
 	tp->mmio_addr = ioaddr;
-	tp->lock = SPIN_LOCK_UNLOCKED;
+	spin_lock_init (&tp->lock);
+	init_waitqueue_head (&tp->thr_wait);
 
 	pdev->driver_data = dev;
 
@@ -897,7 +907,7 @@
 	RTL_W8_F (HltClk, 'H');	/* 'R' would leave the clock running. */
 
 	/* The lower four bits are the media type. */
-	option = (board_idx > 7) ? 0 : media[board_idx];
+	option = (board_idx >= ARRAY_SIZE(media)) ? 0 : media[board_idx];
 	if (option > 0) {
 		tp->full_duplex = (option & 0x200) ? 1 : 0;
 		tp->default_port = option & 15;
@@ -1193,6 +1203,7 @@
 
 	tp->full_duplex = tp->duplex_lock;
 	tp->tx_flag = (TX_FIFO_THRESH << 11) & 0x003f0000;
+	tp->twistie = 1;
 
 	rtl8139_init_ring (dev);
 	rtl8139_hw_start (dev);
@@ -1203,13 +1214,7 @@
 			dev->irq, RTL_R8 (MediaStatus),
 			tp->full_duplex ? "full" : "half");
 
-	/* Set the timer to switch to check for link beat and perhaps switch
-	   to an alternate media type. */
-	init_timer (&tp->timer);
-	tp->timer.expires = jiffies + 3 * HZ;
-	tp->timer.data = (unsigned long) dev;
-	tp->timer.function = &rtl8139_timer;
-	add_timer (&tp->timer);
+	tp->thr_pid = kernel_thread (rtl8139_thread, dev, 0);
 
 	DPRINTK ("EXIT, returning 0\n");
 	return 0;
@@ -1330,7 +1335,10 @@
 }
 
 
-#ifndef RTL_TUNE_TWISTER
+/* This must be global for CONFIG_8139TOO_TUNE_TWISTER case */
+static int next_tick = 3 * HZ;
+
+#ifndef CONFIG_8139TOO_TUNE_TWISTER
 static inline void rtl8139_tune_twister (struct net_device *dev,
 				  struct rtl8139_private *tp) {}
 #else
@@ -1338,6 +1346,7 @@
 				  struct rtl8139_private *tp)
 {
 	int linkcase;
+	void *ioaddr = tp->mmio_addr; /* SAM */
 
 	DPRINTK ("ENTER\n");
 
@@ -1421,18 +1430,18 @@
 
 	DPRINTK ("EXIT\n");
 }
-#endif /* RTL_TUNE_TWISTER */
+#endif /* CONFIG_8139TOO_TUNE_TWISTER */
 
 
-static void rtl8139_timer (unsigned long data)
+static void rtl8139_thread_iter (struct net_device *dev,
+				 struct rtl8139_private *tp,
+				 void *ioaddr)
 {
-	struct net_device *dev = (struct net_device *) data;
-	struct rtl8139_private *tp = (struct rtl8139_private *) dev->priv;
-	void *ioaddr = tp->mmio_addr;
-	int next_tick = 60 * HZ;
 	int mii_reg5;
 
+	spin_lock (&tp->lock);
 	mii_reg5 = mdio_read (dev, tp->phys[0], 5);
+	spin_unlock (&tp->lock);
 
 	if (!tp->duplex_lock && mii_reg5 != 0xffff) {
 		int duplex = (mii_reg5 & 0x0100)
@@ -1450,6 +1459,8 @@
 		}
 	}
 
+	next_tick = HZ * 60;
+
 	rtl8139_tune_twister (dev, tp);
 
 	DPRINTK ("%s: Media selection tick, Link partner %4.4x.\n",
@@ -1462,9 +1473,34 @@
 	DPRINTK ("%s:  Chip config %2.2x %2.2x.\n",
 		 dev->name, RTL_R8 (Config0),
 		 RTL_R8 (Config1));
+}
+
+
+static int rtl8139_thread (void *data)
+{
+	struct net_device *dev = data;
+	struct rtl8139_private *tp = dev->priv;
+	void *ioaddr = tp->mmio_addr;
+	unsigned long timeout;
+
+	MOD_INC_USE_COUNT;
 
-	tp->timer.expires = jiffies + next_tick;
-	add_timer (&tp->timer);
+	daemonize ();
+	sprintf (current->comm, "k8139d-%s", dev->name);
+
+	while (!test_bit(1, &tp->thr_shutdown)) {
+		timeout = next_tick;
+		do {
+			timeout = interruptible_sleep_on_timeout (&tp->thr_wait, timeout);
+		} while (!signal_pending (current) && (timeout > 0));
+		if (signal_pending (current))
+			break;
+
+		rtl8139_thread_iter (dev, tp, ioaddr);
+	}
+
+	MOD_DEC_USE_COUNT;
+	return 0;
 }
 
 
@@ -1550,11 +1586,20 @@
 	assert (tp->tx_info[entry].mapping == 0);
 
 	tp->tx_info[entry].skb = skb;
-	/* tp->tx_info[entry].mapping = 0; */
-	memcpy (tp->tx_buf[entry], skb->data, skb->len);
+	if ((long) skb->data & 3) {	/* Must use alignment buffer. */
+		/* tp->tx_info[entry].mapping = 0; */
+		memcpy (tp->tx_buf[entry], skb->data, skb->len);
+		RTL_W32 (TxAddr0 + (entry * 4),
+			 tp->tx_bufs_dma + (tp->tx_buf[entry] - tp->tx_bufs));
+	} else {
+		tp->tx_info[entry].mapping =
+		    pci_map_single (tp->pci_dev, skb->data, skb->len,
+				    PCI_DMA_TODEVICE);
+		RTL_W32 (TxAddr0 + (entry * 4), tp->tx_info[entry].mapping);
+	}
 
 	/* Note: the chip doesn't have auto-pad! */
-	RTL_W32 (TxStatus0 + (entry * sizeof(u32)),
+	RTL_W32 (TxStatus0 + (entry * sizeof (u32)),
 		 tp->tx_flag | (skb->len >= ETH_ZLEN ? skb->len : ETH_ZLEN));
 
 	dev->trans_start = jiffies;
@@ -1962,19 +2007,21 @@
 
 static int rtl8139_close (struct net_device *dev)
 {
-	struct rtl8139_private *tp = (struct rtl8139_private *) dev->priv;
+	struct rtl8139_private *tp = dev->priv;
 	void *ioaddr = tp->mmio_addr;
 	unsigned long flags;
 
 	DPRINTK ("ENTER\n");
 
+	set_bit (1, &tp->thr_shutdown);
+	wake_up_interruptible (&tp->thr_wait);
+	waitpid (tp->thr_pid, NULL, 0);
+
 	netif_stop_queue (dev);
 
 	DPRINTK ("%s: Shutting down ethercard, status was 0x%4.4x.\n",
 			dev->name, RTL_R16 (IntrStatus));
 
-	del_timer_sync (&tp->timer);
-
 	spin_lock_irqsave (&tp->lock, flags);
 
 	/* Stop the chip's Tx and Rx DMA processes. */
@@ -2015,9 +2062,8 @@
 
 static int mii_ioctl (struct net_device *dev, struct ifreq *rq, int cmd)
 {
-	struct rtl8139_private *tp = (struct rtl8139_private *) dev->priv;
+	struct rtl8139_private *tp = dev->priv;
 	u16 *data = (u16 *) & rq->ifr_data;
-	unsigned long flags;
 	int rc = 0;
 
 	DPRINTK ("ENTER\n");
@@ -2028,9 +2074,9 @@
 		/* Fall Through */
 
 	case SIOCDEVPRIVATE + 1:	/* Read the specified MII register. */
-		spin_lock_irqsave (&tp->lock, flags);
+		spin_lock (&tp->lock);
 		data[3] = mdio_read (dev, data[0], data[1] & 0x1f);
-		spin_unlock_irqrestore (&tp->lock, flags);
+		spin_unlock (&tp->lock);
 		break;
 
 	case SIOCDEVPRIVATE + 2:	/* Write the specified MII register */
@@ -2039,9 +2085,9 @@
 			break;
 		}
 
-		spin_lock_irqsave (&tp->lock, flags);
+		spin_lock (&tp->lock);
 		mdio_write (dev, data[0], data[1] & 0x1f, data[2]);
-		spin_unlock_irqrestore (&tp->lock, flags);
+		spin_unlock (&tp->lock);
 		break;
 
 	default:

From owner-netdev@oss.sgi.com Fri Nov 10 16:50:00 2000
Received:  by oss.sgi.com id <S553879AbQKKAtl>;
	Fri, 10 Nov 2000 16:49:41 -0800
Received: from horus.its.uow.edu.au ([130.130.68.25]:19645 "EHLO
        horus.its.uow.edu.au") by oss.sgi.com with ESMTP id <S553874AbQKKAtP>;
	Fri, 10 Nov 2000 16:49:15 -0800
Received: from uow.edu.au (wumpus.its.uow.edu.au [130.130.68.12])
	by horus.its.uow.edu.au (8.9.3/8.9.3) with ESMTP id LAA14312;
	Sat, 11 Nov 2000 11:48:38 +1100 (EST)
Message-ID: <3A0C9778.E982F55B@uow.edu.au>
Date:   Sat, 11 Nov 2000 11:48:56 +1100
From:   Andrew Morton <andrewm@uow.edu.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.0-test8 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Jeff Garzik <jgarzik@mandrakesoft.com>
CC:     linux-kernel@vger.kernel.org, Rik van Riel <riel@conectiva.com.br>,
        netdev@oss.sgi.com
Subject: Re: PATCH: 8139too kernel thread
References: <200011102129.QAA13369@havoc.gtf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Jeff Garzik wrote:
> 
> (note Linus, not for applying...)
> 
> Here is a patch, against 2.4.0-test11-pre2, that I wanted to forward
> to the lists for comment.
> 
> Many of the ethernet drivers have timer routines, which are
> called every three-five seconds or so.  These timer routines
> typically do stuff related to media selection or checking, and call
> mdio_{read,write} to interact with the phy.
> 

I think it's useful.  More generally, I'd like to have
"process context timers" - the ability to call a function
from process context at a set time.  Then a single kernel
thread could handle all things like this.  Pretty simple to do.


BTW: can the OOM killer possibly kill a kernel thread?
If it does, yenta_socket_thread() will nuke the machine.

From owner-netdev@oss.sgi.com Sat Nov 11 08:10:09 2000
Received:  by oss.sgi.com id <S553893AbQKKQJu>;
	Sat, 11 Nov 2000 08:09:50 -0800
Received: from laurin.munich.netsurf.de ([194.64.166.1]:33718 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S553888AbQKKQJ0>; Sat, 11 Nov 2000 08:09:26 -0800
Received: from fred.muc.de (ns1176.munich.netsurf.de [195.180.235.176])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id RAA03522;
	Sat, 11 Nov 2000 17:09:15 +0100 (MET)
Received: by fred.muc.de (Postfix, from userid 500)
	id C927EE3912; Sat, 11 Nov 2000 16:17:07 +0100 (CET)
Date:   Sat, 11 Nov 2000 16:17:07 +0100
From:   Andi Kleen <ak@muc.de>
To:     kuznet@ms2.inr.ac.ru
Cc:     Alexander Stanich <astanich@reutershealth.com>, patrik@ein.cz,
        netdev@oss.sgi.com
Subject: Re: Bug in TCP/IP stack in 2.2.17? (fwd)
Message-ID: <20001111161707.A6901@fred.local>
References: <3A0C2C04.1B720C90@reutershealth.com> <200011101749.UAA23246@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200011101749.UAA23246@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Fri, Nov 10, 2000 at 06:50:59PM +0100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Nov 10, 2000 at 06:50:59PM +0100, A.N.Kuznetsov wrote:
> Hello!
> 
> > the firewall happens to be doing the handshaking on all incoming TCP connections, been the victim
> > of several TCP/SYN flood attacks. maybe this is where it flakes?  the firewall intercepts the
> > client SYN, send the SYN/ACK, waits for the client ACK.  if it gets the ACK it's supposed to open
> > up a new connection to the server. 
> 
> I heard that such beasts exist, but believed that it is rather joke.
> Hmm... not a joke, indeed. Bad joke to be more exact. 8)
> 
> Apparently, it tries to relay options received in server's SYN-ACK.
> It is too late to drink mineral water, when kidneys dilapidated. 8)8)

And someone posted a patch to let Linux do that on l-k a few weeks ago ...
(actually using syncookies so it at least didn't mangle any options) 


-Andi

-- 
This is like TV. I don't like TV.

From owner-netdev@oss.sgi.com Sat Nov 11 08:36:10 2000
Received:  by oss.sgi.com id <S553895AbQKKQgA>;
	Sat, 11 Nov 2000 08:36:00 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:5905 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553892AbQKKQfs>;
	Sat, 11 Nov 2000 08:35:48 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id TAA04251; Sat, 11 Nov 2000 19:35:09 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011111635.TAA04251@ms2.inr.ac.ru>
Subject: Re: Bug in TCP/IP stack in 2.2.17? (fwd)
To:     ak@muc.de (Andi Kleen)
Date:   Sat, 11 Nov 2000 19:35:09 +0300 (MSK)
Cc:     astanich@reutershealth.com, patrik@ein.cz, netdev@oss.sgi.com
In-Reply-To: <20001111161707.A6901@fred.local> from "Andi Kleen" at Nov 11, 0 04:17:07 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 217       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> And someone posted a patch to let Linux do that on l-k a few weeks ago ...
> (actually using syncookies so it at least didn't mangle any options) 

And we are not going to accept this patch, I hope.

Alexey

From owner-netdev@oss.sgi.com Sun Nov 12 03:49:17 2000
Received:  by oss.sgi.com id <S553903AbQKLLs5>;
	Sun, 12 Nov 2000 03:48:57 -0800
Received: from thalia.fm.intel.com ([132.233.247.11]:27409 "EHLO
        thalia.fm.intel.com") by oss.sgi.com with ESMTP id <S553901AbQKLLsd>;
	Sun, 12 Nov 2000 03:48:33 -0800
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id LAA00100;
	Sun, 12 Nov 2000 11:49:47 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Sun, 12 Nov 2000 11:48:30 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <WS6RY8KC>; Sun, 12 Nov 2000 03:48:28 -0800
Message-ID: <07E6E3B8C072D211AC4100A0C9C5758302B2708E@hasmsx52.iil.intel.com>
From:   "Hen, Shmulik" <shmulik.hen@intel.com>
To:     "'Jeff Garzik'" <jgarzik@mandrakesoft.com>,
        "Hen, Shmulik" <shmulik.hen@intel.com>
Cc:     "'LNML'" <linux-net@vger.kernel.org>,
        "'LKML'" <linux-kernel@vger.kernel.org>, netdev@oss.sgi.com
Subject: RE: catch 22 - porting net driver from 2.2 to 2.4
Date:   Sun, 12 Nov 2000 03:48:22 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

So how come I get the "RTNL: assertion failed at
devinet.c(775):inetdev_event" when I call register_netdevice without
rtnl_lock/unlock ?
could it be a 2.4.0-test9 thing ? (haven't used test10 or 11 yet).

and what about rmmod causing the panic when I use unregister_netdev or never
completing the operation when I use unregister_netdevice ?
does module_exit run inside rtnl_lock too ?


	Shmulik.

-----Original Message-----
From: Jeff Garzik [mailto:jgarzik@mandrakesoft.com]
Sent: Thursday, November 09, 2000 7:37 PM
To: Hen, Shmulik
Cc: 'LNML'; 'LKML'; netdev@oss.sgi.com
Subject: Re: catch 22 - porting net driver from 2.2 to 2.4


do_ioctl is inside rtnl_lock...

Remember if you need to alter the rules, you can always queue work in
the current context, and have a kernel thread handle the work.  The nice
thing about a kernel thread is that you start with a [almost] clean
state, when it comes to locks.

	Jeff


-- 
Jeff Garzik             |
Building 1024           | Would you like a Twinkie?
MandrakeSoft            |
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org


From owner-netdev@oss.sgi.com Sun Nov 12 03:54:37 2000
Received:  by oss.sgi.com id <S553906AbQKLLyR>;
	Sun, 12 Nov 2000 03:54:17 -0800
Received: from a203-167-249-89.reverse.clear.net.nz ([203.167.249.89]:10244
        "HELO metastasis.f00f.org") by oss.sgi.com with SMTP
	id <S553902AbQKLLyH>; Sun, 12 Nov 2000 03:54:07 -0800
Received: by metastasis.f00f.org (Postfix, from userid 1000)
	id 56B9D9DA8; Mon, 13 Nov 2000 00:54:03 +1300 (NZDT)
Date:   Mon, 13 Nov 2000 00:54:03 +1300
From:   Chris Wedgwood <cw@f00f.org>
To:     kuznet@ms2.inr.ac.ru
Cc:     Andi Kleen <ak@muc.de>, astanich@reutershealth.com, patrik@ein.cz,
        netdev@oss.sgi.com
Subject: Re: Bug in TCP/IP stack in 2.2.17? (fwd)
Message-ID: <20001113005403.A2187@metastasis.f00f.org>
References: <20001111161707.A6901@fred.local> <200011111635.TAA04251@ms2.inr.ac.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200011111635.TAA04251@ms2.inr.ac.ru>; from kuznet@ms2.inr.ac.ru on Sat, Nov 11, 2000 at 07:35:09PM +0300
X-No-Archive: Yes
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Sat, Nov 11, 2000 at 07:35:09PM +0300, kuznet@ms2.inr.ac.ru wrote:

    And we are not going to accept this patch, I hope.

Did we ever determine what kind of firewall this is?


  --cw

From owner-netdev@oss.sgi.com Sun Nov 12 04:18:37 2000
Received:  by oss.sgi.com id <S553910AbQKLMS1>;
	Sun, 12 Nov 2000 04:18:27 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:29455 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S553904AbQKLMSM>;
	Sun, 12 Nov 2000 04:18:12 -0800
Received: from mandrakesoft.com (adsl-20-73-115.asm.bellsouth.net [66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id HAA19629;
	Sun, 12 Nov 2000 07:17:57 -0500
Message-ID: <3A0E8A75.A1C24416@mandrakesoft.com>
Date:   Sun, 12 Nov 2000 07:17:57 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Hen, Shmulik" <shmulik.hen@intel.com>
CC:     "'LNML'" <linux-net@vger.kernel.org>,
        "'LKML'" <linux-kernel@vger.kernel.org>, netdev@oss.sgi.com
Subject: Re: catch 22 - porting net driver from 2.2 to 2.4
References: <07E6E3B8C072D211AC4100A0C9C5758302B2708E@hasmsx52.iil.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

"Hen, Shmulik" wrote:
> 
> So how come I get the "RTNL: assertion failed at
> devinet.c(775):inetdev_event" when I call register_netdevice without
> rtnl_lock/unlock ?

Uh.  Don't do that.  You MUST call register_netdevice with rtnl_lock
held.


> and what about rmmod causing the panic when I use unregister_netdev or never
> completing the operation when I use unregister_netdevice ?
> does module_exit run inside rtnl_lock too ?

module_exit does not run inside rtnl_lock.

Theoretically, if you call unregister_netdev from rmmon, it should grab
rtnl_lock and then complete the operation for you.  If that doesn't work
for you, it sounds like you are not setting up, or cleaning up,
something correctly.

Basically... it sounds like there are still bugs in your driver that
need working out :)

	Jeff


-- 
Jeff Garzik             |
Building 1024           | Would you like a Twinkie?
MandrakeSoft            |

From owner-netdev@oss.sgi.com Sun Nov 12 05:25:58 2000
Received:  by oss.sgi.com id <S553912AbQKLNZr>;
	Sun, 12 Nov 2000 05:25:47 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:52740 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553908AbQKLNZb>;
	Sun, 12 Nov 2000 05:25:31 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id QAA16208; Sun, 12 Nov 2000 16:25:12 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011121325.QAA16208@ms2.inr.ac.ru>
Subject: Re: Bug in TCP/IP stack in 2.2.17? (fwd)
To:     cw@f00f.org (Chris Wedgwood)
Date:   Sun, 12 Nov 2000 16:25:12 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20001113005403.A2187@metastasis.f00f.org> from "Chris Wedgwood" at Nov 13, 0 00:54:03 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 92        
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> Did we ever determine what kind of firewall this is?

cyberguard firewall

Alexey

From owner-netdev@oss.sgi.com Sun Nov 12 06:37:29 2000
Received:  by oss.sgi.com id <S553915AbQKLOhT>;
	Sun, 12 Nov 2000 06:37:19 -0800
Received: from sirppi.helsinki.fi ([128.214.205.27]:18696 "EHLO
        sirppi.helsinki.fi") by oss.sgi.com with ESMTP id <S553911AbQKLOhH>;
	Sun, 12 Nov 2000 06:37:07 -0800
Received: from localhost (amlaukka@localhost)
	by sirppi.helsinki.fi (8.10.1/8.10.1) with ESMTP id eACEb0c03436
	for <netdev@oss.sgi.com>; Sun, 12 Nov 2000 16:37:01 +0200 (EET)
X-Authentication-Warning: sirppi.helsinki.fi: amlaukka owned process doing -bs
Date:   Sun, 12 Nov 2000 16:37:00 +0200 (EET)
From:   Aki M Laukkanen <amlaukka@cc.helsinki.fi>
To:     <netdev@oss.sgi.com>
Subject: IPv6 evaluating according to draft-ietf-ipngwg-icmp-v3-00.eval
Message-ID: <Pine.OSF.4.30.0011121626380.9072-100000@sirppi.helsinki.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello,
The next installment in the evaluation series. The full raw texts are
available at:

http://www.cs.helsinki.fi/u/amlaukka/ipv6/rfc2460-01.eval
http://www.cs.helsinki.fi/u/amlaukka/ipv6/draft-icmp-v3-00.eval

This is the shortened version. There are some minor points but
nothing really major, except for the lack of anycast support?

---
INTERNET-DRAFT                                         A. Conta, Lucent
IPNG Working Group                            S. Deering, Cisco Systems

               Internet Control Message Protocol (ICMPv6)
               for the Internet Protocol Version 6 (IPv6)
                             Specification

                   <draft-ietf-ipngwg-icmp-v3-00.txt>

   This document specifies a set of Internet Control Message Protocol
   (ICMP) messages for use with version 6 of the Internet Protocol
   (IPv6).
+++

This is a raw "code-review" type evaluation of the Linux IPv6 stack
implementation according to the requirements specified in the above
document.

Disclaimer:
o Passing this review does not mean the code is not buggy. Only that
  it appears to pass the requirements in the respective RFCs. I've tried
  to look for bugs in the process but of course can't guarantee anything.
o Also I can not guarantee that I misintepreted some requirement or
  the code that was supposed to implement it.
o RFCs are not a substitute for design document - meaning they assume
  a level that is above the implementation. Implementation can make
  wrong decisions which are not simply covered in the RFCs.

Definition of markups:
Q: Question
A: Answer - to questions
E: Error - not compliant
N: Note or todo
O: Okay - compliant

+++
    (a) If the message is a response to a message sent to one of the
        node's unicast addresses, the Source Address of the reply must
        be that same address.
---
O:	if (ipv6_chk_addr(&hdr->daddr, skb->dev))
O:		saddr = &hdr->daddr;
O:
N: ipv6_chk_addr() checks for the validity of the address (i.e. not tentative
N: and of correct scope). However it does not check for unicast address. Meaning
N: ipv6_add_addr() MUST never be given anycast or multicast addresses.
Q: Can this happen?
Q: I can't see much support for anycast addresses, is this correct?
+++
    (b) If the message is a response to a message sent to a multicast or
        anycast group in which the node is a member, the Source Address
        of the reply must be a unicast address belonging to the
        interface on which the multicast or anycast packet was received.
---
E: 	if ((addr_type & IPV6_ADDR_MULTICAST || skb->pkt_type != PACKET_HOST)) {
E: There seems to be no check for the anycast case.

Q:              saddr = NULL;
Q: Later on saddr is written to fl.nl_u.ip6_u.saddr. Pointer to the flowi
Q: is given as a parameter to ip6_build_xmit(). Now that the the sending
Q: interface to be the same, the following conditions must be fullfilled:

	if (!fl->oif && ipv6_addr_is_multicast(fl->nl_u.ip6_u.daddr))
		fl->oif = np->mcast_oif;

Q: o address is not a link-local address and np->mcast_oif must point to the
Q:   same interface than where the packet came from. Now this is per sock
Q:   variable and there is only a global icmp socket for flow control
Q:   purposes so I don't see this happening.

	dst = __sk_dst_check(sk, np->dst_cookie);
	if (dst) {

		    || (fl->oif && fl->oif != dst->dev->ifindex)) {
			dst = NULL;

Q: o if there is a destination cache entry for the socket which I don't
Q:   understand in the context of icmp btw. and it is a link local
Q:   address, ip6_route_output() is called. It is also called if there
Q:   is no destination cache entry. Anyway, function checks route
Q:   with rt6_device_match()

	if ((rt->rt6i_flags & RTF_CACHE)) {
		if (ip6_rt_policy == 0) {
			rt = rt6_device_match(rt, fl->oif, strict);
Q: if these conditions hold true. Let us be reminded that fl->oif is != 0
Q: if addr_type & IPV6_ADDR_LINKLOCAL. If not RTF_CACHE then we get a lot
Q: of code I didn't get through.

Q: For the sending address to be a "unicast address beloging to the interface"
Q: then it must be that ipv6_get_saddr() given chosen route and especially
Q: its device must be same. Oh, and there must of course valid unicast addresses
Q: belonging to that interface.

Q: My hunch is that the sending address is most probably belonging to the same
Q: interface only if oif is set. Then it would be:
E: It is not guaranteed that sending unicast address belongs to the same
E: interface.
+++
    (c) If the message is a response to a message sent to an address
        that does not belong to the node, the Source Address should be
        that unicast address belonging to the node that will be most
        helpful in diagnosing the error. For example, if the message is
        a response to a packet forwarding action that cannot complete
        successfully, the Source Address should be a unicast address
        belonging to the interface on which the packet forwarding
        failed.
---
N: "Most helpful" is not very clearly defined. Neither do I understand
N: "on which the packet forwarding" failed. There are of course two interfaces
N: involved in packet forwarding. ICMP packets are sent to the sender so
N: this could logically refer to the ingress interface.

Q:		/* Force OUTPUT device used as source address */
Q:		skb->dev = dst->dev;
Q: But in this case the code seems to do the opposite. What's the logic of this?
Q: The text above could be intepreted to propose just that but is it the
Q: sensible thing to do?
+++
2.3 Message Checksum Calculation
---
O: icmpv6_getfrag() calculates the checksum. Pseudo-header checksum
O: calculated by csum_ipv6_magic() using IPPROTO_ICMPV6 as the proto.
Q: Wouldn't the checksum need be converted to network byte order? How
Q: is this done? I can't see the code in asm-i386/checksum.h.
+++
    (b) If an ICMPv6 informational message of unknown type is received,
        it MUST be silently discarded.
---
O: there is an explicit check for type & 0x80.
N: Change to use the constant.
+++
    (d) In those cases where the internet-layer protocol is required to
        pass an ICMPv6 error message to the upper-layer process, the
        upper-layer protocol type is extracted from the original packet
        (contained in the body of the ICMPv6 error message) and used to
        select the appropriate upper-layer process to handle the error.
---
O: icmpv6_notify() skips extension headers by calling ipv6_skip_exthdr()
O: though it only understands a limited set of extension headers.
N:
N:	/* BUGGG_FUTURE: we should try to parse exthdrs in this packet.
N:	   Without this we will not able f.e. to make source routed
N:	   pmtu discovery.
N:	   Corresponding argument (opt) to notifiers is already added.
N:	   --ANK (980726)
N:	 */
+++
         (e.4) a packet sent as a link-layer multicast, (the exception
               from e.2 applies to this case too), or
---
Q: That must refer to e.3?
+++
         (f.1) Timer-based - for example, limiting the rate of
               transmission of error messages to a given source, or to
               any source, to at most once every T milliseconds.
---
O: This is implemented -- sysctl_icmpv6_time = 1*HZ.
N: With the following exceptions:
N:	/* Informational messages are not limited. */
N:	if (type & 0x80)
N:		return 1;
N:
N:	/* Do not limit pmtu discovery, it would break it. */
N:	if (type == ICMPV6_PKT_TOOBIG)
N:		return 1;
Q: Doesn't this poke holes if intentionally exploited?
+++
         (f.2) Bandwidth-based - for example, limiting the rate at which
               error messages are sent from a particular interface to
               some fraction F of the attached link's bandwidth.
---
N: Not implemented.
+++
   NOTE: THE RESTRICTIONS UNDER (e) AND (f) ABOVE TAKE PRECEDENCE OVER
   ANY REQUIREMENT ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR
   MESSAGES.
---
O: They do.
N: Except for echo reply?
Q: Why does this bypass the checks in icmpv6_send()?
+++
   A Destination Unreachable message SHOULD be generated by a router, or
   by the IPv6 layer in the originating node, in response to a packet
   that cannot be delivered to its destination address for reasons other
   than congestion.  (An ICMPv6 message MUST NOT be generated if a
   packet is dropped due to congestion.)
---
N: NOROUTE messages seem not to be generated.
N: ADM_PROHIBITED not sent by IPv6 code itself.
N: NOT_NEIGHBOUR messages are not either.
N: ADDR_UNREACH is generated. Maybe sometimes NOROUTE could be used instead.
N: PORT_UNREACH generated by udp, sit. Tcp probably sends RST instead?
+++
   If the reason for the failure to deliver is lack of a matching entry
   in the forwarding node's routing table, the Code field is set to 0
   (NOTE: this error can occur only in nodes that do not hold a "default
   route" in their routing tables).
---
E: see above.
+++
   If the reason for the failure to deliver is administrative
   prohibition, e.g., a "firewall filter", the Code field is set to 1.
---
N: Unimplemented. REJECT target is not currently supported by the IPv6 code.
+++
   If the reason for the failure to deliver is that the destination is
   beyond the scope of the source address, the Code field is set to 2.
   This condition can occur only when the scope of the source address is
   smaller than the scope of the destination address (e.g., when a
   packet has a site-local source address and a global-scope destination
   address) and the packet cannot be delivered to the destination
   without leaving the scope of the source address (e.g., without
   leaving the source's site, in the case of a site-local source
   address).
---
N: Unimplemented. SITELOCAL is not checked anywhere in the code.
+++
   Upper layer notification

   An incoming Packet Too Big message MUST be passed to the upper-layer
   process.
---
O: See icmpv6_rcv():
N:		/* BUGGG_FUTURE: if packet contains rthdr, we cannot update
N:		   standard destination cache. Seems, only "advanced"
N:		   destination cache will allow to solve this problem
N:		   --ANK (980726)
N:		 */
Q: What does this mean exactly?
+++
   Data           Zero or more octets of arbitrary data.
---
Q: Can echo reply packets be fragmented? It seems so.
+++
   An Echo Reply SHOULD be sent in response to an Echo Request message
   sent to an IPv6 multicast address.  The source address of the reply
   MUST be a unicast address belonging to the interface on which the
   multicast Echo Request message was received.
---
O:	if (ipv6_addr_type(saddr) & IPV6_ADDR_MULTICAST)
O:		saddr = NULL;
N: Same concerns apply than with icmpv6_send().
+++
5. Security Considerations

5.1 Authentication and Encryption of ICMP messages

   ICMP protocol packet exchanges can be authenticated using the IP
   Authentication Header [IPv6-AUTH].  A node SHOULD include an
   Authentication Header when sending ICMP messages if a security
   association for use with the IP Authentication Header exists for the
   destination address.  The security associations may have been created
   through manual configuration or through the operation of some key
   management protocol.
---
N: Not implemented.
+++
5.2 ICMP Attacks

   4. ICMP messages may be used as attempts to perform denial of service
      attacks by sending back to back erroneous IP packets.  An
      implementation that correctly followed section 2.4, paragraph (f)
      of this specifications, would be protected by the ICMP error rate
      limiting mechanism.
---
N: Echo replies are not rate limited.


-- 
D.


From owner-netdev@oss.sgi.com Sun Nov 12 06:49:28 2000
Received:  by oss.sgi.com id <S553931AbQKLOtS>;
	Sun, 12 Nov 2000 06:49:18 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:38160 "EHLO
        havoc.gtf.org") by oss.sgi.com with ESMTP id <S553913AbQKLOtD>;
	Sun, 12 Nov 2000 06:49:03 -0800
Received: from mandrakesoft.com (adsl-20-73-115.asm.bellsouth.net [66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id JAA23738;
	Sun, 12 Nov 2000 09:48:48 -0500
Message-ID: <3A0EADB2.2CB1A4BA@mandrakesoft.com>
Date:   Sun, 12 Nov 2000 09:48:18 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Aki M Laukkanen <amlaukka@cc.helsinki.fi>
CC:     netdev@oss.sgi.com
Subject: Re: IPv6 evaluating according to draft-ietf-ipngwg-icmp-v3-00.eval
References: <Pine.OSF.4.30.0011121626380.9072-100000@sirppi.helsinki.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Aki M Laukkanen wrote:
> 5.1 Authentication and Encryption of ICMP messages
> 
>    ICMP protocol packet exchanges can be authenticated using the IP
>    Authentication Header [IPv6-AUTH].  A node SHOULD include an
>    Authentication Header when sending ICMP messages if a security
>    association for use with the IP Authentication Header exists for the
>    destination address.  The security associations may have been created
>    through manual configuration or through the operation of some key
>    management protocol.

I wonder how long until we see IPsec in the kernel...  hpa already got
permission to put crypto source and binaries (derived from open source
crypto) on kernel.org.

	Jeff


-- 
Jeff Garzik             |
Building 1024           | Would you like a Twinkie?
MandrakeSoft            |

From owner-netdev@oss.sgi.com Mon Nov 13 00:19:07 2000
Received:  by oss.sgi.com id <S553973AbQKMISs>;
	Mon, 13 Nov 2000 00:18:48 -0800
Received: from thalia.fm.intel.com ([132.233.247.11]:46607 "EHLO
        thalia.fm.intel.com") by oss.sgi.com with ESMTP id <S553968AbQKMISf>;
	Mon, 13 Nov 2000 00:18:35 -0800
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id IAA09126;
	Mon, 13 Nov 2000 08:19:28 GMT
Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 13 Nov 2000 08:18:11 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <WS654BPT>; Mon, 13 Nov 2000 00:18:09 -0800
Message-ID: <07E6E3B8C072D211AC4100A0C9C5758302B27092@hasmsx52.iil.intel.com>
From:   "Hen, Shmulik" <shmulik.hen@intel.com>
To:     "'Jeff Garzik'" <jgarzik@mandrakesoft.com>
Cc:     "'LNML'" <linux-net@vger.kernel.org>,
        "'LKML'" <linux-kernel@vger.kernel.org>, netdev@oss.sgi.com
Subject: RE: catch 22 - porting net driver from 2.2 to 2.4
Date:   Mon, 13 Nov 2000 00:18:06 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Where can I find info about that ?
My first idea was to fire a timer and let the callback routine do the work,
but I worry about synchronization and about passing the list of items for it
to handle.
What is the accepted way of starting a kernel thread and how do I handle
parameters and sync. ?


	Thanks,
	Shmulik.

-----Original Message-----
From: Jeff Garzik [mailto:jgarzik@mandrakesoft.com]
Sent: Thursday, November 09, 2000 7:37 PM
To: Hen, Shmulik
Cc: 'LNML'; 'LKML'; netdev@oss.sgi.com
Subject: Re: catch 22 - porting net driver from 2.2 to 2.4


do_ioctl is inside rtnl_lock...

Remember if you need to alter the rules, you can always queue work in
the current context, and have a kernel thread handle the work.  The nice
thing about a kernel thread is that you start with a [almost] clean
state, when it comes to locks.

	Jeff


-- 
Jeff Garzik             |
Building 1024           | Would you like a Twinkie?
MandrakeSoft            |
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org


From owner-netdev@oss.sgi.com Mon Nov 13 02:25:08 2000
Received:  by oss.sgi.com id <S553977AbQKMKY7>;
	Mon, 13 Nov 2000 02:24:59 -0800
Received: from luna.tlmat.unican.es ([193.144.186.2]:43780 "EHLO
        luna.tlmat.unican.es") by oss.sgi.com with ESMTP id <S553974AbQKMKYl>;
	Mon, 13 Nov 2000 02:24:41 -0800
Received: from centauro (lira.tlmat.unican.es [193.144.186.27]) by luna.tlmat.unican.es with SMTP (8.7.6/8.7.1) id LAA03951 for <netdev@oss.sgi.com>; Mon, 13 Nov 2000 11:43:16 +0100 (MET)
Message-ID: <002b01c04d5c$08c48240$1bba90c1@tlmat.unican.es>
From:   =?iso-8859-1?B?UmFt824gQWf8ZXJv?= <ramon@tlmat.unican.es>
To:     <netdev@oss.sgi.com>
Subject: RTO calculation in Linux
Date:   Mon, 13 Nov 2000 11:25:23 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0028_01C04D64.6A1C93E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_0028_01C04D64.6A1C93E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

    Hi all,

    Having examined in detail the current TCP IP stack implementation =
within Linux Kernel, I have come with the piece of code in which the RTO =
timer is calculated, ie the following lines in tcp_input.c

                tp->rto =3D (tp->srtt >> 3) + tp->mdev;
                tp->rto +=3D (tp->rto >> 2) + (tp->rto >> =
(tp->snd_cwnd-1));

    The fact is that the rto should be calculated, according to =
Jacobson's algorithm, as srtt+4*mdev, which is exactly the first line =
shown above. Taking this into account, I can't see why the second line =
is used....Furthermore I would like to know what does the tp->snd_cwnd =
variable exactly mean.

    I would be grateful if I get some little piece of help with this =
issue....

    Thank you in advance and regards

    Ram=F3n

PD.- Please I wish to be personally CC'ed the answers/comments posted to =
the list in response to my posting





------=_NextPart_000_0028_01C04D64.6A1C93E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Hi all,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Having examined in detail the =
current TCP=20
IP stack implementation within Linux Kernel, I have come with the piece =
of code=20
in which the RTO timer is calculated, ie the following lines in=20
tcp_input.c</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; tp-&gt;rto =3D (tp-&gt;srtt &gt;&gt; 3) +=20
tp-&gt;mdev;<BR>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =

&nbsp;&nbsp;&nbsp; tp-&gt;rto +=3D (tp-&gt;rto &gt;&gt; 2) + (tp-&gt;rto =
&gt;&gt;=20
(tp-&gt;snd_cwnd-1));</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; The fact is that the rto should =
be=20
calculated, according to Jacobson's algorithm, as srtt+4*mdev, which is =
exactly=20
the first line shown above. Taking this into account, I can't see why =
the second=20
line is used....Furthermore I would like to know what does the =
tp-&gt;snd_cwnd=20
variable exactly mean.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; I would be grateful if I get some =
little=20
piece of help with this issue....</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Thank you in advance and=20
regards</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp; Ram=F3n</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>PD.- Please&nbsp;I wish to be personally CC'ed the=20
answers/comments posted to the list in response to&nbsp;my=20
posting<BR></DIV></FONT></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV><BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_0028_01C04D64.6A1C93E0--


From owner-netdev@oss.sgi.com Mon Nov 13 04:08:49 2000
Received:  by oss.sgi.com id <S554083AbQKMMI3>;
	Mon, 13 Nov 2000 04:08:29 -0800
Received: from nbgdi5-145-253-148-035.arcor-ip.net ([145.253.148.35]:7163 "EHLO
        coruscant.gnumonks.org") by oss.sgi.com with ESMTP
	id <S553985AbQKMMIT>; Mon, 13 Nov 2000 04:08:19 -0800
Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 3.16 #1)
	id 13vH5I-0005F6-00
	for netdev@oss.sgi.com; Mon, 13 Nov 2000 11:43:32 +0100
Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.16 #1)
	id 13v5Bd-0000zq-00
	for netdev@oss.sgi.com; Sun, 12 Nov 2000 23:01:17 +0100
Date:   Sun, 12 Nov 2000 23:01:17 +0100
From:   Harald Welte <laforge@obroa-skai.gnumonks.org>
To:     netdev@oss.sgi.com
Subject: Why is struct ipv6hdr still old-style RFC1883 ?
Message-ID: <20001112230116.A3817@obroa-skai.gnumonks.org>
Reply-To: laforge@gnumonks.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Operating-System: Linux obroa-skai.gnumonks.org 2.4.0-test8
X-Date: Today is Sweetmorn, the 24th day of The Aftermath in the YOLD 3166
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 813
Lines: 20

Hi!

I'm currently doing some work for netfilter_ipv6 / ip6tables and had a 
very extensive look into the current linux 2.4.0-testX ipv6 code.

The most obvious question arising was:

Why is struct ipv6hdr still implementing the old RFC1883 style 
4-bit prio and 24-bit flowlabel fields instead of the RFC2460
8-bit tc and 20-bit flowlabel fields?

Is this just some legacy which nobody got around to change? If this is 
the case, I'm going to update this. Are there any other reasons?

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org                http://www.gnumonks.org
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

From owner-netdev@oss.sgi.com Mon Nov 13 04:15:50 2000
Received:  by oss.sgi.com id <S554085AbQKMMPk>;
	Mon, 13 Nov 2000 04:15:40 -0800
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:3590 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S554079AbQKMMPe>; Mon, 13 Nov 2000 04:15:34 -0800
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.11.0+3.3W/8.11.1/Debian 8.11.0-6) with ESMTP id eADCEqZ15686;
	Mon, 13 Nov 2000 21:14:52 +0900
To:     laforge@gnumonks.org, laforge@obroa-skai.gnumonks.org
Cc:     netdev@oss.sgi.com, usagi-users@linux-ipv6.org
Subject: Re: Why is struct ipv6hdr still old-style RFC1883 ?
In-Reply-To: <20001112230116.A3817@obroa-skai.gnumonks.org>
References: <20001112230116.A3817@obroa-skai.gnumonks.org>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20001113211452L.yoshfuji@ecei.tohoku.ac.jp>
Date:   Mon, 13 Nov 2000 21:14:52 +0900
From:   Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) 
        <yoshfuji@ecei.tohoku.ac.jp>
X-Dispatcher: imput version 990905(IM130)
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 690
Lines: 15

In article <20001112230116.A3817@obroa-skai.gnumonks.org> (at Sun, 12 Nov 2000 23:01:17 +0100), Harald Welte <laforge@obroa-skai.gnumonks.org> says:

> Why is struct ipv6hdr still implementing the old RFC1883 style 
> 4-bit prio and 24-bit flowlabel fields instead of the RFC2460
> 8-bit tc and 20-bit flowlabel fields?
> 
> Is this just some legacy which nobody got around to change? If this is 
> the case, I'm going to update this. Are there any other reasons?

Do you mind if we, USAGI Project, decided to use new structures
defined in RFC2292 / RFC2292bis?

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@linux-ipv6.org>
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Mon Nov 13 10:17:22 2000
Received:  by oss.sgi.com id <S553900AbQKMSRM>;
	Mon, 13 Nov 2000 10:17:12 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:29188 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553885AbQKMSQq>;
	Mon, 13 Nov 2000 10:16:46 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id VAA02431; Mon, 13 Nov 2000 21:16:16 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011131816.VAA02431@ms2.inr.ac.ru>
Subject: Re: Why is struct ipv6hdr still old-style RFC1883 ?
To:     laforge@gnumonks.org
Date:   Mon, 13 Nov 2000 21:16:16 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <20001112230116.A3817@obroa-skai.gnumonks.org> from "Harald Welte" at Nov 13, 0 03:15:40 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing
Content-Length: 582
Lines: 19

Hello!

> Why is struct ipv6hdr still implementing the old RFC1883 style 
> 4-bit prio and 24-bit flowlabel fields instead of the RFC2460
> 8-bit tc and 20-bit flowlabel fields?

Because none of them are used by clear reason (byte wide filed
spanning byte boundary is a non-sense).

0th word of header is accesed only as whole.


> Is this just some legacy which nobody got around to change? If this is 
> the case, I'm going to update this. Are there any other reasons?

If update consists in removing these bitfield crap and replacing
with single word, I see no problems.

Alexey

From owner-netdev@oss.sgi.com Tue Nov 14 12:24:31 2000
Received:  by oss.sgi.com id <S553667AbQKNUYV>;
	Tue, 14 Nov 2000 12:24:21 -0800
Received: from mxout1.cac.washington.edu ([140.142.32.5]:30724 "EHLO
        mxout1.cac.washington.edu") by oss.sgi.com with ESMTP
	id <S553659AbQKNUYB>; Tue, 14 Nov 2000 12:24:01 -0800
Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2])
	by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id MAA23494;
	Tue, 14 Nov 2000 12:23:59 -0800
Received: from iocanendc (D-140-142-110-200.dhcp.washington.edu [140.142.110.200])
	by mailhost2.u.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with SMTP id MAA28542;
	Tue, 14 Nov 2000 12:23:59 -0800
From:   "Vernon Wells" <wells@madhouse.org>
To:     "Michael H. Warfield" <mhw@wittsend.com>,
        "Greg Simpson" <gws@eagle.deardorff.com>
Cc:     <netdev@oss.sgi.com>
Subject: RE: colliding ip detection!
Date:   Tue, 14 Nov 2000 12:23:59 -0800
Message-ID: <GKEKJJDNAHGGOHGFLJKOEECCCAAA.wells@madhouse.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <20001110145414.A4310@alcove.wittsend.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>> M$-windows of course pops up a friendly dialog box, indicating that the
ip
>> has been detected in use by someone else, and courteously disables that
>> ethernet interface for you :) :)

>	M$ farts out prodigeous numbers of broadcast packets and expects
>to seen prodigeous numbers of broadcast packets.  It spots the fact that
>someone else sends out a packet with your IP address in the src address.
>(at least that's one way they detect it).  Amusing random acts of terrorism
>can result including some spectacular denial of service attacks (think
>about it for a second).

This is perhaps misworded.  As with most systems, Windows sends a
"gratuitous ARP" for an IP address the IP address is bound (see, e.g.,
TCP/IP Illustrated Volume 1 for an explanation of gratuitous ARPs) and waits
for an (Ethernet) unicast ARP reply, which indicates that somebody else is
using the same address.  The denial of service you hint at only works
locally; machines can't (bugs aside) propagate ARP requests to a remote
network.

>> The question:
>
>> linux does not seem to indicate if anyone else answers arp requests for
>> its own ip's (correct me if i am wrong); how does one tell if the ip is
in
>> use [short of unplugging the box or querying someone else's arp tables :)
>> :)]?

>	Detecting the arp replies would not work on a switched network.

A gratuitous ARP is an ARP request, which uses the layer2 broadcast
mechanism for delivery.  A straight Ethernet switch (e.g., not configured
for multiple VLANs) honors Ethernet broadcasts by transmitting them on all
ports.  If they didn't, many things would not work.  The purpose of a
gratuitous ARP request is to identify whether another system is using your
IP address.  If you are using a particular IP address and you receive an ARP
request for that address, you should send an ARP reply (unicast to
requesting MAC address).  Normally, the station that sent the gratuitous ARP
will disable their local use of the IP address in response to the ARP reply.
At this point, the station that sent the ARP reply has two choices.  Windows
and Mac, for example, disable their local use of the IP address.  At least
some versions of DUX follow their ARP reply with another ARP request.  They
do this so that other stations on the same netblock will re-update their ARP
cache.  Two DUX boxen doing this, of course, leads to an ARP storm...  On
the other hand, if they didn't do this, a handy man-in-the-middle attack
becomes possible.

>You generally need to see another system (one with a MAC address you
>don't own) claiming to be an IP address which you claim.  On a switched
>network, this generally must be a broadcast packet and you examine the
>source IP and source MAC (consider the case where YOU have two network
>cards on the same cable - this can be a non-trivial exercise with
>unexpected surprises).

>	Keying off of arp replies or broadcast packet source addresses
>opens up some nasty DoS attacks.  I could just flood the network with
>fake packets claiming to be different MAC addresses and IP addresses of
>systems I want to shut down.  Do it with Windows named datagrams (UDP port
>137) and older windows systems just fall over very nicely and hit the
floor.
>It's tougher to do with newer Windows systems and there are much more fun
>games you can play with the name caches instead.

>> I would think a syslog entry would be most helpful to a lot of people on
>> dhcp-run networks!

>	Dhcpd (at least the ISC one) attempts to ping the address before
>assigning a lease.  If it gets a ping response, the address is flagged
>as "abandoned" in the leases file.  Hijacked addresses are thus avoided
>and not leased out.  Then, when you find your leases file full of abandoned
>entries, you get to track down the guilty parties and deliver a rubber hose
>IP release datagram to them.  Repeatedly.  :-)

>> -g

>	Mike


From owner-netdev@oss.sgi.com Tue Nov 14 12:41:10 2000
Received:  by oss.sgi.com id <S553672AbQKNUlA>;
	Tue, 14 Nov 2000 12:41:00 -0800
Received: from alcove.wittsend.com ([130.205.0.20]:7695 "EHLO
        alcove.wittsend.com") by oss.sgi.com with ESMTP id <S553665AbQKNUkq>;
	Tue, 14 Nov 2000 12:40:46 -0800
Received: (from mhw@localhost)
	by alcove.wittsend.com (8.9.3/8.9.3) id QAA31205;
	Tue, 14 Nov 2000 16:39:31 -0500
Date:   Tue, 14 Nov 2000 16:39:31 -0500
From:   "Michael H. Warfield" <mhw@wittsend.com>
To:     Vernon Wells <wells@madhouse.org>
Cc:     "Michael H. Warfield" <mhw@wittsend.com>,
        Greg Simpson <gws@eagle.deardorff.com>, netdev@oss.sgi.com
Subject: Re: colliding ip detection!
Message-ID: <20001114163931.C30435@alcove.wittsend.com>
Mail-Followup-To: Vernon Wells <wells@madhouse.org>,
	"Michael H. Warfield" <mhw@wittsend.com>,
	Greg Simpson <gws@eagle.deardorff.com>, netdev@oss.sgi.com
References: <20001110145414.A4310@alcove.wittsend.com> <GKEKJJDNAHGGOHGFLJKOEECCCAAA.wells@madhouse.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.2i
In-Reply-To: <GKEKJJDNAHGGOHGFLJKOEECCCAAA.wells@madhouse.org>; from wells@madhouse.org on Tue, Nov 14, 2000 at 12:23:59PM -0800
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, Nov 14, 2000 at 12:23:59PM -0800, Vernon Wells wrote:
> >> M$-windows of course pops up a friendly dialog box, indicating that the
> ip
> >> has been detected in use by someone else, and courteously disables that
> >> ethernet interface for you :) :)

> >	M$ farts out prodigeous numbers of broadcast packets and expects
> >to seen prodigeous numbers of broadcast packets.  It spots the fact that
> >someone else sends out a packet with your IP address in the src address.
> >(at least that's one way they detect it).  Amusing random acts of terrorism
> >can result including some spectacular denial of service attacks (think
> >about it for a second).

> This is perhaps misworded.  As with most systems, Windows sends a
> "gratuitous ARP" for an IP address the IP address is bound (see, e.g.,
> TCP/IP Illustrated Volume 1 for an explanation of gratuitous ARPs) and waits
> for an (Ethernet) unicast ARP reply, which indicates that somebody else is
> using the same address.  The denial of service you hint at only works
> locally; machines can't (bugs aside) propagate ARP requests to a remote
> network.

	Oh, very true...  Just like most dhcp address exhaustion attacks
only work locally.  It's just that they are a royal bitch to track down
once they happen (and that's when you start in with the rubber hose because
the guilty party is a local).  :-)

	[...]

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!


From owner-netdev@oss.sgi.com Wed Nov 15 11:34:08 2000
Received:  by oss.sgi.com id <S553683AbQKOTd6>;
	Wed, 15 Nov 2000 11:33:58 -0800
Received: from hoochie.linux-support.net ([216.207.245.2]:55308 "EHLO
        hoochie.linux-support.net") by oss.sgi.com with ESMTP
	id <S553669AbQKOTdq>; Wed, 15 Nov 2000 11:33:46 -0800
Received: from localhost (markster@localhost)
	by hoochie.linux-support.net (8.9.3/8.9.3) with ESMTP id NAA08487
	for <netdev@oss.sgi.com>; Wed, 15 Nov 2000 13:33:20 -0600
Date:   Wed, 15 Nov 2000 13:33:20 -0600 (CST)
From:   Mark Spencer <markster@linux-support.net>
To:     netdev@oss.sgi.com
Subject: Neighbour Table Overflow
Message-ID: <Pine.LNX.4.21.0011151319110.6256-100000@hoochie.linux-support.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

I've been running some tests on an x86 Linux based router with basically
an AMD 486 DX4-100 processor and two PCNet32 ethernet controllers.

The kernel on the router is 2.2.17 with "optimize as router".

For these tests, I'm using netperf (tcp stream test) running on two PC's,
and asking the router in the middle to forward the packets between the two
hosts.

After delivering packets successfully for about 15 seconds, the unit will
cease to respond to packets for several seconds.  The only clue that I
have to the source of the problem is that I receive the message "Neighbour
table overflow".  My understanding of the neighbour table is that it is
used primarily for ARP'ing.  If so, this is a surprising message since the
router should only be aware of one machine on each subnet, and indeed if I
cat /proc/net/arp I see only the two machines.

Does anyone have any suggestions at what to look for?

Mark


From owner-netdev@oss.sgi.com Wed Nov 15 12:33:40 2000
Received:  by oss.sgi.com id <S553782AbQKOUda>;
	Wed, 15 Nov 2000 12:33:30 -0800
Received: from ns1.engrs.org ([216.54.29.10]:28683 "EHLO ns1.engrs.org") convert rfc822-to-8bit17243i
	by oss.sgi.com with ESMTP id <S553770AbQKOUdS>;
	Wed, 15 Nov 2000 12:33:18 -0800
Received: (from uucp@localhost)
	by ns1.engrs.org (8.9.3/8.9.3) id PAA22762;
	Wed, 15 Nov 2000 15:35:14 -0500
Received: from UNKNOWN(216.54.52.141), claiming to be "mal.sourcesoft.org"
 via SMTP by ns1.engrs.org, id smtpdvXT81m; Wed Nov 15 20:35:11 2000
From:   Frank Byrum <greatbridge.com@ns1.engrs.org>
Date:   Wed, 15 Nov 2000 21:33:59 GMT
Message-ID: <20001115.21335900@mal.sourcesoft.org>
Subject: Re: Neighbour Table Overflow
To:     Mark Spencer <markster@linux-support.net>
CC:     netdev@oss.sgi.com
In-Reply-To: 
        <Pine.LNX.4.21.0011151319110.6256-100000@hoochie.linux-support.net>
References: <Pine.LNX.4.21.0011151319110.6256-100000@hoochie.linux-support.net>
X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Linux)
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

I have noticed something like this which seems to be related to the ARP 
cache entry expiring and so the packet can not be delivered.  This 
usually happens somewhere between 12 and 15 seconds.  If you hardcode the 
ARP entries the problems goes away.  

BTW, how long does an ARP entry live in the cache?

Frank

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 11/15/00, 1:33:20 PM, Mark Spencer <markster@linux-support.net> wrote 
regarding Neighbour Table Overflow:


> I've been running some tests on an x86 Linux based router with basically
> an AMD 486 DX4-100 processor and two PCNet32 ethernet controllers.

> The kernel on the router is 2.2.17 with "optimize as router".

> For these tests, I'm using netperf (tcp stream test) running on two PC's,
> and asking the router in the middle to forward the packets between the 
two
> hosts.

> After delivering packets successfully for about 15 seconds, the unit will
> cease to respond to packets for several seconds.  The only clue that I
> have to the source of the problem is that I receive the message 
"Neighbour
> table overflow".  My understanding of the neighbour table is that it is
> used primarily for ARP'ing.  If so, this is a surprising message since 
the
> router should only be aware of one machine on each subnet, and indeed if 
I
> cat /proc/net/arp I see only the two machines.

> Does anyone have any suggestions at what to look for?

> Mark

From owner-netdev@oss.sgi.com Wed Nov 15 14:39:50 2000
Received:  by oss.sgi.com id <S553791AbQKOWjk>;
	Wed, 15 Nov 2000 14:39:40 -0800
Received: from hoochie.linux-support.net ([216.207.245.2]:3086 "EHLO
        hoochie.linux-support.net") by oss.sgi.com with ESMTP
	id <S553698AbQKOWjU>; Wed, 15 Nov 2000 14:39:20 -0800
Received: from localhost (markster@localhost)
	by hoochie.linux-support.net (8.9.3/8.9.3) with ESMTP id QAA09379;
	Wed, 15 Nov 2000 16:39:07 -0600
Date:   Wed, 15 Nov 2000 16:39:07 -0600 (CST)
From:   Mark Spencer <markster@linux-support.net>
To:     Frank Byrum <greatbridge.com@ns1.engrs.org>
cc:     netdev@oss.sgi.com
Subject: Re: Neighbour Table Overflow
In-Reply-To: <20001115.21335900@mal.sourcesoft.org>
Message-ID: <Pine.LNX.4.21.0011151636370.6256-100000@hoochie.linux-support.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> I have noticed something like this which seems to be related to the ARP 
> cache entry expiring and so the packet can not be delivered.  This 
> usually happens somewhere between 12 and 15 seconds.  If you hardcode the 
> ARP entries the problems goes away.  

But why is the re-arp taking so long?  And I thought ARP entries lived
much longer than 15 seconds, more like a couple of minutes.  Can the time
be changed?  That's still not the solution, certainly.    Do arp entries
get their lives extended if they're used?

Perhaps what's happening is that the ethernet is getting overrun, and so
the ARP is getting dropped because the ethernet is flooded.  But shouldn't
an ARP have some sort of priority?

Mark


From owner-netdev@oss.sgi.com Thu Nov 16 02:17:53 2000
Received:  by oss.sgi.com id <S553694AbQKPKRn>;
	Thu, 16 Nov 2000 02:17:43 -0800
Received: from host000012.arnet.net.ar ([200.45.0.12]:3854 "HELO
        smtp1.arnet.com.ar") by oss.sgi.com with SMTP id <S553660AbQKPKRa>;
	Thu, 16 Nov 2000 02:17:30 -0800
Received: (qmail 19888 invoked from network); 16 Nov 2000 10:17:15 -0000
Received: ThePolice Version 0.02 by GCM
Received: AntiBombing Version 0.08 by GCM
Received: from host000005.arnet.net.ar (HELO mail2.arnet.com.ar) (200.45.0.5)
  by host000012.arnet.net.ar with SMTP; 16 Nov 2000 10:17:15 -0000
Received: from mail pickup service by mail2.arnet.com.ar with Microsoft SMTPSVC;
	 Thu, 16 Nov 2000 07:16:43 -0300
Received: from recife.arnet.com.ar ([192.168.202.70]) by mail1.arnet.com.ar  with Microsoft SMTPSVC(5.5.1877.357.35);
	 Wed, 15 Nov 2000 19:44:14 -0300
Received: (qmail 22414 invoked from network); 15 Nov 2000 22:44:08 -0000
Received: from oss.sgi.com (216.32.174.190)
  by recife.arnet.com.ar with SMTP; 15 Nov 2000 22:44:08 -0000
Received:  by oss.sgi.com id <S553791AbQKOWjk>;
	Wed, 15 Nov 2000 14:39:40 -0800
Received: from hoochie.linux-support.net ([216.207.245.2]:3086 "EHLO
        hoochie.linux-support.net") by oss.sgi.com with ESMTP
	id <S553698AbQKOWjU>; Wed, 15 Nov 2000 14:39:20 -0800
Received: from localhost (markster@localhost)
	by hoochie.linux-support.net (8.9.3/8.9.3) with ESMTP id QAA09379;
	Wed, 15 Nov 2000 16:39:07 -0600
Date:   Wed, 15 Nov 2000 16:39:07 -0600 (CST)
From:   Mark Spencer <markster@linux-support.net>
To:     Frank Byrum <greatbridge.com@ns1.engrs.org>
cc:     netdev@oss.sgi.com
Subject: Re: Neighbour Table Overflow
In-Reply-To: <20001115.21335900@mal.sourcesoft.org>
Message-ID: <Pine.LNX.4.21.0011151636370.6256-100000@hoochie.linux-support.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> I have noticed something like this which seems to be related to the ARP 
> cache entry expiring and so the packet can not be delivered.  This 
> usually happens somewhere between 12 and 15 seconds.  If you hardcode the 
> ARP entries the problems goes away.  

But why is the re-arp taking so long?  And I thought ARP entries lived
much longer than 15 seconds, more like a couple of minutes.  Can the time
be changed?  That's still not the solution, certainly.    Do arp entries
get their lives extended if they're used?

Perhaps what's happening is that the ethernet is getting overrun, and so
the ARP is getting dropped because the ethernet is flooded.  But shouldn't
an ARP have some sort of priority?

Mark

From owner-netdev@oss.sgi.com Thu Nov 16 10:00:26 2000
Received:  by oss.sgi.com id <S553714AbQKPSAQ>;
	Thu, 16 Nov 2000 10:00:16 -0800
Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:6208 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S553702AbQKPR75>;
	Thu, 16 Nov 2000 09:59:57 -0800
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 13wTKL-000899-00; Thu, 16 Nov 2000 18:00:02 +0000
Subject: Re: PATCH: 8139too kernel thread
To:     jgarzik@mandrakesoft.com (Jeff Garzik)
Date:   Thu, 16 Nov 2000 17:59:58 +0000 (GMT)
Cc:     linux-kernel@vger.kernel.org, torvalds@transmeta.com,
        netdev@oss.sgi.com
In-Reply-To: <200011102129.QAA13369@havoc.gtf.org> from "Jeff Garzik" at Nov 10, 2000 04:29:51 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E13wTKL-000899-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> The only disadvantage to this scheme is the added cost of a kernel
> thread over a kernel timer.  I think this is an ok cost, because this
> is a low-impact thread that sleeps a lot..

8K of memory, two tlb flushes, cache misses on the scheduler. The price is
actually extremely high.


From owner-netdev@oss.sgi.com Thu Nov 16 10:06:26 2000
Received:  by oss.sgi.com id <S553716AbQKPSGQ>;
	Thu, 16 Nov 2000 10:06:16 -0800
Received: from leibniz.math.psu.edu ([146.186.130.2]:65475 "EHLO math.psu.edu")
	by oss.sgi.com with ESMTP id <S553708AbQKPSGK>;
	Thu, 16 Nov 2000 10:06:10 -0800
Received: from weyl.math.psu.edu (weyl.math.psu.edu [146.186.130.226])
	by math.psu.edu (8.9.3/8.9.3) with ESMTP id NAA11974;
	Thu, 16 Nov 2000 13:05:54 -0500 (EST)
Received: from localhost (viro@localhost)
	by weyl.math.psu.edu (8.9.3/8.9.3) with ESMTP id NAA13413;
	Thu, 16 Nov 2000 13:05:54 -0500 (EST)
X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs
Date:   Thu, 16 Nov 2000 13:05:53 -0500 (EST)
From:   Alexander Viro <viro@math.psu.edu>
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
cc:     Jeff Garzik <jgarzik@mandrakesoft.com>,
        linux-kernel@vger.kernel.org, torvalds@transmeta.com,
        netdev@oss.sgi.com
Subject: Re: PATCH: 8139too kernel thread
In-Reply-To: <E13wTKL-000899-00@the-village.bc.nu>
Message-ID: <Pine.GSO.4.21.0011161302200.13047-100000@weyl.math.psu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



On Thu, 16 Nov 2000, Alan Cox wrote:

> > The only disadvantage to this scheme is the added cost of a kernel
> > thread over a kernel timer.  I think this is an ok cost, because this
> > is a low-impact thread that sleeps a lot..
> 
> 8K of memory, two tlb flushes, cache misses on the scheduler. The price is
                ^^^^^^^^^^^^^^^
> actually extremely high.

<confused>
Does it really need non-lazy TLB?

I'm not saying that it's a good idea, but...


From owner-netdev@oss.sgi.com Thu Nov 16 10:11:46 2000
Received:  by oss.sgi.com id <S553722AbQKPSL0>;
	Thu, 16 Nov 2000 10:11:26 -0800
Received: from neon-gw.transmeta.com ([209.10.217.66]:12560 "EHLO
        neon-gw.transmeta.com") by oss.sgi.com with ESMTP
	id <S553715AbQKPSLN>; Thu, 16 Nov 2000 10:11:13 -0800
Received: (from root@localhost)
	by neon-gw.transmeta.com (8.9.3/8.9.3) id KAA03971;
	Thu, 16 Nov 2000 10:11:08 -0800
Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1)
	id xma003966; Thu, 16 Nov 00 10:10:51 -0800
Received: from penguin.transmeta.com (penguin.transmeta.com [10.1.2.202])
	by deepthought.transmeta.com (8.9.3/8.9.3) with ESMTP id KAA06755;
	Thu, 16 Nov 2000 10:10:51 -0800 (PST)
Received: from localhost (torvalds@localhost) by penguin.transmeta.com (8.9.3/8.7.3) with ESMTP id KAA02570; Thu, 16 Nov 2000 10:10:51 -0800
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Date:   Thu, 16 Nov 2000 10:10:48 -0800 (PST)
From:   Linus Torvalds <torvalds@transmeta.com>
To:     Alexander Viro <viro@math.psu.edu>
cc:     Alan Cox <alan@lxorguk.ukuu.org.uk>,
        Jeff Garzik <jgarzik@mandrakesoft.com>,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: PATCH: 8139too kernel thread
In-Reply-To: <Pine.GSO.4.21.0011161302200.13047-100000@weyl.math.psu.edu>
Message-ID: <Pine.LNX.4.10.10011161008060.2513-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



On Thu, 16 Nov 2000, Alexander Viro wrote:
> 
> On Thu, 16 Nov 2000, Alan Cox wrote:
> 
> > > The only disadvantage to this scheme is the added cost of a kernel
> > > thread over a kernel timer.  I think this is an ok cost, because this
> > > is a low-impact thread that sleeps a lot..
> > 
> > 8K of memory, two tlb flushes, cache misses on the scheduler. The price is
>                 ^^^^^^^^^^^^^^^
> > actually extremely high.
> 
> <confused>
> Does it really need non-lazy TLB?

If Alan wants to back-port it into 2.2.x, the lazy tlb won't work.

But yes, on 2.4.x the cost of threads is fairly low. The biggest cost by
far is probably the locking needed for the scheduler etc, and there the
best rule of thumb is probably to see whether the driver really ends up
being noticeably simpler.

The event stuff that we are discussing for pcmcia may make all of this
moot, maybe media selection is the perfect example of how to do the very
same thing. I'll forward Jeff the emails on that.

		Linus


From owner-netdev@oss.sgi.com Thu Nov 16 10:20:36 2000
Received:  by oss.sgi.com id <S553729AbQKPSU0>;
	Thu, 16 Nov 2000 10:20:26 -0800
Received: from lightning.swansea.linux.org.uk ([194.168.151.1]:18496 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S553717AbQKPSUO>;
	Thu, 16 Nov 2000 10:20:14 -0800
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 13wTdO-0008BQ-00; Thu, 16 Nov 2000 18:19:42 +0000
Subject: Re: PATCH: 8139too kernel thread
To:     viro@math.psu.edu (Alexander Viro)
Date:   Thu, 16 Nov 2000 18:19:40 +0000 (GMT)
Cc:     alan@lxorguk.ukuu.org.uk (Alan Cox),
        jgarzik@mandrakesoft.com (Jeff Garzik),
        linux-kernel@vger.kernel.org, torvalds@transmeta.com,
        netdev@oss.sgi.com
In-Reply-To: <Pine.GSO.4.21.0011161302200.13047-100000@weyl.math.psu.edu> from "Alexander Viro" at Nov 16, 2000 01:05:53 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E13wTdO-0008BQ-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> > 8K of memory, two tlb flushes, cache misses on the scheduler. The price is
>                 ^^^^^^^^^^^^^^^
> > actually extremely high.
> 
> <confused>
> Does it really need non-lazy TLB?

Good point, so its a mere 8K of memory and the scheduler cache misses

> I'm not saying that it's a good idea, but...

It seems a very bad idea for the general case. It might be justified for a few
drivers but then they should not use their own thread but (to merge two mail
discussions together) use the generic api dwmw2 is doing to solve the pcmcia
problem.

Now we can sleep and we are back to a single 8K stack for all of it


From owner-netdev@oss.sgi.com Thu Nov 16 10:30:06 2000
Received:  by oss.sgi.com id <S553743AbQKPS3q>;
	Thu, 16 Nov 2000 10:29:46 -0800
Received: from panic.ohr.gatech.edu ([130.207.47.194]:4358 "EHLO havoc.gtf.org")
	by oss.sgi.com with ESMTP id <S553724AbQKPS3f>;
	Thu, 16 Nov 2000 10:29:35 -0800
Received: from mandrakesoft.com (adsl-20-73-115.asm.bellsouth.net [66.20.73.115])
	by havoc.gtf.org (8.9.3/8.9.3) with ESMTP id NAA23156;
	Thu, 16 Nov 2000 13:29:16 -0500
Message-ID: <3A14275E.99DF4D89@mandrakesoft.com>
Date:   Thu, 16 Nov 2000 13:28:46 -0500
From:   Jeff Garzik <jgarzik@mandrakesoft.com>
Organization: MandrakeSoft
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Linus Torvalds <torvalds@transmeta.com>
CC:     Alexander Viro <viro@math.psu.edu>,
        Alan Cox <alan@lxorguk.ukuu.org.uk>,
        linux-kernel@vger.kernel.org, netdev@oss.sgi.com
Subject: Re: PATCH: 8139too kernel thread
References: <Pine.LNX.4.10.10011161008060.2513-100000@penguin.transmeta.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Linus Torvalds wrote:
> But yes, on 2.4.x the cost of threads is fairly low. The biggest cost by
> far is probably the locking needed for the scheduler etc, and there the
> best rule of thumb is probably to see whether the driver really ends up
> being noticeably simpler.

My main motivations for moving media selection from a timer into a
kernel thread are:
* the timer oftens takes a loooong time to run (some drivers have extra
junk in the timer funcs that really should be in a kthread anyway),  and
* do_ioctl, which calls the mdio_xxx functions, holds rtnl_lock, which
is a semaphore.  the kernel thread can easily acquire this semaphore
too, a timer can't.

I agree that it needs to be examined on a case-by-case basis.  Better
hardware, where MDIO access is just a few bus reads/writes, probably
doesn't need a kernel thread.

Finally, for most net drivers, media selection occurs once every 60
seconds or so, not a big impact even on 2.2.x...


> The event stuff that we are discussing for pcmcia may make all of this
> moot, maybe media selection is the perfect example of how to do the very
> same thing. I'll forward Jeff the emails on that.

I think I'm already on the CC list.

I'm confused here though....   How does tq_context apply here?  Your
suggested direction of tq_context seems ok, but I don't see how it
applies to situations where polling needs to occur, like where yenta
polls when request_irq fails, or when net drivers poll media selection
here.

Regards,

	Jeff


-- 
Jeff Garzik             |
Building 1024           | The chief enemy of creativity is "good" sense
MandrakeSoft            |          -- Picasso

From owner-netdev@oss.sgi.com Thu Nov 16 11:17:46 2000
Received:  by oss.sgi.com id <S553755AbQKPTRh>;
	Thu, 16 Nov 2000 11:17:37 -0800
Received: from hoochie.linux-support.net ([216.207.245.2]:13839 "EHLO
        hoochie.linux-support.net") by oss.sgi.com with ESMTP
	id <S553746AbQKPTR3>; Thu, 16 Nov 2000 11:17:29 -0800
Received: from localhost (markster@localhost)
	by hoochie.linux-support.net (8.9.3/8.9.3) with ESMTP id NAA11827;
	Thu, 16 Nov 2000 13:17:16 -0600
Date:   Thu, 16 Nov 2000 13:17:16 -0600 (CST)
From:   Mark Spencer <markster@linux-support.net>
To:     Frank Byrum <greatbridge.com@ns1.engrs.org>
cc:     netdev@oss.sgi.com
Subject: Re: Neighbour Table Overflow
In-Reply-To: <20001115.21335900@mal.sourcesoft.org>
Message-ID: <Pine.LNX.4.21.0011161314590.6256-100000@hoochie.linux-support.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

> I have noticed something like this which seems to be related to the
> ARP cache entry expiring and so the packet can not be delivered.  
> This usually happens somewhere between 12 and 15 seconds.  If you
> hardcode the ARP entries the problems goes away.

I tried hardcoding the ARP entries in using arp -s, however the problem
still presents itself.  The unit appears to halt all network activity for
perhaps another 15-20 seconds before resuming operations normally.

Mark


From owner-netdev@oss.sgi.com Thu Nov 16 12:20:57 2000
Received:  by oss.sgi.com id <S553809AbQKPUUh>;
	Thu, 16 Nov 2000 12:20:37 -0800
Received: from ns1.engrs.org ([216.54.29.10]:2060 "EHLO ns1.engrs.org") convert rfc822-to-8bitrtner.i
	by oss.sgi.com with ESMTP id <S553776AbQKPUUb>;
	Thu, 16 Nov 2000 12:20:31 -0800
Received: (from uucp@localhost)
	by ns1.engrs.org (8.9.3/8.9.3) id PAA25635;
	Thu, 16 Nov 2000 15:22:40 -0500
Received: from UNKNOWN(216.54.52.141), claiming to be "mal.sourcesoft.org"
 via SMTP by ns1.engrs.org, id smtpdwYD0Wx; Thu Nov 16 20:22:31 2000
From:   Frank Byrum <greatbridge.com@ns1.engrs.org>
Date:   Thu, 16 Nov 2000 21:21:00 GMT
Message-ID: <20001116.21210000@mal.sourcesoft.org>
Subject: Re: Neighbour Table Overflow
To:     Mark Spencer <markster@linux-support.net>
CC:     Frank Byrum <greatbridge.com@ns1.engrs.org>, netdev@oss.sgi.com
In-Reply-To: 
        <Pine.LNX.4.21.0011151636370.6256-100000@hoochie.linux-support.net>
References: <Pine.LNX.4.21.0011151636370.6256-100000@hoochie.linux-support.net>
X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Linux)
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 11/15/00, 4:39:07 PM, Mark Spencer <markster@linux-support.net> wrote 
regarding Re: Neighbour Table Overflow:
> > I have noticed something like this which seems to be related to the ARP
> > cache entry expiring and so the packet can not be delivered.  This
> > usually happens somewhere between 12 and 15 seconds.  If you hardcode the
> > ARP entries the problems goes away.

> But why is the re-arp taking so long?  And I thought ARP entries lived
> much longer than 15 seconds, more like a couple of minutes.  Can the time
> be changed?  That's still not the solution, certainly.    Do arp entries
> get their lives extended if they're used?
Nope, in our test we are blasting packets at the box and they are 
expiring (or dropping).  It turns out that the device that I was using 
for testing only replies to arp at the beginning of the test (so that I 
can account for packets exactly).  This seems to be just a problem under 
linux, other OSes don't seem to have the problem and Cisco routers (et. 
al.) don't either.  We used the hardcode arp trick to get throught the 
test.

> Perhaps what's happening is that the ethernet is getting overrun, and so
> the ARP is getting dropped because the ethernet is flooded.  But 
shouldn't
> an ARP have some sort of priority?
Nope, not it either.  I can generate the same problem with a 1% test 
traffic load, so I don't think that it is load related.  The odd think is 
that it does this at all load levels that we have tested...up to 100%.  

We know that it occurs just after the linux box does an arp request at 
around 12 secs, but the odd thing is that it makes the request for an 
existing arp entry that has an established flow moving through the device 
at the same time.

Frank

From owner-netdev@oss.sgi.com Fri Nov 17 08:55:33 2000
Received:  by oss.sgi.com id <S553763AbQKQQzY>;
	Fri, 17 Nov 2000 08:55:24 -0800
Received: from mta-1.gci.net ([208.138.130.82]:2948 "EHLO mta-1.gci.net")
	by oss.sgi.com with ESMTP id <S553717AbQKQQzC>;
	Fri, 17 Nov 2000 08:55:02 -0800
Received: from mmp-1.gci.net ([208.138.130.80]) by mta-1.gci.net
          (Netscape Messaging Server 4.15) with ESMTP id G46HNK01.G65 for
          <netdev@oss.sgi.com>; Fri, 17 Nov 2000 07:54:56 -0900 
Received: from gci.net ([24.237.29.53]) by mmp-1.gci.net
          (Netscape Messaging Server 4.15) with ESMTP id G46HNL03.50I;
          Fri, 17 Nov 2000 07:54:57 -0900 
Message-ID: <3A156261.C95B698D@gci.net>
Date:   Fri, 17 Nov 2000 07:52:49 -0900
From:   Shawn Houston <mhouston@gci.net>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18pre21 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     netdev@oss.sgi.com, linux-net@vger.kernel.org
Subject: 2.2.18pre kernel net problem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Help.

The 2.2.18pre series from Alan Cox, through pre21, has a problem with
connection in CLOSE_WAIT that data still in the buffers. The connections
never go away:

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address        
State      
tcp        0      0 router.home.pc:ssh      mutt.home.pc:918       
ESTABLISHED 
tcp        1      0 router.home.pc:time     mutt.home.pc:2013      
CLOSE_WAIT  

The program I was using when I discovered this is rdate, it apparently
has a bug that exposes this bug. The above condition is persistant for
over 24 hours so far, and I have observed up to 5 days without the
connectins going away. I do not think they will short of a reboot.

As I would like to sync my machines using rdate, and the 2.2.18pre
series are the most stable and feature complete kernels available, I am
hoping that this can be either fixed, or give me some direction as to
the source file location, I can probably fix this myself.

This problem may exist in other 2.2.x series kernels, but I only started
using rdate recently.

-Shawn
-- 

Shawn Houston
mhouston@gci.net

From owner-netdev@oss.sgi.com Fri Nov 17 10:17:54 2000
Received:  by oss.sgi.com id <S553785AbQKQSRo>;
	Fri, 17 Nov 2000 10:17:44 -0800
Received: from ikar.t17.ds.pwr.wroc.pl ([156.17.210.253]:33803 "HELO
        ikar.t17.ds.pwr.wroc.pl") by oss.sgi.com with SMTP
	id <S553729AbQKQSRZ>; Fri, 17 Nov 2000 10:17:25 -0800
Received: by ikar.t17.ds.pwr.wroc.pl (Postfix+IPv6, from userid 1002)
	id C6D07C8002; Fri, 17 Nov 2000 18:15:02 +0100 (CET)
Date:   Fri, 17 Nov 2000 18:15:02 +0100
From:   Arkadiusz Miskiewicz <misiek@pld.ORG.PL>
To:     netdev@oss.sgi.com
Subject: sin6_scope_id and 2.2.x kernel
Message-ID: <20001117181502.B25253@pld.ORG.PL>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
X-URL:  http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/
X-Operating-System: Linux dark 4.0.20 #119 Tue Jan 16 12:21:53 MET 2001 i986 pld
X-Team: Polish Linux Distribution Team Member
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi,

in glibc 2.2 functions (ie. getnameinfo()) check for sizeof(struct sockaddr_in6)
passed from 2.2 kernel against sizeof(struct sockaddr_in6+with sin6_scope_id field)
and for 2.2.x kernels these functions will fail, so maybe such patch
should be applied to 2.2.x kernel tree. Just add sin6_scope_id field
to struct sockaddr_in6 (as in 2.4 kernel) but don't use it.

diff -urN linux-2.2.x.org/include/linux/in6.h linux-2.2.x/include/linux/in6.h
--- linux-2.2.x.org/include/linux/in6.h	Fri Nov 17 18:21:58 2000
+++ linux-2.2.x/include/linux/in6.h	Fri Nov 17 18:22:26 2000
@@ -56,6 +56,7 @@
 	__u16			sin6_port;      /* Transport layer port # */
 	__u32			sin6_flowinfo;  /* IPv6 flow information */
 	struct in6_addr		sin6_addr;      /* IPv6 address */
+	__u32			sin6_scope_id;	/* scope id (new in RFC2553) */
 };
 
 
diff -urN linux-2.2.x.org/include/net/ipv6.h linux-2.2.x/include/net/ipv6.h
--- linux-2.2.x.org/include/net/ipv6.h	Tue May 11 19:36:50 1999
+++ linux-2.2.x/include/net/ipv6.h	Fri Nov 17 18:55:27 2000
@@ -20,6 +20,8 @@
 #include <net/ndisc.h>
 #include <net/flow.h>
 
+#define	SIN6_LEN_RFC2133	24
+
 /*
  *	NextHeader field of IPv6 header
  */
diff -urN linux-2.2.x.org/net/ipv6/af_inet6.c linux-2.2.x/net/ipv6/af_inet6.c
--- linux-2.2.x.org/net/ipv6/af_inet6.c	Thu May  4 02:16:53 2000
+++ linux-2.2.x/net/ipv6/af_inet6.c	Fri Nov 17 18:56:34 2000
@@ -199,7 +199,7 @@
 		
 	/* Check these errors (active socket, bad address length, double bind). */
 	if ((sk->state != TCP_CLOSE)			||
-	    (addr_len < sizeof(struct sockaddr_in6))	||
+	    (addr_len < SIN6_LEN_RFC2133)		||
 	    (sk->num != 0))
 		return -EINVAL;
 		
diff -urN linux-2.2.x.org/net/ipv6/raw.c linux-2.2.x/net/ipv6/raw.c
--- linux-2.2.x.org/net/ipv6/raw.c	Mon Aug  9 21:04:41 1999
+++ linux-2.2.x/net/ipv6/raw.c	Fri Nov 17 18:57:01 2000
@@ -117,7 +117,7 @@
 	int addr_type;
 
 	/* Check these errors. */
-	if (sk->state != TCP_CLOSE || (addr_len < sizeof(struct sockaddr_in6)))
+	if (sk->state != TCP_CLOSE || (addr_len < SIN6_LEN_RFC2133))
 		return -EINVAL;
 
 	addr_type = ipv6_addr_type(&addr->sin6_addr);
@@ -360,7 +360,7 @@
 	fl.fl6_flowlabel = 0;
 
 	if (sin6) {
-		if (addr_len < sizeof(struct sockaddr_in6)) 
+		if (addr_len < SIN6_LEN_RFC2133) 
 			return(-EINVAL);
 
 		if (sin6->sin6_family && sin6->sin6_family != AF_INET6) 
diff -urN linux-2.2.x.org/net/ipv6/tcp_ipv6.c linux-2.2.x/net/ipv6/tcp_ipv6.c
--- linux-2.2.x.org/net/ipv6/tcp_ipv6.c	Thu May  4 02:16:53 2000
+++ linux-2.2.x/net/ipv6/tcp_ipv6.c	Fri Nov 17 18:57:12 2000
@@ -387,7 +387,7 @@
 	if(!ipv6_addr_any(&np->daddr))
 		return -EINVAL;
 	
-	if (addr_len < sizeof(struct sockaddr_in6)) 
+	if (addr_len < SIN6_LEN_RFC2133) 
 		return(-EINVAL);
 
 	if (usin->sin6_family && usin->sin6_family != AF_INET6) 
diff -urN linux-2.2.x.org/net/ipv6/udp.c linux-2.2.x/net/ipv6/udp.c
--- linux-2.2.x.org/net/ipv6/udp.c	Mon Aug  9 21:04:41 1999
+++ linux-2.2.x/net/ipv6/udp.c	Fri Nov 17 18:58:13 2000
@@ -210,7 +210,7 @@
 		goto ipv4_connected;
 	}
 
-	if (addr_len < sizeof(*usin)) 
+	if (addr_len < SIN6_LEN_RFC2133) 
 	  	return(-EINVAL);
 
 	if (usin->sin6_family && usin->sin6_family != AF_INET6) 
@@ -777,7 +777,7 @@
 		if (sin6->sin6_family == AF_INET)
 			return udp_sendmsg(sk, msg, ulen);
 
-		if (addr_len < sizeof(*sin6))
+		if (addr_len < SIN6_LEN_RFC2133)
 			return(-EINVAL);
 
 		if (sin6->sin6_family && sin6->sin6_family != AF_INET6)

-- 
Arkadiusz Mi¶kiewicz, AM2-6BONE    [ PLD GNU/Linux IPv6 ]
http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/   [ enabled ]

From owner-netdev@oss.sgi.com Fri Nov 17 15:23:26 2000
Received:  by oss.sgi.com id <S553808AbQKQXXQ>;
	Fri, 17 Nov 2000 15:23:16 -0800
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:34820 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S553675AbQKQXXG>; Fri, 17 Nov 2000 15:23:06 -0800
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.11.0+3.3W/8.11.1/Debian 8.11.0-6) with ESMTP id eAHNMC801519;
	Sat, 18 Nov 2000 08:22:12 +0900
To:     misiek@pld.ORG.PL
Cc:     netdev@oss.sgi.com
Subject: Re: sin6_scope_id and 2.2.x kernel
In-Reply-To: <20001117181502.B25253@pld.ORG.PL>
References: <20001117181502.B25253@pld.ORG.PL>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20001118082211C.yoshfuji@ecei.tohoku.ac.jp>
Date:   Sat, 18 Nov 2000 08:22:11 +0900
From:   Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) 
        <yoshfuji@ecei.tohoku.ac.jp>
X-Dispatcher: imput version 990905(IM130)
Lines:  23
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In article <20001117181502.B25253@pld.ORG.PL> (at Fri, 17 Nov 2000 18:15:02 +0100), Arkadiusz Miskiewicz <misiek@pld.ORG.PL> says:

> in glibc 2.2 functions (ie. getnameinfo()) check for sizeof(struct sockaddr_in6)
> passed from 2.2 kernel against sizeof(struct sockaddr_in6+with sin6_scope_id field)
> and for 2.2.x kernels these functions will fail, so maybe such patch
> should be applied to 2.2.x kernel tree. Just add sin6_scope_id field
> to struct sockaddr_in6 (as in 2.4 kernel) but don't use it.

I don't think this is a good idea.

If you introduce sin6_scope_id into linux-2.2.x,
binaries on glibc-2.1 systems (including binaries
build on glibc-2.1 systems) encounter many random problem.

If you introduce sin6_scope_id into linux-2.2.x, sin6_scope_id
should take effect as of linux-2.4.x (usagi linux-2.2.x supports it)
to avoid any confusion.

Use linux-2.4.x (, or usagi linux-2.2.x).

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@linux-ipv6.org>
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Fri Nov 17 18:03:17 2000
Received:  by oss.sgi.com id <S553781AbQKRCDI>;
	Fri, 17 Nov 2000 18:03:08 -0800
Received: from laurin.munich.netsurf.de ([194.64.166.1]:40142 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S553751AbQKRCC6>; Fri, 17 Nov 2000 18:02:58 -0800
Received: from fred.muc.de (noidentity@ns1110.munich.netsurf.de [195.180.235.110])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id DAA22209;
	Sat, 18 Nov 2000 03:02:52 +0100 (MET)
Received: by fred.muc.de (Postfix, from userid 500)
	id 85510E3914; Fri, 17 Nov 2000 18:59:12 +0100 (CET)
Date:   Fri, 17 Nov 2000 18:59:12 +0100
From:   Andi Kleen <ak@muc.de>
To:     Shawn Houston <mhouston@gci.net>
Cc:     netdev@oss.sgi.com, linux-net@vger.kernel.org
Subject: Re: 2.2.18pre kernel net problem
Message-ID: <20001117185912.A5793@fred.local>
References: <3A156261.C95B698D@gci.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <3A156261.C95B698D@gci.net>; from mhouston@gci.net on Fri, Nov 17, 2000 at 05:56:35PM +0100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Fri, Nov 17, 2000 at 05:56:35PM +0100, Shawn Houston wrote:
> Help.
> 
> The 2.2.18pre series from Alan Cox, through pre21, has a problem with
> connection in CLOSE_WAIT that data still in the buffers. The connections
> never go away:

CLOSE_WAIT means what it says -- it is waiting for the close from the application.

Try killing it.

-Andi

From owner-netdev@oss.sgi.com Fri Nov 17 22:46:32 2000
Received:  by oss.sgi.com id <S553802AbQKRGqW>;
	Fri, 17 Nov 2000 22:46:22 -0800
Received: from mta-1.gci.net ([208.138.130.82]:47772 "EHLO mta-1.gci.net")
	by oss.sgi.com with ESMTP id <S553738AbQKRGqD>;
	Fri, 17 Nov 2000 22:46:03 -0800
Received: from mmp-2.gci.net ([208.138.130.81]) by mta-1.gci.net
          (Netscape Messaging Server 4.15) with ESMTP id G47K4H00.FUI for
          <netdev@oss.sgi.com>; Fri, 17 Nov 2000 21:45:53 -0900 
Received: from gci.net ([24.237.29.53]) by mmp-2.gci.net
          (Netscape Messaging Server 4.15) with ESMTP id G47K4I02.L47;
          Fri, 17 Nov 2000 21:45:54 -0900 
Message-ID: <3A1625E0.D60E1EC7@gci.net>
Date:   Fri, 17 Nov 2000 21:46:56 -0900
From:   Shawn Houston <mhouston@gci.net>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18pre21 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andi Kleen <ak@muc.de>
CC:     netdev@oss.sgi.com, linux-net@vger.kernel.org
Subject: Re: 2.2.18pre kernel net problem
References: <3A156261.C95B698D@gci.net> <20001117185912.A5793@fred.local>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Andi Kleen wrote:
> 
> On Fri, Nov 17, 2000 at 05:56:35PM +0100, Shawn Houston wrote:
> > Help.
> >
> > The 2.2.18pre series from Alan Cox, through pre21, has a problem with
> > connection in CLOSE_WAIT that data still in the buffers. The connections
> > never go away:
> 
> CLOSE_WAIT means what it says -- it is waiting for the close from the application.
> 
> Try killing it.
> 
> -Andi

I was about to send a flame, but thought better, as I do not know your
level of expertise, nor you mine. 

rdate finishes, so there is no need to kill it.

I am just going to go look in the source myself.

This represents a serious DOS attack and should be fixed. Really.

-Shawn

-- 

Shawn Houston
mhouston@gci.net

From owner-netdev@oss.sgi.com Sat Nov 18 11:14:27 2000
Received:  by oss.sgi.com id <S553739AbQKRTOH>;
	Sat, 18 Nov 2000 11:14:07 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:34830 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553671AbQKRTNj>;
	Sat, 18 Nov 2000 11:13:39 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id WAA16765; Sat, 18 Nov 2000 22:13:26 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011181913.WAA16765@ms2.inr.ac.ru>
Subject: Re: 2.2.18pre kernel net problem
To:     mhouston@gci.NET (Shawn Houston)
Date:   Sat, 18 Nov 2000 22:13:26 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <3A1625E0.D60E1EC7@gci.net> from "Shawn Houston" at Nov 18, 0 10:15:00 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 277       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> This represents a serious DOS attack and should be fixed. Really.

Funny, this bug in inetd has age of several years. 8)

Workaround is not to use "internal" time service in inetd.conf,
use your own one. Or to use some old inetd, sort of dated by 1996 or so.

Alexey

From owner-netdev@oss.sgi.com Sat Nov 18 12:07:17 2000
Received:  by oss.sgi.com id <S553790AbQKRUG5>;
	Sat, 18 Nov 2000 12:06:57 -0800
Received: from ikar.t17.ds.pwr.wroc.pl ([156.17.210.253]:4359 "HELO
        ikar.t17.ds.pwr.wroc.pl") by oss.sgi.com with SMTP
	id <S553735AbQKRUGh>; Sat, 18 Nov 2000 12:06:37 -0800
Received: by ikar.t17.ds.pwr.wroc.pl (Postfix+IPv6, from userid 1002)
	id 2E746C8002; Sat, 18 Nov 2000 20:04:32 +0100 (CET)
Date:   Sat, 18 Nov 2000 20:04:32 +0100
From:   Arkadiusz Miskiewicz <misiek@pld.ORG.PL>
To:     netdev@oss.sgi.com
Subject: Re: sin6_scope_id and 2.2.x kernel
Message-ID: <20001118200432.B10801@pld.ORG.PL>
References: <20001117181502.B25253@pld.ORG.PL> <20001118082211C.yoshfuji@ecei.tohoku.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001118082211C.yoshfuji@ecei.tohoku.ac.jp>; from yoshfuji@ecei.tohoku.ac.jp on Sat, Nov 18, 2000 at 08:22:11AM +0900
X-URL:  http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/
X-Operating-System: Linux dark 4.0.20 #119 Tue Jan 16 12:21:53 MET 2001 i986 pld
X-Team: Polish Linux Distribution Team Member
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On/Dnia Sat, Nov 18, 2000 at 08:22:11AM +0900, Hideaki YOSHIFUJI wrote/napisał(a)
> I don't think this is a good idea.
maybe. I'm not a expert :)

> If you introduce sin6_scope_id into linux-2.2.x,
> binaries on glibc-2.1 systems (including binaries
> build on glibc-2.1 systems) encounter many random problem.
IMO you are wrong here because all such binaries && linux 2.4
(so sin6_scope_id in kernel) are working fine without almost
any problems (one problem is lack of sin6_scope support in glibc,
so troubles with link-local addresses)

> Use linux-2.4.x
I'm always using latest devel kernel 8) but some PLD users
still use 2.2

(, or usagi linux-2.2.x).
when we were testing it we got problems such as invalid argument
in connect() even for global v6 addresses etc so it was unusable.

> Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@linux-ipv6.org>

-- 
Arkadiusz Mi¶kiewicz, AM2-6BONE    [ PLD GNU/Linux IPv6 ]
http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/   [ enabled ]

From owner-netdev@oss.sgi.com Sat Nov 18 16:44:31 2000
Received:  by oss.sgi.com id <S553803AbQKSAoW>;
	Sat, 18 Nov 2000 16:44:22 -0800
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:12037 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S553773AbQKSAny>; Sat, 18 Nov 2000 16:43:54 -0800
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.11.0+3.3W/8.11.1/Debian 8.11.0-6) with ESMTP id eAJ0gh815876;
	Sun, 19 Nov 2000 09:42:43 +0900
To:     misiek@pld.ORG.PL
Cc:     netdev@oss.sgi.com, usagi-users@linux-ipv6.org
Subject: Re: sin6_scope_id and 2.2.x kernel
In-Reply-To: <20001118200432.B10801@pld.ORG.PL>
References: <20001117181502.B25253@pld.ORG.PL>
	<20001118082211C.yoshfuji@ecei.tohoku.ac.jp>
	<20001118200432.B10801@pld.ORG.PL>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20001119094243O.yoshfuji@ecei.tohoku.ac.jp>
Date:   Sun, 19 Nov 2000 09:42:43 +0900
From:   YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= 
        <yoshfuji@ecei.tohoku.ac.jp>
X-Dispatcher: imput version 990905(IM130)
Lines:  352
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In article <20001118200432.B10801@pld.ORG.PL> (at Sat, 18 Nov 2000 20:04:32 +0100), Arkadiusz Miskiewicz <misiek@pld.ORG.PL> says:

> > If you introduce sin6_scope_id into linux-2.2.x,
> > binaries on glibc-2.1 systems (including binaries
> > build on glibc-2.1 systems) encounter many random problem.
> IMO you are wrong here because all such binaries && linux 2.4
> (so sin6_scope_id in kernel) are working fine without almost
> any problems (one problem is lack of sin6_scope support in glibc,
> so troubles with link-local addresses)

You are wrong.
There are possibility of binary incompatibility and security flaws.


> > Use linux-2.4.x
> I'm always using latest devel kernel 8) but some PLD users
> still use 2.2

Ipv6 users should upgrade to linux-2.4 as glibc people expect.
(or, convince them introduce linux-2.2 hack into glibc-2.2.)


> (, or usagi linux-2.2.x).
> when we were testing it we got problems such as invalid argument
> in connect() even for global v6 addresses etc so it was unusable.

Why don't you report it to us?


Anyway, this patch against glibc-2.2 will help you.
(this was contributed to glibc without linux-2.2 hack.)

Index: inet/getnameinfo.c
===================================================================
RCS file: /cvsroot/usagi/libc/glibc22/inet/getnameinfo.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.4.9
diff -u -r1.1.1.2 -r1.1.1.2.4.9
--- inet/getnameinfo.c	2000/11/03 07:25:51	1.1.1.2
+++ inet/getnameinfo.c	2000/11/19 00:19:13	1.1.1.2.4.9
@@ -1,3 +1,5 @@
+/* $USAGI: getnameinfo.c,v 1.1.1.2.4.9 2000/11/19 00:19:13 yoshfuji Exp $ */
+
 /* The Inner Net License, Version 2.00
 
   The author(s) grant permission for redistribution and use in source and
@@ -175,6 +177,10 @@
   struct hostent th;
   int ok = 0;
 
+  if (flags & ~(NI_NUMERICHOST|NI_NUMERICSERV|NI_NOFQDN|
+		NI_NAMEREQD|NI_DGRAM))
+    return -1;
+
   if (sa == NULL || addrlen < sizeof (sa_family_t))
     return -1;
 
@@ -189,7 +195,7 @@
 	return -1;
       break;
     case AF_INET6:
-      if (addrlen < sizeof (struct sockaddr_in6))
+      if (addrlen < sizeof (struct __sockaddr_in6_rfc2133))
 	return -1;
       break;
     default:
@@ -273,8 +279,11 @@
 			ok = 1;
 		      }
 		  }
-		strncpy (host, h->h_name, hostlen);
-		ok = 1;
+		else
+		  {
+		    strncpy (host, h->h_name, hostlen);
+		    ok = 1;
+		  }
 	      }
 	  }
 
@@ -295,40 +304,37 @@
 
 		    c = inet_ntop (AF_INET6,
 				   (void *) &sin6p->sin6_addr, host, hostlen);
-		    if (addrlen > sizeof (struct sockaddr_in6)
+		    if (addrlen >= sizeof (struct sockaddr_in6)
 			&& (scopeid = sin6p->sin6_scope_id))
 		      {
 			/* Buffer is >= IFNAMSIZ+1.  */
-			char scopebuf[IFNAMSIZ + 1];
+			char scopebuf[IFNAMSIZ + 1]={SCOPE_DELIMITER};
+			char *scopeptr = &scopebuf[1];
 			int ni_numericscope = 0;
+			size_t real_hostlen = __strnlen(host, hostlen);
+			size_t scopelen = 0;
 
 			if (IN6_IS_ADDR_LINKLOCAL (&sin6p->sin6_addr)
 			    || IN6_IS_ADDR_MC_LINKLOCAL (&sin6p->sin6_addr))
 			  {
 			    if (if_indextoname (scopeid, scopebuf) == NULL)
 			      ++ni_numericscope;
+			    else
+			      scopelen = strlen(scopebuf);
 			  }
 			else
 			  ++ni_numericscope;
 
 			if (ni_numericscope)
-			  {
-			    char *scopeptr = &scopebuf[1];
-			    size_t real_hostlen;
-			    size_t scopelen;
-
-			    scopebuf[0] = SCOPE_DELIMITER;
-			    scopelen = 1 + __snprintf (scopeptr,
-						       (scopebuf
-							+ sizeof scopebuf
-							- scopeptr),
-						       "%u", scopeid);
-
-			    real_hostlen = __strnlen (host, hostlen);
-			    if (real_hostlen + scopelen + 1 > hostlen)
-			      return -1;
-			    memcpy (host + real_hostlen, scopebuf, scopelen);
-			  }
+			  scopelen = 1 + __snprintf (scopeptr,
+						     (scopebuf
+						      + sizeof scopebuf
+						      - scopeptr),
+						     "%u", scopeid);
+
+			if (real_hostlen + scopelen + 1 > hostlen)
+			  return -1;
+			memcpy (host + real_hostlen, scopebuf, scopelen + 1);
 		      }
 		  }
 		else
Index: inet/netinet/in.h
===================================================================
RCS file: /cvsroot/usagi/libc/glibc22/inet/netinet/in.h,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.1.4.4
diff -u -r1.1.1.1 -r1.1.1.1.4.4
--- inet/netinet/in.h	2000/10/13 09:38:50	1.1.1.1
+++ inet/netinet/in.h	2000/11/19 00:19:13	1.1.1.1.4.4
@@ -1,3 +1,5 @@
+/* $USAGI: in.h,v 1.1.1.1.4.4 2000/11/19 00:19:13 yoshfuji Exp $ */
+
 /* Copyright (C) 1991-1999, 2000 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
 
@@ -212,6 +214,15 @@
     struct in6_addr sin6_addr;	/* IPv6 address */
     uint32_t sin6_scope_id;	/* IPv6 scope-id */
   };
+#ifdef __USE_GNU
+struct __sockaddr_in6_rfc2133
+  {
+    __SOCKADDR_COMMON (__sin6_);
+    in_port_t __sin6_port;
+    uint32_t __sin6_flowinfo;
+    struct in6_addr __sin6_addr;
+  };
+#endif
 
 /* IPv6 multicast request.  */
 struct ipv6_mreq
Index: sysdeps/posix/getaddrinfo.c
===================================================================
RCS file: /cvsroot/usagi/libc/glibc22/sysdeps/posix/getaddrinfo.c,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.1.4.8
diff -u -r1.1.1.1 -r1.1.1.1.4.8
--- sysdeps/posix/getaddrinfo.c	2000/10/13 09:38:40	1.1.1.1
+++ sysdeps/posix/getaddrinfo.c	2000/11/06 08:55:47	1.1.1.1.4.8
@@ -1,3 +1,5 @@
+/* $USAGI: getaddrinfo.c,v 1.1.1.1.4.8 2000/11/06 08:55:47 yoshfuji Exp $ */
+
 /* The Inner Net License, Version 2.00
 
   The author(s) grant permission for redistribution and use in source and
@@ -99,13 +101,14 @@
 
 /* Values for `protoflag'.  */
 #define GAI_PROTO_NOSERVICE	1
+#define GAI_PROTO_PROTOANY	2
 
 static struct gaih_typeproto gaih_inet_typeproto[] =
 {
   { 0, 0, NULL, 0 },
   { SOCK_STREAM, IPPROTO_TCP, (char *) "tcp", 0 },
   { SOCK_DGRAM, IPPROTO_UDP, (char *) "udp", 0 },
-  { SOCK_RAW, IPPROTO_RAW, (char *) "raw", GAI_PROTO_NOSERVICE },
+  { SOCK_RAW, 0, (char *) "raw", GAI_PROTO_PROTOANY|GAI_PROTO_NOSERVICE },
   { 0, 0, NULL, 0 }
 };
 
@@ -150,6 +153,7 @@
 	     && ((tp->protoflag & GAI_PROTO_NOSERVICE) != 0
 		 || (req->ai_socktype != 0 && req->ai_socktype != tp->socktype)
 		 || (req->ai_protocol != 0
+		     && !(tp->protoflag & GAI_PROTO_PROTOANY)
 		     && req->ai_protocol != tp->protocol)))
 	++tp;
 
@@ -229,6 +233,7 @@
 
 static int
 gaih_inet_serv (const char *servicename, struct gaih_typeproto *tp,
+	       const struct addrinfo *req,
 	       struct gaih_servtuple *st)
 {
   struct servent *s;
@@ -255,7 +260,8 @@
 
   st->next = NULL;
   st->socktype = tp->socktype;
-  st->protocol = tp->protocol;
+  st->protocol = (tp->protoflag & GAI_PROTO_PROTOANY) ?
+		 req->ai_protocol : tp->protocol;
   st->port = s->s_port;
 
   return 0;
@@ -291,8 +297,10 @@
     {								\
       for (i = 0; h->h_addr_list[i]; i++)			\
 	{							\
-	  if (*pat == NULL)					\
+	  if (*pat == NULL) {					\
 	    *pat = __alloca (sizeof(struct gaih_addrtuple));	\
+	    (*pat)->scopeid = 0;				\
+	  }							\
 	  (*pat)->next = NULL;					\
 	  (*pat)->family = _family;				\
 	  memcpy ((*pat)->addr, h->h_addr_list[i],		\
@@ -319,6 +327,7 @@
       while (tp->name != NULL
 	     && ((req->ai_socktype != 0 && req->ai_socktype != tp->socktype)
 		 || (req->ai_protocol != 0
+		     && !(tp->protoflag & GAI_PROTO_PROTOANY)
 		     && req->ai_protocol != tp->protocol)))
 	++tp;
 
@@ -343,7 +352,7 @@
 	      st = (struct gaih_servtuple *)
 		__alloca (sizeof (struct gaih_servtuple));
 
-	      if ((rc = gaih_inet_serv (service->name, tp, st)))
+	      if ((rc = gaih_inet_serv (service->name, tp, req, st)))
 		return rc;
 	    }
 	  else
@@ -359,11 +368,15 @@
 		  if (req->ai_socktype != 0
 		      && req->ai_socktype != tp->socktype)
 		    continue;
+		  if (req->ai_protocol != 0 
+		      && !(tp->protoflag & GAI_PROTO_PROTOANY)
+		      && req->ai_protocol != tp->protocol)
+		    continue;
 
 		  newp = (struct gaih_servtuple *)
 		    __alloca (sizeof (struct gaih_servtuple));
 
-		  if ((rc = gaih_inet_serv (service->name, tp, newp)))
+		  if ((rc = gaih_inet_serv (service->name, tp, req, newp)))
 		    {
 		      if (rc & GAIH_OKIFUNSPEC)
 			continue;
@@ -382,7 +395,8 @@
 	  st = __alloca (sizeof (struct gaih_servtuple));
 	  st->next = NULL;
 	  st->socktype = tp->socktype;
-	  st->protocol = tp->protocol;
+	  st->protocol = (tp->protoflag & GAI_PROTO_PROTOANY) ?
+			 req->ai_protocol : tp->protocol;
 	  st->port = htons (service->num);
 	}
     }
@@ -390,8 +404,9 @@
     {
       st = __alloca (sizeof (struct gaih_servtuple));
       st->next = NULL;
-      st->socktype = req->ai_socktype;
-      st->protocol = req->ai_protocol;
+      st->socktype = tp->socktype;
+      st->protocol = (tp->protoflag & GAI_PROTO_PROTOANY) ?
+		     req->ai_protocol : tp->protocol;
       st->port = 0;
     }
   else
@@ -542,6 +557,7 @@
     struct gaih_servtuple *st2;
     struct gaih_addrtuple *at2 = at;
     size_t socklen, namelen;
+    sa_family_t family;
 
     /*
       buffer is the size of an unformatted IPv6 address in printable format.
@@ -597,9 +613,15 @@
 	  namelen = 0;
 
 	if (at2->family == AF_INET6)
-	  socklen = sizeof (struct sockaddr_in6);
+	  { 
+	    family = AF_INET6;
+	    socklen = sizeof (struct sockaddr_in6);
+	  }
 	else
-	  socklen = sizeof (struct sockaddr_in);
+	  {
+	    family = AF_INET;
+	    socklen = sizeof (struct sockaddr_in);
+	  }
 
 	for (st2 = st; st2 != NULL; st2 = st2->next)
 	  {
@@ -608,7 +630,7 @@
 	      return -EAI_MEMORY;
 
 	    (*pai)->ai_flags = req->ai_flags;
-	    (*pai)->ai_family = at2->family;
+	    (*pai)->ai_family = family;
 	    (*pai)->ai_socktype = st2->socktype;
 	    (*pai)->ai_protocol = st2->protocol;
 	    (*pai)->ai_addrlen = socklen;
@@ -616,9 +638,9 @@
 #if SALEN
 	    (*pai)->ai_addr->sa_len = socklen;
 #endif /* SALEN */
-	    (*pai)->ai_addr->sa_family = at2->family;
+	    (*pai)->ai_addr->sa_family = family;
 
-	    if (at2->family == AF_INET6)
+	    if (family == AF_INET6)
 	      {
 		struct sockaddr_in6 *sin6p =
 		  (struct sockaddr_in6 *) (*pai)->ai_addr;
@@ -703,7 +725,7 @@
       else
 	/* Can't specify a numerical socket unless a protocol family was
 	   given. */
-        if (hints->ai_socktype == 0)
+        if (hints->ai_socktype == 0 && hints->ai_protocol == 0)
           return EAI_SERVICE;
       pservice = &gaih_service;
     }


-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@linux-ipv6.org>
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Sat Nov 18 17:01:11 2000
Received:  by oss.sgi.com id <S553811AbQKSBAv>;
	Sat, 18 Nov 2000 17:00:51 -0800
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:14341 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S553798AbQKSBAU>; Sat, 18 Nov 2000 17:00:20 -0800
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.11.0+3.3W/8.11.1/Debian 8.11.0-6) with ESMTP id eAJ103815954;
	Sun, 19 Nov 2000 10:00:03 +0900
To:     misiek@pld.ORG.PL
Cc:     netdev@oss.sgi.com, usagi-users@linux-ipv6.org
Subject: Re: sin6_scope_id and 2.2.x kernel
In-Reply-To: <20001119094243O.yoshfuji@ecei.tohoku.ac.jp>
References: <20001118082211C.yoshfuji@ecei.tohoku.ac.jp>
	<20001118200432.B10801@pld.ORG.PL>
	<20001119094243O.yoshfuji@ecei.tohoku.ac.jp>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Message-Id: <20001119100003F.yoshfuji@ecei.tohoku.ac.jp>
Date:   Sun, 19 Nov 2000 10:00:03 +0900
From:   YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= 
        <yoshfuji@ecei.tohoku.ac.jp>
X-Dispatcher: imput version 990905(IM130)
Lines:  39
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In article <20001119094243O.yoshfuji@ecei.tohoku.ac.jp> (at Sun, 19 Nov 2000 09:42:43 +0900), YOSHIFUJI Hideaki / $B5HF#1QL@(B <yoshfuji@ecei.tohoku.ac.jp> says:

> Anyway, this patch against glibc-2.2 will help you.
> (this was contributed to glibc without linux-2.2 hack.)

auch, this includes editorial error, so apply this.

you can get (update) patch at
ftp://ftp.linux-ipv6.org/pub/usagi/misc/glibc22-fix-20001119a.patch.gz

sorry for the mess.

Index: inet/getnameinfo.c
===================================================================
RCS file: /cvsroot/usagi/libc/glibc22/inet/getnameinfo.c,v
retrieving revision 1.1.1.2.4.9
retrieving revision 1.1.1.2.4.10
diff -u -r1.1.1.2.4.9 -r1.1.1.2.4.10
--- inet/getnameinfo.c	2000/11/19 00:19:13	1.1.1.2.4.9
+++ inet/getnameinfo.c	2000/11/19 00:49:49	1.1.1.2.4.10
@@ -1,4 +1,4 @@
-/* $USAGI: getnameinfo.c,v 1.1.1.2.4.9 2000/11/19 00:19:13 yoshfuji Exp $ */
+/* $USAGI: getnameinfo.c,v 1.1.1.2.4.10 2000/11/19 00:49:49 yoshfuji Exp $ */
 
 /* The Inner Net License, Version 2.00
 
@@ -317,7 +317,7 @@
 			if (IN6_IS_ADDR_LINKLOCAL (&sin6p->sin6_addr)
 			    || IN6_IS_ADDR_MC_LINKLOCAL (&sin6p->sin6_addr))
 			  {
-			    if (if_indextoname (scopeid, scopebuf) == NULL)
+			    if (if_indextoname (scopeid, scopeptr) == NULL)
 			      ++ni_numericscope;
 			    else
 			      scopelen = strlen(scopebuf);

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@linux-ipv6.org>
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Sun Nov 19 00:37:16 2000
Received:  by oss.sgi.com id <S553823AbQKSIg5>;
	Sun, 19 Nov 2000 00:36:57 -0800
Received: from ikar.t17.ds.pwr.wroc.pl ([156.17.210.253]:33801 "HELO
        ikar.t17.ds.pwr.wroc.pl") by oss.sgi.com with SMTP
	id <S553807AbQKSIg2>; Sun, 19 Nov 2000 00:36:28 -0800
Received: by ikar.t17.ds.pwr.wroc.pl (Postfix+IPv6, from userid 1002)
	id DE5AEC8002; Sun, 19 Nov 2000 08:34:24 +0100 (CET)
Date:   Sun, 19 Nov 2000 08:34:24 +0100
From:   Arkadiusz Miskiewicz <misiek@pld.org.pl>
To:     usagi-users@linux-ipv6.org
Cc:     netdev@oss.sgi.com
Subject: Re: (usagi-users 00035) Re: sin6_scope_id and 2.2.x kernel
Message-ID: <20001119083424.A24100@pld.ORG.PL>
Mail-Followup-To: Arkadiusz Miskiewicz <misiek@pld.org.pl>,
	usagi-users@linux-ipv6.org, netdev@oss.sgi.com
References: <20001117181502.B25253@pld.ORG.PL> <20001118082211C.yoshfuji@ecei.tohoku.ac.jp> <20001118200432.B10801@pld.ORG.PL> <20001119094243O.yoshfuji@ecei.tohoku.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001119094243O.yoshfuji@ecei.tohoku.ac.jp>; from yoshfuji@ecei.tohoku.ac.jp on Sun, Nov 19, 2000 at 09:42:43AM +0900
X-URL:  http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/
X-Operating-System: Linux dark 4.0.20 #119 Tue Jan 16 12:21:53 MET 2001 i986 pld
X-Team: Polish Linux Distribution Team Member
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On/Dnia Sun, Nov 19, 2000 at 09:42:43AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@?(B wrote/napisał(a)
> > > If you introduce sin6_scope_id into linux-2.2.x,
> > > binaries on glibc-2.1 systems (including binaries
> > > build on glibc-2.1 systems) encounter many random problem.
> > IMO you are wrong here because all such binaries && linux 2.4
> > (so sin6_scope_id in kernel) are working fine without almost
> > any problems (one problem is lack of sin6_scope support in glibc,
> > so troubles with link-local addresses)
> 
> You are wrong.
> There are possibility of binary incompatibility
I don't understand in which situation binary incompatibility
will occur. 

> and security flaws.
Maybe this but not binary incompatibility (IMHO).

> (or, convince them introduce linux-2.2 hack into glibc-2.2.)
I dislike hacks. I preffer to fix broken 2.2 kernel.

> > (, or usagi linux-2.2.x).
> > when we were testing it we got problems such as invalid argument
> > in connect() even for global v6 addresses etc so it was unusable.
> 
> Why don't you report it to us?
well, I should.

> Anyway, this patch against glibc-2.2 will help you.
> (this was contributed to glibc without linux-2.2 hack.)
our glibc 2.2 has this patch applied (without linux-2.2 hack)
and we really don't want to add hacks.

 
> Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@linux-ipv6.org>

-- 
Arkadiusz Mi¶kiewicz, AM2-6BONE    [ PLD GNU/Linux IPv6 ]
http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/   [ enabled ]

From owner-netdev@oss.sgi.com Sun Nov 19 21:31:44 2000
Received:  by oss.sgi.com id <S553836AbQKTFbY>;
	Sun, 19 Nov 2000 21:31:24 -0800
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]:9476 "EHLO
        cerberus.nemoto.ecei.tohoku.ac.jp") by oss.sgi.com with ESMTP
	id <S553832AbQKTFbC>; Sun, 19 Nov 2000 21:31:02 -0800
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.11.0+3.3W/8.11.1/Debian 8.11.0-6) with ESMTP id eAK5UL400915;
	Mon, 20 Nov 2000 14:30:21 +0900
To:     misiek@pld.ORG.PL
CC:     usagi-users@linux-ipv6.org
CC:     netdev@oss.sgi.com
Reply-To: usagi-users@linux-ipv6.org
Subject: Re: sin6_scope_id and 2.2.x kernel
In-Reply-To: <20001118200432.B10801@pld.ORG.PL>
References: <20001117181502.B25253@pld.ORG.PL>
	<20001118082211C.yoshfuji@ecei.tohoku.ac.jp>
	<20001118200432.B10801@pld.ORG.PL>
X-Mailer: Mew version 1.94 on XEmacs 21.1 (Capitol Reef)
X-URL:  http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20001120143021D.yoshfuji@ecei.tohoku.ac.jp>
Date:   Mon, 20 Nov 2000 14:30:21 +0900
From:   YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= 
        <yoshfuji@ecei.tohoku.ac.jp>
X-Dispatcher: imput version 990905(IM130)
Lines:  100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

In article <20001118200432.B10801@pld.ORG.PL> (at Sat, 18 Nov 2000 20:04:32 +0100), Arkadiusz Miskiewicz <misiek@pld.ORG.PL> says:

> (, or usagi linux-2.2.x).
> when we were testing it we got problems such as invalid argument
> in connect() even for global v6 addresses etc so it was unusable.

Does this fix your problem?

Index: net/ipv6/af_inet6.c
===================================================================
RCS file: /cvsroot/usagi/kernel/linux22/net/ipv6/af_inet6.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- net/ipv6/af_inet6.c	2000/10/17 03:29:35	1.2
+++ net/ipv6/af_inet6.c	2000/11/20 05:03:31	1.3
@@ -201,8 +201,8 @@
 		return sk->prot->bind(sk, uaddr, addr_len);
 		
 	/* Check these errors (active socket, bad address length, double bind). */
-	if ((sk->state != TCP_CLOSE)			||
-	    (addr_len < sizeof(struct sockaddr_in6))	||
+	if ((sk->state != TCP_CLOSE)		||
+	    (addr_len < SIN6_LEN_RFC2133)	||
 	    (sk->num != 0))
 		return -EINVAL;
 		
Index: net/ipv6/raw.c
===================================================================
RCS file: /cvsroot/usagi/kernel/linux22/net/ipv6/raw.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- net/ipv6/raw.c	2000/10/17 03:29:35	1.2
+++ net/ipv6/raw.c	2000/11/20 05:03:31	1.3
@@ -151,7 +151,7 @@
 			 */ 
 			sk->bound_dev_if = addr->sin6_scope_id;
 		}
-#ifndef CONFIG_IPV6_LOOSE_SOCPE_ID
+#ifndef CONFIG_IPV6_LOOSE_SCOPE_ID
 		if (sk->bound_dev_if == 0)
 			return -EINVAL;
 #endif
@@ -386,7 +386,7 @@
 	fl.fl6_flowlabel = 0;
 
 	if (sin6) {
-		if (addr_len < sizeof(struct sockaddr_in6)) 
+		if (addr_len < SIN6_LEN_RFC2133)
 			return(-EINVAL);
 
 		if (sin6->sin6_family && sin6->sin6_family != AF_INET6) 
Index: net/ipv6/tcp_ipv6.c
===================================================================
RCS file: /cvsroot/usagi/kernel/linux22/net/ipv6/tcp_ipv6.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- net/ipv6/tcp_ipv6.c	2000/10/17 03:29:35	1.2
+++ net/ipv6/tcp_ipv6.c	2000/11/20 05:03:31	1.3
@@ -390,7 +390,7 @@
 	if(!ipv6_addr_any(&np->daddr))
 		return -EINVAL;
 	
-	if (addr_len < sizeof(struct sockaddr_in6)) 
+	if (addr_len < SIN6_LEN_RFC2133)
 		return(-EINVAL);
 
 	if (usin->sin6_family && usin->sin6_family != AF_INET6) 
Index: net/ipv6/udp.c
===================================================================
RCS file: /cvsroot/usagi/kernel/linux22/net/ipv6/udp.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- net/ipv6/udp.c	2000/10/17 03:29:35	1.2
+++ net/ipv6/udp.c	2000/11/20 05:03:31	1.3
@@ -213,7 +213,7 @@
 		goto ipv4_connected;
 	}
 
-	if (addr_len < sizeof(*usin)) 
+	if (addr_len < SIN6_LEN_RFC2133)
 	  	return(-EINVAL);
 
 	if (usin->sin6_family && usin->sin6_family != AF_INET6) 
@@ -809,7 +809,7 @@
 		if (sin6->sin6_family == AF_INET)
 			return udp_sendmsg(sk, msg, ulen);
 
-		if (addr_len < sizeof(*sin6))
+		if (addr_len < SIN6_LEN_RFC2133)
 			return(-EINVAL);
 
 		if (sin6->sin6_family && sin6->sin6_family != AF_INET6)

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@linux-ipv6.org>
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 

From owner-netdev@oss.sgi.com Tue Nov 21 14:25:34 2000
Received:  by oss.sgi.com id <S553655AbQKUWZO>;
	Tue, 21 Nov 2000 14:25:14 -0800
Received: from kogge.hanse.de ([192.76.134.17]:29447 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553650AbQKUWYu>;
	Tue, 21 Nov 2000 14:24:50 -0800
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id XAA23872
	for netdev@oss.sgi.com; Tue, 21 Nov 2000 23:24:33 +0100 (CET)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id XAA03012;
	Tue, 21 Nov 2000 23:22:58 +0100
Date:   Tue, 21 Nov 2000 23:22:58 +0100
From:   Henner Eisen <eis@baty.hanse.de>
Message-Id: <200011212222.XAA03012@baty.hanse.de>
To:     netdev@oss.sgi.com
Subject: sk->user_data
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi,

2.4.0 struct sock contains a member

        void                    *user_data;

which is currently only used for pointing to an in-kernel RPC layer
control block.

Is it o.k. to use this pointer for alternative upper layer or would that
be a bad idea?

Rationale:

I have implemented a framework that allows tunneling of PPP and IP over
PF_X25 socket connections. For this I need a pointer to a socket tunnel
structure which I currently maintain in the private x25 protocol block.
As this code is generic (it is not x25 specific and aims at being
re-usable for tunneling over other linux network protocol stacks), it
makes sense to maintain the pointer in a protocol-independent area of
struct sock.
RPC already uses the sk->user_data field to point to an upper layer
control structure. My tunnel scenario is similar: it is also an alternative
(not a struct socket) in-kernel upper layer.

As the type is void*, it seems to me that it was intended for such use.
And there won't be any conflicts with RPC because a socket attached to
in-kernel RPC won't be simultaneously used for tunneling.
Thus, if it's o.k to re-use sk->user_data, I'd like to document this in
the source by means of the following patch.

Henner

--- sktn/include/net/sock.h.old	Mon Nov 20 22:45:24 2000
+++ sktn/include/net/sock.h	Tue Nov 21 22:38:14 2000
@@ -651,7 +651,7 @@
 	/* Identd and reporting IO signals */
 	struct socket		*socket;
 
-	/* RPC layer private data */
+	/* Private data for non-socket upper layer (e.g. in-kernel RPC) */
 	void			*user_data;
   
 	/* Callbacks */



From owner-netdev@oss.sgi.com Wed Nov 22 16:08:00 2000
Received:  by oss.sgi.com id <S553778AbQKWAHv>;
	Wed, 22 Nov 2000 16:07:51 -0800
Received: from cx97923-a.phnx3.az.home.com ([24.9.112.194]:31246 "EHLO
        grok.yi.org") by oss.sgi.com with ESMTP id <S553769AbQKWAH0>;
	Wed, 22 Nov 2000 16:07:26 -0800
Received: from candelatech.com (IDENT:greear@localhost [127.0.0.1])
	by grok.yi.org (8.9.3/8.8.7) with ESMTP id SAA30601;
	Wed, 22 Nov 2000 18:03:27 -0700
Message-ID: <3A1C6CDF.CA7A1F4A@candelatech.com>
Date:   Wed, 22 Nov 2000 18:03:27 -0700
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16 i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Henner Eisen <eis@baty.hanse.de>
CC:     netdev@oss.sgi.com
Subject: Re: sk->user_data
References: <200011212222.XAA03012@baty.hanse.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Henner Eisen wrote:
> 
> Hi,
> 
> 2.4.0 struct sock contains a member
> 
>         void                    *user_data;
> 
> which is currently only used for pointing to an in-kernel RPC layer
> control block.
> 
> Is it o.k. to use this pointer for alternative upper layer or would that
> be a bad idea?

I've been thinking that if we used unions instead of all the void*,
then it might be more obvious what the use of the variable is (in
the using code), and could be (when looking at net_dev.h).

As long as the data types are all pointers,
the space used in the struct containing the union is the same, right?

Either way, comments are a good idea.

> 
> Rationale:
> 
> I have implemented a framework that allows tunneling of PPP and IP over
> PF_X25 socket connections. For this I need a pointer to a socket tunnel
> structure which I currently maintain in the private x25 protocol block.
> As this code is generic (it is not x25 specific and aims at being
> re-usable for tunneling over other linux network protocol stacks), it
> makes sense to maintain the pointer in a protocol-independent area of
> struct sock.
> RPC already uses the sk->user_data field to point to an upper layer
> control structure. My tunnel scenario is similar: it is also an alternative
> (not a struct socket) in-kernel upper layer.
> 
> As the type is void*, it seems to me that it was intended for such use.
> And there won't be any conflicts with RPC because a socket attached to
> in-kernel RPC won't be simultaneously used for tunneling.
> Thus, if it's o.k to re-use sk->user_data, I'd like to document this in
> the source by means of the following patch.
> 
> Henner
> 
> --- sktn/include/net/sock.h.old Mon Nov 20 22:45:24 2000
> +++ sktn/include/net/sock.h     Tue Nov 21 22:38:14 2000
> @@ -651,7 +651,7 @@
>         /* Identd and reporting IO signals */
>         struct socket           *socket;
> 
> -       /* RPC layer private data */
> +       /* Private data for non-socket upper layer (e.g. in-kernel RPC) */
>         void                    *user_data;
> 
>         /* Callbacks */

-- 
Ben Greear (greearb@candelatech.com)  http://www.candelatech.com
Author of ScryMUD:  scry.wanfear.com 4444        (Released under GPL)
http://scry.wanfear.com               http://scry.wanfear.com/~greear

From owner-netdev@oss.sgi.com Thu Nov 23 08:02:46 2000
Received:  by oss.sgi.com id <S553796AbQKWQCg>;
	Thu, 23 Nov 2000 08:02:36 -0800
Received: from as3-3-4.ml.g.bonet.se ([194.236.33.69]:12805 "EHLO
        tellus.mine.nu") by oss.sgi.com with ESMTP id <S553786AbQKWQCN>;
	Thu, 23 Nov 2000 08:02:13 -0800
Received: from localhost (tori@localhost)
	by tellus.mine.nu (8.9.3/8.9.3) with ESMTP id RAA32528;
	Thu, 23 Nov 2000 17:02:10 +0100
Date:   Thu, 23 Nov 2000 17:02:10 +0100 (CET)
From:   Tobias Ringstrom <tori@tellus.mine.nu>
X-Sender: tori@svea.tellus
To:     netdev@oss.sgi.com
cc:     Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Too long network device names corrupts kernel
Message-ID: <Pine.LNX.4.21.0011231642110.32263-100000@svea.tellus>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

(2.4.0-test11, but probably every version)

The name member of the net_device struct is fixed to IFNAMSIZ (16) bytes,
and is accessed using strcpy, strcmp and friends all over the place, which
suggests that the last byte of the name must be a null character. This
must be verified when the name is set. I haven't looked very hard, but
this seems not to be the case.

It is, to my knowledge, not possible for a normal user to create/name a
device, so only root can cause the corruption. Bad enough, but not
catastrophic.

As I see it, one (or both) of the following must be done:

1. Find all places where the device name is set and use length checking
   functions such as strncpy.

2. Find all places where a device name is used, and use special methods to
   copy and add a null character, or use strncpy, strncmp, etc.

...where number one is probably the only realistic solution.

I discovered this when I tried to create a tunnel using more than
IFNAMSIZ-1 (15) characters. It's quite hard to remove that tunnel. I'll go
for the Windows solution and reboot. Sigh!

Btw, does anyone know of a C function that works like strncpy, but does
add a terminating null character, event if the string does not fit, ro
does one have to do str[5]=0 first, and then strncpy(str,src,4)?

/Tobias



From owner-netdev@oss.sgi.com Thu Nov 23 09:10:06 2000
Received:  by oss.sgi.com id <S553804AbQKWRJ4>;
	Thu, 23 Nov 2000 09:09:56 -0800
Received: from ganymede.or.intel.com ([134.134.248.3]:46087 "EHLO
        ganymede.or.intel.com") by oss.sgi.com with ESMTP
	id <S553800AbQKWRJc>; Thu, 23 Nov 2000 09:09:32 -0800
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id JAA00684
	for <netdev@oss.sgi.com>; Thu, 23 Nov 2000 09:09:21 -0800 (PST)
Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 23 Nov 2000 17:09:20 0000 (GMT)
Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21)
	id <XN0F8J4K>; Thu, 23 Nov 2000 09:09:19 -0800
Message-ID: <B113FF77ABB8D311AC6A00A0C9C58AE602E5A416@hasmsx30.iil.intel.com>
From:   "Trumper, Fabian" <fabian.trumper@intel.com>
To:     "'netdev@oss.sgi.com'" <netdev@oss.sgi.com>
Subject: info
Date:   Thu, 23 Nov 2000 09:09:14 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing



 Fabian Trumper 
 Linux Drivers and Security
 LAN Access Division
 Intel Network Communications Group
 Phone: +972 2 5892427 
 Email: fabian.trumper@intel.com



From owner-netdev@oss.sgi.com Thu Nov 23 10:46:56 2000
Received:  by oss.sgi.com id <S553769AbQKWSqq>;
	Thu, 23 Nov 2000 10:46:46 -0800
Received: from zikova.cvut.cz ([147.32.235.100]:26639 "EHLO zikova.cvut.cz")
	by oss.sgi.com with ESMTP id <S553704AbQKWSqZ>;
	Thu, 23 Nov 2000 10:46:25 -0800
Received: from vcnet.vc.cvut.cz (vcnet.vc.cvut.cz [147.32.240.61])
	by zikova.cvut.cz (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id TAA82712;
	Thu, 23 Nov 2000 19:45:56 +0100
Received: from VCNET/SpoolDir by vcnet.vc.cvut.cz (Mercury 1.21);
    23 Nov 100 19:46:02 MET-1MEST
Received: from SpoolDir by VCNET (Mercury 1.30); 23 Nov 100 19:45:48 MET-1MEST
From:   "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
Organization:  CC CTU Prague
To:     kuznet@ms2.inr.ac.ru
Date:          Thu, 23 Nov 2000 19:45:43 MET-1
MIME-Version:  1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject:       2.4.0-test11 and af_inet.c(164)
CC:     netdev@oss.sgi.com
X-mailer: Pegasus Mail v3.40
Message-ID: <DB22ED31E32@vcnet.vc.cvut.cz>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi Alexey,
  I did not want to broke your circles, but 2.4.0-test11 said:
  
KERNEL: assertion (atomic_read(&sk->wmem_alloc) == 0) failed at af_inet.c(164):inet_sock_destruct

It happened when some of our students found some hole in Win95/98/NT,
so ethernet utilization was 100% and nothing worked (now I even have
RX dropped: 127; pretty impressive on dual PIII/450 with 10Mbps network
attached (tulip driver) ;-))

Everything still works and I have no idea how to find whether some 100 bytes
were leaked somewhere or not... (of course, error is non-repeatable)
                                        Best regards,
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz
                                                    
BTW, does anybody know what listens (and answers) on IPX port 0x550 in 
Windows? I tried Novell Knowledgebase, Altavista and Google, but neither
wants to give me well known IPX ports (sockets) list :-(

From owner-netdev@oss.sgi.com Thu Nov 23 12:08:57 2000
Received:  by oss.sgi.com id <S553809AbQKWUIs>;
	Thu, 23 Nov 2000 12:08:48 -0800
Received: from minus.inr.ac.ru ([193.233.7.97]:60679 "HELO ms2.inr.ac.ru")
	by oss.sgi.com with SMTP id <S553778AbQKWUIh>;
	Thu, 23 Nov 2000 12:08:37 -0800
Received: (from kuznet@localhost) by ms2.inr.ac.ru (8.6.13/ANK) id XAA06575; Thu, 23 Nov 2000 23:08:16 +0300
From:   kuznet@ms2.inr.ac.ru
Message-Id: <200011232008.XAA06575@ms2.inr.ac.ru>
Subject: Re: 2.4.0-test11 and af_inet.c(164)
To:     VANDROVE@vc.cvut.cz (Petr Vandrovec)
Date:   Thu, 23 Nov 2000 23:08:16 +0300 (MSK)
Cc:     netdev@oss.sgi.com
In-Reply-To: <DB22ED31E32@vcnet.vc.cvut.cz> from "Petr Vandrovec" at Nov 23, 0 07:45:43 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Length: 434       
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hello!

> KERNEL: assertion (atomic_read(&sk->wmem_alloc) == 0) failed at af_inet.c(164):inet_sock_destruct
....
> Everything still works and I have no idea how to find whether some 100 bytes
> were leaked somewhere or not... (of course, error is non-repeatable)

Well, it is not plain 100 bytes leaked.
It is rather an absolutely impossible event, which cannot happen
even if all the bits leaked. 8)

OK... Audit is started.

Alexey

From owner-netdev@oss.sgi.com Thu Nov 23 15:07:58 2000
Received:  by oss.sgi.com id <S553823AbQKWXHh>;
	Thu, 23 Nov 2000 15:07:37 -0800
Received: from zikova.cvut.cz ([147.32.235.100]:16145 "EHLO zikova.cvut.cz")
	by oss.sgi.com with ESMTP id <S553817AbQKWXHI>;
	Thu, 23 Nov 2000 15:07:08 -0800
Received: from vcnet.vc.cvut.cz (vcnet.vc.cvut.cz [147.32.240.61])
	by zikova.cvut.cz (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id AAA78330;
	Fri, 24 Nov 2000 00:06:59 +0100
Received: from VCNET/SpoolDir by vcnet.vc.cvut.cz (Mercury 1.21);
    24 Nov 100 00:07:00 MET-1MEST
Received: from SpoolDir by VCNET (Mercury 1.30); 24 Nov 100 00:06:57 MET-1MEST
From:   "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
Organization:  CC CTU Prague
To:     kuznet@ms2.inr.ac.ru
Date:          Fri, 24 Nov 2000 00:06:55 MET-1
MIME-Version:  1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject:       Re: 2.4.0-test11 and af_inet.c(164)
CC:     netdev@oss.sgi.com
X-mailer: Pegasus Mail v3.40
Message-ID: <DB6897C2EB0@vcnet.vc.cvut.cz>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On 23 Nov 00 at 23:08, kuznet@ms2.inr.ac.ru wrote:
> > KERNEL: assertion (atomic_read(&sk->wmem_alloc) == 0) failed at af_inet.c(164):inet_sock_destruct
> ....
> > Everything still works and I have no idea how to find whether some 100 bytes
> > were leaked somewhere or not... (of course, error is non-repeatable)
> 
> Well, it is not plain 100 bytes leaked.
> It is rather an absolutely impossible event, which cannot happen
> even if all the bits leaked. 8)
> 
> OK... Audit is started.

Just FYI, as I already stated, machine is SMP. When assertion happened,
there was running tcpdump catching all frames to file, in addition to 
usual stuff (arpwatch, bind, apache, ntpd and slapd (Service Location 
Protocol daemon from Novell).
                                        Thanks,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                

From owner-netdev@oss.sgi.com Fri Nov 24 00:00:52 2000
Received:  by oss.sgi.com id <S553796AbQKXIAm>;
	Fri, 24 Nov 2000 00:00:42 -0800
Received: from kogge.hanse.de ([192.76.134.17]:34824 "EHLO kogge.Hanse.DE")
	by oss.sgi.com with ESMTP id <S553744AbQKXIAP>;
	Fri, 24 Nov 2000 00:00:15 -0800
Received: (from uucp@localhost)
	by kogge.Hanse.DE (8.9.3/8.9.1) with UUCP id JAA16293;
	Fri, 24 Nov 2000 09:00:04 +0100 (CET)
	(envelope-from eis@baty.hanse.de)
Received: (from eis@localhost)
	by baty.hanse.de (8.9.3/8.9.3) id UAA05547;
	Thu, 23 Nov 2000 20:31:26 +0100
To:     Ben Greear <greearb@candelatech.com>
cc:     netdev@oss.sgi.com
Subject: Re: sk->user_data
References: <200011212222.XAA03012@baty.hanse.de> <3A1C6CDF.CA7A1F4A@candelatech.com>
From:   Henner Eisen <eis@baty.hanse.de>
Date:   23 Nov 2000 20:31:26 +0100
In-Reply-To: Ben Greear's message of "Wed, 22 Nov 2000 18:03:27 -0700"
Message-ID: <ouitpe7aep.fsf@baty.hanse.de>
Lines:  29
X-Mailer: Gnus v5.5/Emacs 20.3
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

>>>>> "Ben" == Ben Greear <greearb@candelatech.com> writes:

    Ben> Henner Eisen wrote:
    >>  Hi,
    >> 
    >> 2.4.0 struct sock contains a member
    >> 
    >> void *user_data;
    >> 
    >> which is currently only used for pointing to an in-kernel RPC
    >> layer control block.
    >> 
    >> Is it o.k. to use this pointer for alternative upper layer or
    >> would that be a bad idea?

    Ben> I've been thinking that if we used unions instead of all the
    Ben> void*, then it might be more obvious what the use of the
    Ben> variable is (in the using code), and could be (when looking
    Ben> at net_dev.h).

Yes, good idea. Well, most of struct sock (outside the protocol-specific
unions} is obviously really generic. But there is apparently some
PF_INET specific data (the __u16 and __u32 typed fields related to ipv4
address and ports) in struct sock which does not even use void*.
Maybe this can also reasonnably be re-used for similar purpose by other
protocol families.

Henner


From owner-netdev@oss.sgi.com Fri Nov 24 13:50:57 2000
Received:  by oss.sgi.com id <S553804AbQKXVus>;
	Fri, 24 Nov 2000 13:50:48 -0800
Received: from zikova.cvut.cz ([147.32.235.100]:36366 "EHLO zikova.cvut.cz")
	by oss.sgi.com with ESMTP id <S553778AbQKXVuX>;
	Fri, 24 Nov 2000 13:50:23 -0800
Received: from vcnet.vc.cvut.cz (vcnet.vc.cvut.cz [147.32.240.61])
	by zikova.cvut.cz (8.9.0.Beta5/8.9.0.Beta5) with ESMTP id WAA52186;
	Fri, 24 Nov 2000 22:50:13 +0100
Received: from VCNET/SpoolDir by vcnet.vc.cvut.cz (Mercury 1.21);
    24 Nov 100 22:50:14 MET-1MEST
Received: from SpoolDir by VCNET (Mercury 1.30); 24 Nov 100 22:49:50 MET-1MEST
From:   "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
Organization:  CC CTU Prague
To:     kuznet@ms2.inr.ac.ru
Date:          Fri, 24 Nov 2000 22:49:49 MET-1
MIME-Version:  1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject:       Re: 2.4.0-test11 and af_inet.c(164)
CC:     netdev@oss.sgi.com
X-mailer: Pegasus Mail v3.40
Message-ID: <DCD42DC4A30@vcnet.vc.cvut.cz>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On 24 Nov 00 at 0:06, Petr Vandrovec wrote:
> > OK... Audit is started.
> 
> Just FYI, as I already stated, machine is SMP. When assertion happened,
> there was running tcpdump catching all frames to file, in addition to 
> usual stuff (arpwatch, bind, apache, ntpd and slapd (Service Location 
> Protocol daemon from Novell).

Hi,
  I got warning message about af_inet.c(164) again. After few seconds
it was followed by oops below. 

  Probably someone set sk->sleep == NULL during schedule_timeout().
But this should not happen, should it? Someone doing 
memset(random, 0, random) in kernel?
                                            Best regards,
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz
                                                    
Nov 24 22:24:10 vana kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Nov 24 22:24:10 vana kernel: c0118ce6
Nov 24 22:24:10 vana kernel: *pde = 00000000
Nov 24 22:24:10 vana kernel: Oops: 0002
Nov 24 22:24:10 vana kernel: CPU:    1
Nov 24 22:24:10 vana kernel: EIP:    0010:[remove_wait_queue+6/36]
Nov 24 22:24:10 vana kernel: EFLAGS: 00010086
Nov 24 22:24:10 vana kernel: eax: 00000286   ebx: 00000000   ecx: 00000011   edx: c712ddec
Nov 24 22:24:10 vana kernel: esi: c712ddec   edi: cae729a0   ebp: c712de20   esp: c712ddc4
Nov 24 22:24:10 vana kernel: ds: 0018   es: 0018   ss: 0018
Nov 24 22:24:10 vana kernel: Process ping (pid: 3948, stackpage=c712d000)
Nov 24 22:24:10 vana kernel: Stack: ffffff95 c01a6ec6 00000246 cae729a0 cae729f4 c712de4c 00000000 c712c000 
Nov 24 22:24:10 vana kernel:        00000000 00000000 00000001 c712c000 cc868a6c cc868a6c c01a6fdc cae729a0 
Nov 24 22:24:10 vana kernel:        c712de4c c712de20 00000000 cae729a0 000000c0 c712df6c 00000000 7fffffff 
Nov 24 22:24:10 vana kernel: Call Trace: [wait_for_packet+230/300] [skb_recv_datagram+208/240] [raw_recvmsg+104/308] [inet_recvmsg+88/112] [sock_recvmsg+61/172] [sys_recvfrom+173/264] [do_page_fault+323/1000] 
Nov 24 22:24:10 vana kernel:        [<dcf02093>] [do_page_fault+0/1000] [do_mmap_pgoff+895/1044] [do_getitimer+156/164] [sys_socketcall+383/508] [system_call+51/56] 
Nov 24 22:24:10 vana kernel: Code: f0 fe 0b 0f 88 25 29 0c 00 8b 4a 0c 8b 52 08 89 4a 04 89 11 
Using defaults from ksymoops -t elf32-i386 -a i386

Trace; dcf02093 <END_OF_CODE+a600478/????>
Code;  00000000 Before first symbol
0000000000000000 <_EIP>:
Code;  00000000 Before first symbol
   0:   f0 fe 0b                  lock decb (%ebx)
Code;  00000003 Before first symbol
   3:   0f 88 25 29 0c 00         js     c292e <_EIP+0xc292e> 000c292e Before first symbol
Code;  00000009 Before first symbol
   9:   8b 4a 0c                  mov    0xc(%edx),%ecx
Code;  0000000c Before first symbol
   c:   8b 52 08                  mov    0x8(%edx),%edx
Code;  0000000f Before first symbol
   f:   89 4a 04                  mov    %ecx,0x4(%edx)
Code;  00000012 Before first symbol
  12:   89 11                     mov    %edx,(%ecx)


From owner-netdev@oss.sgi.com Sun Nov 26 08:08:24 2000
Received:  by oss.sgi.com id <S553863AbQKZQID>;
	Sun, 26 Nov 2000 08:08:03 -0800
Received: from chmls06.mediaone.net ([24.147.1.144]:8685 "EHLO
        chmls06.mediaone.net") by oss.sgi.com with ESMTP id <S553664AbQKZQHh>;
	Sun, 26 Nov 2000 08:07:37 -0800
Received: from toto (h00105aa6df30.ne.mediaone.net [24.218.216.100])
	by chmls06.mediaone.net (8.8.7/8.8.7) with SMTP id LAA12548
	for <netdev@oss.sgi.com>; Sun, 26 Nov 2000 11:07:34 -0500 (EST)
Message-ID: <002701c057c3$c22863c0$64d8da18@toto>
From:   "Murtaza Amiji" <kijana@mediaone.net>
To:     <netdev@oss.sgi.com>
Subject: How to access route table ?
Date:   Sun, 26 Nov 2000 11:13:04 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi,

I am writing a network device driver for an IP telephony board and one of
the requirements in this driver is to fetch route table entries for gateway
address for the device and pass it to the board.  Conventional network
drivers don't have to deal with IP stuff which is why device driver
structures don't mention much about IP information.  I have search through
the kernel network code but failed to determine how I can read this
information from my device driver.  Can someone please tell me how I can do
this.

Thank you

- Murtaza



From owner-netdev@oss.sgi.com Mon Nov 27 02:32:00 2000
Received:  by oss.sgi.com id <S553837AbQK0Kbk>;
	Mon, 27 Nov 2000 02:31:40 -0800
Received: from mean.netppl.fi ([195.242.208.16]:1298 "EHLO mean.netppl.fi")
	by oss.sgi.com with ESMTP id <S553831AbQK0KbW>;
	Mon, 27 Nov 2000 02:31:22 -0800
Received: from evil.netppl.fi (root@evil.netppl.fi [195.242.209.201])
	by mean.netppl.fi (8.9.3/8.9.3) with ESMTP id MAA04436
	for <netdev@oss.sgi.com>; Mon, 27 Nov 2000 12:31:09 +0200
Received: (from pp@localhost)
	by evil.netppl.fi (8.9.3/8.9.3) id MAA08475
	for netdev@oss.sgi.com; Mon, 27 Nov 2000 12:31:09 +0200
Date:   Mon, 27 Nov 2000 12:31:08 +0200
From:   Pekka Pietikainen <pp@netppl.fi>
To:     netdev@oss.sgi.com
Subject: linux to solaris tcp issues on WAN
Message-ID: <20001127123108.A7599@netppl.fi>
References: <Pine.LNX.4.21.0011271109450.23417-100000@lxplus001.cern.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
In-Reply-To: <Pine.LNX.4.21.0011271109450.23417-100000@lxplus001.cern.ch>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi

A co-worker is having performance problems when doing Linux to Solaris
transfers on WAN's. 

> -------- Original Message --------
> Subject: linux to solaris tcp issues
> Date: Fri, 24 Nov 2000 16:05:57 +0100
> From: Brian Tierney <bltierney@lbl.gov>
> Organization: CERN/LBNL
>  
> 
> Hello all:
> 
> I have noticed a rather dramatic performance problem with TCP with
> a Linux sender and a non-Linux receiver, and wonder if this is a known
> problem, and if there is a solution.  Higher latency and/or higher
> congestion makes the problem worse.
> 
> 
> Here are some results:
> 
> local 100BT network: Linux to Solaris = Solaris to Linux = 90 Mbps
>                      (i.e.: no problems (also no congestion))
> 
> ANL to LBL (45 ms RTT): Linux to Linux: 50 Mbps
>                         Solaris to Linux: 50 Mbps
>                         Linux to Solaris: 3 Mbps
> 		
> 
> LBL to CERN: (180 ms RTT) : Linux to Linux: 25 Mbps
>                             Solaris to Linux: 25 Mbps
>                             Linux to Solaris: .5 Mbps
>                             Linux to FreeBSD: .5 Mbps
> 			    Solaris to solaris: 25 Mbps
> 
> 
> I have tested this with Linux 2.2.12, 2.2.14, 2.2.16, 2.2.17 and
> 2.4.0-test6 kernels on the sender, and Solaris 2.6 and 2.7 for the 
> receiver, and the results are the same.   
> 
> I am using iperf for the testing, and have triple checked that the TCP
> buffers are set correctly. http://dast.nlanr.net/Projects/Iperf/index.html
> 
> 
> For a sample tcpdump output showing this, see:
> http://www-didc.lbl.gov/tierney/tmp/tcpdump-solaris-vs-linux.out.gz
> 
> This file has 2 simultaneous streams from a linux box, 1 to a linux and the
> other to a
> solaris host.
> 
> The important tcptrace output files for this run are:
> http://www-didc.lbl.gov/tierney/tmp/linux-to-linux.xpl.gz
> http://www-didc.lbl.gov/tierney/tmp/linux-to-solaris.xpl.gz
> 
> 
> Thanks for any insight you might have into this. I can't believe that this
> isn't a more well-known issue.
> 
> 
> 
> -------- Original Message --------
> Subject: Re: linux to solaris tcp issues
> Date: Fri, 24 Nov 2000 10:08:37 PST
> From: Vern Paxson <vern@ee.lbl.gov>
> To: Brian Tierney <bltierney@lbl.gov>
>  
> 
> Well, the problem is that the sender is miscomputing its RTO, setting it to
> a value that's much too low (according to the standard).  This appears to
> work Linux-Linux because the Linux delayed ack is very small (also not a
> good idea!).  Solaris uses a larger delayed ack (looks like around 50 msec,
> still quite small) and that's enough to push the RTT above the RTO.  This
> just needs to happen once when you have a lot of data in flight and its
> disaster, the entire flight gets retransmitted and the congestion response
> is drastic.
>  
> > (Sorry if this is a well know problem with a well known
> > solution. If so, let me know!).
> 
> Not that I know of, though I agree you'd think it would be.  A while ago
> there was a similar sort of bug in Solaris (ironically) that wasn't widely
> known, either, even though it spelled disaster any time the RTT got above a
> couple hundred msec.
> 
> 		Vern
> 
> 
> -- 
> ------------------------------------------------------------------------
>   Brian L. Tierney,   Lawrence Berkeley National Laboratory (LBNL)
>   1 Cyclotron Rd.  MS: 50B-2239,  Berkeley, CA  94720
>   tel: 510-486-7381    fax: 510-495-2998   efax: 603-719-5047
>   bltierney@lbl.gov   http://www-didc.lbl.gov/~tierney
> 
>  currently on leave from LBNL to CERN:
>   CERN, IT/PDP, Bldg 31, 2-013, 1211 Geneva 23, Switzerland
>   tel: +41 22 76 74543  fax: +41 22 76 77155
> ------------------------------------------------------------------------

-- 
Pekka Pietikainen




From owner-netdev@oss.sgi.com Mon Nov 27 04:13:49 2000
Received:  by oss.sgi.com id <S553840AbQK0MNa>;
	Mon, 27 Nov 2000 04:13:30 -0800
Received: from mean.netppl.fi ([195.242.208.16]:261 "EHLO mean.netppl.fi")
	by oss.sgi.com with ESMTP id <S553838AbQK0MNK>;
	Mon, 27 Nov 2000 04:13:10 -0800
Received: from evil.netppl.fi (root@evil.netppl.fi [195.242.209.201])
	by mean.netppl.fi (8.9.3/8.9.3) with ESMTP id OAA05610
	for <netdev@oss.sgi.com>; Mon, 27 Nov 2000 14:12:57 +0200
Received: (from pp@localhost)
	by evil.netppl.fi (8.9.3/8.9.3) id OAA12984
	for netdev@oss.sgi.com; Mon, 27 Nov 2000 14:12:57 +0200
Date:   Mon, 27 Nov 2000 14:12:57 +0200
From:   Pekka Pietikainen <pp@netppl.fi>
To:     netdev@oss.sgi.com
Subject: Re: linux to solaris tcp issues on WAN
Message-ID: <20001127141257.A11000@netppl.fi>
References: <Pine.LNX.4.21.0011271109450.23417-100000@lxplus001.cern.ch> <20001127123108.A7599@netppl.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
In-Reply-To: <20001127123108.A7599@netppl.fi>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Nov 27, 2000 at 12:31:08PM +0200, Pekka Pietikainen wrote:
> Hi
> 
> A co-worker is having performance problems when doing Linux to Solaris
> transfers on WAN's. 
> 
Seems to be fixed by patches in Alexey's zerocopy diff
(Tested only on a box with 10baseT though, I'll try to backport the changes
to 2.2 and test this on the boxes he had problems with, the pipe
certainly can handle quite a bit more than 10Mbps even though it's 
transatlantic ;) )

Not related to zerocopy:

* rtt is calculated not by the last acked packet, but the earlier one.
* tcp_input has hole allowing to cancel backoff even if not retransmitted
  data was acked.
  [ After some discussion with Andrey Gurtov. He proposed to relax Karn
    algo, to be honest. 8) Well, and result is more strong. ]

From owner-netdev@oss.sgi.com Mon Nov 27 04:14:00 2000
Received:  by oss.sgi.com id <S553865AbQK0MNt>;
	Mon, 27 Nov 2000 04:13:49 -0800
Received: from [202.130.239.186] ([202.130.239.186]:14087 "HELO sp1.elong.com")
	by oss.sgi.com with SMTP id <S553839AbQK0MNk>;
	Mon, 27 Nov 2000 04:13:40 -0800
Received: from netemon (unknown [202.108.19.66])
	by sp1.elong.com (eLongMail) with SMTP id 0B0E48F288
	for <netdev@oss.sgi.com>; Mon, 27 Nov 2000 20:09:30 +0800 (CST)
From:   "sun6789" <sun6789@elong.com>
To:     <netdev@oss.sgi.com>
Subject: Need Help
Date:   Mon, 27 Nov 2000 20:13:58 +0800
Message-ID: <LPBBICMAFKGHPMIHMLNLKEDFCAAA.sun6789@elong.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

SSBhbSBhIGxpbnV4IGxvdmVyIGZyb20gQ2hpbmEuIEkgYW0gaW50ZXJlc3RlZCBpbiBwYWNrZXQg
d2l0aCBtbWFwLg0KQ291bGQgeW91IGdpdmUgbWUgc29tZSBleGFtcGxlcyBhbmQgYWR2aWNlcyBm
b3IgUEFDS0VUX01NQVA/DQpUaGFuayB5b3UgdmVyeSBtdWNoISA=


From owner-netdev@oss.sgi.com Mon Nov 27 04:14:00 2000
Received:  by oss.sgi.com id <S553839AbQK0MNt>;
	Mon, 27 Nov 2000 04:13:49 -0800
Received: from [202.130.239.186] ([202.130.239.186]:13319 "HELO sp1.elong.com")
	by oss.sgi.com with SMTP id <S553838AbQK0MNk>;
	Mon, 27 Nov 2000 04:13:40 -0800
Received: from netemon (unknown [202.108.19.66])
	by sp1.elong.com (eLongMail) with SMTP id 583F58F289
	for <netdev@oss.sgi.com>; Mon, 27 Nov 2000 20:09:25 +0800 (CST)
From:   "sun6789" <sun6789@elong.com>
To:     <netdev@oss.sgi.com>
Subject: Need Help!
Date:   Mon, 27 Nov 2000 20:13:57 +0800
Message-ID: <LPBBICMAFKGHPMIHMLNLIEDFCAAA.sun6789@elong.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

DQpJIGFtIGEgbGludXggbG92ZXIgZnJvbSBDaGluYS4gSSBhbSBpbnRlcmVzdGVkIGluIHBhY2tl
dCB3aXRoIG1tYXAuDQpDb3VsZCB5b3UgZ2l2ZSBtZSBhIGV4YW1wbGUgYW5kIGFkdmljZSBmb3Ig
UEFDS0VUX01NQVA/DQpUaGFuayB5b3UgdmVyeSBtdWNoISA=


From owner-netdev@oss.sgi.com Mon Nov 27 13:49:33 2000
Received:  by oss.sgi.com id <S553686AbQK0VtW>;
	Mon, 27 Nov 2000 13:49:22 -0800
Received: from p3EE1EE54.dip.t-dialin.net ([62.225.238.84]:16392 "EHLO master")
	by oss.sgi.com with ESMTP id <S553652AbQK0VtE>;
	Mon, 27 Nov 2000 13:49:04 -0800
Received: from udo by master with local (Exim 3.16 #1 (Debian))
	id 140XH6-00005k-00; Tue, 28 Nov 2000 00:01:28 +0100
Date:   Tue, 28 Nov 2000 00:01:26 +0100
From:   Udo Held <udo@udoheld.de>
To:     linux-kernel@vger.kernel.org, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: Hardware recognization error on Davicom 9102 with Tulip DS21140 driver
Message-ID: <20001128000125.A295@udoheld.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi!

I didn't know which driver was the right one for my network card so I
just compiled all network-card drivers that where listed into my kernel
I tried it with test9 and test11. The DS21140 Tulip driver found my card
and crashes the system during boot up. My card is a Davicom 9102(?). It's
working fine with the right driver.

I give you the cutted output of lspci -m and lspci -vvv

lspci -m:

Device: 00:09.0
Class:  Ethernet controller
Vendor: Davicom Semiconductor, Inc.
Device: Ethernet 100/10 MBit
SVendor:        1282
SDevice:        9102
Rev:    31

lspci -vvv

00:09.0 Ethernet controller: Davicom Semiconductor, Inc. Ethernet 100/10 MBit (rev 31)
Subsystem: Unknown device 4554:434e
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (5000ns min, 10000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 6100 [size=256]
Region 1: Memory at f4000000 (32-bit, non-prefetchable) [size=256]
Expansion ROM at <unassigned> [disabled] [size=256K]
Capabilities: [50] Power Management version 1
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-

I will send this mail to:

linux@vger.kernel.org
linux-net@vger.kernel.org
netdev@oss.sgi.com

I'm not in any of these lists anymore, because the digest service is
not offered anymore. :-(%

Questions are welcome.

Cheers,
Udo

From owner-netdev@oss.sgi.com Mon Nov 27 15:17:53 2000
Received:  by oss.sgi.com id <S553759AbQK0XRo>;
	Mon, 27 Nov 2000 15:17:44 -0800
Received: from p3EE1EE54.dip.t-dialin.net ([62.225.238.84]:53001 "EHLO master")
	by oss.sgi.com with ESMTP id <S553736AbQK0XR0>;
	Mon, 27 Nov 2000 15:17:26 -0800
Received: from udo by master with local (Exim 3.16 #1 (Debian))
	id 140Yen-0000Um-00; Tue, 28 Nov 2000 01:30:01 +0100
Date:   Tue, 28 Nov 2000 01:30:01 +0100
From:   Udo Held <udo@udoheld.de>
To:     linux-kernel@vger.kernel.org, linux-net@vger.kernel.org,
        netdev@oss.sgi.com
Subject: [udo@udoheld.de: Hardware recognization error on Davicom 9102 with Tulip DS21140 driver]
Message-ID: <20001128013001.A1459@udoheld.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

---- Forwarded message from Udo Held <udo@udoheld.de> -----

Date: Tue, 28 Nov 2000 00:01:26 +0100
From: Udo Held <udo@udoheld.de>
To: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org,
	netdev@oss.sgi.com
Subject: Hardware recognization error on Davicom 9102 with Tulip DS21140 driver
User-Agent: Mutt/1.2.5i

> Hi!
> 
> I didn't know which driver was the right one for my network card so I
> just compiled all network-card drivers that where listed into my kernel
> I tried it with test9 and test11. The DS21140 Tulip driver found my card
> and crashes the system during boot up. My card is a Davicom 9102(?). It's
> working fine with the right driver.

The system crashes with an oops. I'm not able
to copy and paste it without pencil and paper, because it's hanging
during booting up. If you really need that output please tell me.
Imo you should just fix that the Tulip driver thinks there is a card
with a DS21140 chipset.

I'm using the right experimental driver and it's working. So please 
don't mail me about using the right driver.

[..]

Cheers,
Udo

From owner-netdev@oss.sgi.com Tue Nov 28 07:29:55 2000
Received:  by oss.sgi.com id <S553671AbQK1P3q>;
	Tue, 28 Nov 2000 07:29:46 -0800
Received: from xerxes.thphy.uni-duesseldorf.de ([134.99.64.10]:5041 "EHLO
        xerxes.thphy.uni-duesseldorf.de") by oss.sgi.com with ESMTP
	id <S553663AbQK1P31>; Tue, 28 Nov 2000 07:29:27 -0800
Received: from chaos.thphy.uni-duesseldorf.de (IDENT:root@chaos [134.99.64.99])
	by xerxes.thphy.uni-duesseldorf.de (8.9.3/8.9.3) with ESMTP id QAA11246
	for <netdev@oss.sgi.com>; Tue, 28 Nov 2000 16:28:56 +0100 (MET)
Received: from localhost (kai@localhost)
	by chaos.thphy.uni-duesseldorf.de (8.9.3/8.8.7) with ESMTP id QAA32252
	for <netdev@oss.sgi.com>; Tue, 28 Nov 2000 16:29:25 +0100
X-Authentication-Warning: chaos.thphy.uni-duesseldorf.de: kai owned process doing -bs
Date:   Tue, 28 Nov 2000 16:29:25 +0100 (CET)
From:   Kai Germaschewski <kai@thphy.uni-duesseldorf.de>
To:     netdev@oss.sgi.com
Subject: strange dial-up problem
Message-ID: <Pine.LNX.4.10.10011281617290.25387-100000@chaos.thphy.uni-duesseldorf.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

	
Hi!

I'm encountering strange behaviour when dialing up to my ISP.

I'm using syncPPP over ISDN, so I have a device ippp0 and an
ipppd (isdn variant of pppd) doing negotiations.

I also have a private LAN, i.e. eth0 192.168.10.1.

When I'm not online, I had set ippp0's ip addr to 127.0.0.1.
When dialing up, the address of ippp0 (and the p2p address) are
changed to the values ipppd negotiates, ifconfig ippp0 verifies that.
Then, also a default route via ippp0 gw p2p address is setup.

I can ping the p2p addr just fine. However, when pinging some other
address (or trying to establish a TPC connection), that doesn't work.

tcpdump shows packets going out via ippp2, but with an source address
of 192.168.10.1, i.e. eth0's address - not ippp0's. So it's not exactly
suprising that I never get an answer back.

However, when I set ippp0's address to a non-local address from the start,
e.g. to 192.168.11.1, everything works fine (it's changed to the
negotiated address as before, and now the packets get the right source
address and everything works).

This happened on 2.4.0test11, but I believe also on 2.2.18pre - didn't
tcpdump then, though.

I suppose ipppd is doing something wrong when changing addresses or so,
but before investigating myself I thought somebody might have the answer
handy here.

--Kai



From owner-netdev@oss.sgi.com Wed Nov 29 17:34:42 2000
Received:  by oss.sgi.com id <S553763AbQK3BeW>;
	Wed, 29 Nov 2000 17:34:22 -0800
Received: from laurin.munich.netsurf.de ([194.64.166.1]:652 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S553779AbQK3BeN>; Wed, 29 Nov 2000 17:34:13 -0800
Received: from fred.muc.de (noidentity@ns1152.munich.netsurf.de [195.180.235.152])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id CAA17856;
	Thu, 30 Nov 2000 02:34:10 +0100 (MET)
Received: by fred.muc.de (Postfix, from userid 500)
	id 05711E3914; Tue, 28 Nov 2000 20:29:38 +0100 (CET)
Date:   Tue, 28 Nov 2000 20:29:38 +0100
From:   Andi Kleen <ak@muc.de>
To:     Kai Germaschewski <kai@thphy.uni-duesseldorf.de>
Cc:     netdev@oss.sgi.com
Subject: Re: strange dial-up problem
Message-ID: <20001128202938.A3100@fred.local>
References: <Pine.LNX.4.10.10011281617290.25387-100000@chaos.thphy. uni-duesseldorf.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.LNX.4.10.10011281617290.25387-100000@chaos.thphy. uni-duesseldorf.de>; from kai@thphy.uni-duesseldorf.de on Tue, Nov 28, 2000 at 04:30:50PM +0100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Tue, Nov 28, 2000 at 04:30:50PM +0100, Kai Germaschewski wrote:
> 
> However, when I set ippp0's address to a non-local address from the start,
> e.g. to 192.168.11.1, everything works fine (it's changed to the
> negotiated address as before, and now the packets get the right source
> address and everything works).
> 
> This happened on 2.4.0test11, but I believe also on 2.2.18pre - didn't
> tcpdump then, though.
> 
> I suppose ipppd is doing something wrong when changing addresses or so,
> but before investigating myself I thought somebody might have the answer
> handy here.

Try echo 0 > /proc/sys/net/ipv4/ip_dynaddr

-Andi

-- 
This is like TV. I don't like TV.

From owner-netdev@oss.sgi.com Thu Nov 30 03:46:55 2000
Received:  by oss.sgi.com id <S553839AbQK3Lqq>;
	Thu, 30 Nov 2000 03:46:46 -0800
Received: from mean.netppl.fi ([195.242.208.16]:43279 "EHLO mean.netppl.fi")
	by oss.sgi.com with ESMTP id <S553833AbQK3Lqa>;
	Thu, 30 Nov 2000 03:46:30 -0800
Received: from evil.netppl.fi (root@evil.netppl.fi [195.242.209.201])
	by mean.netppl.fi (8.9.3/8.9.3) with ESMTP id NAA08917
	for <netdev@oss.sgi.com>; Thu, 30 Nov 2000 13:46:16 +0200
Received: (from pp@localhost)
	by evil.netppl.fi (8.9.3/8.9.3) id NAA21192
	for netdev@oss.sgi.com; Thu, 30 Nov 2000 13:46:15 +0200
Date:   Thu, 30 Nov 2000 13:46:15 +0200
From:   Pekka Pietikainen <pp@netppl.fi>
To:     netdev@oss.sgi.com
Subject: Re: linux to solaris tcp issues on WAN
Message-ID: <20001130134615.A20456@netppl.fi>
References: <Pine.LNX.4.21.0011271109450.23417-100000@lxplus001.cern.ch> <20001127123108.A7599@netppl.fi> <20001127141257.A11000@netppl.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
In-Reply-To: <20001127141257.A11000@netppl.fi>
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Mon, Nov 27, 2000 at 02:12:57PM +0200, Pekka Pietikainen wrote:
> On Mon, Nov 27, 2000 at 12:31:08PM +0200, Pekka Pietikainen wrote:
> > Hi
> > 
> > A co-worker is having performance problems when doing Linux to Solaris
> > transfers on WAN's. 
> > 
> Seems to be fixed by patches in Alexey's zerocopy diff
> (Tested only on a box with 10baseT though, I'll try to backport the changes
> to 2.2 and test this on the boxes he had problems with, the pipe
> certainly can handle quite a bit more than 10Mbps even though it's 
> transatlantic ;) )

The problem is also fixed with 2.4.0-test12pre3 (this time running on the same
machine he had problems with):

[  3] local 137.138.225.101 port 32769 connected with 131.243.2.109 port
6003
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 5.0 sec  10.6 MBytes  16.9 Mbits/sec
[  3]  5.0-10.9 sec  21.7 MBytes  29.8 Mbits/sec
[  3] 10.9-15.0 sec  11.2 MBytes  21.4 Mbits/sec
[  3] 15.0-20.1 sec  14.4 MBytes  23.0 Mbits/sec
[  3] 20.1-25.0 sec  14.8 MBytes  23.7 Mbits/sec
[  3] 25.0-30.1 sec  14.8 MBytes  23.2 Mbits/sec
[  3] 30.1-35.1 sec   7.8 MBytes  12.6 Mbits/sec
[  3] 35.1-40.8 sec   3.8 MBytes   5.3 Mbits/sec
[  3] 40.8-45.3 sec   2.6 MBytes   4.5 Mbits/sec
[  3] 45.3-50.6 sec   3.7 MBytes   5.5 Mbits/sec
[  3] 50.6-55.3 sec   3.7 MBytes   6.3 Mbits/sec
[  3] 55.3-60.5 sec   4.8 MBytes   7.3 Mbits/sec
[  3]  0.0-61.7 sec   114 MBytes  14.8 Mbits/sec

A fix for 2.2 would be nice, though. I did some modifications to 2.2 based
on the 2.4 changes, but only managed to get a very small improvement (and
after even further changes a mostly non-functioning TCP ;) )

From owner-netdev@oss.sgi.com Thu Nov 30 05:46:17 2000
Received:  by oss.sgi.com id <S553720AbQK3Np6>;
	Thu, 30 Nov 2000 05:45:58 -0800
Received: from tufnell.poggs.com ([193.118.189.50]:35087 "EHLO
        tufnell.poggs.com") by oss.sgi.com with ESMTP id <S553672AbQK3Npe>;
	Thu, 30 Nov 2000 05:45:34 -0800
Received: from localhost (pwh@localhost)
	by tufnell.poggs.com (8.11.0/8.10.2/poggs-1.1-inet) with ESMTP id eAUDkMJ03241;
	Thu, 30 Nov 2000 13:46:23 GMT
Date:   Thu, 30 Nov 2000 13:46:22 +0000 (GMT)
From:   Peter Hicks <pwh@tufnell.poggs.com>
To:     netdev@oss.sgi.com, davem@redhat.com, ak@muc.de,
        kuznet@ms2.inr.ac.ru
cc:     cc@poggs.co.uk
Subject: 2.4.0-test11 - broken UDP?
Message-ID: <Pine.LNX.4.21.0011301342280.3207-100000@tufnell.poggs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Hi there

The latest stable version of freeradius (www.freeradius.org) doesn't seem
to work properly on 2.4.0-test11, yet it worked fine on 2.4.0-test9.

Network sniffers show the RADIUS packets are leaving the Cisco routers in
question, and are getting to the segment the machine is on, but no
further.

I have a system here I can run tests on if it's of use - please let me
know, I'd be happy to help!. Additionally, I'm also compling a 2.2.17
kernel before I pop out for lunch to see if that 'fixes' the problem.




Peter.



From owner-netdev@oss.sgi.com Thu Nov 30 06:00:57 2000
Received:  by oss.sgi.com id <S553843AbQK3OAr>;
	Thu, 30 Nov 2000 06:00:47 -0800
Received: from a203-167-249-89.reverse.clear.net.nz ([203.167.249.89]:29451
        "HELO metastasis.f00f.org") by oss.sgi.com with SMTP
	id <S553725AbQK3OAd>; Thu, 30 Nov 2000 06:00:33 -0800
Received: by metastasis.f00f.org (Postfix, from userid 1000)
	id DA6929DAB; Fri,  1 Dec 2000 03:00:29 +1300 (NZDT)
Date:   Fri, 1 Dec 2000 03:00:29 +1300
From:   Chris Wedgwood <cw@f00f.org>
To:     sun6789 <sun6789@elong.com>
Cc:     netdev@oss.sgi.com
Subject: Re: Need Help
Message-ID: <20001201030029.A7960@metastasis.f00f.org>
References: <LPBBICMAFKGHPMIHMLNLKEDFCAAA.sun6789@elong.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <LPBBICMAFKGHPMIHMLNLKEDFCAAA.sun6789@elong.com>; from sun6789@elong.com on Mon, Nov 27, 2000 at 08:13:58PM +0800
X-No-Archive: Yes
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

Grab Alexeys diffs to libpcap from somewhere on
ftp://ftp.inr.au.ru/ip-routing/lbl-tools or easier still do as I have
and use libpcap (there is a slightly modified API for turbo+all
interfaces capturing mode)





  --cw


On Mon, Nov 27, 2000 at 08:13:58PM +0800, sun6789 wrote:
    I am a linux lover from China. I am interested in packet with mmap.
    Could you give me some examples and advices for PACKET_MMAP?
    Thank you very much! 

From owner-netdev@oss.sgi.com Thu Nov 30 06:02:37 2000
Received:  by oss.sgi.com id <S553849AbQK3OC1>;
	Thu, 30 Nov 2000 06:02:27 -0800
Received: from a203-167-249-89.reverse.clear.net.nz ([203.167.249.89]:29707
        "HELO metastasis.f00f.org") by oss.sgi.com with SMTP
	id <S553840AbQK3OCV>; Thu, 30 Nov 2000 06:02:21 -0800
Received: by metastasis.f00f.org (Postfix, from userid 1000)
	id E73949DAB; Fri,  1 Dec 2000 03:02:18 +1300 (NZDT)
Date:   Fri, 1 Dec 2000 03:02:18 +1300
From:   Chris Wedgwood <cw@f00f.org>
To:     Murtaza Amiji <kijana@mediaone.net>
Cc:     netdev@oss.sgi.com
Subject: Re: How to access route table ?
Message-ID: <20001201030218.B7960@metastasis.f00f.org>
References: <002701c057c3$c22863c0$64d8da18@toto>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <002701c057c3$c22863c0$64d8da18@toto>; from kijana@mediaone.net on Sun, Nov 26, 2000 at 11:13:04AM -0500
X-No-Archive: Yes
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

see /proc/net/route


  --cw

On Sun, Nov 26, 2000 at 11:13:04AM -0500, Murtaza Amiji wrote:
    Hi,
    
    I am writing a network device driver for an IP telephony board and one of
    the requirements in this driver is to fetch route table entries for gateway
    address for the device and pass it to the board.  Conventional network
    drivers don't have to deal with IP stuff which is why device driver
    structures don't mention much about IP information.  I have search through
    the kernel network code but failed to determine how I can read this
    information from my device driver.  Can someone please tell me how I can do
    this.
    
    Thank you
    
    - Murtaza
    
    

From owner-netdev@oss.sgi.com Thu Nov 30 13:44:01 2000
Received:  by oss.sgi.com id <S553905AbQK3Vnv>;
	Thu, 30 Nov 2000 13:43:51 -0800
Received: from lennier.cc.vt.edu ([198.82.161.193]:44036 "EHLO
        lennier.cc.vt.edu") by oss.sgi.com with ESMTP id <S553902AbQK3Vnh>;
	Thu, 30 Nov 2000 13:43:37 -0800
Received: from mail.vt.edu (gkar.cc.vt.edu [198.82.161.190])
	by lennier.cc.vt.edu (8.11.0/8.11.0) with ESMTP id eAULhZB133048
	for <netdev@oss.sgi.com>; Thu, 30 Nov 2000 16:43:35 -0500 (EST)
Received: from pavilion ([128.173.37.216])
 by gkar.cc.vt.edu (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10)
 with SMTP id <0G4U00AFCXOLRC@gkar.cc.vt.edu> for netdev@oss.sgi.com; Thu,
 30 Nov 2000 16:43:34 -0500 (EST)
Date:   Thu, 30 Nov 2000 16:47:32 -0700
From:   Tao Lin <taolin@vt.edu>
Subject: Question about Linux source code on network
To:     netdev@oss.sgi.com
Message-id: <002f01c05b27$e96d9920$2934ad80@pavilion>
MIME-version: 1.0
X-Mailer: Microsoft Outlook Express 5.00.2615.200
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Priority: 3
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

hi,

I am reading the source codes about Linux networking stuffs. Actually I want
to modify the routing policy so that my linux router can route datagram
based on the network interface, not source/destination IP address. Could you
tell me which set of codes I should take a look at? Thank you very much for
your help!

BTW: A simple example, a linux box with eth0, eth1, and eth2. I want to
route all packets from eth0 directly to eth1 and eth2, route all packets
from eth1 directory to eth2 and all packets from eth2 directly to eth1.
Thanks!

_____________________

           Tao Lin

2010/2015 Torgersen Hall
  Computer Network Lab
ECPE Dept. Virginia Tech.
    540-231-8347(O)
    540-961-2123(H)
     www.lintao.com
_____________________


From owner-netdev@oss.sgi.com Thu Nov 30 16:21:21 2000
Received:  by oss.sgi.com id <S553927AbQLAAVB>;
	Thu, 30 Nov 2000 16:21:01 -0800
Received: from laurin.munich.netsurf.de ([194.64.166.1]:55227 "EHLO
        laurin.munich.netsurf.de") by oss.sgi.com with ESMTP
	id <S553924AbQLAAUz>; Thu, 30 Nov 2000 16:20:55 -0800
Received: from fred.muc.de (noidentity@ns1191.munich.netsurf.de [195.180.235.191])
	by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id BAA15136;
	Fri, 1 Dec 2000 01:20:52 +0100 (MET)
Received: by fred.muc.de (Postfix, from userid 500)
	id CE220E3911; Fri,  1 Dec 2000 00:43:25 +0100 (CET)
Date:   Fri, 1 Dec 2000 00:43:25 +0100
From:   Andi Kleen <ak@muc.de>
To:     Tao Lin <taolin@vt.edu>
Cc:     netdev@oss.sgi.com
Subject: Re: Question about Linux source code on network
Message-ID: <20001201004325.A6588@fred.local>
References: <002f01c05b27$e96d9920$2934ad80@pavilion>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <002f01c05b27$e96d9920$2934ad80@pavilion>; from taolin@vt.edu on Thu, Nov 30, 2000 at 10:44:50PM +0100
Sender: owner-netdev@oss.sgi.com
Precedence: bulk
Return-Path: <owner-netdev@oss.sgi.com>
X-Orcpt: rfc822;netdev-outgoing

On Thu, Nov 30, 2000 at 10:44:50PM +0100, Tao Lin wrote:
> BTW: A simple example, a linux box with eth0, eth1, and eth2. I want to
> route all packets from eth0 directly to eth1 and eth2, route all packets
> from eth1 directory to eth2 and all packets from eth2 directly to eth1.
> Thanks!
You don't need to modify the linux source for that, the existing policy routing
already does that fine.

-Andi