From owner-freebsd-net  Sun Nov 25  4:20:59 2001
Delivered-To: freebsd-net@freebsd.org
Received: from quack.kfu.com (quack.kfu.com [205.178.90.194])
	by hub.freebsd.org (Postfix) with ESMTP id 0024337B417
	for <freebsd-net@freebsd.org>; Sun, 25 Nov 2001 04:20:47 -0800 (PST)
Received: from morpheus.kfu.com (morpheus.kfu.com [205.178.90.238])
	by quack.kfu.com (8.11.6/8.11.6) with ESMTP id fAPCKfD36996
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK)
	for <freebsd-net@freebsd.org>; Sun, 25 Nov 2001 04:20:42 -0800 (PST)
	(envelope-from nsayer@quack.kfu.com)
Received: from quack.kfu.com (nospam@localhost [::1])
	by morpheus.kfu.com (8.11.6/8.11.6) with ESMTP id fAPCKfH55943
	for <freebsd-net@freebsd.org>; Sun, 25 Nov 2001 04:20:41 -0800 (PST)
	(envelope-from nsayer@quack.kfu.com)
Message-ID: <3C00E219.30203@quack.kfu.com>
Date: Sun, 25 Nov 2001 04:20:41 -0800
From: Nick Sayer <nsayer@quack.kfu.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.5) Gecko/20011112
X-Accept-Language: en, en-US, en-GB
MIME-Version: 1.0
To: freebsd-net@freebsd.org
Subject: Help! if_dc is driving me insane
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

I have a Znyx quad 21143 card.

dc0: <Intel 21143 10/100BaseTX> port 0xd800-0xd87f mem 
0xdf000000-0xdf0003ff irq 12 at device 4.0 on pci2
dc0: Ethernet address: 00:c0:95:e1:af:10
miibus0: <MII bus> on dc0
dcphy0: <Intel 21143 NWAY media interface> on miibus0
dcphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

(the other 3 ports look pretty much the same)

None of the ports on this card will in any way correctly connect to a 
10baseT half duplex hub. I have to lie and tell it that it's connecting 
at full-duplex, which sort of works, but drops lots of frames.

I have poked around the driver trying to fix this, but have utterly failed.

There are at least two different code paths that appear to be being used 
to fiddle with the registers pertaining to this. One code path is in 
/sys/pci/if_dc.c, the other is in /sys/dev/mii/dcphy.c. Both code paths 
appear to do the same sorts of operations in a different order. Both, 
according to my tombstoning, are actually being used :-( . The bit in 
if_dc.c leaves out setting or clearing DC_NETCFG_FULLDUPLEX (but having 
it do that does not fix the problem), and both code paths appear to me 
to be using the wrong constant for DC_10BTCTRL. The Intel datasheet does 
indeed says 0x7F3F, but I don't see why the correct value isn't 0x7F7D 
(0x7F3F does not set the half-duplex bit, but turns on internal loopback 
instead, according to the datasheet). Changing this value doesn't appear 
to fix it either.

I am left to ponder the purpose of dc_apply_fixup(), which appears to do 
things that are so mysterious that I can do nothing but throw my hands 
up in defeat and dispair.

I tried looking at the NetBSD driver, but it is also maze twisty of 
alike a passages all.

Oh, and for extra credit, the LEDs on the card don't work right either. 
But I don't even care about that so long as "ifconfig dc2 media 
10baseT/UTP" would just do the right thing.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Sun Nov 25 16: 4:11 2001
Delivered-To: freebsd-net@freebsd.org
Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106])
	by hub.freebsd.org (Postfix) with ESMTP id 1809837B416
	for <freebsd-net@freebsd.org>; Sun, 25 Nov 2001 16:04:07 -0800 (PST)
Received: (from uucp@localhost)
	by srv1.cosmo-project.de (8.11.0/8.11.0) with UUCP id fAQ044U32294
	for freebsd-net@freebsd.org; Mon, 26 Nov 2001 01:04:04 +0100 (CET)
Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22])
	by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id fAQ04Gp1050659
	for <freebsd-net@freebsd.org>; Mon, 26 Nov 2001 01:04:16 +0100 (CET)?g
	(envelope-from ticso@cicely8.cicely.de)
Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10])
	by mail.cicely.de (8.11.0/8.11.0) with ESMTP id fAQ04BL09776
	for <freebsd-net@freebsd.org>; Mon, 26 Nov 2001 01:04:15 +0100 (CET)
Received: (from ticso@localhost)
	by cicely8.cicely.de (8.11.4/8.11.4) id fAQ04AR98958
	for freebsd-net@freebsd.org; Mon, 26 Nov 2001 01:04:10 +0100 (CET)
	(envelope-from ticso)
Date: Mon, 26 Nov 2001 01:04:09 +0100
From: Bernd Walter <ticso@cicely8.cicely.de>
To: freebsd-net@freebsd.org
Subject: setkey unaligned access on alpha-4.4-stable and -current
Message-ID: <20011126010408.D72247@cicely8.cicely.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.23i
X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

I already wrote this on -alpha two days ago.
Maybe the ipsec developers don't read -alpha.

bernd@srv1.cosmo-project.de:/root# setkey -D
pid 12656 (setkey): unaligned access: va=0x120026199 pc=0x120001d80 ra=0x120001b68 op=0xd
Bus error (core dumped)
Exit 138
bernd@srv1.cosmo-project.de:/root# setkey -DP
pid 12657 (setkey): unaligned access: va=0x120026199 pc=0x120001d80 ra=0x120001b68 op=0xd
Bus error (core dumped)
Exit 138
FreeBSD srv1.cosmo-project.de 4.4-STABLE FreeBSD 4.4-STABLE #0: Fri Nov 23 02:30:26 CET 2001     root@srv1.cosmo-project.de:/var/d1/FreeBSD-2001-11-21/src/sys/compile/SRV1  alpha

A short look onto an older -current showed similar problems:
ticso@cicely9# setkey -D
pid 95795 (setkey): unaligned access: va=0x120026231 pc=0x120001e00 ra=0x120001be8 op=0xd
Bus error (core dumped)
Exit 138
ticso@cicely9# setkey -DP
pid 95796 (setkey): unaligned access: va=0x120026231 pc=0x120001e00 ra=0x120001be8 op=0xd
Bus error (core dumped)
Exit 138
ticso@cicely9# uname -a
FreeBSD cicely9.cicely.de 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Tue Sep 11 11:27:34 CEST 2001     ticso@cicely9.cicely.de:/var/d8/FreeBSD-2001-09-03-ev56/src/sys/alpha/compile/CICELY9  alpha

setkey seemed to work on 4.0-stable, but I never got a working ipsec
connection, which may or may not be my fault.

Is anyone successfully running ipsec on alpha?

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso@cicely.de         Usergroup           info@cosmo-project.de


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26  3:29:14 2001
Delivered-To: freebsd-net@freebsd.org
Received: from ns.sirena2000.ru (ns.sirena2000.ru [194.84.25.34])
	by hub.freebsd.org (Postfix) with ESMTP id 76EB137B41E
	for <net@freebsd.org>; Mon, 26 Nov 2001 03:29:09 -0800 (PST)
Received: from sirena2000.ru (chek.network.sirena2000.ru [10.1.9.71])
	by ns.sirena2000.ru (8.9.3/8.9.3) with ESMTP id OAA28189;
	Mon, 26 Nov 2001 14:28:52 +0300 (MSK)
	(envelope-from serg@sirena2000.ru)
Message-ID: <3C02275C.E4C56BF@sirena2000.ru>
Date: Mon, 26 Nov 2001 14:28:29 +0300
From: "Serg V. Chemisov" <serg@sirena2000.ru>
X-Mailer: Mozilla 4.72 [en] (X11; I; SCO_SV 3.2 i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: larse@ISI.EDU
Cc: Jonathan Lemon <jlemon@flugsvamp.com>, net@freebsd.org
Subject: Re: decreasing TIME_WAIT duration(T/TCP?)
References: <PLEAKFMAJKNOEPLJKGBLGEJGCAAA.larse@isi.edu>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Lars Eggert wrote:
> 
> > In article
> > <local.mail.freebsd-net/3BFE4622.DA72E0D5@sirena2000.ru> you write:
> > >Hello!
> > >
> > >It is important to me to have duration of TIME_WAIT state of TCP
> > >connection as short time as possible.
> >
> > Tweak net.inet.tcp.msl, which specifies the 2MSL timeout.
> 
> And know what you are doing, it's there for a reason. If you need to
> dramatically change this value, I'd wager your system would benefit from a
> design change.
> 
> Lars
> --
> Lars Eggert <larse@isi.edu>               Information Sciences Institute
> http://www.isi.edu/larse/              University of Southern California


Alan Cox wrote: 
| 
| > Machine is web serwer with reather big traffic. Why there is 
| > so much connections in TIME_WAIT state ? 
| 
|
| "2 mintues" may be how the Linux kernel does it, but it's not the way 
| TCP says it should be done.
|
| TIME_WAIT should last for 2*MSL (maximum segment lifetime). I know
it's 
| hard to calculate MSL, and if you make up a hard-coded value it has to 
| be long enough for the slowest connections. It could be that FreeBSD 
| 4.0 does do this calculation. If we can calculate semi-accurate MSLs 
| for each connection, TIME_WAIT states would be minimized. 
|
| Even over a slow Internet link, the MSL can't be much longer than 10 
| seconds or so. By then a segment has either been TTL'd out, or is 
| lost. I don't buy "MSL == 1 minute" at all. 

How to turn on this calculation for 4.x ?

Serg.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26  6:46:30 2001
Delivered-To: freebsd-net@freebsd.org
Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9])
	by hub.freebsd.org (Postfix) with ESMTP id ECEF437B405
	for <net@freebsd.org>; Mon, 26 Nov 2001 06:46:26 -0800 (PST)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.11.0/8.11.0) id fAQEhu185094;
	Mon, 26 Nov 2001 08:43:56 -0600 (CST)
	(envelope-from jlemon)
Date: Mon, 26 Nov 2001 08:43:56 -0600 (CST)
From: Jonathan Lemon <jlemon@flugsvamp.com>
Message-Id: <200111261443.fAQEhu185094@prism.flugsvamp.com>
To: serg@sirena2000.ru, net@freebsd.org
Subject: Re: decreasing TIME_WAIT duration(T/TCP?)
X-Newsgroups: local.mail.freebsd-net
In-Reply-To: <local.mail.freebsd-net/3C02275C.E4C56BF@sirena2000.ru>
References: <local.mail.freebsd-net/PLEAKFMAJKNOEPLJKGBLGEJGCAAA.larse@isi.edu>
Organization: 
Cc: 
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

In article <local.mail.freebsd-net/3C02275C.E4C56BF@sirena2000.ru> you write:
>Lars Eggert wrote:
>> 
>> > In article
>> > <local.mail.freebsd-net/3BFE4622.DA72E0D5@sirena2000.ru> you write:
>> > >Hello!
>> > >
>> > >It is important to me to have duration of TIME_WAIT state of TCP
>> > >connection as short time as possible.
>> >
>> > Tweak net.inet.tcp.msl, which specifies the 2MSL timeout.
>> 
>> And know what you are doing, it's there for a reason. If you need to
>> dramatically change this value, I'd wager your system would benefit from a
>> design change.
>> 
>> Lars
>> --
>> Lars Eggert <larse@isi.edu>               Information Sciences Institute
>> http://www.isi.edu/larse/              University of Southern California
>
>
>Alan Cox wrote: 
>| 
>| > Machine is web serwer with reather big traffic. Why there is 
>| > so much connections in TIME_WAIT state ? 
>| 
>|
>| "2 mintues" may be how the Linux kernel does it, but it's not the way 
>| TCP says it should be done.
>|
>| TIME_WAIT should last for 2*MSL (maximum segment lifetime). I know
>it's 
>| hard to calculate MSL, and if you make up a hard-coded value it has to 
>| be long enough for the slowest connections. It could be that FreeBSD 
>| 4.0 does do this calculation. If we can calculate semi-accurate MSLs 
>| for each connection, TIME_WAIT states would be minimized. 
>|
>| Even over a slow Internet link, the MSL can't be much longer than 10 
>| seconds or so. By then a segment has either been TTL'd out, or is 
>| lost. I don't buy "MSL == 1 minute" at all. 
>
>How to turn on this calculation for 4.x ?

Unfortunately, this is not calculated; we still rely on a static 
(default 30sec) MSL quiet period.  Ideally, it should be possible to
set MSL based on some multiple of RTT for the connection, and default 
to a hard coded value if there are not enough samples to calculate RTT.
-- 
Jonathan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26  7:20:11 2001
Delivered-To: freebsd-net@freebsd.org
Received: from hotmail.com (f149.pav2.hotmail.com [64.4.37.149])
	by hub.freebsd.org (Postfix) with ESMTP id 4AD3737B405
	for <net@freebsd.org>; Mon, 26 Nov 2001 07:20:08 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 26 Nov 2001 07:20:08 -0800
Received: from 204.178.20.14 by pv2fd.pav2.hotmail.msn.com with HTTP;
	Mon, 26 Nov 2001 15:20:07 GMT
X-Originating-IP: [204.178.20.14]
From: "murthy kn" <knmurthy30@hotmail.com>
To: net@freebsd.org
Subject: Understanding fxp driver
Date: Mon, 26 Nov 2001 20:50:07 +0530
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F149XOLyWeSH6nk4r7d0000af5a@hotmail.com>
X-OriginalArrivalTime: 26 Nov 2001 15:20:08.0284 (UTC) FILETIME=[D53919C0:01C1768D]
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Hello,

Am trying to playaround and understand the Intel NIC fxp driver and it would 
be of help if you driver-gurus can please clarify a couple of points.

I understand that Tx DMA size is 128.

1. what parameter exactly determines how many packets the NIC
sends before interrupting the Host Cpu after transmit (assuming
no packet is received).

2. Does the NIC interrupt the Host cpu on each packet reception?

If so, how are packets that are put into the RFA (while the
CPU is busy processing the current interrupt) notified -
(my understanding is the "rcvloop" in fxp_intr will automatically
take care of this - is it correct?).

3. What is the exact role of tx_threshold

4. Suppose I want to make the NIC interrupt the cpu for each packet,
if I just reduce the Tx DMA length to 2-power-0, i.e,1, will it work?

Thanks a lot for your time.

       Murthy

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26  9:45:17 2001
Delivered-To: freebsd-net@freebsd.org
Received: from quack.kfu.com (quack.kfu.com [205.178.90.194])
	by hub.freebsd.org (Postfix) with ESMTP id 0163037B416
	for <freebsd-net@freebsd.org>; Mon, 26 Nov 2001 09:45:14 -0800 (PST)
Received: from morpheus.kfu.com (morpheus.kfu.com [205.178.90.238])
	by quack.kfu.com (8.11.6/8.11.6) with ESMTP id fAQHiAD54030
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK);
	Mon, 26 Nov 2001 09:44:11 -0800 (PST)
	(envelope-from nsayer@quack.kfu.com)
Received: from quack.kfu.com (nospam@localhost [::1])
	by morpheus.kfu.com (8.11.6/8.11.6) with ESMTP id fAQHiAn03742;
	Mon, 26 Nov 2001 09:44:10 -0800 (PST)
	(envelope-from nsayer@quack.kfu.com)
Message-ID: <3C027F6A.3060708@quack.kfu.com>
Date: Mon, 26 Nov 2001 09:44:10 -0800
From: Nick Sayer <nsayer@quack.kfu.com>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.5) Gecko/20011112
X-Accept-Language: en, en-US, en-GB
MIME-Version: 1.0
To: freebsd-net@freebsd.org
Subject: if_dc problem identified
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

I have done some more investigating. I believe if_dc is not correctly 
interpreting the SROM. It turns out that on Znyx cards, the SIA block is 
not in the format the driver expects (there is a format bit you need to 
check to see what format it is in).

I manually re-interpreted the data in the SROM and put a special case in 
dc_apply_fixup() and now 10baseT half duplex works correctly (not only 
that, but the LEDs do the correct thing too).

I won't post a patch, since the hack has SROM data that is specific to 
this card, but it appears that the SROM parsing section of if_dc and the 
media selection code needs serious work. According to the sample code 
I've seen (thanks to Andrew Gallatin for pointing me to the sample 
below), we're not consulting the SROM for _enough_ information, and 
we're making too many assumptions about its format.

http://www.tru64unix.compaq.com/docs/dev_doc/DOCUMENTATION/HTML/DDK_R2/usr/opt/OSCB505/src/usr/examples/ddk/src/pci/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26 11:20:34 2001
Delivered-To: freebsd-net@freebsd.org
Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9])
	by hub.freebsd.org (Postfix) with ESMTP id 875C737B417
	for <net@freebsd.org>; Mon, 26 Nov 2001 11:20:26 -0800 (PST)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.11.0/8.11.0) id fAQJHrx94789;
	Mon, 26 Nov 2001 13:17:53 -0600 (CST)
	(envelope-from jlemon)
Date: Mon, 26 Nov 2001 13:17:53 -0600 (CST)
From: Jonathan Lemon <jlemon@flugsvamp.com>
Message-Id: <200111261917.fAQJHrx94789@prism.flugsvamp.com>
To: knmurthy30@hotmail.com, net@freebsd.org
Subject: Re: Understanding fxp driver
X-Newsgroups: local.mail.freebsd-net
In-Reply-To: <local.mail.freebsd-net/F149XOLyWeSH6nk4r7d0000af5a@hotmail.com>
Organization: 
Cc: 
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

In article <local.mail.freebsd-net/F149XOLyWeSH6nk4r7d0000af5a@hotmail.com> you write:
>Hello,
>
>Am trying to playaround and understand the Intel NIC fxp driver and it would 
>be of help if you driver-gurus can please clarify a couple of points.
>
>I understand that Tx DMA size is 128.

The number of control blocks is 128; this is not the same as the DMA size.


>1. what parameter exactly determines how many packets the NIC
>sends before interrupting the Host Cpu after transmit (assuming
>no packet is received).

	/*
	 * Number of completed TX commands at which point an interrupt
	 * will be generated to garbage collect the attached buffers.
	 * Must be at least one less than FXP_NTXCB, and should be
	 * enough less so that the transmitter doesn't becomes idle
	 * during the buffer rundown (which would reduce performance).
	 */
	#define FXP_CXINT_THRESH 120


>2. Does the NIC interrupt the Host cpu on each packet reception?

Yes, unless the receive interrupt migitation code is enabled.  But note
that this does not necessarily translate into "one interrupt per packet",
as multiple packets may be processed under the same interrupt.


>If so, how are packets that are put into the RFA (while the
>CPU is busy processing the current interrupt) notified -
>(my understanding is the "rcvloop" in fxp_intr will automatically
>take care of this - is it correct?).

Packets are added at the tail end of the RFA while the cpu processes
the head.  The code processes all completed entries, then loops again
to check for new interrupts before exiting the interrupt handler.


>3. What is the exact role of tx_threshold

Indicates the # of bytes that should be present on-chip before a
transmit starts; if an underrun occurrs (cpu can't provide data to
the chip in time to complete a frame), this is increased.


>4. Suppose I want to make the NIC interrupt the cpu for each packet,
>if I just reduce the Tx DMA length to 2-power-0, i.e,1, will it work?

No, that won't work, but why would you want to do that? 
-- 
Jonathan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26 11:47: 8 2001
Delivered-To: freebsd-net@freebsd.org
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP id 44CD237B416
	for <net@FreeBSD.ORG>; Mon, 26 Nov 2001 11:47:02 -0800 (PST)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fAQJl0321324;
	Mon, 26 Nov 2001 14:47:00 -0500 (EST)
	(envelope-from wollman)
Date: Mon, 26 Nov 2001 14:47:00 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200111261947.fAQJl0321324@khavrinen.lcs.mit.edu>
To: Jonathan Lemon <jlemon@flugsvamp.com>
Cc: net@FreeBSD.ORG
Subject: Re: decreasing TIME_WAIT duration(T/TCP?)
In-Reply-To: <200111261443.fAQEhu185094@prism.flugsvamp.com>
References: <local.mail.freebsd-net/PLEAKFMAJKNOEPLJKGBLGEJGCAAA.larse@isi.edu>
	<local.mail.freebsd-net/3C02275C.E4C56BF@sirena2000.ru>
	<200111261443.fAQEhu185094@prism.flugsvamp.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

<<On Mon, 26 Nov 2001 08:43:56 -0600 (CST), Jonathan Lemon <jlemon@flugsvamp.com> said:

> Unfortunately, this is not calculated; we still rely on a static 
> (default 30sec) MSL quiet period.  Ideally, it should be possible to
> set MSL based on some multiple of RTT for the connection, and default 
> to a hard coded value if there are not enough samples to calculate RTT.

There is no way to `calculate' the maximum segment lifetime unless you
are omniscient.  It is assumed to be 30 seconds, but in reality can be
much, much more.  (As a result, TCP is theoretically broken, but the
situations in which this happens are rare enough to be masked by other
events.)  The RTT gives you the *critical path length* of the graph;
it does not have anything to do with the MSL except for trivial
(two-node) networks.

-GAWollman


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26 12: 2:26 2001
Delivered-To: freebsd-net@freebsd.org
Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4D3D437B41B; Mon, 26 Nov 2001 12:01:12 -0800 (PST)
Received: (from rizzo@localhost)
	by iguana.aciri.org (8.11.3/8.11.1) id fAQJv4M89422;
	Mon, 26 Nov 2001 11:57:04 -0800 (PST)
	(envelope-from rizzo)
Date: Mon, 26 Nov 2001 11:57:04 -0800
From: Luigi Rizzo <rizzo@aciri.org>
To: net@freebsd.org
Subject: Revised polling code for STABLE
Message-ID: <20011126115704.L88153@iguana.aciri.org>
References: <20011027005905.A72758@iguana.aciri.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="mP3DRpeJDSE+ciuQ"
Content-Disposition: inline
In-Reply-To: <20011027005905.A72758@iguana.aciri.org>
User-Agent: Mutt/1.3.23i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

[Bcc to -stable in case someone is interested there]

Attached you can find the latest version of the polling code
for STABLE (which is useful to make boxes much more robust
to attacks and have much better responsiveness under [over]load).

Note that this code is only useful for RELENG_4, x86, non-SMP
boxes.

This version includes driver modifications for the following
drivers:

    fxp (this is for version 1.110.2.7 of the driver, i.e.
	the one in FreeBSD 4.4; hopefully the change should
	work for the newer driver as well without too
	many changes)

    dc

    sis (this one includes an i386 optimization which avoids
	an additional copy of the packet. The performance
	improvement I have measured from this can be as high as
	50% in some embedded systems with not a lot of CPU power).

Other drivers should be modified mostly following what is done in
the above drivers.
	
The sysctl variables to control polling mode are:

    net.xorp.polling
	set to 1 to enable polling, 0 to disable (default)

    net.xorp.poll_burst_max
	how many packets are processed at most at each clock
	tick. Defaults to 100.

    net.xorp.poll_burst
	how many packets are processed at each clock tick.
	Automatically adjusted depending on system load
	between 1 and net.xorp.poll_burst_max

    net.xorp.poll_in_trap
	how many packets are processed at each trap.
	Upper bounded by net.xorp.poll_burst.

    net.xorp.sis_quick
	set to 1 (default) to avoid the additional copy in the
	sis driver. There should be no reason to turn this off
	except seeing how much you are gaining.

Installation is trivial:

  + (cd /sys ; patch < polling.patches )
  + add the following two lines to the kernel config:
 	options HZ=1000
 	options	XORP_ETHER_POLLING
  + build and install the kernel
  + at runtime use the sysctl variables listed above to control polling.
    Basically you just need to turn on net.xorp.polling

The files touched by this diff are:

    sys/conf/options.i386
	option definition

    sys/i386/include/asnames.h
    sys/net/if.h
    sys/net/netisr.h
    sys/sys/systm.h
	constants, variable and prototypes (mostly one-line changes)

    sys/i386/i386/swtch.s
    sys/i386/i386/trap.c
	calls to ether_poll from the idle loop and traps

    sys/kern/kern_clock.c
	main polling routines

    sys/dev/fxp/if_fxp.c
    sys/pci/if_dc.c
    sys/pci/if_dcreg.h
    sys/pci/if_sis.c
    sys/pci/if_sisreg.h
	device driver changes

Have fun, please report success or problems if you use this code.

	cheers
	luigi

----------------------------------+-----------------------------------------
 Luigi RIZZO, luigi@iet.unipi.it  . ACIRI/ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone: (510) 666 2927
----------------------------------+-----------------------------------------

--mP3DRpeJDSE+ciuQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="stable.xorp.diff.011126a"

Index: sys/conf/options.i386
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/conf/options.i386,v
retrieving revision 1.132.2.8
diff -u -r1.132.2.8 options.i386
--- sys/conf/options.i386	2001/10/03 07:15:37	1.132.2.8
+++ sys/conf/options.i386	2001/10/27 00:23:01
@@ -208,5 +208,10 @@
 SMBFS
 
 # -------------------------------
+# Xorp stuff
+# -------------------------------
+XORP_ETHER_POLLING	opt_global.h
+
+# -------------------------------
 # EOF
 # -------------------------------
Index: sys/dev/fxp/if_fxp.c
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/dev/fxp/if_fxp.c,v
retrieving revision 1.110.2.7
diff -u -r1.110.2.7 if_fxp.c
--- sys/dev/fxp/if_fxp.c	2001/08/31 02:17:02	1.110.2.7
+++ sys/dev/fxp/if_fxp.c	2001/11/23 17:54:41
@@ -1123,6 +1123,38 @@
 	}
 }
 
+static void fxp_intr_body(struct fxp_softc *sc, u_int8_t statack, int count);
+
+#ifdef XORP_ETHER_POLLING
+static poll_handler_t fxp_poll;
+
+static void
+fxp_poll(struct ifnet *ifp, int cmd, int count)  
+{
+	struct fxp_softc *sc = ifp->if_softc;
+	u_int8_t statack ;
+
+	if (cmd == 2) {		/* final call, enable interrupts */
+		CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL, 0);
+		return;
+	}
+	statack = FXP_SCB_STATACK_CXTNO | FXP_SCB_STATACK_CNA |
+		FXP_SCB_STATACK_FR ;
+	if (cmd == 1) {
+		u_int8_t tmp ;
+		tmp = CSR_READ_1(sc, FXP_CSR_SCB_STATACK);
+		if (tmp == 0xff || tmp == 0)
+			return ; /* nothing to do */
+		tmp &= ~statack ;
+		/* ack what we can */
+		if (tmp != 0)
+			CSR_WRITE_1(sc, FXP_CSR_SCB_STATACK, tmp);
+		statack |= tmp ;
+	}
+	fxp_intr_body(sc, statack, count);
+}
+#endif /* XORP_ETHER_POLLING */
+
 /*
  * Process interface interrupts.
  */
@@ -1130,9 +1162,21 @@
 fxp_intr(void *xsc)
 {
 	struct fxp_softc *sc = xsc;
-	struct ifnet *ifp = &sc->sc_if;
 	u_int8_t statack;
 
+#ifdef XORP_ETHER_POLLING
+	struct ifnet *ifp = &sc->sc_if;
+
+	if (ifp->if_ipending & IFF_POLLING)
+		return ;
+	if (ether_poll_register(fxp_poll, ifp)) {
+		/* disable interrupts */
+		CSR_WRITE_1(sc, FXP_CSR_SCB_INTRCNTL, FXP_SCB_INTR_DISABLE);
+		fxp_poll(ifp, 0, poll_burst);
+		return ;
+	}
+#endif
+
 	if (sc->suspended) {
 		return;
 	}
@@ -1151,7 +1195,15 @@
 		 * First ACK all the interrupts in this pass.
 		 */
 		CSR_WRITE_1(sc, FXP_CSR_SCB_STATACK, statack);
+		fxp_intr_body(sc, statack, -1);
+	}
+}
 
+static void
+fxp_intr_body(struct fxp_softc *sc, u_int8_t statack, int count)
+{
+	struct ifnet *ifp = &sc->sc_if;
+
 		/*
 		 * Free any finished transmit mbuf chains.
 		 *
@@ -1201,7 +1253,9 @@
 			m = sc->rfa_headm;
 			rfa = (struct fxp_rfa *)(m->m_ext.ext_buf +
 			    RFA_ALIGNMENT_FUDGE);
-
+#ifdef XORP_ETHER_POLLING /* loop at most count times if count >=0 */
+			if (count < 0 || count-- > 0)
+#endif
 			if (rfa->rfa_status & FXP_RFA_STATUS_C) {
 				/*
 				 * Remove first packet from the chain.
@@ -1258,7 +1312,6 @@
 				fxp_scb_cmd(sc, FXP_SCB_COMMAND_RU_START);
 			}
 		}
-	}
 }
 
 /*
Index: sys/i386/i386/swtch.s
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/i386/i386/swtch.s,v
retrieving revision 1.89.2.4
diff -u -r1.89.2.4 swtch.s
--- sys/i386/i386/swtch.s	2001/07/26 02:29:10	1.89.2.4
+++ sys/i386/i386/swtch.s	2001/10/26 21:54:19
@@ -246,6 +246,17 @@
 	call	_procrunnable
 	testl	%eax,%eax
 	CROSSJUMP(jnz, sw1a, jz)
+#ifdef	XORP_ETHER_POLLING
+	incl	_idle_done
+	pushl	_poll_burst
+	call	_ether_poll
+	addl	$4,%esp
+	sti
+	nop
+	cli
+	testl   %eax, %eax
+	jnz     idle_loop
+#endif
 	call	_vm_page_zero_idle
 	testl	%eax, %eax
 	jnz	idle_loop
Index: sys/i386/i386/trap.c
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/i386/i386/trap.c,v
retrieving revision 1.147.2.5
diff -u -r1.147.2.5 trap.c
--- sys/i386/i386/trap.c	2001/08/15 01:23:50	1.147.2.5
+++ sys/i386/i386/trap.c	2001/10/26 21:47:16
@@ -266,6 +266,11 @@
 		enable_intr();
 	}
 
+#ifdef	XORP_ETHER_POLLING
+	if (poll_in_trap)
+		ether_poll(poll_in_trap);
+#endif /* XORP_ETHER_POLLING */
+
 #if defined(I586_CPU) && !defined(NO_F00F_HACK)
 restart:
 #endif
Index: sys/i386/include/asnames.h
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/i386/include/Attic/asnames.h,v
retrieving revision 1.44.2.3
diff -u -r1.44.2.3 asnames.h
--- sys/i386/include/asnames.h	2001/09/20 09:29:23	1.44.2.3
+++ sys/i386/include/asnames.h	2001/10/27 00:32:28
@@ -210,6 +210,7 @@
 #define _eintrnames			eintrnames
 #define _end				end
 #define _etext				etext
+#define _ether_poll			ether_poll
 #define _exception			exception
 #define _fast_intr_lock			fast_intr_lock
 #define _fastmove			fastmove
@@ -225,6 +226,7 @@
 #define _get_mplock			get_mplock
 #define _get_syscall_lock		get_syscall_lock
 #define _idle				idle
+#define _idle_done 			idle_done
 #define _ihandlers			ihandlers
 #define _imen				imen
 #define _imen_lock			imen_lock
@@ -266,6 +268,7 @@
 #define _ovbcopy_vector			ovbcopy_vector
 #define _panic				panic
 #define _pc98_system_parameter		pc98_system_parameter
+#define _poll_burst			poll_burst
 #define _poly_div16			poly_div16
 #define _poly_div2			poly_div2
 #define _poly_div4			poly_div4
Index: sys/kern/kern_clock.c
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/kern/kern_clock.c,v
retrieving revision 1.105.2.4
diff -u -r1.105.2.4 kern_clock.c
--- sys/kern/kern_clock.c	2001/02/18 15:29:14	1.105.2.4
+++ sys/kern/kern_clock.c	2001/11/23 18:01:12
@@ -67,7 +67,14 @@
 #include <sys/gmon.h>
 #endif
 
+#ifdef XORP_ETHER_POLLING
+#include <sys/socket.h>	/* needed by sys/if.h */
+#include <net/if.h>	/* for IFF_* flags */
+#include <net/netisr.h>	/* for NETISR_POLL */
 
+static void update_poll_threshold(struct clockframe *frame);
+#endif
+
 /*
  * Number of timecounters used to implement stable storage
  */
@@ -188,6 +195,10 @@
 	psdiv = pscnt = 1;
 	cpu_initclocks();
 
+#ifdef XORP_ETHER_POLLING
+	register_netisr(NETISR_POLL, ether_poll1);
+#endif
+
 	/*
 	 * Compute profhz/stathz, and fix profhz if needed.
 	 */
@@ -236,6 +247,12 @@
 	tco_forward(0);
 	ticks++;
 
+#ifdef XORP_ETHER_POLLING
+	update_poll_threshold(frame);
+	if (poll_handlers > 0)
+		schednetisr(NETISR_POLL);
+#endif
+
 	/*
 	 * Process callouts at a very low cpu priority, so we don't keep the
 	 * relatively high clock interrupt priority any longer than necessary.
@@ -999,3 +1016,203 @@
 	}
 #endif
 }
+
+#ifdef XORP_ETHER_POLLING
+/*
+ * Polling support for device drivers.
+ */
+
+SYSCTL_NODE(_net, OID_AUTO, xorp, CTLFLAG_RW, 0, "Xorp parameters");
+
+u_int32_t idle_done;
+SYSCTL_ULONG(_net_xorp, OID_AUTO, idle_done, CTLFLAG_RD,
+	&idle_done, 0, "Have gone in idle_loop");
+
+u_int32_t poll_burst = 5;
+SYSCTL_ULONG(_net_xorp, OID_AUTO, poll_burst, CTLFLAG_RW,
+	&poll_burst, 0, "Current Polling burst size");
+
+u_int32_t poll_burst_max = 100;
+SYSCTL_ULONG(_net_xorp, OID_AUTO, poll_burst_max, CTLFLAG_RW,
+	&poll_burst_max, 0, "Max Polling burst size");
+
+u_int32_t poll_in_trap;
+SYSCTL_ULONG(_net_xorp, OID_AUTO, poll_in_trap, CTLFLAG_RW,
+	&poll_in_trap, 0, "Poll size while getting a trap ?");
+
+static u_int32_t user_frac = 50;
+SYSCTL_ULONG(_net_xorp, OID_AUTO, user_frac, CTLFLAG_RW,
+	&user_frac, 0, "Desired user fraction of cpu time");
+
+/*
+ * Devices that want to do polling must register for it,
+ * typically from the interrupt service routine, by calling
+ * ether_poll_register(handler, arg).
+ *
+ * The handler is called with 3 arguments: the "arg" passed at register
+ * time (a struct ifnet pointer), a command (see below) and a count limit.
+ * The command can be one of the following:
+ *  0: quick move of "count" packets from input/output queues.
+ *  1: as above, plus check status registers for errors etc.
+ *  2: unregister and return to interrupt mode.
+ * Commands 0 and 1 are only issued if the interface is marked as 'IFF_UP',
+ * command 2 is issued inconditionally.
+ *
+ * The count limit specifies how much work the handler can do during the
+ * call -- typically this is the number of packets to be received, or
+ * transmitted, etc. (drivers are free to interpret this number, as long
+ * as the max time spent in the function grows roughly linearly with the
+ * count).
+ */
+#define POLL_LIST_LEN  128
+struct pollrec {
+	poll_handler_t	*handler ;
+	struct ifnet	*ifp;
+};
+
+static struct pollrec pr[POLL_LIST_LEN];
+u_int32_t poll_handlers; /* next free entry in pr[]. */
+SYSCTL_ULONG(_net_xorp, OID_AUTO, poll_handlers, CTLFLAG_RD,
+	&poll_handlers, 0, "next entry in poll register array");
+
+/*
+ * this sysctl variable globally controls polling
+ */
+static int polling = 0 ;
+SYSCTL_ULONG(_net_xorp, OID_AUTO, polling, CTLFLAG_RW,
+	&polling, 0, "Polling enabled");
+
+/*
+ * poll state reflects from what context we are polling.
+ */
+enum poll_states {
+	POLL_NONE, POLL_INTR, POLL_IDLE,
+};
+static enum poll_states poll_state = POLL_NONE;
+
+/*
+ * ether_poll is called from the idle loop or from trap handlers.
+ */
+int
+ether_poll(int count)
+{
+	static int i;
+	int s = splimp();
+
+	poll_state = POLL_IDLE;
+	if (count > poll_burst)
+		count = poll_burst;
+	if (i >= poll_handlers)
+		i = 0;
+	if (pr[i].handler && pr[i].ifp->if_flags & IFF_UP)
+		pr[i].handler(pr[i].ifp, 0, count); /* quick check */
+	i++ ;
+	poll_state = POLL_NONE;
+	splx(s);
+	return 1; /* more polling */
+}
+
+/*
+ * keep statistics on how much userland could used the CPU
+ */
+
+static void
+update_poll_threshold(struct clockframe *frame)
+{
+	static u_int32_t ready = 0 ; /* act when ready==0 */
+
+	if (poll_state == POLL_INTR) {
+		/*
+		 * We are spending too much time in polling,
+		 * so we need to lower the threshold.
+		 */
+		if (poll_burst >= 2)
+			poll_burst >>= 1 ;
+	} else if (idle_done > 0 && ready == 0 && poll_burst < poll_burst_max)
+		poll_burst++;
+
+	idle_done = 0 ;
+
+	if (ready-- > 0)
+		return ;
+
+	ready = hz/10 ;
+}
+
+/*
+ * ether_poll1 is called by schednetisr when appropriate, typically once
+ * per tick. It is called at splnet() so first thing to do is to upgrade to
+ * splimp(), and call all registered handlers.
+ */
+void
+ether_poll1(void)
+{
+	int i;
+	int s=splimp();
+
+	poll_state = POLL_INTR ;
+	if (polling) {
+		for (i = 0 ; i < poll_handlers ; i++)
+			if (pr[i].handler && pr[i].ifp->if_flags & IFF_UP)
+				pr[i].handler(pr[i].ifp, 1, poll_burst);
+	} else {	/* unregister */
+		for (i = 0 ; i < poll_handlers ; i++) {
+			if (pr[i].handler) {
+				pr[i].ifp->if_ipending &= ~IFF_POLLING;
+				pr[i].handler(pr[i].ifp, 2, poll_burst);
+			}
+			pr[i].handler=NULL;
+		}
+		poll_handlers = 0;
+	}
+	poll_state = POLL_NONE;
+	splx(s);
+}
+
+/*
+ * Try to register routine for polling. Returns 1 if successful
+ * (and polling should be enabled), 0 otherwise.
+ * A device is not supposed to register itself multiple times.
+ */
+int
+ether_poll_register(poll_handler_t *h, struct ifnet *ifp)
+{
+	int s;
+
+	if (polling == 0) /* polling disabled, cannot register */
+		return 0;
+	if (h == NULL || ifp == NULL) /* bad arguments */
+		return 0;
+	if ( !(ifp->if_flags & IFF_UP) )	/* must be up */
+		return 0;
+	if (ifp->if_ipending & IFF_POLLING)	/* sorry, already polling */
+		return 0;
+
+	s = splhigh();
+	if (poll_handlers >= POLL_LIST_LEN) {
+		/*
+		 * List full, cannot register more entries.
+		 * This should never happen; if it does, it is probably a
+		 * broken driver trying to register multiple times. Checking
+		 * this at runtime is expensive, and won't solve the problem
+		 * anyways, so just report a few times and then give up.
+		 */
+		static int verbose = 10 ;
+		splx(s);
+		if (verbose >0) {
+			printf("poll handlers list full, "
+				"maybe a broken driver ?\n");
+			verbose--;
+		}
+		return 0; /* no polling for you */
+	}
+
+	pr[poll_handlers].handler = h;
+	pr[poll_handlers].ifp = ifp;
+	poll_handlers++;
+	ifp->if_ipending |= IFF_POLLING;
+	splx(s);
+	return 1; /* polling enabled in next call */
+}
+
+#endif /* XORP_ETHER_POLLING */
Index: sys/net/if.h
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/net/if.h,v
retrieving revision 1.58.2.2
diff -u -r1.58.2.2 if.h
--- sys/net/if.h	2001/07/24 19:10:18	1.58.2.2
+++ sys/net/if.h	2001/10/27 00:46:45
@@ -131,6 +131,15 @@
 #define	IFF_ALTPHYS	IFF_LINK2	/* use alternate physical connection */
 #define	IFF_MULTICAST	0x8000		/* supports multicast */
 
+/*
+ * The following flag(s) ought to go in if_flags, but we cannot change
+ * struct ifnet because of binary compatibility, so we store them in
+ * if_ipending, which is not used so far.
+ * If possible, make sure the value is not conflicting with other
+ * IFF flags, so we have an easier time when we want to merge them.
+ */
+#define	IFF_POLLING	0x10000		/* Interface is in polling mode. */
+
 /* flags set internally only: */
 #define	IFF_CANTCHANGE \
 	(IFF_BROADCAST|IFF_POINTOPOINT|IFF_RUNNING|IFF_OACTIVE|\
Index: sys/net/netisr.h
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/net/netisr.h,v
retrieving revision 1.21.2.2
diff -u -r1.21.2.2 netisr.h
--- sys/net/netisr.h	2001/03/06 00:55:07	1.21.2.2
+++ sys/net/netisr.h	2001/10/25 23:23:58
@@ -52,6 +52,7 @@
  * interrupt used for scheduling the network code to calls
  * on the lowest level routine of each protocol.
  */
+#define	NETISR_POLL	1		/* polling callback */
 #define	NETISR_IP	2		/* same as AF_INET */
 #define	NETISR_NS	6		/* same as AF_NS */
 #define	NETISR_ATALK    16              /* same as AF_APPLETALK */
Index: sys/pci/if_dc.c
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/pci/if_dc.c,v
retrieving revision 1.9.2.23
diff -u -r1.9.2.23 if_dc.c
--- sys/pci/if_dc.c	2001/10/28 17:23:24	1.9.2.23
+++ sys/pci/if_dc.c	2001/11/23 17:55:52
@@ -2318,6 +2318,13 @@
 	while(!(sc->dc_ldata->dc_rx_list[i].dc_status & DC_RXSTAT_OWN)) {
 		struct mbuf		*m0 = NULL;
 
+#ifdef XORP_ETHER_POLLING
+		if (ifp->if_ipending & IFF_POLLING) {
+			if (sc->rxcycles <= 0)
+				break ;
+			sc->rxcycles -- ;
+		}
+#endif /* XORP_ETHER_POLLING */
 		cur_rx = &sc->dc_ldata->dc_rx_list[i];
 		rxstat = cur_rx->dc_status;
 		m = sc->dc_cdata.dc_rx_chain[i];
@@ -2606,6 +2613,61 @@
 	return;
 }
 
+#ifdef XORP_ETHER_POLLING
+static poll_handler_t dc_poll;
+
+static void
+dc_poll(struct ifnet *ifp, int cmd, int count)
+{
+	struct	dc_softc *sc = ifp->if_softc;
+
+	if (cmd == 2) { /* final call, enable interrupts */
+		/* Re-enable interrupts. */
+		CSR_WRITE_4(sc, DC_IMR, DC_INTRS);
+		return;
+	}
+	sc->rxcycles = count;
+	dc_rxeof(sc);
+	dc_txeof(sc);
+	if (ifp->if_snd.ifq_head != NULL && !(ifp->if_flags & IFF_OACTIVE))
+		dc_start(ifp);
+
+	if (cmd == 1) { /* also check status register */
+		u_int32_t          status;
+
+		status = CSR_READ_4(sc, DC_ISR);
+		status &= (DC_ISR_RX_WATDOGTIMEO|DC_ISR_RX_NOBUF|
+			DC_ISR_TX_NOBUF|DC_ISR_TX_IDLE|DC_ISR_TX_UNDERRUN|
+			DC_ISR_BUS_ERR);
+		if (!status)
+			return ;
+		/* ack what we have */
+		CSR_WRITE_4(sc, DC_ISR, status);
+
+		if (status & (DC_ISR_RX_WATDOGTIMEO|DC_ISR_RX_NOBUF) ) {
+			u_int32_t r = CSR_READ_4(sc, DC_FRAMESDISCARDED);
+			ifp->if_ierrors += (r & 0xffff) +
+				( (r >> 17) & 0x7ff ) ;
+
+			if (dc_rx_resync(sc))
+				dc_rxeof(sc);
+		}
+		/* restart transmit unit if necessary */
+		if (status & DC_ISR_TX_IDLE && sc->dc_cdata.dc_tx_cnt)
+			CSR_WRITE_4(sc, DC_TXSTART, 0xFFFFFFFF);
+
+		if (status & DC_ISR_TX_UNDERRUN)
+			dc_tx_underrun(sc);
+
+		if (status & DC_ISR_BUS_ERR) {
+			printf("dc_poll: dc%d bus error\n", sc->dc_unit);
+			dc_reset(sc);
+			dc_init(sc);
+		}
+	}
+}
+#endif /* XORP_ETHER_POLLING */
+
 static void dc_intr(arg)
 	void			*arg;
 {
@@ -2614,11 +2676,21 @@
 	u_int32_t		status;
 
 	sc = arg;
+	ifp = &sc->arpcom.ac_if;
 
+#ifdef XORP_ETHER_POLLING
+	if (ifp->if_ipending & IFF_POLLING)
+		return ;
+	if (ether_poll_register(dc_poll, ifp)) { /* ok, disable interrupts */
+		CSR_WRITE_4(sc, DC_IMR, 0x00000000);
+		dc_poll(ifp, 0, poll_burst);
+		return ;
+	}
+#endif
+
 	if ( (CSR_READ_4(sc, DC_ISR) & DC_INTRS) == 0)
 		return ;
 
-	ifp = &sc->arpcom.ac_if;
 
 	/* Suppress unwanted interrupts */
 	if (!(ifp->if_flags & IFF_UP)) {
Index: sys/pci/if_dcreg.h
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/pci/if_dcreg.h,v
retrieving revision 1.4.2.11
diff -u -r1.4.2.11 if_dcreg.h
--- sys/pci/if_dcreg.h	2001/10/25 18:50:18	1.4.2.11
+++ sys/pci/if_dcreg.h	2001/10/26 07:22:36
@@ -429,7 +429,7 @@
 #define DC_FILTER_HASHONLY	0x10400000
 
 #define DC_MAXFRAGS		16
-#define DC_RX_LIST_CNT		64
+#define DC_RX_LIST_CNT		192 /* was 64 */
 #define DC_TX_LIST_CNT		256
 #define DC_MIN_FRAMELEN		60
 #define DC_RXLEN		1536
@@ -659,6 +659,7 @@
 	bus_space_handle_t	dc_bhandle;	/* bus space handle */
 	bus_space_tag_t		dc_btag;	/* bus space tag */
 	void			*dc_intrhand;
+	int			rxcycles;	/* ... when polling */
 	struct resource		*dc_irq;
 	struct resource		*dc_res;
 	struct dc_type		*dc_info;	/* adapter info */
Index: sys/pci/if_sis.c
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/pci/if_sis.c,v
retrieving revision 1.13.4.7
diff -u -r1.13.4.7 if_sis.c
--- sys/pci/if_sis.c	2001/02/21 22:17:51	1.13.4.7
+++ sys/pci/if_sis.c	2001/11/26 18:37:21
@@ -64,6 +64,7 @@
 #include <sys/malloc.h>
 #include <sys/kernel.h>
 #include <sys/socket.h>
+#include <sys/sysctl.h>
 
 #include <net/if.h>
 #include <net/if_arp.h>
@@ -1091,6 +1092,11 @@
 	return(0);
 }
 
+int sis_quick=1;
+SYSCTL_DECL(_net_xorp);
+SYSCTL_INT(_net_xorp, OID_AUTO, sis_quick, CTLFLAG_RW,
+            &sis_quick,0,"do not mdevget in sis driver");
+
 /*
  * A frame has been uploaded: pass the resulting mbuf chain up to
  * the higher level protocols.
@@ -1111,6 +1117,13 @@
 	while(SIS_OWNDESC(&sc->sis_ldata->sis_rx_list[i])) {
 		struct mbuf		*m0 = NULL;
 
+#ifdef XORP_ETHER_POLLING
+		if (ifp->if_ipending & IFF_POLLING) {
+			if (sc->rxcycles <= 0)
+				break ;
+			sc->rxcycles -- ;
+		}
+#endif /* XORP_ETHER_POLLING */
 		cur_rx = &sc->sis_ldata->sis_rx_list[i];
 		rxstat = cur_rx->sis_rxstat;
 		m = cur_rx->sis_mbuf;
@@ -1132,7 +1145,15 @@
 			continue;
 		}
 
-		/* No errors; receive the packet. */	
+#ifdef __i386__
+	    if (sis_quick) {
+		m->m_pkthdr.rcvif = ifp;
+		m->m_pkthdr.len = m->m_len = total_len;
+		sis_newbuf(sc, cur_rx, NULL);
+	    } else
+#endif
+	    {
+		struct mbuf		*m0 = NULL;
 		m0 = m_devget(mtod(m, char *) - ETHER_ALIGN,
 		    total_len + ETHER_ALIGN, 0, ifp, NULL);
 		sis_newbuf(sc, cur_rx, m);
@@ -1142,7 +1163,7 @@
 		}
 		m_adj(m0, ETHER_ALIGN);
 		m = m0;
-
+	    }
 		ifp->if_ipackets++;
 		eh = mtod(m, struct ether_header *);
 
@@ -1260,6 +1281,53 @@
 	return;
 }
 
+
+#ifdef XORP_ETHER_POLLING
+static poll_handler_t sis_poll;
+
+static void
+sis_poll(struct ifnet *ifp, int cmd, int count)
+{
+	struct  sis_softc *sc = ifp->if_softc ;
+
+	if (cmd == 2) {		/* final call, enable interrupts */
+		CSR_WRITE_4(sc, SIS_IER, 1);
+		return;
+	}
+
+	/*
+	 * On the sis, reading the status register also clears it.
+	 * So before returning to intr mode we must make sure that all
+	 * possible pending sources of interrupts have been served.
+	 * In practice this means run to completion the *eof routines,
+	 * and then call the interrupt routine
+	 */
+	sc->rxcycles = count ;
+	sis_rxeof(sc);
+	sis_txeof(sc);
+	if (ifp->if_snd.ifq_head != NULL)
+		sis_start(ifp);
+
+	if (sc->rxcycles > 0 || cmd == 1) { /* also check status register */
+		u_int32_t          status;
+
+		/* Reading the ISR register clears all interrupts. */
+		status = CSR_READ_4(sc, SIS_ISR);
+
+		if (status & (SIS_ISR_RX_ERR|SIS_ISR_RX_OFLOW))
+                        sis_rxeoc(sc);
+        
+		if (status & (SIS_ISR_RX_IDLE))
+			SIS_SETBIT(sc, SIS_CSR, SIS_CSR_RX_ENABLE);
+
+                if (status & SIS_ISR_SYSERR) {
+                        sis_reset(sc);
+                        sis_init(sc);
+                }
+	}
+}
+#endif /* XORP_ETHER_POLLING */
+
 static void sis_intr(arg)
 	void			*arg;
 {
@@ -1270,6 +1338,16 @@
 	sc = arg;
 	ifp = &sc->arpcom.ac_if;
 
+#ifdef XORP_ETHER_POLLING
+	if (ifp->if_ipending & IFF_POLLING)
+		return ;
+	if (ether_poll_register(sis_poll, ifp)) { /* ok, disable interrupts */
+		CSR_WRITE_4(sc, SIS_IER, 0);
+		sis_poll(ifp, 0, poll_burst);
+		return ;
+	}
+#endif
+
 	/* Supress unwanted interrupts */
 	if (!(ifp->if_flags & IFF_UP)) {
 		sis_stop(sc);
@@ -1286,19 +1364,19 @@
 		if ((status & SIS_INTRS) == 0)
 			break;
 
-		if ((status & SIS_ISR_TX_DESC_OK) ||
-		    (status & SIS_ISR_TX_ERR) ||
-		    (status & SIS_ISR_TX_OK) ||
-		    (status & SIS_ISR_TX_IDLE))
+		if (status &
+		    (SIS_ISR_TX_DESC_OK|SIS_ISR_TX_ERR| \
+		     SIS_ISR_TX_OK|SIS_ISR_TX_IDLE) )
 			sis_txeof(sc);
 
-		if ((status & SIS_ISR_RX_DESC_OK) ||
-		    (status & SIS_ISR_RX_OK))
+		if (status & (SIS_ISR_RX_DESC_OK|SIS_ISR_RX_OK|SIS_ISR_RX_IDLE))
 			sis_rxeof(sc);
 
-		if ((status & SIS_ISR_RX_ERR) ||
-		    (status & SIS_ISR_RX_OFLOW)) {
+		if (status & (SIS_ISR_RX_ERR|SIS_ISR_RX_OFLOW))
 			sis_rxeoc(sc);
+
+		if (status & (SIS_ISR_RX_IDLE)) {
+			SIS_SETBIT(sc, SIS_CSR, SIS_CSR_RX_ENABLE);
 		}
 
 		if (status & SIS_ISR_SYSERR) {
@@ -1546,6 +1624,9 @@
 	 * Enable interrupts.
 	 */
 	CSR_WRITE_4(sc, SIS_IMR, SIS_INTRS);
+#ifdef XORP_ETHER_POLLING
+	if (!(ifp->if_ipending & IFF_POLLING))
+#endif
 	CSR_WRITE_4(sc, SIS_IER, 1);
 
 	/* Enable receiver and transmitter. */
Index: sys/pci/if_sisreg.h
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/pci/if_sisreg.h,v
retrieving revision 1.1.4.3
diff -u -r1.1.4.3 if_sisreg.h
--- sys/pci/if_sisreg.h	2001/02/21 22:17:51	1.1.4.3
+++ sys/pci/if_sisreg.h	2001/10/31 02:25:29
@@ -305,7 +305,7 @@
 
 #define SIS_LASTDESC(x)		(!((x)->sis_ctl & SIS_CMDSTS_MORE)))
 #define SIS_OWNDESC(x)		((x)->sis_ctl & SIS_CMDSTS_OWN)
-#define SIS_INC(x, y)		(x) = (x + 1) % y
+#define SIS_INC(x, y)		{ if (++(x) == y) x=0 ; }
 #define SIS_RXBYTES(x)		((x)->sis_ctl & SIS_CMDSTS_BUFLEN)
 
 #define SIS_RXSTAT_COLL		0x00010000
@@ -401,6 +401,7 @@
 	struct sis_list_data	*sis_ldata;
 	struct sis_ring_data	sis_cdata;
 	struct callout_handle	sis_stat_ch;
+	int			rxcycles;
 };
 
 /*
Index: sys/sys/systm.h
===================================================================
RCS file: /home/xorpc/u2/freebsd/src/sys/sys/systm.h,v
retrieving revision 1.111.2.8
diff -u -r1.111.2.8 systm.h
--- sys/sys/systm.h	2001/07/30 23:28:01	1.111.2.8
+++ sys/sys/systm.h	2001/11/25 16:34:15
@@ -89,6 +89,21 @@
 #define	CONDSPLASSERT(cond, level, msg)
 #endif
 
+#ifdef XORP_ETHER_POLLING
+#ifdef SMP
+#error XORP_ETHER_POLLING not yet compatible with SMP
+#endif
+extern u_int32_t poll_handlers;	/* how many handlers registered for polling */
+extern u_int32_t poll_in_trap;	/* do we poll devices in a trap ? */
+extern u_int32_t poll_burst;	/* how many pkts per poll cycle */
+
+struct	ifnet ; /* keep compiler quiet */
+typedef	void poll_handler_t __P((struct ifnet *ifp, int cmd, int count));
+int	ether_poll __P((int count));
+void	ether_poll1 __P((void));
+int	ether_poll_register __P((poll_handler_t *h, struct ifnet *sc));
+#endif /* XORP_ETHER_POLLING */
+
 /*
  * General function declarations.
  */

--mP3DRpeJDSE+ciuQ--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26 12: 7:51 2001
Delivered-To: freebsd-net@freebsd.org
Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4])
	by hub.freebsd.org (Postfix) with ESMTP id 19FFA37B41D
	for <net@FreeBSD.ORG>; Mon, 26 Nov 2001 12:07:47 -0800 (PST)
Received: from simoeon.sentex.net (pyroxene.sentex.ca [199.212.134.18])
	by smtp1.sentex.ca (8.11.6/8.11.6) with ESMTP id fAQK7TE74778;
	Mon, 26 Nov 2001 15:07:29 -0500 (EST)
	(envelope-from mike@sentex.net)
Message-Id: <5.1.0.14.0.20011126145936.046f69c0@marble.sentex.ca>
X-Sender: mdtpop@marble.sentex.ca
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 26 Nov 2001 15:01:11 -0500
To: Luigi Rizzo <rizzo@aciri.org>, net@FreeBSD.ORG
From: Mike Tancsa <mike@sentex.net>
Subject: Re: Revised polling code for STABLE
In-Reply-To: <20011126115704.L88153@iguana.aciri.org>
References: <20011027005905.A72758@iguana.aciri.org>
 <20011027005905.A72758@iguana.aciri.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

At 11:57 AM 11/26/01 -0800, Luigi Rizzo wrote:
>[Bcc to -stable in case someone is interested there]
>
>Attached you can find the latest version of the polling code
>for STABLE (which is useful to make boxes much more robust
>to attacks and have much better responsiveness under [over]load).

Thanks for this code!  Are there any particular compile time options one 
should use ? e.g. HZ=1000 etc ? The box in question would be running Zebra 
and BGPd and forwarding lots-o-packets with lots-o-routes (100k+)

         ---Mike


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26 12:22: 2 2001
Delivered-To: freebsd-net@freebsd.org
Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9])
	by hub.freebsd.org (Postfix) with ESMTP id 0228537B41B
	for <net@FreeBSD.ORG>; Mon, 26 Nov 2001 12:21:48 -0800 (PST)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.11.0/8.11.0) id fAQKJ9997042;
	Mon, 26 Nov 2001 14:19:09 -0600 (CST)
	(envelope-from jlemon)
Date: Mon, 26 Nov 2001 14:19:09 -0600
From: Jonathan Lemon <jlemon@flugsvamp.com>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: Jonathan Lemon <jlemon@flugsvamp.com>, net@FreeBSD.ORG
Subject: Re: decreasing TIME_WAIT duration(T/TCP?)
Message-ID: <20011126141909.N75389@prism.flugsvamp.com>
References: <local.mail.freebsd-net/PLEAKFMAJKNOEPLJKGBLGEJGCAAA.larse@isi.edu> <local.mail.freebsd-net/3C02275C.E4C56BF@sirena2000.ru> <200111261443.fAQEhu185094@prism.flugsvamp.com> <200111261947.fAQJl0321324@khavrinen.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <200111261947.fAQJl0321324@khavrinen.lcs.mit.edu>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Mon, Nov 26, 2001 at 02:47:00PM -0500, Garrett Wollman wrote:
> <<On Mon, 26 Nov 2001 08:43:56 -0600 (CST), Jonathan Lemon <jlemon@flugsvamp.com> said:
> 
> > Unfortunately, this is not calculated; we still rely on a static 
> > (default 30sec) MSL quiet period.  Ideally, it should be possible to
> > set MSL based on some multiple of RTT for the connection, and default 
> > to a hard coded value if there are not enough samples to calculate RTT.
> 
> There is no way to `calculate' the maximum segment lifetime unless you
> are omniscient.  It is assumed to be 30 seconds, but in reality can be
> much, much more.  (As a result, TCP is theoretically broken, but the
> situations in which this happens are rare enough to be masked by other
> events.)  The RTT gives you the *critical path length* of the graph;
> it does not have anything to do with the MSL except for trivial
> (two-node) networks.

MSL is the maximum time that the segment is assumed to exist in the
network; in practice I would interpret this to mean the maximal amount
of time it takes to travel from one node endpoint to another, taking into
account congestion, route changes, and queuing delay.

As you said, there is no way to reliably calculate this value, since the
delay is theortically unbounded; in fact RFC 793 sets it at 120 seconds.  

However, my assertion is that in most cases, the true MSL for segments
on a given connection will tend to be tied to some multiple of the RTT;
that is, there exists a strong correlation between the two.

Packets can be held up for an arbitrarily long length of time, but I
would imagine that the number of active segments after (say) 10*RTT
would not be significantly different than the number after 30 seconds.

Note that it is quite possible I'm wrong in this assertion, though.  :-)
-- 
Jonathan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26 12:33:34 2001
Delivered-To: freebsd-net@freebsd.org
Received: from clicktosecure.com (ppp-66-126-254-34.cleveldesign.com [66.126.254.34])
	by hub.freebsd.org (Postfix) with ESMTP id E19BE37B419
	for <freebsd-net@freebsd.org>; Mon, 26 Nov 2001 12:33:30 -0800 (PST)
Received: from kfu.com ([10.0.0.25]) by clicktosecure.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 26 Nov 2001 12:33:30 -0800
Message-ID: <3C02A71A.2040007@kfu.com>
Date: Mon, 26 Nov 2001 12:33:30 -0800
From: Nick Sayer <nsayer@kfu.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011
X-Accept-Language: en-us
MIME-Version: 1.0
Cc: freebsd-net@freebsd.org
Subject: Re: if_dc problem identified
References: <3C027F6A.3060708@quack.kfu.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Nov 2001 20:33:30.0107 (UTC) FILETIME=[9BFB9CB0:01C176B9]
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

One more bit of data. The document needed for doing the work I mention 
is here:

http://developer.intel.com/design/network/drivers/srom_409.pdf

If no one else steps up, I will probably give this a try in my copious 
spare time.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26 13: 7: 8 2001
Delivered-To: freebsd-net@freebsd.org
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by hub.freebsd.org (Postfix) with ESMTP id 4D89437B41B
	for <net@FreeBSD.ORG>; Mon, 26 Nov 2001 13:07:02 -0800 (PST)
Received: from isi.edu (nlpxnd1jsu3riexh@hbo.isi.edu [128.9.160.75])
	by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id fAQL6xN20261;
	Mon, 26 Nov 2001 13:06:59 -0800 (PST)
Message-ID: <3C02AEF3.3000502@isi.edu>
Date: Mon, 26 Nov 2001 13:06:59 -0800
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011121
X-Accept-Language: en, de
MIME-Version: 1.0
To: Jonathan Lemon <jlemon@flugsvamp.com>
Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, net@FreeBSD.ORG
Subject: Re: decreasing TIME_WAIT duration(T/TCP?)
References: <local.mail.freebsd-net/PLEAKFMAJKNOEPLJKGBLGEJGCAAA.larse@isi.edu> <local.mail.freebsd-net/3C02275C.E4C56BF@sirena2000.ru> <200111261443.fAQEhu185094@prism.flugsvamp.com> <200111261947.fAQJl0321324@khavrinen.lcs.mit.edu> <20011126141909.N75389@prism.flugsvamp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Jonathan Lemon wrote:

> As you said, there is no way to reliably calculate this value, since the
> delay is theortically unbounded; in fact RFC 793 sets it at 120 seconds.  
> 
> However, my assertion is that in most cases, the true MSL for segments
> on a given connection will tend to be tied to some multiple of the RTT;
> that is, there exists a strong correlation between the two.

While I agree that the average "segment lifetime" of a given connection 
is probably on the same order of magnitude than the RTT, this does not 
have any impact on the MAXIMUM segment lifetime: it's an Internet-wide 
upper bound. Even for connections with millisecond RTTs, packets can be 
delayed for seconds or longer due to routing glitches.

The original poster wanted to shorten the MSL to avoid accumulating TIME 
WAITs at the server. There are better techniques for that, see for 
example Ted Faber's paper in INFOCOM '99 
(http://www.isi.edu/~faber/pubs.html).

Lars
-- 
Lars Eggert <larse@isi.edu>               Information Sciences Institute
http://www.isi.edu/larse/              University of Southern California


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26 15:58:29 2001
Delivered-To: freebsd-net@freebsd.org
Received: from hotmail.com (f28.pav2.hotmail.com [64.4.37.28])
	by hub.freebsd.org (Postfix) with ESMTP id 3A12737B41A
	for <net@freebsd.org>; Mon, 26 Nov 2001 15:58:19 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 26 Nov 2001 15:58:19 -0800
Received: from 204.178.20.14 by pv2fd.pav2.hotmail.msn.com with HTTP;
	Mon, 26 Nov 2001 23:58:18 GMT
X-Originating-IP: [204.178.20.14]
From: "murthy kn" <knmurthy30@hotmail.com>
To: jlemon@flugsvamp.com
Cc: net@freebsd.org
Subject: Re: Understanding fxp driver
Date: Tue, 27 Nov 2001 05:28:18 +0530
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F28riLdElsBt8sBjukJ00015693@hotmail.com>
X-OriginalArrivalTime: 26 Nov 2001 23:58:19.0089 (UTC) FILETIME=[38C97410:01C176D6]
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Thanks.


>
> >4. Suppose I want to make the NIC interrupt the cpu for each packet,
> >if I just reduce the Tx DMA length to 2-power-0, i.e,1, will it work?
>
>No, that won't work, but why would you want to do that?

------> I have a virtual interface that Round Robins packets
over the actual physical interface. ( modified ng_etherchannelbonding). But, 
the receiver is
getting the packets out-of-order - as expected, when packets
are of different size, but, I am
not understanding, why,even when the 2 NICs are identical and
packets are of MTU size, reordering is occuring.

Any clues welcome.

I was  trying to see if the reason is the fact that each NIC puts up a lot 
of packets at a time to the TX DMA Area - and so, is it possible
in any way to gain a better contol over the actual sending of packets.



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26 17:54: 8 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mailrelay.netcologne.de (mailrelay.netcologne.de [194.8.194.96])
	by hub.freebsd.org (Postfix) with ESMTP
	id 52E1F37B419; Mon, 26 Nov 2001 17:53:54 -0800 (PST)
Received: from design.freestyling.de (design.freestyling.de [195.14.253.182])
	by mailrelay.netcologne.de (8.11.6/8.11.6) with ESMTP id fAR1ro729059;
	Tue, 27 Nov 2001 02:53:50 +0100 (MET)
X-Received: from tick.sc.omation.com (64-58-167-31.cbi.cox-oc.net [64.58.167.31] (may be forged))
	by design.freestyling.de (8.11.3/8.11.3) with ESMTP id fAR1vF294206
	for <pherman@design.freestyling.de>; Tue, 27 Nov 2001 02:57:15 +0100 (CET)
	(envelope-from pherman@frenchfries.net)
X-Received: from tick.sc.omation.com (tick.sc.omation.com [192.168.128.2])
	by tick.sc.omation.com (8.11.6/8.11.6) with ESMTP id fAR1qnE44864;
	Mon, 26 Nov 2001 17:52:49 -0800 (PST)
	(envelope-from pherman@frenchfries.net)
Date: Mon, 26 Nov 2001 17:52:49 -0800 (PST)
From: Paul Herman <pherman@frenchfries.net>
X-X-Sender:  <pherman@tick.sc.omation.com>
To: Ruslan Ermilov <ru@FreeBSD.ORG>
Cc: <freebsd-net@FreeBSD.ORG>
Subject: Re: arp_rtrequest: bad gateway value
In-Reply-To: <20011123160634.I49441-100000@tick.sc.omation.com>
Message-ID: <20011126173433.W39004-100000@tick.sc.omation.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Fri, 23 Nov 2001, Paul Herman wrote:

> On Thu, 22 Nov 2001, Ruslan Ermilov wrote:
>
> > On Wed, Nov 21, 2001 at 05:32:27PM -0800, Paul Herman wrote:
> > > Hi,
> > >
> > > I'd like to pick some brains before I file a PR.
> > >
> > There's already a PR open on this, kern/29170.
> >
> > [...]
> >

Here's a patch against 4.4-RELEASE that fixes this problem.  As
mentioned before, the problem happens when a gateway with the
RTF_LLINFO set gets polluted with non-link information.  routed and
route are both culprits.  BTW, KAME does this as well by putting
AF_INET6 data into gateways with the RTF_LLINFO flag set, which I
don't think is a good idea, but it calls rt_setgate() directly and
isn't affected by this patch.

I've decided to have the kernel leave the gateway untouched and
continue, rather than having the kernel return EINVAL.  This
produces the least astonishment :-)

Please review and if it's OK, I'll send it to gnats for the audit
trail.  Thanks,

-Paul.

Index: sys/net/rtsock.c
===================================================================
RCS file: /mnt/ncvs/src/sys/net/rtsock.c,v
retrieving revision 1.44.2.4
diff -u -r1.44.2.4 rtsock.c
--- sys/net/rtsock.c	2001/07/11 09:37:37	1.44.2.4
+++ sys/net/rtsock.c	2001/11/27 01:33:03
@@ -399,6 +399,14 @@
 			break;

 		case RTM_CHANGE:
+			/* Don't let the user specify non-link information
+			 * for a gateway if the RTF_LLINFO flag is set.
+			 * We'll just leave the gateway alone.
+			 */
+			if (gate && (rt->rt_flags & RTF_LLINFO) &&
+			    gate->sa_family != AF_LINK)
+				gate = rt->rt_gateway;
+
 			if (gate && (error = rt_setgate(rt, rt_key(rt), gate)))
 				senderr(error);





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26 17:57:58 2001
Delivered-To: freebsd-net@freebsd.org
Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40])
	by hub.freebsd.org (Postfix) with ESMTP id 37F0037B491
	for <freebsd-net@freebsd.org>; Mon, 26 Nov 2001 17:57:43 -0800 (PST)
Received: from xena.gsicomp.on.ca ([199.243.149.34])
          by tomts7-srv.bellnexxia.net
          (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP
          id <20011127015741.LYZZ9080.tomts7-srv.bellnexxia.net@xena.gsicomp.on.ca>
          for <freebsd-net@freebsd.org>; Mon, 26 Nov 2001 20:57:41 -0500
Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18])
	by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id fAR1nSW54983
	for <freebsd-net@freebsd.org>; Mon, 26 Nov 2001 20:49:29 -0500 (EST)
	(envelope-from matt@gsicomp.on.ca)
Message-ID: <004801c176e6$e57a2eb0$1200a8c0@gsicomp.on.ca>
From: "Matthew Emmerton" <matt@gsicomp.on.ca>
To: <freebsd-net@freebsd.org>
Subject: Very strange network behaviour - can anyone help me analyse tcpdump output?
Date: Mon, 26 Nov 2001 20:57:38 -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.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Hi all,

In the continuing saga of IPSec over PPPoE for a retail POS environment that
I'm maintaing, the problems seem to become more complex as time goes on.

The network is quite simple:
[ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway #2 ] - [
LAN #2 ]

Both LANs connect using PPPoE with the same ISP, and are one hop apart
(according to traceroute).

The problem is that a connection from the Internet (anywhere) to either of
the FreeBSD gateways will "hang".  Usually I can login but doing an 'ls -al'
will display a few lines of text and then nothing.  This happens using a
bunch of telnet clients (Anzio on Win2K, Win2K and Win95 native, FreeBSD)
from various ISPs, as well as *between* the gateways, so the problem is most
definitely related to the ISP providing us service.  However, they seem to
think that it's our problem ("none of the customers that use Windows have
this problem -- must be that Unix thing that you're using").

I have an ethereal trace of a hanging telnet session from my desktop to one
of the gateway machines, and the corresponding tcpdump trace of the same
session on the gateway.  Since I'm not too familiar with TCP/IP at such a
low level, I was wondering if anyone would be willing to take a look at the
two dumps and see if there is anything strange going on.

Thanks,

--
Matt Emmerton


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26 18:20:24 2001
Delivered-To: freebsd-net@freebsd.org
Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9])
	by hub.freebsd.org (Postfix) with ESMTP id DE09937B41A
	for <freebsd-net@freebsd.org>; Mon, 26 Nov 2001 18:20:16 -0800 (PST)
Received: from localhost (localhost.elischer.org [127.0.0.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA06174;
	Mon, 26 Nov 2001 18:03:30 -0800 (PST)
Date: Mon, 26 Nov 2001 18:03:30 -0800 (PST)
From: Julian Elischer <julian@elischer.org>
To: Matthew Emmerton <matt@gsicomp.on.ca>
Cc: freebsd-net@freebsd.org
Subject: Re: Very strange network behaviour - can anyone help me analyse
 tcpdump output?
In-Reply-To: <004801c176e6$e57a2eb0$1200a8c0@gsicomp.on.ca>
Message-ID: <Pine.BSF.4.21.0111261802070.5212-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org



On Mon, 26 Nov 2001, Matthew Emmerton wrote:

> Hi all,
> 
> In the continuing saga of IPSec over PPPoE for a retail POS environment that
> I'm maintaing, the problems seem to become more complex as time goes on.
> 
> The network is quite simple:
> [ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway #2 ] - [
> LAN #2 ]
> 
> Both LANs connect using PPPoE with the same ISP, and are one hop apart
> (according to traceroute).
> 
> The problem is that a connection from the Internet (anywhere) to either of
> the FreeBSD gateways will "hang".  Usually I can login but doing an 'ls -al'
> will display a few lines of text and then nothing.  This happens using a
> bunch of telnet clients (Anzio on Win2K, Win2K and Win95 native, FreeBSD)
> from various ISPs, as well as *between* the gateways, so the problem is most
> definitely related to the ISP providing us service.  However, they seem to
> think that it's our problem ("none of the customers that use Windows have
> this problem -- must be that Unix thing that you're using").

If you are using gif, make sure it has a small MTU (try 512 bytes)

> 
> I have an ethereal trace of a hanging telnet session from my desktop to one
> of the gateway machines, and the corresponding tcpdump trace of the same
> session on the gateway.  Since I'm not too familiar with TCP/IP at such a
> low level, I was wondering if anyone would be willing to take a look at the
> two dumps and see if there is anything strange going on.
> 
> Thanks,
> 
> --
> Matt Emmerton
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Mon Nov 26 18:27:50 2001
Delivered-To: freebsd-net@freebsd.org
Received: from tomts9-srv.bellnexxia.net (tomts9.bellnexxia.net [209.226.175.53])
	by hub.freebsd.org (Postfix) with ESMTP id 0B67937B405
	for <freebsd-net@FreeBSD.ORG>; Mon, 26 Nov 2001 18:27:44 -0800 (PST)
Received: from xena.gsicomp.on.ca ([199.243.149.34])
          by tomts9-srv.bellnexxia.net
          (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP
          id <20011127022743.ZYIQ20714.tomts9-srv.bellnexxia.net@xena.gsicomp.on.ca>;
          Mon, 26 Nov 2001 21:27:43 -0500
Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18])
	by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id fAR2JUW55053;
	Mon, 26 Nov 2001 21:19:30 -0500 (EST)
	(envelope-from matt@gsicomp.on.ca)
Message-ID: <006a01c176eb$172f6a20$1200a8c0@gsicomp.on.ca>
From: "Matthew Emmerton" <matt@gsicomp.on.ca>
To: "Julian Elischer" <julian@elischer.org>
Cc: <freebsd-net@FreeBSD.ORG>
References: <Pine.BSF.4.21.0111261802070.5212-100000@InterJet.elischer.org>
Subject: Re: Very strange network behaviour - can anyone help me analyse tcpdump output?
Date: Mon, 26 Nov 2001 21:27:40 -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.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

> On Mon, 26 Nov 2001, Matthew Emmerton wrote:
>
> > Hi all,
> >
> > In the continuing saga of IPSec over PPPoE for a retail POS environment
that
> > I'm maintaing, the problems seem to become more complex as time goes on.
> >
> > The network is quite simple:
> > [ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway #2 ] -
[
> > LAN #2 ]
> >
> > Both LANs connect using PPPoE with the same ISP, and are one hop apart
> > (according to traceroute).
> >
> > The problem is that a connection from the Internet (anywhere) to either
of
> > the FreeBSD gateways will "hang".  Usually I can login but doing an
'ls -al'
> > will display a few lines of text and then nothing.  This happens using a
> > bunch of telnet clients (Anzio on Win2K, Win2K and Win95 native,
FreeBSD)
> > from various ISPs, as well as *between* the gateways, so the problem is
most
> > definitely related to the ISP providing us service.  However, they seem
to
> > think that it's our problem ("none of the customers that use Windows
have
> > this problem -- must be that Unix thing that you're using").
>
> If you are using gif, make sure it has a small MTU (try 512 bytes)

belmont.heers.on.ca# ifconfig gif0
gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280
        inet 10.0.2.2 --> 10.0.2.130 netmask 0xffffffff
belmont.heers.on.ca# ifconfig gif0 mtu 512
ifconfig: ioctl (set mtu): Invalid argument
belmont.heers.on.ca# gifconfig gif0 mtu 512
gifconfig: mtu: bad value
belmont.heers.on.ca#

How am I supposed to change the MTU?
(These machines are running 4.3-RELEASE-p12)

--
Matt Emmerton


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27  1:20:24 2001
Delivered-To: freebsd-net@freebsd.org
Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9])
	by hub.freebsd.org (Postfix) with ESMTP id 2DCF637B798
	for <freebsd-net@FreeBSD.ORG>; Tue, 27 Nov 2001 01:20:16 -0800 (PST)
Received: from localhost (localhost.elischer.org [127.0.0.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA07527;
	Tue, 27 Nov 2001 01:03:17 -0800 (PST)
Date: Tue, 27 Nov 2001 01:03:15 -0800 (PST)
From: Julian Elischer <julian@elischer.org>
To: Matthew Emmerton <matt@gsicomp.on.ca>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: Very strange network behaviour - can anyone help me analyse
 tcpdump output?
In-Reply-To: <006a01c176eb$172f6a20$1200a8c0@gsicomp.on.ca>
Message-ID: <Pine.BSF.4.21.0111270102060.7513-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

ok, well at least use the ability of ppp to 'forge' the mss 
negotiated.. that will also keep the packet sizes down.
(It just sonds like that to me....)



On Mon, 26 Nov 2001, Matthew Emmerton wrote:

> > On Mon, 26 Nov 2001, Matthew Emmerton wrote:
> >
> > > Hi all,
> > >
> > > In the continuing saga of IPSec over PPPoE for a retail POS environment
> that
> > > I'm maintaing, the problems seem to become more complex as time goes on.
> > >
> > > The network is quite simple:
> > > [ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway #2 ] -
> [
> > > LAN #2 ]
> > >
> > > Both LANs connect using PPPoE with the same ISP, and are one hop apart
> > > (according to traceroute).
> > >
> > > The problem is that a connection from the Internet (anywhere) to either
> of
> > > the FreeBSD gateways will "hang".  Usually I can login but doing an
> 'ls -al'
> > > will display a few lines of text and then nothing.  This happens using a
> > > bunch of telnet clients (Anzio on Win2K, Win2K and Win95 native,
> FreeBSD)
> > > from various ISPs, as well as *between* the gateways, so the problem is
> most
> > > definitely related to the ISP providing us service.  However, they seem
> to
> > > think that it's our problem ("none of the customers that use Windows
> have
> > > this problem -- must be that Unix thing that you're using").
> >
> > If you are using gif, make sure it has a small MTU (try 512 bytes)
> 
> belmont.heers.on.ca# ifconfig gif0
> gif0: flags=8011<UP,POINTOPOINT,MULTICAST> mtu 1280
>         inet 10.0.2.2 --> 10.0.2.130 netmask 0xffffffff
> belmont.heers.on.ca# ifconfig gif0 mtu 512
> ifconfig: ioctl (set mtu): Invalid argument
> belmont.heers.on.ca# gifconfig gif0 mtu 512
> gifconfig: mtu: bad value
> belmont.heers.on.ca#
> 
> How am I supposed to change the MTU?
> (These machines are running 4.3-RELEASE-p12)
> 
> --
> Matt Emmerton
> 
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27  2:47:18 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70])
	by hub.freebsd.org (Postfix) with SMTP id AA9BD37B429
	for <freebsd-net@freebsd.org>; Tue, 27 Nov 2001 02:47:10 -0800 (PST)
Received: (qmail 97755 invoked from network); 27 Nov 2001 10:46:52 -0000
Received: from unknown (HELO pipeline.ch) ([62.48.21.59]) (envelope-sender <oppermann@pipeline.ch>)
          by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP
          for <matt@gsicomp.on.ca>; 27 Nov 2001 10:46:52 -0000
Message-ID: <3C036E9D.21808A44@pipeline.ch>
Date: Tue, 27 Nov 2001 11:44:45 +0100
From: Andre Oppermann <oppermann@pipeline.ch>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matthew Emmerton <matt@gsicomp.on.ca>
Cc: freebsd-net@freebsd.org
Subject: Re: Very strange network behaviour - can anyone help me analyse tcpdump 
 output?
References: <004801c176e6$e57a2eb0$1200a8c0@gsicomp.on.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Matthew Emmerton wrote:
> 
> Hi all,
> 
> In the continuing saga of IPSec over PPPoE for a retail POS environment that
> I'm maintaing, the problems seem to become more complex as time goes on.
> 
> The network is quite simple:
> [ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway #2 ] - [
> LAN #2 ]
> 
> Both LANs connect using PPPoE with the same ISP, and are one hop apart
> (according to traceroute).

This smells like MTU problems. Try to set the MTU on your physical LAN
interfaces to something like 1480 or so any try again.

-- 
Andre


> The problem is that a connection from the Internet (anywhere) to either of
> the FreeBSD gateways will "hang".  Usually I can login but doing an 'ls -al'
> will display a few lines of text and then nothing.  This happens using a
> bunch of telnet clients (Anzio on Win2K, Win2K and Win95 native, FreeBSD)
> from various ISPs, as well as *between* the gateways, so the problem is most
> definitely related to the ISP providing us service.  However, they seem to
> think that it's our problem ("none of the customers that use Windows have
> this problem -- must be that Unix thing that you're using").
> 
> I have an ethereal trace of a hanging telnet session from my desktop to one
> of the gateway machines, and the corresponding tcpdump trace of the same
> session on the gateway.  Since I'm not too familiar with TCP/IP at such a
> low level, I was wondering if anyone would be willing to take a look at the
> two dumps and see if there is anything strange going on.
> 
> Thanks,
> 
> --
> Matt Emmerton
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27  9: 3:29 2001
Delivered-To: freebsd-net@freebsd.org
Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4])
	by hub.freebsd.org (Postfix) with ESMTP id 1E48037B43B
	for <net@FreeBSD.ORG>; Tue, 27 Nov 2001 09:03:14 -0800 (PST)
Received: from simoeon.sentex.net (pyroxene.sentex.ca [199.212.134.18])
	by smtp1.sentex.ca (8.11.6/8.11.6) with ESMTP id fARH3A905669;
	Tue, 27 Nov 2001 12:03:10 -0500 (EST)
	(envelope-from mike@sentex.net)
Message-Id: <5.1.0.14.0.20011127113111.04f0b390@marble.sentex.ca>
X-Sender: mdtpop@marble.sentex.ca
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 27 Nov 2001 11:56:45 -0500
To: Luigi Rizzo <rizzo@aciri.org>, net@FreeBSD.ORG
From: Mike Tancsa <mike@sentex.net>
Subject: Re: Revised polling code (some stats)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


Hi, just as an FYI, I did some simple tests using netperf of the polling 
code. On first blush, it does look quite nice.  I am going to try and 
simulate  what the effect is under network load while at the same time, 
trying to bring up a BGP peer with a full view.

Machine A is a PIII 800 with a D-Link 4port NIC using the dc 
driver.  Connected to it was a PIV 1.5 845 chipset board with integrated 
fxp running the server portion of netperf

On the PIII with the Dlink card I ran the tests only varying
net.xorp.polling: 0
vs
net.xorp.polling: 1


The other nice thing of course of the polling code that does not show up in 
the figures below is the load average, which on the stream test at least 
shows .


                     /0   /10  /20  /30  /40  /50  /60  /70  /80  /90  /100
              <idle> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+POLL        <idle> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


/usr/local/netperf/netperf -t TCP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 
-- -s 57344 -S 57344 -m 4096
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

  57344  57344   4096    60.06      60.10   +POLL
  57344  57344   4096    60.00      59.37


/usr/local/netperf/netperf -t TCP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 
-- -s 32768 -S 32768 -m 4096
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

  32768  32768   4096    59.99      61.31   +POLL
  32768  32768   4096    60.16      60.73


/usr/local/netperf/netperf -t TCP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- 
-r 1,1
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

16384  16384  1        1       59.99    8260.80   +POLL
16384  16384  1        1       59.99    6072.08


/usr/local/netperf/netperf -t UDP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- 
-r 1,1
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

9216   42080  1        1       59.99    10398.39   +POLL
9216   42080  1        1       59.99    9248.39


/usr/local/netperf/netperf -t UDP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- 
-r 516,4
UDP REQUEST/RESPONSE TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

9216   42080  516      4       59.99    5857.40   +POLL
9216   42080  516      4       59.99    5482.58



/usr/local/netperf/netperf -t UDP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 
-- -s 32768 -S 32768 -m 4096

UDP UNIDIRECTIONAL SEND TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
Socket  Message  Elapsed      Messages
Size    Size     Time         Okay Errors   Throughput
bytes   bytes    secs            #      #   10^6bits/sec

  32768    4096   59.99      115161 10324576      62.90 +POLL
  32768           59.99      114009             62.27 +POLL
  32768    4096   59.99      108361 7401883      59.19
  32768           59.99      108342             59.18

  32768    1024   59.99      478638 13513083      65.36 +POLL
  32768           59.99      478475             65.34 +POLL
  32768    1024   59.99      452463 8759390      61.79
  32768           59.99      451930             61.71


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27  9:13:23 2001
Delivered-To: freebsd-net@freebsd.org
Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36])
	by hub.freebsd.org (Postfix) with ESMTP id 1624137B416
	for <net@FreeBSD.ORG>; Tue, 27 Nov 2001 09:13:18 -0800 (PST)
Received: (from rizzo@localhost)
	by iguana.aciri.org (8.11.3/8.11.1) id fARH97X99724;
	Tue, 27 Nov 2001 09:09:07 -0800 (PST)
	(envelope-from rizzo)
Date: Tue, 27 Nov 2001 09:09:07 -0800
From: Luigi Rizzo <rizzo@aciri.org>
To: Mike Tancsa <mike@sentex.net>
Cc: net@FreeBSD.ORG
Subject: Re: Revised polling code (some stats)
Message-ID: <20011127090907.A99632@iguana.aciri.org>
References: <5.1.0.14.0.20011127113111.04f0b390@marble.sentex.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5.1.0.14.0.20011127113111.04f0b390@marble.sentex.ca>
User-Agent: Mutt/1.3.23i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Tue, Nov 27, 2001 at 11:56:45AM -0500, Mike Tancsa wrote:
> 
> Hi, just as an FYI, I did some simple tests using netperf of the polling 
> code. On first blush, it does look quite nice.  I am going to try and 

well, the throughput numbers seems essentially unmodified,
which is not surprising given that with large packet sizes
your hardware should be able to bear the load.

I have to say that 60Mbit/s for TCP seems a bit low given your
hardware, i wonder if you are using half-duplex link
(this would explain the huge number of errors in the udp test).
If so, you should really re-run the test with full-duplex.

	cheers
	luigi


> Local /Remote
> Socket Size   Request  Resp.   Elapsed  Trans.
> Send   Recv   Size     Size    Time     Rate
> bytes  Bytes  bytes    bytes   secs.    per sec
> 
> 9216   42080  1        1       59.99    10398.39   +POLL
> 9216   42080  1        1       59.99    9248.39
> 
> 
> /usr/local/netperf/netperf -t UDP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- 
> -r 516,4
> UDP REQUEST/RESPONSE TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
> Local /Remote
> Socket Size   Request  Resp.   Elapsed  Trans.
> Send   Recv   Size     Size    Time     Rate
> bytes  Bytes  bytes    bytes   secs.    per sec
> 
> 9216   42080  516      4       59.99    5857.40   +POLL
> 9216   42080  516      4       59.99    5482.58
> 
> 
> 
> /usr/local/netperf/netperf -t UDP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 
> -- -s 32768 -S 32768 -m 4096
> 
> UDP UNIDIRECTIONAL SEND TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
> Socket  Message  Elapsed      Messages
> Size    Size     Time         Okay Errors   Throughput
> bytes   bytes    secs            #      #   10^6bits/sec
> 
>  32768    4096   59.99      115161 10324576      62.90 +POLL
>  32768           59.99      114009             62.27 +POLL
>  32768    4096   59.99      108361 7401883      59.19
>  32768           59.99      108342             59.18
> 
>  32768    1024   59.99      478638 13513083      65.36 +POLL
>  32768           59.99      478475             65.34 +POLL
>  32768    1024   59.99      452463 8759390      61.79
>  32768           59.99      451930             61.71
> 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27  9:21:16 2001
Delivered-To: freebsd-net@freebsd.org
Received: from tomts20-srv.bellnexxia.net (tomts20.bellnexxia.net [209.226.175.74])
	by hub.freebsd.org (Postfix) with ESMTP id BD13137B417
	for <freebsd-net@FreeBSD.ORG>; Tue, 27 Nov 2001 09:21:04 -0800 (PST)
Received: from xena.gsicomp.on.ca ([199.243.149.34])
          by tomts20-srv.bellnexxia.net
          (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP
          id <20011127172103.ZMVL25459.tomts20-srv.bellnexxia.net@xena.gsicomp.on.ca>;
          Tue, 27 Nov 2001 12:21:03 -0500
Received: from localhost (matt@localhost)
	by xena.gsicomp.on.ca (8.11.1/8.11.1) with ESMTP id fARHCoV57133;
	Tue, 27 Nov 2001 12:12:51 -0500 (EST)
	(envelope-from matt@xena.gsicomp.on.ca)
Date: Tue, 27 Nov 2001 12:12:50 -0500 (EST)
From: Matthew Emmerton <matt@gsicomp.on.ca>
To: Andre Oppermann <oppermann@pipeline.ch>, julian@elischer.org
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: Very strange network behaviour - can anyone help me analyse
 tcpdump  output?
In-Reply-To: <3C036E9D.21808A44@pipeline.ch>
Message-ID: <Pine.BSF.4.21.0111271041160.56896-100000@xena.gsicomp.on.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


On Tue, 27 Nov 2001, Andre Oppermann wrote:

> Matthew Emmerton wrote:
> > 
> > Hi all,
> > 
> > In the continuing saga of IPSec over PPPoE for a retail POS environment that
> > I'm maintaing, the problems seem to become more complex as time goes on.
> > 
> > The network is quite simple:
> > [ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway #2 ] - [
> > LAN #2 ]
> > 
> > Both LANs connect using PPPoE with the same ISP, and are one hop apart
> > (according to traceroute).
> 
> This smells like MTU problems. Try to set the MTU on your physical LAN
> interfaces to something like 1480 or so any try again.

That's what I thought too.  I checked, and ppp is doing the TPC MSS
fixup.  Even after removing the gif/ipsec stuff that I was doing
(less overhead, and converting this installation into a plain
LAN-behind-NAT setup), the problem persists.

I tried dropping the MTU on my LAN interface to 1200 (from 1500), but that
didn't change anything.

If my ISP installed a bunch of really buggy hardware, would that explain
why this started happening recently without any changes on my side?

--
Matt Emmerton


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27  9:41: 5 2001
Delivered-To: freebsd-net@freebsd.org
Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4])
	by hub.freebsd.org (Postfix) with ESMTP id 3D78837B419
	for <net@FreeBSD.ORG>; Tue, 27 Nov 2001 09:41:02 -0800 (PST)
Received: from simoeon.sentex.net (pyroxene.sentex.ca [199.212.134.18])
	by smtp1.sentex.ca (8.11.6/8.11.6) with ESMTP id fARHf0E11202;
	Tue, 27 Nov 2001 12:41:00 -0500 (EST)
	(envelope-from mike@sentex.net)
Message-Id: <5.1.0.14.0.20011127122334.036f8090@marble.sentex.ca>
X-Sender: mdtpop@marble.sentex.ca
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 27 Nov 2001 12:34:36 -0500
To: Luigi Rizzo <rizzo@aciri.org>
From: Mike Tancsa <mike@sentex.net>
Subject: Re: Revised polling code (some stats)
Cc: net@FreeBSD.ORG
In-Reply-To: <20011127090907.A99632@iguana.aciri.org>
References: <5.1.0.14.0.20011127113111.04f0b390@marble.sentex.ca>
 <5.1.0.14.0.20011127113111.04f0b390@marble.sentex.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

At 09:09 AM 11/27/01 -0800, Luigi Rizzo wrote:
>On Tue, Nov 27, 2001 at 11:56:45AM -0500, Mike Tancsa wrote:
> >
> > Hi, just as an FYI, I did some simple tests using netperf of the polling
> > code. On first blush, it does look quite nice.  I am going to try and
>
>well, the throughput numbers seems essentially unmodified,
>which is not surprising given that with large packet sizes
>your hardware should be able to bear the load.
>
>I have to say that 60Mbit/s for TCP seems a bit low given your
>hardware, i wonder if you are using half-duplex link
>(this would explain the huge number of errors in the udp test).
>If so, you should really re-run the test with full-duplex.

Hmmm, I think you are right!

fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         inet6 fe80::201:80ff:fe10:46a3%fxp0 prefixlen 64 scopeid 0x2
         inet 10.1.1.1 netmask 0xffffff00 broadcast 10.1.1.255
         ether 00:01:80:10:46:a3
         media: Ethernet autoselect (100baseTX)
         status: active
marble4#

dc3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         inet6 fe80::280:c8ff:fef8:51d4%dc3 prefixlen 64 scopeid 0x4
         inet 10.1.1.2 netmask 0xffffff00 broadcast 10.1.1.255
         ether 00:80:c8:f8:51:d4
         media: Ethernet 100baseTX <full-duplex>
         status: active

Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll
fxp0  1500  <Link#2>    00:01:80:10:46:a3 42682189     4 27310290     0 338169


That is strange, the fxp _used_ to negotiate duplex settings just fine 
against this card. Perhaps its this poxy onboard variant!

fxp0: <Intel Pro/100 Ethernet> port 0xc800-0xc83f mem 0xe7001000-0xe7001fff 
irq 10 at device 8.0 on pci2
fxp0: Ethernet address 00:01:80:10:46:a3
inphy0: <i82562ET 10/100 media interface> on miibus1
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

I will re-run them.

         ---Mike


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27 11:47:45 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10])
	by hub.freebsd.org (Postfix) with ESMTP id 1375737B41A
	for <freebsd-net@freebsd.org>; Tue, 27 Nov 2001 11:47:37 -0800 (PST)
Received: from nimitz.packetdesign.com (nimitz.packetdesign.com [192.168.0.184])
	by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id fARJla531318;
	Tue, 27 Nov 2001 11:47:36 -0800 (PST)
	(envelope-from bmah@packetdesign.com)
Received: (from bmah@localhost)
	by nimitz.packetdesign.com (8.11.6/8.11.6) id fARJlaq00597;
	Tue, 27 Nov 2001 11:47:36 -0800 (PST)
	(envelope-from bmah)
Message-Id: <200111271947.fARJlaq00597@nimitz.packetdesign.com>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: freebsd-net@freebsd.org
Cc: bmah@packetdesign.com
Subject: RFC: MFC M_ZERO usage for bpf.c
From: bmah@packetdesign.com (Bruce A. Mah)
Reply-To: bmah@packetdesign.com
X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5<Pi&akO)o^8;[r
 %l(8ZHlbF`dD>v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A
 2V%N&+
X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif
X-Url: http://www.employees.org/~bmah/
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1865514496P";
	 micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 27 Nov 2001 11:47:36 -0800
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

--==_Exmh_1865514496P
Content-Type: text/plain; charset=us-ascii

Hi--

I've been reading through src/sys/net/bpf.c, and I noticed that the
changes to make it use M_ZERO haven't been MFC-ed to RELENG_4 yet.  Any
objection if I do this?  (Nothing broke in my quick testing.)

Thanks,

Bruce.

Index: bpf.c
===================================================================
RCS file: /usr/ncvs/src/sys/net/bpf.c,v
retrieving revision 1.59.2.6
diff -u -r1.59.2.6 bpf.c
--- bpf.c	20 Sep 2001 14:31:33 -0000	1.59.2.6
+++ bpf.c	27 Nov 2001 18:49:45 -0000
@@ -358,8 +358,7 @@
 	if (d)
 		return (EBUSY);
 	make_dev(&bpf_cdevsw, minor(dev), 0, 0, 0600, "bpf%d", lminor(dev));
-	MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK);
-	bzero(d, sizeof(*d));
+	MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK | M_ZERO);
 	dev->si_drv1 = d;
 	d->bd_bufsize = bpf_bufsize;
 	d->bd_sig = SIGIO;
@@ -1285,11 +1284,10 @@
 	u_int dlt, hdrlen;
 {
 	struct bpf_if *bp;
-	bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT);
+	bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT | M_ZERO);
 	if (bp == 0)
 		panic("bpfattach");
 
-	bp->bif_dlist = 0;
 	bp->bif_ifp = ifp;
 	bp->bif_dlt = dlt;
 



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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: Exmh on FreeBSD

iD8DBQE8A+3Y2MoxcVugUsMRAl5/AJwOOfK4eWs8cBXCCssGhHoL0EXiKACgsgKO
GAWQ29KVho5yzajShM5Jrio=
=OroY
-----END PGP SIGNATURE-----

--==_Exmh_1865514496P--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27 11:48:24 2001
Delivered-To: freebsd-net@freebsd.org
Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4])
	by hub.freebsd.org (Postfix) with ESMTP id ADF9D37B416
	for <net@FreeBSD.ORG>; Tue, 27 Nov 2001 11:48:14 -0800 (PST)
Received: from simoeon.sentex.net (pyroxene.sentex.ca [199.212.134.18])
	by smtp1.sentex.ca (8.11.6/8.11.6) with ESMTP id fARJmC729850;
	Tue, 27 Nov 2001 14:48:12 -0500 (EST)
	(envelope-from mike@sentex.net)
Message-Id: <5.1.0.14.0.20011127140608.04f23c20@marble.sentex.ca>
X-Sender: mdtpop@marble.sentex.ca
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 27 Nov 2001 14:41:47 -0500
To: Luigi Rizzo <rizzo@aciri.org>
From: Mike Tancsa <mike@sentex.net>
Subject: Re: Revised polling code (some stats II)
Cc: net@FreeBSD.ORG
In-Reply-To: <20011127090907.A99632@iguana.aciri.org>
References: <5.1.0.14.0.20011127113111.04f0b390@marble.sentex.ca>
 <5.1.0.14.0.20011127113111.04f0b390@marble.sentex.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

At 09:09 AM 11/27/01 -0800, Luigi Rizzo wrote:
>On Tue, Nov 27, 2001 at 11:56:45AM -0500, Mike Tancsa wrote:
> >
> > Hi, just as an FYI, I did some simple tests using netperf of the polling
> > code. On first blush, it does look quite nice.  I am going to try and
>
>well, the throughput numbers seems essentially unmodified,
>which is not surprising given that with large packet sizes
>your hardware should be able to bear the load.
>
>I have to say that 60Mbit/s for TCP seems a bit low given your
>hardware, i wonder if you are using half-duplex link


The strange thing is that its not much better having fixed the duplex 
issue. I notice in dmesg that
dc3: TX underrun -- increasing TX threshold
dc3: TX underrun -- increasing TX threshold
dc3: TX underrun -- increasing TX threshold
dc3: TX underrun -- using store and forward mode

But I have found that to be normal for the card.



Anyways, here are the stats going from dc2 (PIII 800) to an fxp card on a PIV.



------------------------------------
Testing with the following command line:
/usr/local/netperf/netperf -t TCP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 
-- -s 57344 -S 57344 -m 4096

TCP STREAM TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

  57344  57344   4096    60.00      62.52
  57344  57344   4096    60.00      64.19   +POLL


/usr/local/netperf/netperf -t TCP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 
-- -s 32768 -S 32768 -m 4096

TCP STREAM TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

  32768  32768   4096    59.99      64.19
  32768  32768   4096    59.99      65.23   +POLL


/usr/local/netperf/netperf -t TCP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- 
-r 1,1

TCP REQUEST/RESPONSE TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

16384  16384  1        1       59.99    6072.04
16384  16384  1        1       59.99    8351.88   +POLL



/usr/local/netperf/netperf -t UDP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- 
-r 1,1

UDP REQUEST/RESPONSE TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

9216   42080  1        1       59.99    9473.54
9216   42080  1        1       59.99    10384.59   +POLL


/usr/local/netperf/netperf -t UDP_RR -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 -- 
-r 516,4

UDP REQUEST/RESPONSE TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
!!! WARNING
!!! Desired confidence was not achieved within the specified iterations.
!!! This implies that there was variability in the test environment that
!!! must be investigated before going further.
!!! Confidence intervals: Throughput      :  8.5%
!!!                       Local CPU util  :  0.0%
!!!                       Remote CPU util :  0.0%

Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

9216   42080  516      4       59.99    5332.39
9216   42080  516      4       59.99    5752.03   +POLL

/usr/local/netperf/netperf -t UDP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 
-- -s 32768 -S 32768 -m 4096

UDP UNIDIRECTIONAL SEND TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
Socket  Message  Elapsed      Messages
Size    Size     Time         Okay Errors   Throughput
bytes   bytes    secs            #      #   10^6bits/sec

  32768    4096   59.99      108559 7379153      59.30
  32768           59.99      108521             59.28
  32768    4096   59.99      114246 10368207      62.40  +POLL
  32768           59.99      114227             62.39    +POLL


Testing with the following command line:
/usr/local/netperf/netperf -t UDP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 
-- -s 32768 -S 32768 -m 1024

UDP UNIDIRECTIONAL SEND TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
Socket  Message  Elapsed      Messages
Size    Size     Time         Okay Errors   Throughput
bytes   bytes    secs            #      #   10^6bits/sec

  32768    1024   59.99      475626 9177882      64.95
  32768           59.99      475467             64.93
  32768    1024   59.99      461228 13567726      62.98  +POLL
  32768           59.99      461151             62.97  +POLL




The only problematic one is the last one.  Still, I am surprised by the 
amount of errors and even the somewhat low throughput. I recall running 
this test some time ago and being able to pretty well get close to 100Mb/s 
on the fxp card.


And, a UDP stream test

/usr/local/netperf/netperf -t UDP_STREAM -l 60 -H 10.1.1.1 -i 10,3 -I 99,5 
-- -s 32768 -S 32768 -m 4
UDP UNIDIRECTIONAL SEND TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
Socket  Message  Elapsed      Messages
Size    Size     Time         Okay Errors   Throughput
bytes   bytes    secs            #      #   10^6bits/sec

  32768       4   59.99     3245141 11827778       1.73
  32768           59.99     3212788              1.71

and
ruby3# sysctl -w net.xorp.polling=0
net.xorp.polling: 1 -> 0
ruby3# /usr/local/netperf/netperf -t UDP_STREAM -l 60 -H 10.1.1.1 -i 10,3 
-I 99,5 -- -s 32768 -S 32768 -m 4
UDP UNIDIRECTIONAL SEND TEST to 10.1.1.1 : +/-2.5% @ 99% conf. : histogram
Socket  Message  Elapsed      Messages
Size    Size     Time         Okay Errors   Throughput
bytes   bytes    secs            #      #   10^6bits/sec

  32768       4   59.99     4168057      0       2.22
  32768           59.99     4032396              2.15

ruby3#

Hmmm.. This is rather puzzling. Why would polling have so many errors and 
be slower ?

On the box I am connected to, I am going to try against a non onboard NIC 
to see if that is the problem.

         ---Mike


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27 11:53: 8 2001
Delivered-To: freebsd-net@freebsd.org
Received: from fledge.watson.org (fledge.watson.org [204.156.12.50])
	by hub.freebsd.org (Postfix) with ESMTP id 10EAF37B405
	for <freebsd-net@FreeBSD.org>; Tue, 27 Nov 2001 11:53:05 -0800 (PST)
Received: from localhost (arr@localhost)
	by fledge.watson.org (8.11.6/8.11.5) with SMTP id fARJqok17843;
	Tue, 27 Nov 2001 14:52:50 -0500 (EST)
	(envelope-from arr@FreeBSD.org)
X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs
Date: Tue, 27 Nov 2001 14:52:49 -0500 (EST)
From: "Andrew R. Reiter" <arr@FreeBSD.org>
X-Sender: arr@fledge.watson.org
To: "Bruce A. Mah" <bmah@packetdesign.com>
Cc: freebsd-net@FreeBSD.org
Subject: Re: RFC: MFC M_ZERO usage for bpf.c
In-Reply-To: <200111271947.fARJlaq00597@nimitz.packetdesign.com>
Message-ID: <Pine.NEB.3.96L.1011127145013.17368A-100000@fledge.watson.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


Just as a note, I decided against MFC'ing this and similar changes because
I didn't feel it was necesary for -STABLE to have this "fix."

On Tue, 27 Nov 2001, Bruce A. Mah wrote:

:Hi--
:
:I've been reading through src/sys/net/bpf.c, and I noticed that the
:changes to make it use M_ZERO haven't been MFC-ed to RELENG_4 yet.  Any
:objection if I do this?  (Nothing broke in my quick testing.)
:
:Thanks,
:
:Bruce.
:
:Index: bpf.c
:===================================================================
:RCS file: /usr/ncvs/src/sys/net/bpf.c,v
:retrieving revision 1.59.2.6
:diff -u -r1.59.2.6 bpf.c
:--- bpf.c	20 Sep 2001 14:31:33 -0000	1.59.2.6
:+++ bpf.c	27 Nov 2001 18:49:45 -0000
:@@ -358,8 +358,7 @@
: 	if (d)
: 		return (EBUSY);
: 	make_dev(&bpf_cdevsw, minor(dev), 0, 0, 0600, "bpf%d", lminor(dev));
:-	MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK);
:-	bzero(d, sizeof(*d));
:+	MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK | M_ZERO);
: 	dev->si_drv1 = d;
: 	d->bd_bufsize = bpf_bufsize;
: 	d->bd_sig = SIGIO;
:@@ -1285,11 +1284,10 @@
: 	u_int dlt, hdrlen;
: {
: 	struct bpf_if *bp;
:-	bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT);
:+	bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT | M_ZERO);
: 	if (bp == 0)
: 		panic("bpfattach");
: 
:-	bp->bif_dlist = 0;
: 	bp->bif_ifp = ifp;
: 	bp->bif_dlt = dlt;
: 
:
:
:

--
Andrew R. Reiter
arr@watson.org
arr@FreeBSD.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27 11:59:20 2001
Delivered-To: freebsd-net@freebsd.org
Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39])
	by hub.freebsd.org (Postfix) with ESMTP id 2576537B53A
	for <freebsd-net@freebsd.org>; Tue, 27 Nov 2001 11:59:11 -0800 (PST)
Received: (qmail 92890 invoked by uid 1000); 27 Nov 2001 19:59:10 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 27 Nov 2001 19:59:10 -0000
Date: Tue, 27 Nov 2001 13:59:09 -0600 (CST)
From: Mike Silbersack <silby@silby.com>
To: "Bruce A. Mah" <bmah@packetdesign.com>
Cc: <freebsd-net@freebsd.org>
Subject: Re: RFC: MFC M_ZERO usage for bpf.c
In-Reply-To: <200111271947.fARJlaq00597@nimitz.packetdesign.com>
Message-ID: <20011127135759.X90727-100000@achilles.silby.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


On Tue, 27 Nov 2001, Bruce A. Mah wrote:

> Hi--
>
> I've been reading through src/sys/net/bpf.c, and I noticed that the
> changes to make it use M_ZERO haven't been MFC-ed to RELENG_4 yet.  Any
> objection if I do this?  (Nothing broke in my quick testing.)
>
> Thanks,
>
> Bruce.

Possibly a dumb question, but does 4.x actually have the M_ZERO
functionality?

If so, syncing these changes to 4.x seems like a good idea.

Mike "Silby" Silbersack


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27 12: 2:38 2001
Delivered-To: freebsd-net@freebsd.org
Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1131E37B417; Tue, 27 Nov 2001 12:02:05 -0800 (PST)
Received: (from rizzo@localhost)
	by iguana.aciri.org (8.11.3/8.11.1) id fARJvuj01234;
	Tue, 27 Nov 2001 11:57:56 -0800 (PST)
	(envelope-from rizzo)
Date: Tue, 27 Nov 2001 11:57:56 -0800
From: Luigi Rizzo <rizzo@aciri.org>
To: "Andrew R. Reiter" <arr@FreeBSD.ORG>
Cc: "Bruce A. Mah" <bmah@packetdesign.com>, freebsd-net@FreeBSD.ORG
Subject: Re: RFC: MFC M_ZERO usage for bpf.c
Message-ID: <20011127115755.A1151@iguana.aciri.org>
References: <200111271947.fARJlaq00597@nimitz.packetdesign.com> <Pine.NEB.3.96L.1011127145013.17368A-100000@fledge.watson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.NEB.3.96L.1011127145013.17368A-100000@fledge.watson.org>
User-Agent: Mutt/1.3.23i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Tue, Nov 27, 2001 at 02:52:49PM -0500, Andrew R. Reiter wrote:
> 
> Just as a note, I decided against MFC'ing this and similar changes because
> I didn't feel it was necesary for -STABLE to have this "fix."

why not ? code is more compact (and cache friendly) and readable,
diffs from HEAD are reduced, no functional changes... I see only
good things in these MFCs.

While we are on the topic, I would also love to see more consistency
in the use of macros vs. inline functions. E.g. below we have

    MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK | M_ZERO);

and

    bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT | M_ZERO);

and the same occurs elsewhere for free() and FREE(). This is confusing
because it leads you into thinking that they are two different things
while they are not.

	cheers
	luigi

> On Tue, 27 Nov 2001, Bruce A. Mah wrote:
> 
> :Hi--
> :
> :I've been reading through src/sys/net/bpf.c, and I noticed that the
> :changes to make it use M_ZERO haven't been MFC-ed to RELENG_4 yet.  Any
> :objection if I do this?  (Nothing broke in my quick testing.)
> :
> :Thanks,
> :
> :Bruce.
> :
> :Index: bpf.c
> :===================================================================
> :RCS file: /usr/ncvs/src/sys/net/bpf.c,v
> :retrieving revision 1.59.2.6
> :diff -u -r1.59.2.6 bpf.c
> :--- bpf.c	20 Sep 2001 14:31:33 -0000	1.59.2.6
> :+++ bpf.c	27 Nov 2001 18:49:45 -0000
> :@@ -358,8 +358,7 @@
> : 	if (d)
> : 		return (EBUSY);
> : 	make_dev(&bpf_cdevsw, minor(dev), 0, 0, 0600, "bpf%d", lminor(dev));
> :-	MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK);
> :-	bzero(d, sizeof(*d));
> :+	MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK | M_ZERO);
> : 	dev->si_drv1 = d;
> : 	d->bd_bufsize = bpf_bufsize;
> : 	d->bd_sig = SIGIO;
> :@@ -1285,11 +1284,10 @@
> : 	u_int dlt, hdrlen;
> : {
> : 	struct bpf_if *bp;
> :-	bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT);
> :+	bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT | M_ZERO);
> : 	if (bp == 0)
> : 		panic("bpfattach");
> : 
> :-	bp->bif_dlist = 0;
> : 	bp->bif_ifp = ifp;
> : 	bp->bif_dlt = dlt;
> : 
> :
> :
> :
> 
> --
> Andrew R. Reiter
> arr@watson.org
> arr@FreeBSD.org
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27 12:40:47 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10])
	by hub.freebsd.org (Postfix) with ESMTP
	id 57BA737B405; Tue, 27 Nov 2001 12:40:41 -0800 (PST)
Received: from nimitz.packetdesign.com (nimitz.packetdesign.com [192.168.0.184])
	by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id fARKee532814;
	Tue, 27 Nov 2001 12:40:40 -0800 (PST)
	(envelope-from bmah@packetdesign.com)
Received: (from bmah@localhost)
	by nimitz.packetdesign.com (8.11.6/8.11.6) id fARKeea01058;
	Tue, 27 Nov 2001 12:40:40 -0800 (PST)
	(envelope-from bmah)
Message-Id: <200111272040.fARKeea01058@nimitz.packetdesign.com>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: "Andrew R. Reiter" <arr@FreeBSD.org>
Cc: "Bruce A. Mah" <bmah@packetdesign.com>, freebsd-net@FreeBSD.org
Subject: Re: RFC: MFC M_ZERO usage for bpf.c 
In-Reply-To: <Pine.NEB.3.96L.1011127145013.17368A-100000@fledge.watson.org> 
References: <Pine.NEB.3.96L.1011127145013.17368A-100000@fledge.watson.org>
Comments: In-reply-to "Andrew R. Reiter" <arr@FreeBSD.org>
   message dated "Tue, 27 Nov 2001 14:52:49 -0500."
From: bmah@packetdesign.com (Bruce A. Mah)
Reply-To: bmah@packetdesign.com
X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5<Pi&akO)o^8;[r
 %l(8ZHlbF`dD>v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A
 2V%N&+
X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif
X-Url: http://www.employees.org/~bmah/
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1725586696P";
	 micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 27 Nov 2001 12:40:40 -0800
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

--==_Exmh_1725586696P
Content-Type: text/plain; charset=us-ascii

If memory serves me right, "Andrew R. Reiter" wrote:

> Just as a note, I decided against MFC'ing this and similar changes because
> I didn't feel it was necesary for -STABLE to have this "fix."

I agree it's not necessary.  I'm reviewing some other BPF patches
(which have been sitting in my queue for way too long) and I wanted to
sync up bpf.c on HEAD and RELENG_4 a little bit before diving in.

Bruce.



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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: Exmh on FreeBSD

iD8DBQE8A/pI2MoxcVugUsMRAkRVAJ9AyFFVIqeVJMblXswpusPKXmbTzgCeOVS4
qe0kxi0dSatpBH4Zr9D7VPU=
=G85j
-----END PGP SIGNATURE-----

--==_Exmh_1725586696P--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27 12:45:18 2001
Delivered-To: freebsd-net@freebsd.org
Received: from fledge.watson.org (fledge.watson.org [204.156.12.50])
	by hub.freebsd.org (Postfix) with ESMTP id D2E7737B41A
	for <freebsd-net@FreeBSD.org>; Tue, 27 Nov 2001 12:45:12 -0800 (PST)
Received: from localhost (arr@localhost)
	by fledge.watson.org (8.11.6/8.11.5) with SMTP id fARKiwp19304;
	Tue, 27 Nov 2001 15:44:58 -0500 (EST)
	(envelope-from arr@FreeBSD.org)
X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs
Date: Tue, 27 Nov 2001 15:44:57 -0500 (EST)
From: "Andrew R. Reiter" <arr@FreeBSD.org>
X-Sender: arr@fledge.watson.org
To: "Bruce A. Mah" <bmah@packetdesign.com>
Cc: freebsd-net@FreeBSD.org
Subject: Re: RFC: MFC M_ZERO usage for bpf.c 
In-Reply-To: <200111272040.fARKeea01058@nimitz.packetdesign.com>
Message-ID: <Pine.NEB.3.96L.1011127154420.18848A-100000@fledge.watson.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


Yea, I think MFC'ing it would be fine.  Don't hesitate to thwap me one if
you guys think I should MFC some things Im not.

Cheers,
Andrew

On Tue, 27 Nov 2001, Bruce A. Mah wrote:

:If memory serves me right, "Andrew R. Reiter" wrote:
:
:> Just as a note, I decided against MFC'ing this and similar changes because
:> I didn't feel it was necesary for -STABLE to have this "fix."
:
:I agree it's not necessary.  I'm reviewing some other BPF patches
:(which have been sitting in my queue for way too long) and I wanted to
:sync up bpf.c on HEAD and RELENG_4 a little bit before diving in.
:
:Bruce.
:
:
:

--
Andrew R. Reiter
arr@watson.org
arr@FreeBSD.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Tue Nov 27 13:21:56 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2123537B416; Tue, 27 Nov 2001 13:21:50 -0800 (PST)
Received: from nimitz.packetdesign.com (nimitz.packetdesign.com [192.168.0.184])
	by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id fARLLV533973;
	Tue, 27 Nov 2001 13:21:31 -0800 (PST)
	(envelope-from bmah@packetdesign.com)
Received: (from bmah@localhost)
	by nimitz.packetdesign.com (8.11.6/8.11.6) id fARLLUZ04116;
	Tue, 27 Nov 2001 13:21:30 -0800 (PST)
	(envelope-from bmah)
Message-Id: <200111272121.fARLLUZ04116@nimitz.packetdesign.com>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: "Andrew R. Reiter" <arr@FreeBSD.org>
Cc: "Bruce A. Mah" <bmah@packetdesign.com>, freebsd-net@FreeBSD.org
Subject: Re: RFC: MFC M_ZERO usage for bpf.c 
In-Reply-To: <Pine.NEB.3.96L.1011127154420.18848A-100000@fledge.watson.org> 
References: <Pine.NEB.3.96L.1011127154420.18848A-100000@fledge.watson.org>
Comments: In-reply-to "Andrew R. Reiter" <arr@FreeBSD.org>
   message dated "Tue, 27 Nov 2001 15:44:57 -0500."
From: bmah@packetdesign.com (Bruce A. Mah)
Reply-To: bmah@packetdesign.com
X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5<Pi&akO)o^8;[r
 %l(8ZHlbF`dD>v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A
 2V%N&+
X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif
X-Url: http://www.employees.org/~bmah/
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1731225426P";
	 micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 27 Nov 2001 13:21:30 -0800
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

--==_Exmh_1731225426P
Content-Type: text/plain; charset=us-ascii

If memory serves me right, "Andrew R. Reiter" wrote:

> Yea, I think MFC'ing it would be fine.  Don't hesitate to thwap me one if
> you guys think I should MFC some things Im not.

I'm sure there's plenty of people who'll be just itching to take you up 
on this offer.  :-)  :-)  :-)

Thanks,

Bruce.



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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: Exmh on FreeBSD

iD8DBQE8BAPa2MoxcVugUsMRAgqMAKDIxWzE9NUGeyvykQmrept/hOIVtgCfUWfx
rdFJAyRMZVQpNmApKKqbJ8A=
=lv2n
-----END PGP SIGNATURE-----

--==_Exmh_1731225426P--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28  0:48:33 2001
Delivered-To: freebsd-net@freebsd.org
Received: from canopus.gading.de (canopus.gading.de [212.222.196.42])
	by hub.freebsd.org (Postfix) with SMTP id 084E937B417
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 00:48:31 -0800 (PST)
Received: (qmail 1751 invoked from network); 28 Nov 2001 08:47:29 -0000
Received: from og-ml@gading.de by canopus with qmail-scanner-0.96 (. Clean. Processed in 0.111514 secs); 28 Nov 2001 08:47:29 -0000
Received: from unknown (HELO ANTARES) ([213.7.122.44]) (envelope-sender <og-ml@gading.de>)
          by 0 (qmail-ldap-1.03) with SMTP
          for <freebsd-net@freebsd.org>; 28 Nov 2001 08:47:28 -0000
From: "Oliver Gading" <og-ml@gading.de>
To: <freebsd-net@freebsd.org>
Subject: Bridging FDDI to Ethernet
Date: Wed, 28 Nov 2001 09:42:47 +0100
Message-ID: <JBEALPOPDCJGNIGJHNMPEEBKCLAA.og-ml@gading.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org



Does anybody have experience in setting up OpenBSD/FreeBSD/Linux boxes
as a bridge between FDDI (Snap) and Ethernet (Gigabit or 100Mb)?

I need a bridge to let NetBEUI pass through these topologies.

Best would be if the bridge code does support differing mtu's,
but this is optional.

Yes i know there are standalone solutions out there.

If FDDI to Ethernet is not supported yet, it would be helpful for me
to know when it will be, or if there are plans to do.

Thanks

  Oliver

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28  1: 5:16 2001
Delivered-To: freebsd-net@freebsd.org
Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49])
	by hub.freebsd.org (Postfix) with ESMTP id E85D737B417
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 01:05:13 -0800 (PST)
Received: from dialup-209.245.139.76.dial1.sanjose1.level3.net ([209.245.139.76] helo=gohan.cjclark.org)
	by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1)
	id 1690eT-0002MI-00
	for freebsd-net@freebsd.org; Wed, 28 Nov 2001 01:05:11 -0800
Received: (from cjc@localhost)
	by gohan.cjclark.org (8.11.6/8.11.1) id fARKX1S04069
	for freebsd-net@freebsd.org; Tue, 27 Nov 2001 12:33:01 -0800 (PST)
	(envelope-from cjc)
Date: Tue, 27 Nov 2001 12:33:01 -0800
From: "Crist J. Clark" <cristjc@earthlink.net>
To: freebsd-net@freebsd.org
Subject: inet_pton(3) Does Not Replace inet_aton(3)
Message-ID: <20011127123301.B3788@gohan.cjclark.org>
Reply-To: cjclark@alum.mit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-URL: http://people.freebsd.org/~cjc/
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

I am not at all sure whether this is a bug or feature. I was just
surprised by the results. If it is a feature, the documentation is
misleading.

The issue is that inet_aton(3) will correctly understand,

  "127.1"

To be the IP address,

  127.0.0.1

Where inet_pton(3) will fail (return a 1). That is, inet_pton(3) only
understands dotted quads. The comments in src/lib/libc/net/inet_pton.c
clearly show this is the intended behavior. But is that what we want?
-- 
Crist J. Clark                           cjclark@alum.mit.edu

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28  2: 0:51 2001
Delivered-To: freebsd-net@freebsd.org
Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9])
	by hub.freebsd.org (Postfix) with ESMTP
	id 50A2B37B405; Wed, 28 Nov 2001 02:00:26 -0800 (PST)
Received: from localhost (localhost.elischer.org [127.0.0.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id BAA13886;
	Wed, 28 Nov 2001 01:46:16 -0800 (PST)
Date: Wed, 28 Nov 2001 01:46:14 -0800 (PST)
From: Julian Elischer <julian@elischer.org>
To: Luigi Rizzo <rizzo@aciri.org>
Cc: "Andrew R. Reiter" <arr@FreeBSD.ORG>,
	"Bruce A. Mah" <bmah@packetdesign.com>, freebsd-net@FreeBSD.ORG
Subject: Re: RFC: MFC M_ZERO usage for bpf.c
In-Reply-To: <20011127115755.A1151@iguana.aciri.org>
Message-ID: <Pine.BSF.4.21.0111280145040.13845-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org



On Tue, 27 Nov 2001, Luigi Rizzo wrote:

> On Tue, Nov 27, 2001 at 02:52:49PM -0500, Andrew R. Reiter wrote:
> > 
> > Just as a note, I decided against MFC'ing this and similar changes because
> > I didn't feel it was necesary for -STABLE to have this "fix."
> 
> why not ? code is more compact (and cache friendly) and readable,
> diffs from HEAD are reduced, no functional changes... I see only
> good things in these MFCs.
> 
> While we are on the topic, I would also love to see more consistency
> in the use of macros vs. inline functions. E.g. below we have
> 
>     MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK | M_ZERO);
> 
> and
> 
>     bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT | M_ZERO);
> 


why cast the thing?  it returns a void *
which obviates the need for any casting....



> and the same occurs elsewhere for free() and FREE(). This is confusing
> because it leads you into thinking that they are two different things
> while they are not.
> 
> 	cheers
> 	luigi
> 
> > On Tue, 27 Nov 2001, Bruce A. Mah wrote:
> > 
> > :Hi--
> > :
> > :I've been reading through src/sys/net/bpf.c, and I noticed that the
> > :changes to make it use M_ZERO haven't been MFC-ed to RELENG_4 yet.  Any
> > :objection if I do this?  (Nothing broke in my quick testing.)
> > :
> > :Thanks,
> > :
> > :Bruce.
> > :
> > :Index: bpf.c
> > :===================================================================
> > :RCS file: /usr/ncvs/src/sys/net/bpf.c,v
> > :retrieving revision 1.59.2.6
> > :diff -u -r1.59.2.6 bpf.c
> > :--- bpf.c	20 Sep 2001 14:31:33 -0000	1.59.2.6
> > :+++ bpf.c	27 Nov 2001 18:49:45 -0000
> > :@@ -358,8 +358,7 @@
> > : 	if (d)
> > : 		return (EBUSY);
> > : 	make_dev(&bpf_cdevsw, minor(dev), 0, 0, 0600, "bpf%d", lminor(dev));
> > :-	MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK);
> > :-	bzero(d, sizeof(*d));
> > :+	MALLOC(d, struct bpf_d *, sizeof(*d), M_BPF, M_WAITOK | M_ZERO);
> > : 	dev->si_drv1 = d;
> > : 	d->bd_bufsize = bpf_bufsize;
> > : 	d->bd_sig = SIGIO;
> > :@@ -1285,11 +1284,10 @@
> > : 	u_int dlt, hdrlen;
> > : {
> > : 	struct bpf_if *bp;
> > :-	bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT);
> > :+	bp = (struct bpf_if *)malloc(sizeof(*bp), M_BPF, M_DONTWAIT | M_ZERO);
> > : 	if (bp == 0)
> > : 		panic("bpfattach");
> > : 
> > :-	bp->bif_dlist = 0;
> > : 	bp->bif_ifp = ifp;
> > : 	bp->bif_dlt = dlt;
> > : 
> > :
> > :
> > :
> > 
> > --
> > Andrew R. Reiter
> > arr@watson.org
> > arr@FreeBSD.org
> > 
> > 
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-net" in the body of the message
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28  6:17:10 2001
Delivered-To: freebsd-net@freebsd.org
Received: from rod.inty.net (rod.inty.net [195.224.93.241])
	by hub.freebsd.org (Postfix) with ESMTP id 1ADDB37B419
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 06:17:05 -0800 (PST)
Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150])
	by rod.inty.net (8.11.3/8.11.3) with ESMTP id fASEGxX62673
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 14:17:00 GMT
Received: from tariq ([10.0.1.156])
	by inty.hq.inty.net (8.9.3/8.9.3) with SMTP id OAA99016
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 14:16:58 GMT
From: "Tariq Rashid" <tariq@inty.net>
To: <freebsd-net@freebsd.org>
Subject: ip change ? not according to tcpdump.
Date: Wed, 28 Nov 2001 14:18:09 -0000
Message-ID: <MPENKFCCIIDAJKJJOLBHAEPOCCAA.tariq@inty.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-Skip-Virus-Check: yes
X-Virus-Checked: 37143
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

his post is about an IP address not being reflected "on the wire":


Two freebsd 4.4-release boxes are connected over ethernet via a hub (using
nics at 10Mbs).

The hub is simple in that it doesn't do anything fancy like arp proxying or
caching....

   [ A ] -------   ------- [ B ]
                |  |
              [ hub  ]


I change the ip address on A as follows:
	* ifconfig fxp0 down
	* ifconfig 192.168.1.33    (it was 192.168.1.3)
	* ifconfig fxp0 up (for good measure!)

now, on A:
	* pinging 192.168.1.33 works
	* pinging 192.168.1.3 does not     -- all good so far

now pinging machine B (ping 192.168.1.1) WORKS :

		13:13:48.460568 192.168.1.3 > 192.168.1.1: icmp: echo request
		13:13:48.460862 192.168.1.1 > 192.168.1.3: icmp: echo reply

BUT a tcpdump shows pings coming from the old 192.168.1.3 address.
This is a problem as other applications like IKE daemons (isakmpd ported
from openbsd) wants to respond to
the old 192.168.1.3 which isn't there... causing arp requests...
icmp-redirects....

		13:13:00.297762 192.168.1.1 > 192.168.1.3: ESP(spi=0x70214267,seq=0x51)
		13:13:00.298396 arp who-has 192.168.1.3 tell 192.168.1.33
		13:13:00.298468 192.168.1.33 > 192.168.1.1: icmp: redirect 192.168.1.3 to
host 192.168.1.3

Necxt, I tried doing arp -da on both machines... but to no avail: this time
the pings from machine A to B fail with:

		13:15:16.914413 192.168.1.3 > 192.168.1.1: icmp: echo request
		13:15:17.924035 192.168.1.3 > 192.168.1.1: icmp: echo request
		13:15:18.934023 192.168.1.3 > 192.168.1.1: icmp: echo request
		13:15:19.944032 192.168.1.3 > 192.168.1.1: icmp: echo request

any ideas anyone?

tariq

-----------------------------------------------
Information in this electronic mail message is confidential
and may be legally privileged. It is intended solely for
the addressee. Access to this message by anyone else is
unauthorised. If you are not the intended recipient any 
use, disclosure, copying or distribution of this message is
prohibited and may be unlawful. When addressed to our
customers, any information contained in this message is
subject to Intelligent Network Technology Ltd Terms & Conditions.
-----------------------------------------------
Take part in the intY 2001 Email Usage survey
online at http://www.inty.net/email/survey.html
-----------------------------------------------

intY has automatically scanned this email using Sophos Anti-Virus (www.inty.net)



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28  6:46:54 2001
Delivered-To: freebsd-net@freebsd.org
Received: from jane.inty.net (jane.inty.net [195.224.93.242])
	by hub.freebsd.org (Postfix) with ESMTP id 5C76F37B416
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 06:46:47 -0800 (PST)
Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150])
	by jane.inty.net (8.11.3/8.11.3) with ESMTP id fASEkiq75039
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 14:46:44 GMT
Received: from tariq ([10.0.1.156])
	by inty.hq.inty.net (8.9.3/8.9.3) with SMTP id OAA01379
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 14:46:43 GMT
From: "Tariq Rashid" <tariq@inty.net>
To: <freebsd-net@freebsd.org>
Subject: solved  : ip change ? not according to tcpdump.
Date: Wed, 28 Nov 2001 14:47:54 -0000
Message-ID: <MPENKFCCIIDAJKJJOLBHKEPOCCAA.tariq@inty.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <MPENKFCCIIDAJKJJOLBHAEPOCCAA.tariq@inty.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-Skip-Virus-Check: yes
X-Virus-Checked: 64989
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


 apologies - natd was running on the interfaces which causes the effects.

 well - i didn't know that natd didn't respond to ip address changes...

t

-----Original Message-----
From: owner-freebsd-net@FreeBSD.ORG
[mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Tariq Rashid
Sent: 28 November 2001 14:18
To: freebsd-net@freebsd.org
Subject: ip change ? not according to tcpdump.


his post is about an IP address not being reflected "on the wire":


Two freebsd 4.4-release boxes are connected over ethernet via a hub (using
nics at 10Mbs).

The hub is simple in that it doesn't do anything fancy like arp proxying or
caching....

   [ A ] -------   ------- [ B ]
                |  |
              [ hub  ]


I change the ip address on A as follows:
	* ifconfig fxp0 down
	* ifconfig 192.168.1.33    (it was 192.168.1.3)
	* ifconfig fxp0 up (for good measure!)

now, on A:
	* pinging 192.168.1.33 works
	* pinging 192.168.1.3 does not     -- all good so far

now pinging machine B (ping 192.168.1.1) WORKS :

		13:13:48.460568 192.168.1.3 > 192.168.1.1: icmp: echo request
		13:13:48.460862 192.168.1.1 > 192.168.1.3: icmp: echo reply

BUT a tcpdump shows pings coming from the old 192.168.1.3 address.
This is a problem as other applications like IKE daemons (isakmpd ported
from openbsd) wants to respond to
the old 192.168.1.3 which isn't there... causing arp requests...
icmp-redirects....

		13:13:00.297762 192.168.1.1 > 192.168.1.3: ESP(spi=0x70214267,seq=0x51)
		13:13:00.298396 arp who-has 192.168.1.3 tell 192.168.1.33
		13:13:00.298468 192.168.1.33 > 192.168.1.1: icmp: redirect 192.168.1.3 to
host 192.168.1.3

Necxt, I tried doing arp -da on both machines... but to no avail: this time
the pings from machine A to B fail with:

		13:15:16.914413 192.168.1.3 > 192.168.1.1: icmp: echo request
		13:15:17.924035 192.168.1.3 > 192.168.1.1: icmp: echo request
		13:15:18.934023 192.168.1.3 > 192.168.1.1: icmp: echo request
		13:15:19.944032 192.168.1.3 > 192.168.1.1: icmp: echo request

any ideas anyone?

tariq

-----------------------------------------------
Information in this electronic mail message is confidential
and may be legally privileged. It is intended solely for
the addressee. Access to this message by anyone else is
unauthorised. If you are not the intended recipient any
use, disclosure, copying or distribution of this message is
prohibited and may be unlawful. When addressed to our
customers, any information contained in this message is
subject to Intelligent Network Technology Ltd Terms & Conditions.
-----------------------------------------------
Take part in the intY 2001 Email Usage survey
online at http://www.inty.net/email/survey.html
-----------------------------------------------

intY has automatically scanned this email using Sophos Anti-Virus
(www.inty.net)



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


-----------------------------------------------
Information in this electronic mail message is confidential
and may be legally privileged. It is intended solely for
the addressee. Access to this message by anyone else is
unauthorised. If you are not the intended recipient any 
use, disclosure, copying or distribution of this message is
prohibited and may be unlawful. When addressed to our
customers, any information contained in this message is
subject to Intelligent Network Technology Ltd Terms & Conditions.
-----------------------------------------------
Take part in the intY 2001 Email Usage survey
online at http://www.inty.net/email/survey.html
-----------------------------------------------

intY has automatically scanned this email using Sophos Anti-Virus (www.inty.net)



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28  7:38:43 2001
Delivered-To: freebsd-net@freebsd.org
Received: from tomts6-srv.bellnexxia.net (tomts6.bellnexxia.net [209.226.175.26])
	by hub.freebsd.org (Postfix) with ESMTP id 3D85337B41A
	for <freebsd-net@FreeBSD.ORG>; Wed, 28 Nov 2001 07:38:38 -0800 (PST)
Received: from xena.gsicomp.on.ca ([199.243.149.34])
          by tomts6-srv.bellnexxia.net
          (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP
          id <20011128153837.IPFV9997.tomts6-srv.bellnexxia.net@xena.gsicomp.on.ca>;
          Wed, 28 Nov 2001 10:38:37 -0500
Received: from localhost (matt@localhost)
	by xena.gsicomp.on.ca (8.11.1/8.11.1) with ESMTP id fASFUL360324;
	Wed, 28 Nov 2001 10:30:24 -0500 (EST)
	(envelope-from matt@xena.gsicomp.on.ca)
Date: Wed, 28 Nov 2001 10:30:21 -0500 (EST)
From: Matthew Emmerton <matt@gsicomp.on.ca>
To: Tariq Rashid <tariq@inty.net>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: solved  : ip change ? not according to tcpdump.
In-Reply-To: <MPENKFCCIIDAJKJJOLBHKEPOCCAA.tariq@inty.net>
Message-ID: <Pine.BSF.4.21.0111281029510.60315-100000@xena.gsicomp.on.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Wed, 28 Nov 2001, Tariq Rashid wrote:

> 
>  apologies - natd was running on the interfaces which causes the effects.
> 
>  well - i didn't know that natd didn't respond to ip address changes...


It will, if you run it with the '-dynamic' flag.

--
Matt Emmerton


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28  8:37:48 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mail2.bigmailbox.com (mail2.bigmailbox.com [209.132.220.33])
	by hub.freebsd.org (Postfix) with ESMTP id BC9D237B416
	for <freebsd-net@FreeBSD.ORG>; Wed, 28 Nov 2001 08:37:42 -0800 (PST)
Received: (from www@localhost)
	by mail2.bigmailbox.com (8.10.0/8.10.0) id fASGbgd07767;
	Wed, 28 Nov 2001 08:37:42 -0800
Date: Wed, 28 Nov 2001 08:37:42 -0800
Message-Id: <200111281637.fASGbgd07767@mail2.bigmailbox.com>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-Mailer: MIME-tools 4.104 (Entity 4.116)
Mime-Version: 1.0
X-Originating-Ip: [200.205.146.199]
From: "irado@nettaxi.com" <irado@nettaxi.com>
To: freebsd-net@FreeBSD.ORG
Subject: netmask for aliased ip
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


somebody told me that, when aliasing, the 2nd to ´n´ ipaddress netmask must not be  the regular one, but 0xffffffff instead. Example:

rl0 = 200.200.200.200 netmask 255.255.0.0
rl0:0 (the aliased) 200.200.220.200 netmask 0xffffffff
[lots more]
rl0:3000 200.200.255.200 netmask 0xffffffff

is it for real?? what is the reason for this?





saudações,

irado furioso com tudo
GNU/Linux user  CASSADO
explicando o padre marcelo (mala) ´popstar´ rossi: mer%# velha com roupagem nova. 

por favor, clique aqui: http://www.thehungersite.com
e aqui também: http://cf6.uol.com.br/umminuto/

------------------------------------------------------------
Nettaxi would like to ask for your help in donations to the RED CROSS today!
http://www.nyredcross.org/donate/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28  9:31:18 2001
Delivered-To: freebsd-net@freebsd.org
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP id B7C2E37B41A
	for <freebsd-net@FreeBSD.ORG>; Wed, 28 Nov 2001 09:31:10 -0800 (PST)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fASHV9948068;
	Wed, 28 Nov 2001 12:31:09 -0500 (EST)
	(envelope-from wollman)
Date: Wed, 28 Nov 2001 12:31:09 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200111281731.fASHV9948068@khavrinen.lcs.mit.edu>
To: cjclark@alum.mit.edu
Cc: freebsd-net@FreeBSD.ORG
Subject: inet_pton(3) Does Not Replace inet_aton(3)
In-Reply-To: <20011127123301.B3788@gohan.cjclark.org>
References: <20011127123301.B3788@gohan.cjclark.org>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

<<On Tue, 27 Nov 2001 12:33:01 -0800, "Crist J. Clark" <cristjc@earthlink.net> said:

> Where inet_pton(3) will fail (return a 1). That is, inet_pton(3) only
> understands dotted quads. The comments in src/lib/libc/net/inet_pton.c
> clearly show this is the intended behavior. But is that what we want?

Yes.  The old format is deprecated, obsolete, legacy, however you want
to put it.

-GAWollman


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28  9:37:41 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.caravan.ru (mx1.caravan.ru [217.23.130.2])
	by hub.freebsd.org (Postfix) with ESMTP id 6A58E37B4EC
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 09:37:33 -0800 (PST)
Received: from virscan (helo=mx1.caravan.ru)
	by mx1.caravan.ru with scanned-ok (Exim 3.33 #2)
	id 1698eK-000HuT-00
	for freebsd-net@freebsd.org; Wed, 28 Nov 2001 20:37:32 +0300
Received: from zk-office.caravan.ru ([217.23.131.8] helo=caravan.ru)
	by mx1.caravan.ru with esmtp (Exim 3.33 #2)
	id 1698eK-000Hu9-00
	for freebsd-net@freebsd.org; Wed, 28 Nov 2001 20:37:32 +0300
Message-ID: <3C0520DB.6090009@caravan.ru>
Date: Wed, 28 Nov 2001 20:37:31 +0300
From: "Sergey V. Artjushkin" <skiv@caravan.ru>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.4) Gecko/20010919
X-Accept-Language: ru, en
MIME-Version: 1.0
To: freebsd-net@freebsd.org
Subject: get client ip from accept(2) ?
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Hello

Colleagues, I have some question about accept(2) functions.
I have wrote the following programm:

-------------------------------
   /* set up the listening tcp socket*/
if ( (l_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
    { log_error("socket (tcp) error"); exit(0); }
memset(&l_servaddr,0,sizeof(l_servaddr));
l_servaddr.sin_family      = AF_INET;
l_servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
l_servaddr.sin_port        = htons(c_tcpport);

if ( bind(l_fd,(struct sockaddr *) &l_servaddr, sizeof(l_servaddr)) < 0)
     { log_error ("bind TCP error"); exit(0); }

if ( listen(l_fd, 32) < 0)
     { log_error("listen error"); exit(0); }

if ( (l_connfd = accept(l_fd,(struct sockaddr *) l_cliaddr, &l_addrlen))
< 0)
        { log_error("accept error"); exit(0); }
----------------------------------------

I'm trying to find out the client ip that connects to this server.
But l_cliaddr structure is NULL after succesfull accept call.
As I understand from manuals in this structure must be client ip.
Where I'm wrong and how I can get this ip?

Thank you for advance.

-- 
With best regards.
------------------------------------------------------------------
Sergey Artjushkin                      Network Operation Center
    (SKIV-RIPE)                               ISP "CARAVAN"



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28  9:50:48 2001
Delivered-To: freebsd-net@freebsd.org
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38])
	by hub.freebsd.org (Postfix) with ESMTP id 0871E37B405
	for <freebsd-net@FreeBSD.ORG>; Wed, 28 Nov 2001 09:50:45 -0800 (PST)
Received: from bbn.com (loewy.bbn.com [128.89.80.25])
	by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA15139;
	Wed, 28 Nov 2001 12:50:35 -0500 (EST)
X-Mailer: exmh version 2.1.1 10/15/1999
To: "Sergey V. Artjushkin" <skiv@caravan.ru>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: get client ip from accept(2) ? 
In-reply-to: Message from "Sergey V. Artjushkin" <skiv@caravan.ru> 
	<3C0520DB.6090009@caravan.ru> .
X-face: &R'hN{mZu#r@8b_JU\bn"!fYpP{?5k4p/(|]?.2'6;>Dc9}~t*vY=/#-:"63ya.%)%o`Kv$
 u&'Ff5k&n[}QC;j7YYsR5Hl]G"E:*9Zmw;dx[sw&9Tmx_PB/7B`RdFW;#@49hJU&kW+J"<[`9^?.dQ
 3]L$zK,4'=tThX$wC!M\`e*@1y
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 28 Nov 2001 12:55:28 -0500
Message-ID: <87326.1006970128@bbn.com>
From: Dennis Rockwell <dennis@bbn.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On 28 Nov, "Sergey V. Artjushkin" wrote:

> if ( (l_connfd = accept(l_fd,(struct sockaddr *) l_cliaddr, &l_addrlen))
> < 0)
>         { log_error("accept error"); exit(0); }

Don't you need an '&' before l_cliaddr above?

Dennis



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 11:21:50 2001
Delivered-To: freebsd-net@freebsd.org
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP id 8DE8E37B422
	for <net@freebsd.org>; Wed, 28 Nov 2001 11:21:31 -0800 (PST)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fASJLVw00725;
	Wed, 28 Nov 2001 14:21:31 -0500 (EST)
	(envelope-from wollman)
Date: Wed, 28 Nov 2001 14:21:31 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200111281921.fASJLVw00725@khavrinen.lcs.mit.edu>
To: net@freebsd.org
Subject: [Bernard Aboba: Announcement of Bill Fenner as IETF Rout]
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Congratulations, Bill!  I hope this won't suck up all of your Copious
Free Time... :-)

-GAWollman

------- start of forwarded message (RFC 934 encapsulation) -------
Message-Id: <200111281207.HAA02501@ietf.org>
From: Bernard Aboba <aboba@internaut.com>
Sender: scoya@cnri.reston.va.us
To: IETF-Announce: ;
Subject: Announcement of Bill Fenner as IETF Routing Director
Date: Wed, 28 Nov 2001 07:07:21 -0500

The 2000 IETF Nominations Committee has now completed the task of
recommending a replacement for the Routing AD slot vacated by the passing
of Abha Ahuja, and the IAB has now approved the recommendation.

Please join us in welcoming Bill Fenner as IESG Routing Area Director.

A word of thanks

The RFC 2727 Interim Vacancy process, once invoked, requires the nomcom to
complete its deliberations in a short period of time. This required the
2000 nomcom members to put in an intense effort in order to complete the
task.

I would also like to thank those individuals who agreed to be considered
for the Routing AD position, and therefore had to complete their
applications in such a short time frame. We hope that the brevity of the
Interim Vacancy process does not dissuade you from continuing as a
candidate for the other Routing AD slot that is being filled by the 2001
nomcom. The IETF needs you.

Our best wishes for your success in the years ahead,

The role of non-voting members (from RFC 2727)

The nominations committee comprises at least a non-voting Chair,
10 voting volunteers, and 3 non-voting liaisons.  The sitting
IAB and IESG members each appoint a non-voting liaison to the
nominating committee from their current membership who are not
sitting in an open position.  The Chair of the prior year's
nominating committee also serves as a non-voting liaison.

The 2000 Nominations Committee

Phil Roberts
Stuart Cheshire
Perry E. Metzger
Bill Woodcock
Hadriel Kaplan
Alain Durand
Vijay Srinivasan
Hal Sandick
David Robinson
David Allan

Non-voting members:
Bernard Aboba (Chair)
Avri Doria (Past Chair)
Leslie Daigle (IAB Liason)
Allison Mankin <mankin@isi.edu>

The role of non-voting members (from RFC 2727)

The nominations committee comprises at least a non-voting Chair,
10 voting volunteers, and 3 non-voting liaisons.  The sitting
IAB and IESG members each appoint a non-voting liaison to the
nominating committee from their current membership who are not
sitting in an open position.  The Chair of the prior year's
nominating committee also serves as a non-voting liaison.
------- end -------

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 11:50:11 2001
Delivered-To: freebsd-net@freebsd.org
Received: from tp.databus.com (p101-46.acedsl.com [160.79.101.46])
	by hub.freebsd.org (Postfix) with ESMTP id F067437B405
	for <freebsd-net@FreeBSD.ORG>; Wed, 28 Nov 2001 11:50:02 -0800 (PST)
Received: (from barney@localhost)
	by tp.databus.com (8.11.6/8.11.4) id fASJnoc16044;
	Wed, 28 Nov 2001 14:49:50 -0500 (EST)
	(envelope-from barney)
Date: Wed, 28 Nov 2001 14:49:49 -0500
From: Barney Wolff <barney@databus.com>
To: "Sergey V. Artjushkin" <skiv@caravan.ru>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: get client ip from accept(2) ?
Message-ID: <20011128144949.A16005@tp.databus.com>
References: <3C0520DB.6090009@caravan.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3C0520DB.6090009@caravan.ru>; from skiv@caravan.ru on Wed, Nov 28, 2001 at 08:37:31PM +0300
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

You probably forgot to initialize l_addrlen to sizeof(sockaddr_in).
(As well as needing the & before l_cliaddr, but that's probably a
typo as it wouldn't compile without it.)

On Wed, Nov 28, 2001 at 08:37:31PM +0300, Sergey V. Artjushkin wrote:
> Hello
> 
> Colleagues, I have some question about accept(2) functions.
> I have wrote the following programm:
> 
> -------------------------------
>    /* set up the listening tcp socket*/
> if ( (l_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
>     { log_error("socket (tcp) error"); exit(0); }
> memset(&l_servaddr,0,sizeof(l_servaddr));
> l_servaddr.sin_family      = AF_INET;
> l_servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
> l_servaddr.sin_port        = htons(c_tcpport);
> 
> if ( bind(l_fd,(struct sockaddr *) &l_servaddr, sizeof(l_servaddr)) < 0)
>      { log_error ("bind TCP error"); exit(0); }
> 
> if ( listen(l_fd, 32) < 0)
>      { log_error("listen error"); exit(0); }
> 
> if ( (l_connfd = accept(l_fd,(struct sockaddr *) l_cliaddr, &l_addrlen))
> < 0)
>         { log_error("accept error"); exit(0); }
> ----------------------------------------
> 
> I'm trying to find out the client ip that connects to this server.
> But l_cliaddr structure is NULL after succesfull accept call.
> As I understand from manuals in this structure must be client ip.
> Where I'm wrong and how I can get this ip?
> 
> Thank you for advance.
> 
> -- 
> With best regards.
> ------------------------------------------------------------------
> Sergey Artjushkin                      Network Operation Center
>     (SKIV-RIPE)                               ISP "CARAVAN"
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message

-- 
Barney Wolff

"Nonetheless, ease and peace had left this people still curiously tough.
They were, if it came to it, difficult to daunt or to kill; and they were,
perhaps, so unwearyingly fond of good things not least because they could,
when put to it, do without them, and could survive rough handling by grief,
foe, or weather in a way that astonished those who did not know them well
and looked no further than their bellies and their well-fed faces." J.R.R.T.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 14:16:54 2001
Delivered-To: freebsd-net@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 916)
	id 9875D37B41A; Wed, 28 Nov 2001 14:16:50 -0800 (PST)
Date: Wed, 28 Nov 2001 14:16:50 -0800
From: Prafulla Deuskar <pdeuskar@freebsd.org>
To: freebsd-hackers@freebsd.org
Cc: freebsd-net@freebsd.org
Subject: Intel gigabit driver
Message-ID: <20011128141650.A96448@hub.freebsd.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 2.0.32 on an i486
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

All,

Intel Corporation has released a gigabit driver for
PRO/1000 series of adapters.

The driver is available for download from the following
url:

http://appsr.intel.com/scripts-df/Product_Filter.asp?ProductID=415


The driver will be committed to -CURRENT first and MFC'ed to
-STABLE later.


Thanks,
Prafulla

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 15:23:49 2001
Delivered-To: freebsd-net@freebsd.org
Received: from speedracer.speedtoys.com (mail.speedtoys.com [66.80.10.170])
	by hub.freebsd.org (Postfix) with ESMTP
	id A2DA137B405; Wed, 28 Nov 2001 15:23:36 -0800 (PST)
Received: from localhost (gemohler@localhost)
	by speedracer.speedtoys.com (8.11.3/8.11.1) with ESMTP id fASNgIS16867;
	Wed, 28 Nov 2001 15:42:19 -0800 (PST)
Date: Wed, 28 Nov 2001 15:42:18 -0800 (PST)
From: Geoff Mohler <gemohler@www.speedtoys.com>
X-Sender: gemohler@speedracer.speedtoys.com
To: Prafulla Deuskar <pdeuskar@FreeBSD.ORG>
Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
Subject: Re: Intel gigabit driver
In-Reply-To: <20011128141650.A96448@hub.freebsd.org>
Message-ID: <Pine.BSF.4.10.10111281541530.15701-100000@speedracer.speedtoys.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Yay..stable jumbo frames!  :^)

On Wed, 28 Nov 2001, Prafulla Deuskar wrote:

> All,
> 
> Intel Corporation has released a gigabit driver for
> PRO/1000 series of adapters.
> 
> The driver is available for download from the following
> url:
> 
> http://appsr.intel.com/scripts-df/Product_Filter.asp?ProductID=415
> 
> 
> The driver will be committed to -CURRENT first and MFC'ed to
> -STABLE later.
> 
> 
> Thanks,
> Prafulla
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 

---
Geoff Mohler


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 15:53:13 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70])
	by hub.freebsd.org (Postfix) with SMTP id B1A7237B417
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 15:53:07 -0800 (PST)
Received: (qmail 31239 invoked from network); 28 Nov 2001 23:52:47 -0000
Received: from unknown (HELO pipeline.ch) ([62.48.21.243]) (envelope-sender <oppermann@pipeline.ch>)
          by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP
          for <pdeuskar@freebsd.org>; 28 Nov 2001 23:52:47 -0000
Message-ID: <3C057850.55E9BC99@pipeline.ch>
Date: Thu, 29 Nov 2001 00:50:40 +0100
From: Andre Oppermann <oppermann@pipeline.ch>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Prafulla Deuskar <pdeuskar@freebsd.org>
Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org
Subject: Re: Intel gigabit driver
References: <20011128141650.A96448@hub.freebsd.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Prafulla Deuskar wrote:
> 
> All,
> 
> Intel Corporation has released a gigabit driver for
> PRO/1000 series of adapters.

That is funny! jlemon commited his gx driver for the same boards
just two weeks ago.

What happend at Intel? Their driver is even released under the
BSD license! (and the Linux one under the GPL)

How come considering their strict NDA policy the last years?

> The driver is available for download from the following
> url:
> 
> http://appsr.intel.com/scripts-df/Product_Filter.asp?ProductID=415
> 
> The driver will be committed to -CURRENT first and MFC'ed to
> -STABLE later.

Really? What about the gx driver?

-- 
Andre

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 16:38:26 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mass.dis.org (mass.dis.org [216.240.45.41])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7482837B417; Wed, 28 Nov 2001 16:38:18 -0800 (PST)
Received: from mass.dis.org (localhost [127.0.0.1])
	by mass.dis.org (8.11.6/8.11.3) with ESMTP id fAT0gCA06193;
	Wed, 28 Nov 2001 16:42:12 -0800 (PST)
	(envelope-from msmith@mass.dis.org)
Message-Id: <200111290042.fAT0gCA06193@mass.dis.org>
To: Andre Oppermann <oppermann@pipeline.ch>
Cc: Prafulla Deuskar <pdeuskar@freebsd.org>,
	freebsd-hackers@freebsd.org, freebsd-net@freebsd.org,
	msmith@mass.dis.org
Subject: Re: Intel gigabit driver 
In-Reply-To: Message from Andre Oppermann <oppermann@pipeline.ch> 
   of "Thu, 29 Nov 2001 00:50:40 +0100." <3C057850.55E9BC99@pipeline.ch> 
Date: Wed, 28 Nov 2001 16:42:12 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

> What happend at Intel? Their driver is even released under the
> BSD license! (and the Linux one under the GPL)

Many Intel software products are released under a BSD-like license.

Consider the ACPI CA codebase we use.

> > The driver will be committed to -CURRENT first and MFC'ed to
> > -STABLE later.
> 
> Really? What about the gx driver?

The 'gx' driver was committed so that Jonathan's code would be on
record, since he'd spent so much time and effort on it.  Testing so
far has indicated that the Intel driver is generally superior, but
it's not a very BSD-like driver and under some circumstances this can
be considered a bad thing.

The Intel driver will be the preferred driver for these cards.

 = Mike


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 16:53: 6 2001
Delivered-To: freebsd-net@freebsd.org
Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84])
	by hub.freebsd.org (Postfix) with ESMTP id 6052A37B419
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 16:53:04 -0800 (PST)
Received: from dialup-209.245.134.84.dial1.sanjose1.level3.net ([209.245.134.84] helo=blossom.cjclark.org)
	by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1)
	id 169FRn-0002Rj-00; Wed, 28 Nov 2001 16:53:03 -0800
Received: (from cjc@localhost)
	by blossom.cjclark.org (8.11.6/8.11.3) id fAT0qx205742;
	Wed, 28 Nov 2001 16:52:59 -0800 (PST)
	(envelope-from cjc)
Date: Wed, 28 Nov 2001 16:52:59 -0800
From: "Crist J. Clark" <cristjc@earthlink.net>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: inet_pton(3) Does Not Replace inet_aton(3)
Message-ID: <20011128165259.F3985@blossom.cjclark.org>
Reply-To: cjclark@alum.mit.edu
References: <20011127123301.B3788@gohan.cjclark.org> <200111281731.fASHV9948068@khavrinen.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200111281731.fASHV9948068@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Wed, Nov 28, 2001 at 12:31:09PM -0500
X-URL: http://people.freebsd.org/~cjc/
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Wed, Nov 28, 2001 at 12:31:09PM -0500, Garrett Wollman wrote:
> <<On Tue, 27 Nov 2001 12:33:01 -0800, "Crist J. Clark" <cristjc@earthlink.net> said:
> 
> > Where inet_pton(3) will fail (return a 1). That is, inet_pton(3) only
> > understands dotted quads. The comments in src/lib/libc/net/inet_pton.c
> > clearly show this is the intended behavior. But is that what we want?
> 
> Yes.  The old format is deprecated, obsolete, legacy, however you want
> to put it.

OK. But I think it should be documented.

Index: inet.3
===================================================================
RCS file: /export/ncvs/src/lib/libc/net/inet.3,v
retrieving revision 1.19
diff -u -r1.19 inet.3
--- inet.3	1 Oct 2001 16:08:55 -0000	1.19
+++ inet.3	29 Nov 2001 00:47:28 -0000
@@ -203,6 +203,14 @@
 otherwise, the number is interpreted as decimal).
 .Pp
 The
+.Fn inet_pton
+function only understands Internet addresses written as dotted quads.
+Each
+.Dq part
+may only contain numeric characters and is always interpreted as a
+decimal value.
+.Pp
+The
 .Fn inet_aton
 and
 .Fn inet_ntoa

-- 
Crist J. Clark                     |     cjclark@alum.mit.edu
                                   |     cjclark@jhu.edu
http://people.freebsd.org/~cjc/    |     cjc@freebsd.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 17: 8:25 2001
Delivered-To: freebsd-net@freebsd.org
Received: from snipe.prod.itd.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62])
	by hub.freebsd.org (Postfix) with ESMTP id 277C737B41A
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 17:08:22 -0800 (PST)
Received: from dialup-209.245.134.84.dial1.sanjose1.level3.net ([209.245.134.84] helo=blossom.cjclark.org)
	by snipe.prod.itd.earthlink.net with esmtp (Exim 3.33 #1)
	id 169FgX-0003da-00; Wed, 28 Nov 2001 17:08:18 -0800
Received: (from cjc@localhost)
	by blossom.cjclark.org (8.11.6/8.11.3) id fAT18FQ05798;
	Wed, 28 Nov 2001 17:08:15 -0800 (PST)
	(envelope-from cjc)
Date: Wed, 28 Nov 2001 17:08:15 -0800
From: "Crist J. Clark" <cristjc@earthlink.net>
To: "irado@nettaxi.com" <irado@nettaxi.com>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: netmask for aliased ip
Message-ID: <20011128170815.G3985@blossom.cjclark.org>
Reply-To: cjclark@alum.mit.edu
References: <200111281637.fASGbgd07767@mail2.bigmailbox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <200111281637.fASGbgd07767@mail2.bigmailbox.com>; from irado@nettaxi.com on Wed, Nov 28, 2001 at 08:37:42AM -0800
X-URL: http://people.freebsd.org/~cjc/
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Wed, Nov 28, 2001 at 08:37:42AM -0800, irado@nettaxi.com wrote:
> 
> somebody told me that, when aliasing, the 2nd to ´n´ ipaddress netmask must not be  the regular one, but 0xffffffff instead. Example:
> 
> rl0 = 200.200.200.200 netmask 255.255.0.0
> rl0:0 (the aliased) 200.200.220.200 netmask 0xffffffff
> [lots more]
> rl0:3000 200.200.255.200 netmask 0xffffffff
> 
> is it for real?? what is the reason for this?

Somebody told you wrong. When adding an alias _which is on the same
logical network_ as other addresses, it should have an 0xffffffff
mask. That is, only one address on an interface should have the "real"
netmask for any one network.

The simple explanation for this is that if you have,

  a.b.c.d/24
  a.b.c.e/24

On an interface and you try to initiate a connection to another
machine through this interface, should your connection use a.b.c.d or
a.b.c.e as the source address? It is ambiguous and can make problems.

In your case, the addresses lie on different networks. Each address
should have the netmask of the network it is on. Note that you do not
have the above problem in this case.
-- 
Crist J. Clark                     |     cjclark@alum.mit.edu
                                   |     cjclark@jhu.edu
http://people.freebsd.org/~cjc/    |     cjc@freebsd.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 17:13:54 2001
Delivered-To: freebsd-net@freebsd.org
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP
	id 011CF37B416; Wed, 28 Nov 2001 17:13:51 -0800 (PST)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fAT1DnH04474;
	Wed, 28 Nov 2001 20:13:49 -0500 (EST)
	(envelope-from wollman)
Date: Wed, 28 Nov 2001 20:13:49 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200111290113.fAT1DnH04474@khavrinen.lcs.mit.edu>
To: Greg Lehey <grog@FreeBSD.org>
Cc: net@FreeBSD.org
Subject: Re: FreeBSD performing worse than Linux?
In-Reply-To: <20011129105321.C74413@monorchid.lemis.com>
References: <20011128102241.6887B380A@overcee.netplex.com.au>
	<20011128112006.195983808@overcee.netplex.com.au>
	<20011129105321.C74413@monorchid.lemis.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

[Redirecting to a more-appropriate mailing-list.]

<<On Thu, 29 Nov 2001 10:53:21 +1030, Greg Lehey <grog@FreeBSD.org> said:

> I spoke to him on the phone this morning.  He replaced it with a 3Com
> card, but there was no significant difference in performance.  He's
> currently upgrading to -STABLE, which seems to be a sensible thing to
> do, so we should wait to see what happens then.

We appear to have some big TCP problems in -stable (and presumably in
-current as well).  Anyone wishing to look at traces is welcome to
retrieve http://khavrinen.lcs.mit.edu/test{,2,3,4}.tcpd and take a
look.  Warning: these files are very, very large:

 95M    test.tcpd
108M    test2.tcpd
107M    test3.tcpd
 15M    test4.tcpd

Each trace shows a single large file transfer from a 4.4-stable
machine to my -current desktop over a local-area network.  test4 was
aborted about 10% into the transfer so that you have a chance at
looking at the whole thing in xplot.  There are multiple pathologies
visible in the results, but a good place to start would be around
:56.44 in test4.

-GAWollman


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 18:49:26 2001
Delivered-To: freebsd-net@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8334237B419; Wed, 28 Nov 2001 18:49:17 -0800 (PST)
Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id fAT2nGW65956;
	Wed, 28 Nov 2001 18:49:16 -0800 (PST)
	(envelope-from mjacob@feral.com)
Date: Wed, 28 Nov 2001 18:49:16 -0800 (PST)
From: Matthew Jacob <mjacob@feral.com>
X-Sender: mjacob@beppo
Reply-To: mjacob@feral.com
To: Prafulla Deuskar <pdeuskar@FreeBSD.ORG>
Cc: freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
Subject: Re: Intel gigabit driver
In-Reply-To: <20011128141650.A96448@hub.freebsd.org>
Message-ID: <Pine.BSF.4.21.0111281848200.64775-100000@beppo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


A belated welcome to being a FreeBSD committer! We look forward eagerly to all
contributions you and Intel's experience with networking can bring to us all!

-matt


On Wed, 28 Nov 2001, Prafulla Deuskar wrote:

> All,
> 
> Intel Corporation has released a gigabit driver for
> PRO/1000 series of adapters.
> 
> The driver is available for download from the following
> url:
> 
> http://appsr.intel.com/scripts-df/Product_Filter.asp?ProductID=415
> 
> 
> The driver will be committed to -CURRENT first and MFC'ed to
> -STABLE later.
> 
> 
> Thanks,
> Prafulla
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 20:37:48 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mail.realtek.com.tw (ms1.realtek.com.tw [203.69.112.3])
	by hub.freebsd.org (Postfix) with ESMTP id E956337B405
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 20:37:38 -0800 (PST)
Received: from RTCN3848 ([172.20.35.162])
          by mail.realtek.com.tw (Lotus Domino Release 5.0.8)
          with SMTP id 2001112912020428:13125 ;
          Thu, 29 Nov 2001 12:02:04 +0800 
Message-ID: <002801c1788b$b2dc3dd0$a22314ac@RTCN3848>
From: "¼B¾JÂ×" <cfliu@realtek.com.tw>
To: <freebsd-net@freebsd.org>
Subject: Does 4.4 kernel supports TCP simultaneous open?
Date: Thu, 29 Nov 2001 12:09:53 +0800
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-MIMETrack: Itemize by SMTP Server on ms1/Realtek(Release 5.0.8 |June 18, 2001) at 11/29/2001
 12:02:04 PM,
	Serialize by Router on ms1/Realtek(Release 5.0.8 |June 18, 2001) at 11/29/2001
 12:35:05 PM,
	Serialize complete at 11/29/2001 12:35:05 PM
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0025_01C178CE.C0E0D240"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

This is a multi-part message in MIME format.

------=_NextPart_000_0025_01C178CE.C0E0D240
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset="big5"

Hi, I am tracing the FreeBSD 4.4 kernel and I found that its TCP seems =
NOT be able to do simultaneous open according to the source code. In =
tcp_input.c,  even though code near line #1750,=20

case TCPS_SYN_RECEIVED:
   .....
  if (tp->t_flags & TF_NEEDFIN) {
   tp->t_state =3D TCPS_FIN_WAIT_1;
   tp->t_flags &=3D ~TF_NEEDFIN;
  } else {
   tp->t_state =3D TCPS_ESTABLISHED;
   callout_reset(tp->tt_keep, tcp_keepidle,=20
          tcp_timer_keep, tp);
  }

do change state from SYN_RCVD state to ESTABLISHED, however, near line =
1700 , the code fragment

if (thflags & TH_SYN) {
  tp =3D tcp_drop(tp, ECONNRESET);
  rstreason =3D BANDLIM_UNLIMITED;
  goto dropwithreset;
 }


 drops a packet with SYN bit set in SYN_RCVD state. I think this would =
break TCP's simultaneous open.=20

Since upon receiving a SYN segment in SYN_SENT state, TCP switches to =
SYN_RCVD state and sends a (ACK,SYN) segment to the peer, if the peer =
drops segments with SYN bit set during SYN_RCVD state, the simultaneous =
open mechanism of TCP would break.=20

Am I correct?

David.




------=_NextPart_000_0025_01C178CE.C0E0D240
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset="big5"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dbig5" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3315.2870" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi, I am tracing the FreeBSD 4.4 kernel and I found =
that its=20
TCP seems NOT be able to do simultaneous open&nbsp;according to the =
source code.=20
In tcp_input.c,&nbsp; e</FONT><FONT size=3D2>ven though code near line =
#1750,=20
</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>case TCPS_SYN_RECEIVED:</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp; .....</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;if (tp-&gt;t_flags &amp; TF_NEEDFIN)=20
{<BR>&nbsp;&nbsp;&nbsp;tp-&gt;t_state =3D=20
TCPS_FIN_WAIT_1;<BR>&nbsp;&nbsp;&nbsp;tp-&gt;t_flags &amp;=3D=20
~TF_NEEDFIN;<BR>&nbsp;&nbsp;} else {<BR>&nbsp;&nbsp;&nbsp;tp-&gt;t_state =
=3D=20
TCPS_ESTABLISHED;<BR>&nbsp;&nbsp;&nbsp;callout_reset(tp-&gt;tt_keep,=20
tcp_keepidle, <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

tcp_timer_keep, tp);<BR>&nbsp;&nbsp;}</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>do change state from SYN_RCVD state to ESTABLISHED, =
however,=20
near line 1700 , the code fragment
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>if (thflags &amp; TH_SYN) {<BR>&nbsp;&nbsp;tp =3D =
tcp_drop(tp,=20
ECONNRESET);<BR>&nbsp;&nbsp;rstreason =3D =
BANDLIM_UNLIMITED;<BR>&nbsp;&nbsp;goto=20
dropwithreset;<BR>&nbsp;}<BR></FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;drops a packet with SYN bit set in SYN_RCVD =
state. I=20
think this would break TCP's simultaneous open. </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Since upon receiving a SYN segment in SYN_SENT =
state, TCP=20
switches to SYN_RCVD state and sends a (ACK,SYN) segment to the peer, if =
the=20
peer drops segments with SYN bit set during SYN_RCVD state, the =
simultaneous=20
open mechanism of TCP would break. </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Am I correct?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>David.</DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;</DIV></FONT></BODY></HTML>

------=_NextPart_000_0025_01C178CE.C0E0D240--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 20:37:53 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mail.realtek.com.tw (ms1.realtek.com.tw [203.69.112.3])
	by hub.freebsd.org (Postfix) with ESMTP id 3C5D937B41A
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 20:37:41 -0800 (PST)
Received: from RTCN3848 ([172.20.35.162])
          by mail.realtek.com.tw (Lotus Domino Release 5.0.8)
          with SMTP id 2001112912302643:13254 ;
          Thu, 29 Nov 2001 12:30:26 +0800 
Message-ID: <003701c1788f$aa1c91a0$a22314ac@RTCN3848>
From: "cfliu" <cfliu@csie.nctu.edu.tw>
To: <freebsd-net@freebsd.org>
Subject: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
Date: Thu, 29 Nov 2001 12:38:17 +0800
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-MIMETrack: Itemize by SMTP Server on ms1/Realtek(Release 5.0.8 |June 18, 2001) at 11/29/2001
 12:30:26 PM,
	Serialize by Router on ms1/Realtek(Release 5.0.8 |June 18, 2001) at 11/29/2001
 12:35:08 PM,
	Serialize complete at 11/29/2001 12:35:08 PM
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0034_01C178D2.B8308F60"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

This is a multi-part message in MIME format.

------=_NextPart_000_0034_01C178D2.B8308F60
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset="big5"

Hi, I am tracing the FreeBSD 4.4 kernel and I found that its TCP seems =
NOT be able to do simultaneous open according to the source code. In =
tcp_input.c,  even though code near line #1750,=20
=20
case TCPS_SYN_RECEIVED:
   .....
  if (tp->t_flags & TF_NEEDFIN) {
   tp->t_state =3D TCPS_FIN_WAIT_1;
   tp->t_flags &=3D ~TF_NEEDFIN;
  } else {
   tp->t_state =3D TCPS_ESTABLISHED;
   callout_reset(tp->tt_keep, tcp_keepidle,=20
          tcp_timer_keep, tp);
  }

do change state from SYN_RCVD state to ESTABLISHED, however, near line =
1700 , the code fragment=20

if (thflags & TH_SYN) {
  tp =3D tcp_drop(tp, ECONNRESET);
  rstreason =3D BANDLIM_UNLIMITED;
  goto dropwithreset;
 }

=20
 drops a packet with SYN bit set in SYN_RCVD state. I think this would =
break TCP's simultaneous open.=20
=20
Since upon receiving a SYN segment in SYN_SENT state, TCP switches to =
SYN_RCVD state and sends a (ACK,SYN) segment to the peer, if the peer =
drops segments with SYN bit set during SYN_RCVD state, the simultaneous =
open mechanism of TCP would break.=20
=20
Am I correct?
=20
David.

=20
=20

------=_NextPart_000_0034_01C178D2.B8308F60
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset="big5"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dbig5" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3315.2870" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>Hi, I am tracing the FreeBSD 4.4 kernel and I found =
that its=20
TCP seems NOT be able to do simultaneous open&nbsp;according to the =
source code.=20
In tcp_input.c,&nbsp; e</FONT><FONT size=3D2>ven though code near line =
#1750,=20
</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>case TCPS_SYN_RECEIVED:</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp; .....</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;if (tp-&gt;t_flags &amp; TF_NEEDFIN)=20
{<BR>&nbsp;&nbsp;&nbsp;tp-&gt;t_state =3D=20
TCPS_FIN_WAIT_1;<BR>&nbsp;&nbsp;&nbsp;tp-&gt;t_flags &amp;=3D=20
~TF_NEEDFIN;<BR>&nbsp;&nbsp;} else {<BR>&nbsp;&nbsp;&nbsp;tp-&gt;t_state =
=3D=20
TCPS_ESTABLISHED;<BR>&nbsp;&nbsp;&nbsp;callout_reset(tp-&gt;tt_keep,=20
tcp_keepidle, <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

tcp_timer_keep, tp);<BR>&nbsp;&nbsp;}</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>do change state from SYN_RCVD state to ESTABLISHED, =
however,=20
near line 1700 , the code fragment=20
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>if (thflags &amp; TH_SYN) {<BR>&nbsp;&nbsp;tp =3D =
tcp_drop(tp,=20
ECONNRESET);<BR>&nbsp;&nbsp;rstreason =3D =
BANDLIM_UNLIMITED;<BR>&nbsp;&nbsp;goto=20
dropwithreset;<BR>&nbsp;}<BR></FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;drops a packet with SYN bit set in SYN_RCVD =
state. I=20
think this would break TCP's simultaneous open. </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Since upon receiving a SYN segment in SYN_SENT =
state, TCP=20
switches to SYN_RCVD state and sends a (ACK,SYN) segment to the peer, if =
the=20
peer drops segments with SYN bit set during SYN_RCVD state, the =
simultaneous=20
open mechanism of TCP would break. </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Am I correct?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV>David.</DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;</DIV></FONT></FONT></DIV></BODY></HTML>

------=_NextPart_000_0034_01C178D2.B8308F60--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 22:24:33 2001
Delivered-To: freebsd-net@freebsd.org
Received: from femail17.sdc1.sfba.home.com (femail17.sdc1.sfba.home.com [24.0.95.144])
	by hub.freebsd.org (Postfix) with ESMTP id A32E837B43F
	for <freebsd-net@FreeBSD.ORG>; Wed, 28 Nov 2001 22:24:29 -0800 (PST)
Received: from lightnin ([65.11.111.111]) by femail17.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP
          id <20011129062429.OEHX5929.femail17.sdc1.sfba.home.com@lightnin>
          for <freebsd-net@FreeBSD.ORG>; Wed, 28 Nov 2001 22:24:29 -0800
Date: Wed, 28 Nov 2001 22:24:28 -0800
Subject: Re: netmask for aliased ip
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v475)
From: justin@mac.com
To: freebsd-net@FreeBSD.ORG
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <20011128170815.G3985@blossom.cjclark.org>
Message-Id: <BDF9EC80-E491-11D5-A7BB-0003934474AC@mac.com>
X-Mailer: Apple Mail (2.475)
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

FWIW, the FreeBSD FAQ (10.9) sez this (it's a one-liner that shows the=20=

netmask 0xffffffff).

Regards,

Justin

On Wednesday, November 28, 2001, at 05:08 , Crist J. Clark wrote:

> On Wed, Nov 28, 2001 at 08:37:42AM -0800, irado@nettaxi.com wrote:
>>
>> somebody told me that, when aliasing, the 2nd to =B4n=B4 ipaddress =
netmask=20
>> must not be  the regular one, but 0xffffffff instead. Example:
>>
>> rl0 =3D 200.200.200.200 netmask 255.255.0.0
>> rl0:0 (the aliased) 200.200.220.200 netmask 0xffffffff
>> [lots more]
>> rl0:3000 200.200.255.200 netmask 0xffffffff
>>
>> is it for real?? what is the reason for this?
>
> Somebody told you wrong. When adding an alias _which is on the same
> logical network_ as other addresses, it should have an 0xffffffff
> mask. That is, only one address on an interface should have the "real"
> netmask for any one network.
>
> The simple explanation for this is that if you have,
>
>   a.b.c.d/24
>   a.b.c.e/24
>
> On an interface and you try to initiate a connection to another
> machine through this interface, should your connection use a.b.c.d or
> a.b.c.e as the source address? It is ambiguous and can make problems.
>
> In your case, the addresses lie on different networks. Each address
> should have the netmask of the network it is on. Note that you do not
> have the above problem in this case.
> --
> Crist J. Clark                     |     cjclark@alum.mit.edu
>                                    |     cjclark@jhu.edu
> http://people.freebsd.org/~cjc/    |     cjc@freebsd.org
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>
>
--
/~\ The ASCII           Justin C. Walker, Curmudgeon-at-large
\ / Ribbon Campaign
  X  Against HTML
/ \ Email!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 22:29:10 2001
Delivered-To: freebsd-net@freebsd.org
Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120])
	by hub.freebsd.org (Postfix) with ESMTP id 1DD7437B442
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 22:29:05 -0800 (PST)
Received: from dialup-209.247.138.241.dial1.sanjose1.level3.net ([209.247.138.241] helo=blossom.cjclark.org)
	by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1)
	id 169Kgy-0002aT-00; Wed, 28 Nov 2001 22:29:04 -0800
Received: (from cjc@localhost)
	by blossom.cjclark.org (8.11.6/8.11.3) id fAT6T0E06578;
	Wed, 28 Nov 2001 22:29:00 -0800 (PST)
	(envelope-from cjc)
Date: Wed, 28 Nov 2001 22:29:00 -0800
From: "Crist J. Clark" <cristjc@earthlink.net>
To: Ahsan Ali <ahsan@khi.comsats.net.pk>
Cc: freebsd-net@freebsd.org
Subject: Re: netmask for aliased ip
Message-ID: <20011128222900.L3985@blossom.cjclark.org>
Reply-To: cjclark@alum.mit.edu
References: <200111281637.fASGbgd07767@mail2.bigmailbox.com> <20011128170815.G3985@blossom.cjclark.org> <002d01c1788c$8388f4f0$be026b83@ahsanali>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <002d01c1788c$8388f4f0$be026b83@ahsanali>; from ahsan@khi.comsats.net.pk on Thu, Nov 29, 2001 at 09:15:34AM +0500
X-URL: http://people.freebsd.org/~cjc/
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Thu, Nov 29, 2001 at 09:15:34AM +0500, Ahsan Ali wrote:
> > Somebody told you wrong. When adding an alias _which is on the same
> > logical network_ as other addresses, it should have an 0xffffffff
> > mask. That is, only one address on an interface should have the "real"
> > netmask for any one network.
> >
> > The simple explanation for this is that if you have,
> >
> >   a.b.c.d/24
> >   a.b.c.e/24
> >
> > On an interface and you try to initiate a connection to another
> > machine through this interface, should your connection use a.b.c.d or
> > a.b.c.e as the source address? It is ambiguous and can make problems.
> 
> 
> Surely this does not hold true for situations in which you're doing IP based
> virtual hosting?

Sure it does.

> Or is it acceptable because most hosting requests will come
> in through the gateway and thus be routed to this IP? Wouldn't that break
> testing from local machines in the sense that traffic would HAVE to go
> through the router?

I am not sure what this means. The traffic will have to go through a
gateway to get anywhere.

> If all IP's have a /24 netmask and you set your default route through one
> specific instance of an interface, wouldn't that be the one thats always
> used?

For TCP, that is what is always used by default when creating an
outbound connection. For incoming connections, the machine will of
course reply using the IP address the connection came in on. And a
program can always request to use a specific address if it wants to.

I am not sure where you see a problem.
-- 
Crist J. Clark                     |     cjclark@alum.mit.edu
                                   |     cjclark@jhu.edu
http://people.freebsd.org/~cjc/    |     cjc@freebsd.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 22:40:33 2001
Delivered-To: freebsd-net@freebsd.org
Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9])
	by hub.freebsd.org (Postfix) with ESMTP id 8632737B422
	for <net@freebsd.org>; Wed, 28 Nov 2001 22:40:30 -0800 (PST)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.11.0/8.11.0) id fAT6bd213755;
	Thu, 29 Nov 2001 00:37:39 -0600 (CST)
	(envelope-from jlemon)
Date: Thu, 29 Nov 2001 00:37:39 -0600 (CST)
From: Jonathan Lemon <jlemon@flugsvamp.com>
Message-Id: <200111290637.fAT6bd213755@prism.flugsvamp.com>
To: cfliu@csie.nctu.edu.tw, net@freebsd.org
Subject: Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
X-Newsgroups: local.mail.freebsd-net
In-Reply-To: <local.mail.freebsd-net/20011129043524$01c0@prism.flugsvamp.com>
Organization: 
Cc: 
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

In article <local.mail.freebsd-net/20011129043524$01c0@prism.flugsvamp.com> you write:
>-=-=-=-=-=-
>
>Hi, I am tracing the FreeBSD 4.4 kernel and I found that its TCP seems
>NOT be able to do simultaneous open according to the source code. In
>tcp_input.c,  even though code near line #1750, 
> 
>case TCPS_SYN_RECEIVED:
>   .....
>  if (tp->t_flags & TF_NEEDFIN) {
>   tp->t_state = TCPS_FIN_WAIT_1;
>   tp->t_flags &= ~TF_NEEDFIN;
>  } else {
>   tp->t_state = TCPS_ESTABLISHED;
>   callout_reset(tp->tt_keep, tcp_keepidle, 
>          tcp_timer_keep, tp);
>  }
>
>do change state from SYN_RCVD state to ESTABLISHED, however, near line
>1700 , the code fragment 
>
>if (thflags & TH_SYN) {
>  tp = tcp_drop(tp, ECONNRESET);
>  rstreason = BANDLIM_UNLIMITED;
>  goto dropwithreset;
> }
>
> 
> drops a packet with SYN bit set in SYN_RCVD state. I think this would
>break TCP's simultaneous open. 
> 
>Since upon receiving a SYN segment in SYN_SENT state, TCP switches to
>SYN_RCVD state and sends a (ACK,SYN) segment to the peer, if the peer
>drops segments with SYN bit set during SYN_RCVD state, the simultaneous
>open mechanism of TCP would break. 
> 
>Am I correct?

No.  In this case, there are 3 distinct state transitions:

	A. send SYN.	CLOSED -> SYN_SENT
	B. recv SYN.	SYN_SENT -> SYN_RECEIVED
	C. recv ACK.	SYN_RECIEVED -> ESTABLISHED

So dropping a connection when receiving a SYN packet in the SYN_RECEIVED
state is the correct thing to do; this is would be a duplicate SYN.  For
a simultaneous open, the peer's SYN is received when the local state is
SYN_SENT.

The error in your logic above is that in step B, only an ACK is sent to
the peer, the SYN is not retransmitted as well.
-- 
Jonathan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 22:59:51 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mail.realtek.com.tw (ms1.realtek.com.tw [203.69.112.3])
	by hub.freebsd.org (Postfix) with ESMTP id 3A9DB37B421
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 22:59:48 -0800 (PST)
Received: from RTCN3848 ([172.20.35.162])
          by mail.realtek.com.tw (Lotus Domino Release 5.0.8)
          with SMTP id 2001112914551241:14066 ;
          Thu, 29 Nov 2001 14:55:12 +0800 
Message-ID: <001701c178a3$e43670e0$a22314ac@RTCN3848>
From: "¼B¾JÂ×" <cfliu@realtek.com.tw>
To: "Jonathan Lemon" <jlemon@flugsvamp.com>
Cc: <freebsd-net@freebsd.org>
References: <200111290637.fAT6bd213755@prism.flugsvamp.com>
Subject: Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
Date: Thu, 29 Nov 2001 15:03:04 +0800
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-MIMETrack: Itemize by SMTP Server on ms1/Realtek(Release 5.0.8 |June 18, 2001) at 11/29/2001
 02:55:12 PM,
	Serialize by Router on ms1/Realtek(Release 5.0.8 |June 18, 2001) at 11/29/2001
 02:57:13 PM,
	Serialize complete at 11/29/2001 02:57:13 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="big5"
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Thanks...I know where my problem is now...It's indeed   a duplicate SYN.

By the way, the tcp_input function is so long and large and there are
several goto statements which make reading the code even more difficult. Is
this intened to be like this? Even with Steven's TCP/IP Vol.2, it took me
three whole days to draw a Visio flow chart of this function. Has anybody
ever considered of reorganizing this module?

David.

> No.  In this case, there are 3 distinct state transitions:
>
> A. send SYN. CLOSED -> SYN_SENT
> B. recv SYN. SYN_SENT -> SYN_RECEIVED
> C. recv ACK. SYN_RECIEVED -> ESTABLISHED
>
> So dropping a connection when receiving a SYN packet in the SYN_RECEIVED
> state is the correct thing to do; this is would be a duplicate SYN.  For
> a simultaneous open, the peer's SYN is received when the local state is
> SYN_SENT.
>
> The error in your logic above is that in step B, only an ACK is sent to
> the peer, the SYN is not retransmitted as well.
> --
> Jonathan
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 23:52:23 2001
Delivered-To: freebsd-net@freebsd.org
Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74])
	by hub.freebsd.org (Postfix) with ESMTP id 4AE7A37B41B
	for <freebsd-net@freebsd.org>; Wed, 28 Nov 2001 23:52:12 -0800 (PST)
Received: from dialup-209.247.138.241.dial1.sanjose1.level3.net ([209.247.138.241] helo=blossom.cjclark.org)
	by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1)
	id 169LzO-00031I-00; Wed, 28 Nov 2001 23:52:11 -0800
Received: (from cjc@localhost)
	by blossom.cjclark.org (8.11.6/8.11.3) id fAT7q8606957;
	Wed, 28 Nov 2001 23:52:08 -0800 (PST)
	(envelope-from cjc)
Date: Wed, 28 Nov 2001 23:52:08 -0800
From: "Crist J. Clark" <cristjc@earthlink.net>
To: justin@mac.com
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: netmask for aliased ip
Message-ID: <20011128235208.O3985@blossom.cjclark.org>
Reply-To: cjclark@alum.mit.edu
References: <20011128170815.G3985@blossom.cjclark.org> <BDF9EC80-E491-11D5-A7BB-0003934474AC@mac.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <BDF9EC80-E491-11D5-A7BB-0003934474AC@mac.com>; from justin@mac.com on Wed, Nov 28, 2001 at 10:24:28PM -0800
X-URL: http://people.freebsd.org/~cjc/
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Wed, Nov 28, 2001 at 10:24:28PM -0800, justin@mac.com wrote:
> FWIW, the FreeBSD FAQ (10.9) sez this (it's a one-liner that shows the 
> netmask 0xffffffff).

I'll send in a doc PR for this. The ifconfig(8) page gets it right.

     alias   Establish an additional network address for this interface.  This
             is sometimes useful when changing network numbers, and one wishes
             to accept packets addressed to the old interface.  If the address
             is on the same subnet as the first network address for this
             interface, a netmask of 0xffffffff has to be specified.
-- 
Crist J. Clark                     |     cjclark@alum.mit.edu
                                   |     cjclark@jhu.edu
http://people.freebsd.org/~cjc/    |     cjc@freebsd.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Wed Nov 28 23:59:54 2001
Delivered-To: freebsd-net@freebsd.org
Received: from femail47.sdc1.sfba.home.com (femail47.sdc1.sfba.home.com [24.254.60.41])
	by hub.freebsd.org (Postfix) with ESMTP id 0E4EA37B41B
	for <freebsd-net@FreeBSD.ORG>; Wed, 28 Nov 2001 23:59:52 -0800 (PST)
Received: from lightnin ([65.11.111.111]) by femail47.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP
          id <20011129075951.PMLY27388.femail47.sdc1.sfba.home.com@lightnin>
          for <freebsd-net@FreeBSD.ORG>; Wed, 28 Nov 2001 23:59:51 -0800
Date: Wed, 28 Nov 2001 23:59:51 -0800
Subject: Re: netmask for aliased ip
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v475)
From: justin@mac.com
To: freebsd-net@FreeBSD.ORG
Content-Transfer-Encoding: 7bit
In-Reply-To: <20011128235208.O3985@blossom.cjclark.org>
Message-Id: <10DB5227-E49F-11D5-A7BB-0003934474AC@mac.com>
X-Mailer: Apple Mail (2.475)
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


On Wednesday, November 28, 2001, at 11:52 , Crist J. Clark wrote:

> On Wed, Nov 28, 2001 at 10:24:28PM -0800, justin@mac.com wrote:
>> FWIW, the FreeBSD FAQ (10.9) sez this (it's a one-liner that shows the
>> netmask 0xffffffff).
>
> I'll send in a doc PR for this. The ifconfig(8) page gets it right.
>
>      alias   Establish an additional network address for this 
> interface.  This
>              is sometimes useful when changing network numbers, and one 
> wishes
>              to accept packets addressed to the old interface.  If the 
> address
>              is on the same subnet as the first network address for this
>              interface, a netmask of 0xffffffff has to be specified.

 From the nitpick front: shouldn't that be "...on the same subnet as an 
existing network address..."?

Regards,

Justin

---
Justin C. Walker, Curmudgeon-At-Large  *
Institute for General Semantics        |       Men are from Earth.
                                        |       Women are from Earth.
                                        |       Deal with it.
*--------------------------------------*-------------------------------*


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29  0:17: 2 2001
Delivered-To: freebsd-net@freebsd.org
Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65])
	by hub.freebsd.org (Postfix) with ESMTP id 0CD4C37B41B
	for <freebsd-net@FreeBSD.ORG>; Thu, 29 Nov 2001 00:16:50 -0800 (PST)
Received: (from ru@localhost)
	by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fAT8GHu84112;
	Thu, 29 Nov 2001 10:16:17 +0200 (EET)
	(envelope-from ru)
Date: Thu, 29 Nov 2001 10:16:17 +0200
From: Ruslan Ermilov <ru@FreeBSD.ORG>
To: cjclark@alum.mit.edu
Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>,
	freebsd-net@FreeBSD.ORG
Subject: Re: inet_pton(3) Does Not Replace inet_aton(3)
Message-ID: <20011129101617.B77679@sunbay.com>
References: <20011127123301.B3788@gohan.cjclark.org> <200111281731.fASHV9948068@khavrinen.lcs.mit.edu> <20011128165259.F3985@blossom.cjclark.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011128165259.F3985@blossom.cjclark.org>
User-Agent: Mutt/1.3.23i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Wed, Nov 28, 2001 at 04:52:59PM -0800, Crist J. Clark wrote:
> On Wed, Nov 28, 2001 at 12:31:09PM -0500, Garrett Wollman wrote:
> > <<On Tue, 27 Nov 2001 12:33:01 -0800, "Crist J. Clark" <cristjc@earthlink.net> said:
> > 
> > > Where inet_pton(3) will fail (return a 1). That is, inet_pton(3) only
> > > understands dotted quads. The comments in src/lib/libc/net/inet_pton.c
> > > clearly show this is the intended behavior. But is that what we want?
> > 
> > Yes.  The old format is deprecated, obsolete, legacy, however you want
> > to put it.
> 
> OK. But I think it should be documented.
> 
> Index: inet.3
> ===================================================================
> RCS file: /export/ncvs/src/lib/libc/net/inet.3,v
> retrieving revision 1.19
> diff -u -r1.19 inet.3
> --- inet.3	1 Oct 2001 16:08:55 -0000	1.19
> +++ inet.3	29 Nov 2001 00:47:28 -0000
> @@ -203,6 +203,14 @@
>  otherwise, the number is interpreted as decimal).
>  .Pp
>  The
> +.Fn inet_pton
> +function only understands Internet addresses written as dotted quads.
> +Each
> +.Dq part
> +may only contain numeric characters and is always interpreted as a
> +decimal value.
> +.Pp
> +The
>  .Fn inet_aton
>  and
>  .Fn inet_ntoa
> 
Um, don't we already have this documented in the STANDARDS section?
Though I liked POSIX.1-200x text more.


Cheers,
-- 
Ruslan Ermilov		Oracle Developer/DBA,
ru@sunbay.com		Sunbay Software AG,
ru@FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29  4:23:10 2001
Delivered-To: freebsd-net@freebsd.org
Received: from tao.org.uk (genius.tao.org.uk [212.135.162.51])
	by hub.freebsd.org (Postfix) with ESMTP id 215D237B434
	for <freebsd-net@freebsd.org>; Thu, 29 Nov 2001 04:23:05 -0800 (PST)
Received: by tao.org.uk (Postfix, from userid 100)
	id 6C6C8CF; Thu, 29 Nov 2001 12:22:57 +0000 (GMT)
Date: Thu, 29 Nov 2001 12:22:57 +0000
From: Josef Karthauser <joe@tao.org.uk>
To: =?iso-8859-1?Q?=BCB=BEJ=C2=D7?= <cfliu@realtek.com.tw>
Cc: Jonathan Lemon <jlemon@flugsvamp.com>, freebsd-net@freebsd.org
Subject: Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
Message-ID: <20011129122257.A19084@tao.org.uk>
References: <200111290637.fAT6bd213755@prism.flugsvamp.com> <001701c178a3$e43670e0$a22314ac@RTCN3848>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <001701c178a3$e43670e0$a22314ac@RTCN3848>; from cfliu@realtek.com.tw on Thu, Nov 29, 2001 at 03:03:04PM +0800
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 29, 2001 at 03:03:04PM +0800, =BCB=BEJ=C2=D7 wrote:
> Thanks...I know where my problem is now...It's indeed   a duplicate SYN.
>=20
> By the way, the tcp_input function is so long and large and there are
> several goto statements which make reading the code even more difficult. =
Is
> this intened to be like this? Even with Steven's TCP/IP Vol.2, it took me
> three whole days to draw a Visio flow chart of this function. Has anybody
> ever considered of reorganizing this module?

Any chance that you could release the chart as a graphic to the
community?  I'd be interested to see that.

Joe

--sm4nu43k4a2Rpi4c
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjwGKKAACgkQXVIcjOaxUBaGbQCfTSUr389h7WDOWGfzKcX+qML1
P8gAoN2RlnG+Xt+OXKM1thNXX5vMm9V9
=CbrW
-----END PGP SIGNATURE-----

--sm4nu43k4a2Rpi4c--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29  4:26:40 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id 66B9A37B43C
	for <net@FreeBSD.ORG>; Thu, 29 Nov 2001 04:26:27 -0800 (PST)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA01501;
	Thu, 29 Nov 2001 23:26:16 +1100
Date: Thu, 29 Nov 2001 23:26:20 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender:  <bde@gamplex.bde.org>
To: Luigi Rizzo <rizzo@aciri.org>
Cc: <net@FreeBSD.ORG>
Subject: Re: Revised polling code for STABLE
In-Reply-To: <20011126115704.L88153@iguana.aciri.org>
Message-ID: <20011129222256.W1389-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

> On Mon, 26 Nov 2001, Luigi Rizzo wrote:
>
> > [Bcc to -stable in case someone is interested there]
> >
> > Attached you can find the latest version of the polling code
> > for STABLE (which is useful to make boxes much more robust
> > to attacks and have much better responsiveness under [over]load).
> > ...
> Index: sys/i386/i386/swtch.s
> ===================================================================
> RCS file: /home/xorpc/u2/freebsd/src/sys/i386/i386/swtch.s,v
> retrieving revision 1.89.2.4
> diff -u -r1.89.2.4 swtch.s
> --- sys/i386/i386/swtch.s	2001/07/26 02:29:10	1.89.2.4
> +++ sys/i386/i386/swtch.s	2001/10/26 21:54:19
> @@ -246,6 +246,17 @@
>  	call	_procrunnable
>  	testl	%eax,%eax
>  	CROSSJUMP(jnz, sw1a, jz)
> +#ifdef	XORP_ETHER_POLLING
> +	incl	_idle_done
> +	pushl	_poll_burst
> +	call	_ether_poll
> +	addl	$4,%esp
> +	sti
> +	nop
> +	cli
> +	testl   %eax, %eax
> +	jnz     idle_loop
> +#endif
>  	call	_vm_page_zero_idle
>  	testl	%eax, %eax
>  	jnz	idle_loop

This has some serious bugs:
(1) ether_poll() is called with interrupts disabled.  This breaks fast
    interrupt handlers.  ether_poll() uses splimp() so it is apparently
    not intended to run with priority higher than splhigh().
(2) The sti/cli stuff belongs in ether_poll(), and the test of the return
    code of ether_poll() only works because ether_poll() always returns 1.
    vm_page_zero_idle() and the hlt instruction are never reached and the
    system spins calling ether_poll() from idle until a process becomes
    runnable.  ether_poll() needs quite different handling than
    vm_page_zero_idle() since it can reasonably find something to do
    whenever an interface is up, while vm_page_zero_idle() soon runs out
    of things to do if it is called a lot.

> Index: sys/kern/kern_clock.c

It shouldn't be necessary to touch this file.  Everything involving
"ether" certainly doesn't belong here.  Everything related to periodic
polling can be done, probably more efficiently, using schedsoft*() or
timeout().  E.g., schedsoftnet() arranges for netisrs to be checked
for at the next clock interrupt.  But this can now be done almost as
well (probably better in -current) using an ordinary timeout.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29  5:36: 0 2001
Delivered-To: freebsd-net@freebsd.org
Received: from khi.comsats.net.pk (khi.comsats.net.pk [210.56.4.10])
	by hub.freebsd.org (Postfix) with ESMTP id 3171337B41B
	for <freebsd-net@FreeBSD.ORG>; Thu, 29 Nov 2001 05:35:54 -0800 (PST)
Received: from company.mail (ppp7-190khi.comsats.net.pk [210.56.7.190] (may be forged))
	by khi.comsats.net.pk (8.11.4/8.11.4) with ESMTP id fATDYI517417
	for <freebsd-net@FreeBSD.ORG>; Thu, 29 Nov 2001 18:34:18 +0500 (PKT)
Received: from ahsanalikh [192.168.0.1]
	by company.mail [192.168.0.1]
	with SMTP (MDaemon.PRO.v4.0.5.T)
	for <freebsd-net@FreeBSD.ORG>; Thu, 29 Nov 2001 18:34:26 +0500
Message-ID: <001301c178da$90108550$0100a8c0@ahsanalikh>
From: "Ahsan Ali" <ahsan@khi.comsats.net.pk>
To: <freebsd-net@FreeBSD.ORG>
References: <200111281637.fASGbgd07767@mail2.bigmailbox.com> <20011128170815.G3985@blossom.cjclark.org> <002d01c1788c$8388f4f0$be026b83@ahsanali> <20011128222900.L3985@blossom.cjclark.org>
Subject: Re: netmask for aliased ip
Date: Thu, 29 Nov 2001 18:01: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.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-MDRemoteIP: 192.168.0.1
X-Return-Path: ahsan@khi.comsats.net.pk
X-MDaemon-Deliver-To: freebsd-net@FreeBSD.ORG
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

> For TCP, that is what is always used by default when creating an
> outbound connection. For incoming connections, the machine will of
> course reply using the IP address the connection came in on. And a
> program can always request to use a specific address if it wants to.
>
> I am not sure where you see a problem.

What I am saying is that if you have (for instance) 192.168.0.0/24 as a
network.

Interface A has the IP  192.168.0.10 with a netmask of 255.255.255.0 (/24)
Alias A:1 has the IP 192.168.0.11 with a netmask of 255.255.255.255 (/32)

Now Host B (192.168.0.20 mask 255.255.255.0) tries to access Alias A:1 which
is 192.168.0.11/32 so B sends to A:1 which it (correctly) assumes to be on
its own network, Alias A:1 cannot however reach B without sending the data
to its configured gateway. If routing is enabled on this host then it may be
able to send the reply routed through Interface A only...


My point is, that if the aliased interface also had a class c mask, this
issue wouldn't have come up in the first place when considering local
(within the same subnet) access from other hosts on that network.

I know this sounds really obfusticating! :)

But I'm just trying to get my concepts sorted out too.

-Ahsan



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29  6: 4:34 2001
Delivered-To: freebsd-net@freebsd.org
Received: from pace.inty.net (pace.inty.net [195.92.21.145])
	by hub.freebsd.org (Postfix) with ESMTP id 948A337B42F
	for <freebsd-net@freebsd.org>; Thu, 29 Nov 2001 06:04:30 -0800 (PST)
Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150])
	by pace.inty.net (8.11.3/8.11.3) with ESMTP id fATE4Pk32697
	for <freebsd-net@freebsd.org>; Thu, 29 Nov 2001 14:04:25 GMT
Received: from tariq ([10.0.1.156])
	by inty.hq.inty.net (8.9.3/8.9.3) with SMTP id OAA73971
	for <freebsd-net@freebsd.org>; Thu, 29 Nov 2001 14:04:24 GMT
From: "Tariq Rashid" <tariq@inty.net>
To: <freebsd-net@freebsd.org>
Subject: isakmpd hogs CPU: select()?
Date: Thu, 29 Nov 2001 14:05:42 -0000
Message-ID: <MPENKFCCIIDAJKJJOLBHMEBKCDAA.tariq@inty.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-Skip-Virus-Check: yes
X-Virus-Checked: 37254
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


as recognised in the ports bug report,  the isakmpd port for freebsd soaks
up 99% CPU even when no connections have been established - even when in
completely passive-connection mode.

i'm not an expert coder but i think the select() in the main loop (isakmpd.c
main()) is doing this.

is there a difference between openbsd select() and freebsd 4.4R select()?

i've ported over the latest isakmpd from openbsd and this is still the
case...

anyone?

regards

tariq


-----------------------------------------------
Information in this electronic mail message is confidential
and may be legally privileged. It is intended solely for
the addressee. Access to this message by anyone else is
unauthorised. If you are not the intended recipient any 
use, disclosure, copying or distribution of this message is
prohibited and may be unlawful. When addressed to our
customers, any information contained in this message is
subject to Intelligent Network Technology Ltd Terms & Conditions.
-----------------------------------------------
Take part in the intY 2001 Email Usage survey
online at http://www.inty.net/email/survey.html
-----------------------------------------------

intY has automatically scanned this email using Sophos Anti-Virus (www.inty.net)



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29  6:35:40 2001
Delivered-To: freebsd-net@freebsd.org
Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36])
	by hub.freebsd.org (Postfix) with ESMTP id 11E7037B421
	for <net@FreeBSD.ORG>; Thu, 29 Nov 2001 06:35:30 -0800 (PST)
Received: (from rizzo@localhost)
	by iguana.aciri.org (8.11.3/8.11.1) id fATEVGP19670;
	Thu, 29 Nov 2001 06:31:16 -0800 (PST)
	(envelope-from rizzo)
Date: Thu, 29 Nov 2001 06:31:16 -0800
From: Luigi Rizzo <rizzo@aciri.org>
To: Bruce Evans <bde@zeta.org.au>
Cc: net@FreeBSD.ORG
Subject: Re: Revised polling code for STABLE
Message-ID: <20011129063116.B19430@iguana.aciri.org>
References: <20011126115704.L88153@iguana.aciri.org> <20011129222256.W1389-100000@gamplex.bde.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011129222256.W1389-100000@gamplex.bde.org>
User-Agent: Mutt/1.3.23i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Bruce, thanks for the feedback.

Re. the second issue:

the code was placed in kern_clock.c just as a placeholder (and
because i needed to touch a couple of places in that file, i tried
to minimize the number of files affected by the patch). But surely,
the core of the code can go somewhere else, e.g. in net/
(i have had it for a long time in if_ethersubr.c), or maybe
even in a separate file, as you like.
The call to update_poll_threshold() however needs to be done by
either hardclock() or statclock() (i am experimenting with that
right now) because the purpose is to sample what the CPU is doing
when we get that particular interrupt.

I do not know how/if I can replace the schednetisr() with an ordinary timeout:
i need the handler to be invoked as soon as possible after the
clock ticks, as the task it performs are as urgent as interrupt requests.
Certainly I do not want it to be run after other netisr handlers
(this is also why NETISR_POLL is lower than any other NETISR, so
the corresponding handler is called first).
It looked like the schednetisr() was the simplest (one-line change) and
more effective way to achieve this, if you know of other ways involving
timeouts please let me know.

Re. the first one, yes the code might probably benefit from
a bit of rearrangement, such as below

    #ifdef     XORP_ETHER_POLLING
	call	_idle_poll
    #else
        call    _vm_page_zero_idle
    #endif
        testl   %eax, %eax
        jnz     idle_loop

with idle_poll being

	int idle_poll() {
	{
		idle_done=1;
		if (poll_handlers > 0) {
		    int s = splimp();
		    __asm __volatile("sti" : : : "memory");
		    retval = ether_poll(poll_burst);
		    __asm __volatile("cli" : : : "memory");
		    splx(s);
		    vm_page_zero_idle();
		    return 1;
		} else
		    return vm_page_zero_idle();
	}

The thing is, with polling you cannot halt the CPU if there are handlers
registered for polling. You can try and deregister polling on
interfaces which are idle, which then should be handled correctly
by the above function.

Does the above make sense ?

	cheers
	luigi


On Thu, Nov 29, 2001 at 11:26:20PM +1100, Bruce Evans wrote:
> > On Mon, 26 Nov 2001, Luigi Rizzo wrote:
> >
> > > [Bcc to -stable in case someone is interested there]
> > >
> > > Attached you can find the latest version of the polling code
> > > for STABLE (which is useful to make boxes much more robust
> > > to attacks and have much better responsiveness under [over]load).
> > > ...
> > Index: sys/i386/i386/swtch.s
> > ===================================================================
> > RCS file: /home/xorpc/u2/freebsd/src/sys/i386/i386/swtch.s,v
> > retrieving revision 1.89.2.4
> > diff -u -r1.89.2.4 swtch.s
> > --- sys/i386/i386/swtch.s	2001/07/26 02:29:10	1.89.2.4
> > +++ sys/i386/i386/swtch.s	2001/10/26 21:54:19
> > @@ -246,6 +246,17 @@
> >  	call	_procrunnable
> >  	testl	%eax,%eax
> >  	CROSSJUMP(jnz, sw1a, jz)
> > +#ifdef	XORP_ETHER_POLLING
> > +	incl	_idle_done
> > +	pushl	_poll_burst
> > +	call	_ether_poll
> > +	addl	$4,%esp
> > +	sti
> > +	nop
> > +	cli
> > +	testl   %eax, %eax
> > +	jnz     idle_loop
> > +#endif
> >  	call	_vm_page_zero_idle
> >  	testl	%eax, %eax
> >  	jnz	idle_loop
> 
> This has some serious bugs:
> (1) ether_poll() is called with interrupts disabled.  This breaks fast
>     interrupt handlers.  ether_poll() uses splimp() so it is apparently
>     not intended to run with priority higher than splhigh().
> (2) The sti/cli stuff belongs in ether_poll(), and the test of the return
>     code of ether_poll() only works because ether_poll() always returns 1.
>     vm_page_zero_idle() and the hlt instruction are never reached and the
>     system spins calling ether_poll() from idle until a process becomes
>     runnable.  ether_poll() needs quite different handling than
>     vm_page_zero_idle() since it can reasonably find something to do
>     whenever an interface is up, while vm_page_zero_idle() soon runs out
>     of things to do if it is called a lot.
> 
> > Index: sys/kern/kern_clock.c
> 
> It shouldn't be necessary to touch this file.  Everything involving
> "ether" certainly doesn't belong here.  Everything related to periodic
> polling can be done, probably more efficiently, using schedsoft*() or
> timeout().  E.g., schedsoftnet() arranges for netisrs to be checked
> for at the next clock interrupt.  But this can now be done almost as
> well (probably better in -current) using an ordinary timeout.
> 
> Bruce
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29  6:52:53 2001
Delivered-To: freebsd-net@freebsd.org
Received: from elvis.mu.org (elvis.mu.org [216.33.66.196])
	by hub.freebsd.org (Postfix) with ESMTP id 12C7A37B41F
	for <freebsd-net@freebsd.org>; Thu, 29 Nov 2001 06:52:40 -0800 (PST)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id 7E9F381D04; Thu, 29 Nov 2001 08:52:34 -0600 (CST)
Date: Thu, 29 Nov 2001 08:52:34 -0600
From: Alfred Perlstein <bright@mu.org>
To: Tariq Rashid <tariq@inty.net>
Cc: freebsd-net@freebsd.org
Subject: Re: isakmpd hogs CPU: select()?
Message-ID: <20011129085234.S46769@elvis.mu.org>
References: <MPENKFCCIIDAJKJJOLBHMEBKCDAA.tariq@inty.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <MPENKFCCIIDAJKJJOLBHMEBKCDAA.tariq@inty.net>; from tariq@inty.net on Thu, Nov 29, 2001 at 02:05:42PM -0000
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

* Tariq Rashid <tariq@inty.net> [011129 08:04] wrote:
> 
> as recognised in the ports bug report,  the isakmpd port for freebsd soaks
> up 99% CPU even when no connections have been established - even when in
> completely passive-connection mode.
> 
> i'm not an expert coder but i think the select() in the main loop (isakmpd.c
> main()) is doing this.
> 
> is there a difference between openbsd select() and freebsd 4.4R select()?
> 
> i've ported over the latest isakmpd from openbsd and this is still the
> case...
> 
> anyone?

truss(1) output might help, along with the code in question, along
with what type of descriptors it's polling.

-- 
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
                           http://www.morons.org/rants/gpl-harmful.php3

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29  7:38:32 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mx3.uninterruptible.net (cyclonis.catonic.net [63.160.99.136])
	by hub.freebsd.org (Postfix) with ESMTP id B70B237B434
	for <freebsd-net@freebsd.org>; Thu, 29 Nov 2001 07:38:28 -0800 (PST)
Received: from mail.uninterruptible.net (ns1.uninterruptible.net [216.7.46.11])
	by mx3.uninterruptible.net (Postfix) with ESMTP id 4C41C5501
	for <freebsd-net@freebsd.org>; Thu, 29 Nov 2001 09:33:17 -0600 (CST)
Received: from Spaz.Catonic.NET (tnt6-216-180-4-13.dialup.HiWAAY.net [216.180.4.13])
	by mail.uninterruptible.net (Postfix) with ESMTP id 6E4D250055
	for <freebsd-net@freebsd.org>; Thu, 29 Nov 2001 15:38:21 +0000 (GMT)
Received: by Spaz.Catonic.NET (Postfix, from userid 1002)
	id D60703322; Thu, 29 Nov 2001 15:38:19 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1])
	by Spaz.Catonic.NET (Postfix) with ESMTP id D0E5F4C25
	for <freebsd-net@freebsd.org>; Thu, 29 Nov 2001 15:38:19 +0000 (GMT)
Date: Thu, 29 Nov 2001 15:38:19 +0000 (GMT)
From: Kris Kirby <kris@catonic.net>
To: <freebsd-net@freebsd.org>
Subject: Etherchannel emulation / channel bonding?
Message-ID: <Pine.BSF.4.33.0111291536320.50477-100000@spaz.catonic.net>
X-Tech-Support-Email: bofh@catonic.net
X-Frames: I hate frames.
Organization: Non Illegitemus Carborundum
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


What's our current best recommended solution for channel-bonding ethernet
cards? Netgraph?

-----
Kris Kirby, KE4AHR          | TGIFreeBSD... 'Nuff said.
<kris@nospam.catonic.net>   | IM: KrisBSD
-------------------------------------------------------
"Fate, it seems, is not without a sense of irony."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29  8: 8:34 2001
Delivered-To: freebsd-net@freebsd.org
Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9])
	by hub.freebsd.org (Postfix) with ESMTP id 676E737B41E
	for <freebsd-net@freebsd.org>; Thu, 29 Nov 2001 08:08:30 -0800 (PST)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.11.0/8.11.0) id fATG5YI31566;
	Thu, 29 Nov 2001 10:05:34 -0600 (CST)
	(envelope-from jlemon)
Date: Thu, 29 Nov 2001 10:05:34 -0600
From: Jonathan Lemon <jlemon@flugsvamp.com>
To: =?iso-8859-1?Q?=BCB=BEJ=C2=D7?= <cfliu@realtek.com.tw>
Cc: Jonathan Lemon <jlemon@flugsvamp.com>, freebsd-net@freebsd.org
Subject: Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
Message-ID: <20011129100534.Q75389@prism.flugsvamp.com>
References: <200111290637.fAT6bd213755@prism.flugsvamp.com> <001701c178a3$e43670e0$a22314ac@RTCN3848>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <001701c178a3$e43670e0$a22314ac@RTCN3848>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> Thanks...I know where my problem is now...It's indeed   a duplicate SYN.
> 
> By the way, the tcp_input function is so long and large and there are
> several goto statements which make reading the code even more difficult. Is
> this intened to be like this? Even with Steven's TCP/IP Vol.2, it took me
> three whole days to draw a Visio flow chart of this function. Has anybody
> ever considered of reorganizing this module?

I don't believe so; the code was originally designned to avoid function 
calls, and is essentially a couple of large switch statements.  The flow
pretty much mirrors the original RFC, and shouldn't be too hard to follow.

I'd be leery of rewriting the code just for the sake of rewriting; chances
would be pretty good that you'd introduce a subtle bug in one way or the
other.
-- 
Jonathan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29  8:34:32 2001
Delivered-To: freebsd-net@freebsd.org
Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36])
	by hub.freebsd.org (Postfix) with ESMTP id 4E09B37B437
	for <freebsd-net@FreeBSD.ORG>; Thu, 29 Nov 2001 08:34:29 -0800 (PST)
Received: (from rizzo@localhost)
	by iguana.aciri.org (8.11.3/8.11.1) id fATGU6u21899;
	Thu, 29 Nov 2001 08:30:06 -0800 (PST)
	(envelope-from rizzo)
Date: Thu, 29 Nov 2001 08:30:06 -0800
From: Luigi Rizzo <rizzo@aciri.org>
To: Jonathan Lemon <jlemon@flugsvamp.com>
Cc: =?iso-8859-1?B?vEK+SsLX?= <cfliu@realtek.com.tw>,
	freebsd-net@FreeBSD.ORG
Subject: Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
Message-ID: <20011129083005.C19821@iguana.aciri.org>
References: <200111290637.fAT6bd213755@prism.flugsvamp.com> <001701c178a3$e43670e0$a22314ac@RTCN3848> <20011129100534.Q75389@prism.flugsvamp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20011129100534.Q75389@prism.flugsvamp.com>
User-Agent: Mutt/1.3.23i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Thu, Nov 29, 2001 at 10:05:34AM -0600, Jonathan Lemon wrote:
> On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> > Thanks...I know where my problem is now...It's indeed   a duplicate SYN.
> > 
> > By the way, the tcp_input function is so long and large and there are
> > several goto statements which make reading the code even more difficult. Is
> > this intened to be like this? Even with Steven's TCP/IP Vol.2, it took me
> > three whole days to draw a Visio flow chart of this function. Has anybody
> > ever considered of reorganizing this module?
> 
> I don't believe so; the code was originally designned to avoid function 
> calls, and is essentially a couple of large switch statements.  The flow
> pretty much mirrors the original RFC, and shouldn't be too hard to follow.

let's be honest, it's a horrible piece of code from a sw engineering
point of view.

> I'd be leery of rewriting the code just for the sake of rewriting; chances
> would be pretty good that you'd introduce a subtle bug in one way or the
> other.

on the other hand, chances are that there are already
subtle bugs with all the modifications that have been applied
these years (TTCP, newreno etc.). No later than yesterday there was
a long thread on this issue, and Garret has also some traces which
according to him evidence patologies.

You have been there, Jonathan, so you should known well how hard is
to make even small modifications to the existing code without
being afraid of breaking a lot of things.

I think a rewrite of FreeBSD's TCP would be extremely needed and welcome,
however is such a large effort that i doubt anyone has the time and energy
to dedicate to this task.

	cheers
	luigi
----------------------------------+-----------------------------------------
 Luigi RIZZO, luigi@iet.unipi.it  . ACIRI/ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone: (510) 666 2927
----------------------------------+-----------------------------------------

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29  9:30:54 2001
Delivered-To: freebsd-net@freebsd.org
Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9])
	by hub.freebsd.org (Postfix) with ESMTP id 48C4F37B429
	for <freebsd-net@FreeBSD.ORG>; Thu, 29 Nov 2001 09:30:48 -0800 (PST)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.11.0/8.11.0) id fATHRoh34259;
	Thu, 29 Nov 2001 11:27:50 -0600 (CST)
	(envelope-from jlemon)
Date: Thu, 29 Nov 2001 11:27:50 -0600
From: Jonathan Lemon <jlemon@flugsvamp.com>
To: Luigi Rizzo <rizzo@aciri.org>
Cc: Jonathan Lemon <jlemon@flugsvamp.com>,
	=?iso-8859-1?Q?=BCB=BEJ=C2=D7?= <cfliu@realtek.com.tw>,
	freebsd-net@FreeBSD.ORG
Subject: Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
Message-ID: <20011129112750.S75389@prism.flugsvamp.com>
References: <200111290637.fAT6bd213755@prism.flugsvamp.com> <001701c178a3$e43670e0$a22314ac@RTCN3848> <20011129100534.Q75389@prism.flugsvamp.com> <20011129083005.C19821@iguana.aciri.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <20011129083005.C19821@iguana.aciri.org>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Thu, Nov 29, 2001 at 08:30:06AM -0800, Luigi Rizzo wrote:
> On Thu, Nov 29, 2001 at 10:05:34AM -0600, Jonathan Lemon wrote:
> > On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> > > Thanks...I know where my problem is now...It's indeed   a duplicate SYN.
> > > 
> > > By the way, the tcp_input function is so long and large and there are
> > > several goto statements which make reading the code even more difficult. Is
> > > this intened to be like this? Even with Steven's TCP/IP Vol.2, it took me
> > > three whole days to draw a Visio flow chart of this function. Has anybody
> > > ever considered of reorganizing this module?
> > 
> > I don't believe so; the code was originally designned to avoid function 
> > calls, and is essentially a couple of large switch statements.  The flow
> > pretty much mirrors the original RFC, and shouldn't be too hard to follow.
> 
> let's be honest, it's a horrible piece of code from a sw engineering
> point of view.

No argument there.

 
> > I'd be leery of rewriting the code just for the sake of rewriting; chances
> > would be pretty good that you'd introduce a subtle bug in one way or the
> > other.
> 
> on the other hand, chances are that there are already
> subtle bugs with all the modifications that have been applied
> these years (TTCP, newreno etc.). No later than yesterday there was
> a long thread on this issue, and Garret has also some traces which
> according to him evidence patologies.

Yes, I'm currently digging into those traces now.  :-(


> You have been there, Jonathan, so you should known well how hard is
> to make even small modifications to the existing code without
> being afraid of breaking a lot of things.
> 
> I think a rewrite of FreeBSD's TCP would be extremely needed and welcome,
> however is such a large effort that i doubt anyone has the time and energy
> to dedicate to this task.

Well, I do have designs on making things better; but as you point out,
before anyone should even think about changing things, they need a good
understanding of how the code works.  Wrapping your head around the entire
TCP/IP stack is not an easy task and I'm not even going to claim that I've
successfully done this.  :-)

All the various #ifdefs scattererd over the code are absolutely sick;
they fairly scream out for a sensible rewrite. However, from my point 
of view, if I'm going to rewrite things, there should be functional
improvements as well, not just rearranging what we have in a different
fashion.  I don't feel quite ready for this... yet.
--
Jonathan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29  9:38: 5 2001
Delivered-To: freebsd-net@freebsd.org
Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36])
	by hub.freebsd.org (Postfix) with ESMTP id 843ED37B405
	for <freebsd-net@FreeBSD.ORG>; Thu, 29 Nov 2001 09:38:01 -0800 (PST)
Received: (from rizzo@localhost)
	by iguana.aciri.org (8.11.3/8.11.1) id fATHXjW22374;
	Thu, 29 Nov 2001 09:33:45 -0800 (PST)
	(envelope-from rizzo)
Date: Thu, 29 Nov 2001 09:33:45 -0800
From: Luigi Rizzo <rizzo@aciri.org>
To: Jonathan Lemon <jlemon@flugsvamp.com>
Cc: =?iso-8859-1?B?vEK+SsLX?= <cfliu@realtek.com.tw>,
	freebsd-net@FreeBSD.ORG
Subject: Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
Message-ID: <20011129093345.A22194@iguana.aciri.org>
References: <200111290637.fAT6bd213755@prism.flugsvamp.com> <001701c178a3$e43670e0$a22314ac@RTCN3848> <20011129100534.Q75389@prism.flugsvamp.com> <20011129083005.C19821@iguana.aciri.org> <20011129112750.S75389@prism.flugsvamp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011129112750.S75389@prism.flugsvamp.com>
User-Agent: Mutt/1.3.23i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Thu, Nov 29, 2001 at 11:27:50AM -0600, Jonathan Lemon wrote:
> 
> All the various #ifdefs scattererd over the code are absolutely sick;
> they fairly scream out for a sensible rewrite. However, from my point 
> of view, if I'm going to rewrite things, there should be functional
> improvements as well, not just rearranging what we have in a different
> fashion.  I don't feel quite ready for this... yet.

functional can be also interpreted as "easier to read and validate"
which seems to be one of the main drawbacks of the current code.
I'd even be willing to pay the price of a small regression in
functionality, on the grounds that it is better to know that
"X is not implemented" than "X, Y, Z are implemented but we have
no idea if they work in all cases, and no way to test".
As a matter of fact, that would be an improvement, not a regression.

	cheers
	luigi

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29 12:36:43 2001
Delivered-To: freebsd-net@freebsd.org
Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97])
	by hub.freebsd.org (Postfix) with ESMTP id E16A137B405
	for <freebsd-net@freebsd.org>; Thu, 29 Nov 2001 12:36:35 -0800 (PST)
Received: by freesbee.wheel.dk (Postfix, from userid 1001)
	id 4291B5DE8; Thu, 29 Nov 2001 21:36:31 +0100 (CET)
Date: Thu, 29 Nov 2001 21:36:31 +0100
From: Jesper Skriver <jesper@FreeBSD.org>
To: Kris Kirby <kris@catonic.net>
Cc: freebsd-net@freebsd.org
Subject: Re: Etherchannel emulation / channel bonding?
Message-ID: <20011129213631.A88954@skriver.dk>
References: <Pine.BSF.4.33.0111291536320.50477-100000@spaz.catonic.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.33.0111291536320.50477-100000@spaz.catonic.net>; from kris@catonic.net on Thu, Nov 29, 2001 at 03:38:19PM +0000
X-PGP-Fingerprint: 6B88 9CE8 66E9 E631 C9C5  5EB4 22AB F0EC F956 1C31
X-PGP-Public-Key: http://freesbee.wheel.dk/~jesper/gpgkey.pub
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Thu, Nov 29, 2001 at 03:38:19PM +0000, Kris Kirby wrote:
> 
> What's our current best recommended solution for channel-bonding ethernet
> cards? Netgraph?

http://people.freebsd.org/~wpaul/FEC/

/Jesper

-- 
Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
Work:    Network manager   @ AS3292 (Tele Danmark DataNetworks)
Private: FreeBSD committer @ AS2109 (A much smaller network ;-)

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29 14:11:39 2001
Delivered-To: freebsd-net@freebsd.org
Received: from scaup.prod.itd.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49])
	by hub.freebsd.org (Postfix) with ESMTP id A430137B41A
	for <freebsd-net@freebsd.org>; Thu, 29 Nov 2001 14:11:33 -0800 (PST)
Received: from dialup-209.244.107.113.dial1.sanjose1.level3.net ([209.244.107.113] helo=blossom.cjclark.org)
	by scaup.prod.itd.earthlink.net with esmtp (Exim 3.33 #1)
	id 169ZOq-0003c5-00; Thu, 29 Nov 2001 14:11:26 -0800
Received: (from cjc@localhost)
	by blossom.cjclark.org (8.11.6/8.11.3) id fATMAbU09926;
	Thu, 29 Nov 2001 14:10:37 -0800 (PST)
	(envelope-from cjc)
Date: Thu, 29 Nov 2001 14:10:37 -0800
From: "Crist J. Clark" <cristjc@earthlink.net>
To: Ahsan Ali <ahsan@khi.comsats.net.pk>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: netmask for aliased ip
Message-ID: <20011129141037.F8815@blossom.cjclark.org>
Reply-To: cjclark@alum.mit.edu
References: <200111281637.fASGbgd07767@mail2.bigmailbox.com> <20011128170815.G3985@blossom.cjclark.org> <002d01c1788c$8388f4f0$be026b83@ahsanali> <20011128222900.L3985@blossom.cjclark.org> <001301c178da$90108550$0100a8c0@ahsanalikh>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <001301c178da$90108550$0100a8c0@ahsanalikh>; from ahsan@khi.comsats.net.pk on Thu, Nov 29, 2001 at 06:01:04PM +0500
X-URL: http://people.freebsd.org/~cjc/
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Thu, Nov 29, 2001 at 06:01:04PM +0500, Ahsan Ali wrote:
> > For TCP, that is what is always used by default when creating an
> > outbound connection. For incoming connections, the machine will of
> > course reply using the IP address the connection came in on. And a
> > program can always request to use a specific address if it wants to.
> >
> > I am not sure where you see a problem.
> 
> What I am saying is that if you have (for instance) 192.168.0.0/24 as a
> network.
> 
> Interface A has the IP  192.168.0.10 with a netmask of 255.255.255.0 (/24)
> Alias A:1 has the IP 192.168.0.11 with a netmask of 255.255.255.255 (/32)
> 
> Now Host B (192.168.0.20 mask 255.255.255.0) tries to access Alias A:1 which
> is 192.168.0.11/32 so B sends to A:1 which it (correctly) assumes to be on
> its own network, Alias A:1 cannot however reach B without sending the data
> to its configured gateway. If routing is enabled on this host then it may be
> able to send the reply routed through Interface A only...

Hmmm? Routing is always enabled if you plan on talking to any other
machines at all. But all of this is a non-issue. The selection of a
route for a packet has _nothing_ to do with the source address, only
the destination. How a packet finds its way to 192.168.0.20 is the
same no matter what the source address is. 192.168.0.20 is local to
the interface A, so it is sent directly to B.
-- 
Crist J. Clark                     |     cjclark@alum.mit.edu
                                   |     cjclark@jhu.edu
http://people.freebsd.org/~cjc/    |     cjc@freebsd.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29 15:39:42 2001
Delivered-To: freebsd-net@freebsd.org
Received: from femail13.sdc1.sfba.home.com (femail13.sdc1.sfba.home.com [24.0.95.140])
	by hub.freebsd.org (Postfix) with ESMTP id 7026C37B405
	for <freebsd-net@FreeBSD.ORG>; Thu, 29 Nov 2001 15:39:34 -0800 (PST)
Received: from lightnin ([65.11.111.111]) by femail13.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP
          id <20011129233934.QCPA759.femail13.sdc1.sfba.home.com@lightnin>
          for <freebsd-net@FreeBSD.ORG>; Thu, 29 Nov 2001 15:39:34 -0800
Date: Thu, 29 Nov 2001 15:39:33 -0800
Subject: Re: netmask for aliased ip
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v475)
From: justin@mac.com
To: <freebsd-net@FreeBSD.ORG>
Content-Transfer-Encoding: 7bit
In-Reply-To: <001301c178da$90108550$0100a8c0@ahsanalikh>
Message-Id: <5756E9F8-E522-11D5-A7BB-0003934474AC@mac.com>
X-Mailer: Apple Mail (2.475)
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


On Thursday, November 29, 2001, at 05:01 , Ahsan Ali wrote:

>> For TCP, that is what is always used by default when creating an
>> outbound connection. For incoming connections, the machine will of
>> course reply using the IP address the connection came in on. And a
>> program can always request to use a specific address if it wants to.
>>
>> I am not sure where you see a problem.
>
> What I am saying is that if you have (for instance) 192.168.0.0/24 as a
> network.
>
> Interface A has the IP  192.168.0.10 with a netmask of 255.255.255.0 
> (/24)
> Alias A:1 has the IP 192.168.0.11 with a netmask of 255.255.255.255 
> (/32)
>
> Now Host B (192.168.0.20 mask 255.255.255.0) tries to access Alias A:1 
> which
> is 192.168.0.11/32 so B sends to A:1 which it (correctly) assumes to be 
> on
> its own network, Alias A:1 cannot however reach B without sending the 
> data
> to its configured gateway. If routing is enabled on this host then it 
> may be
> able to send the reply routed through Interface A only...

I think you are confusing interfaces and addresses.  In your case, B 
will want to send to ...11 (it doesn't see the mask that's installed on 
A), so it will ARP for it, and A will reply.  B then sends the packet to 
A's MAC address (which is the same for both the original and the aliased 
address).  When A replies to B, it will send to B through the same 
physical interface through which B's packet arrived.  There's no issue 
with reachability: both systems, and all three addresses, are on the 
same link.

The netmask tom-foolery is just a 
local-to-the-system-installing-the-alias trick; it has nothing to do 
with the on-the-wire behavior, or how the remote site sees the site 
installing the alias.  With a /32 mask, the system can keep track of the 
various addresses without a lot of routing tricks which would otherwise 
be necessary (more work for the admin to install and remove aliases).

It is confusing, but it has to do with the way the routing 
infrastructure works on *BSD systems, not with the way networking works 
in general.

Regards,

Justin

---
Justin C. Walker, Curmudgeon-At-Large  *
Institute for General Semantics        | It's not whether you win or 
lose...
                                        |  It's whether *I* win or lose.
*--------------------------------------*-------------------------------*


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29 21:18:39 2001
Delivered-To: freebsd-net@freebsd.org
Received: from c527597-a.cstvl1.sfba.home.com (c527597-a.cstvl1.sfba.home.com [24.176.204.87])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3AA5637B416; Thu, 29 Nov 2001 21:18:36 -0800 (PST)
Received: (from bmah@localhost)
	by c527597-a.cstvl1.sfba.home.com (8.11.6/8.11.6) id fAU5IXx11078;
	Thu, 29 Nov 2001 21:18:33 -0800 (PST)
	(envelope-from bmah)
Message-Id: <200111300518.fAU5IXx11078@c527597-a.cstvl1.sfba.home.com>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: Greg Lehey <grog@FreeBSD.ORG>, net@FreeBSD.ORG
Subject: TCP anomalies (was Re: FreeBSD performing worse than Linux?)
In-Reply-To: <200111290113.fAT1DnH04474@khavrinen.lcs.mit.edu> 
References: <20011128102241.6887B380A@overcee.netplex.com.au> <20011128112006.195983808@overcee.netplex.com.au> <20011129105321.C74413@monorchid.lemis.com> <200111290113.fAT1DnH04474@khavrinen.lcs.mit.edu>
Comments: In-reply-to Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
   message dated "Wed, 28 Nov 2001 20:13:49 -0500."
From: "Bruce A. Mah" <bmah@FreeBSD.ORG>
Reply-To: bmah@FreeBSD.ORG
X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5<Pi&akO)o^8;[r
 %l(8ZHlbF`dD>v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A
 2V%N&+
X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif
X-Url: http://www.employees.org/~bmah/
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1808650111P";
	 micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Thu, 29 Nov 2001 21:18:33 -0800
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

--==_Exmh_1808650111P
Content-Type: text/plain; charset=us-ascii

If memory serves me right, Garrett Wollman wrote:

> Each trace shows a single large file transfer from a 4.4-stable
> machine to my -current desktop over a local-area network.  

I'm pretty rusty at debugging TCP implementations, but I'll try to 
contribute something...

Your 4.4-STABLE machine, is it from before or after rev 1.107.2.18 of
sys/netinet/tcp_input.c?  (Mon Nov 12 22:11:24 2001 UTC)  I'm not sure
how relevant this point is, but some of the anomalies I noticed seem
related to fast retransmit (see below).

Also...where did you do the trace (i.e. sender, receiver, or a third
machine)?

> test4 was
> aborted about 10% into the transfer so that you have a chance at
> looking at the whole thing in xplot.  There are multiple pathologies
> visible in the results, but a good place to start would be around
> :56.44 in test4.

test4 was the only trace I looked at.  One thing that caught my eye is
that the receiver seems to be sending a bunch of dupacks (in some cases,
many more than needed to trigger fast retransmit) but no retransmit
happens.  In *most* cases, the receiver somehow gets the missing data
because you can later see it acking later sequence numbers.  The first
place I saw this was at :41.504152.

This looks a little odd, but it *could* be explained by data segments
getting misordered somewhere and the dupacks getting lost.

Another place to look is the large number of consecutive dupacks
starting around :41.978767.  I don't know what's happening here, but
after a long time (about a second?!?) the sender finally gives up and
sends the receiver what it wants.

Cheers,

Bruce.



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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: Exmh version 2.3.1+ 05/14/2001

iD8DBQE8Bxap2MoxcVugUsMRApAMAKDvOa1CwUxLt/XYWS+/eatsEX1N/QCfUwbt
ce2ewwfnFV79kzsG6xRYgQA=
=ha30
-----END PGP SIGNATURE-----

--==_Exmh_1808650111P--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29 21:35:35 2001
Delivered-To: freebsd-net@freebsd.org
Received: from cage.simianscience.com (cage.simianscience.com [64.7.134.1])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5F11B37B417; Thu, 29 Nov 2001 21:35:29 -0800 (PST)
Received: (from root@localhost)
	by cage.simianscience.com (8.11.6/8.11.6) id fAU5ZSg63340;
	Fri, 30 Nov 2001 00:35:28 -0500 (EST)
	(envelope-from mike@sentex.net)
Received: from chimp.sentex.net (fcage [192.168.0.2])
	by cage.simianscience.com (8.11.6/8.11.6av) with ESMTP id fAU5ZP163332;
	Fri, 30 Nov 2001 00:35:25 -0500 (EST)
	(envelope-from mike@sentex.net)
Message-Id: <5.1.0.14.0.20011130000539.03326eb8@192.168.0.12>
X-Sender: mdtancsa@192.168.0.12
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 30 Nov 2001 00:35:24 -0500
To: freebsd-net@freebsd.org
From: Mike Tancsa <mike@sentex.net>
Subject: More Polling vs No Polling tests
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-10
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


OK, I think this time around I have fixed the duplex issues and the problem 
with the D-link not being initialized properly (reset PCI config data in 
the BIOS fixed a the problems).

Using netperf I ran the basic snapshot script to see what affect the 
polling code had on network performance.  In general it seems to work 
better for the most part, but the big bonus is the lowered load average. 
Next tests, I am going to see what effect it has purely on forwarding. For 
now, I have all the raw results available at

http://www.tancsa.com/netperf-11-29-2001.tgz

for anyone interested

tar -tzf netperf-11-29-2001.tgz
no-poll-dc-fxp
no-poll-dc-fxp.no-hz
no-poll-dc-rl
no-poll-fxp-fxp
no-poll-fxp-fxp-vlan
no-poll-fxp-rl
no-poll-fxp-rl.no-hz
poll-dc-fxp
poll-dc-fxp.no-hz
poll-dc-rl
poll-fxp-fxp
poll-fxp-fxp-vlan
poll-fxp-rl
poll-fxp-rl.no-hz
hardware.txt



I did the following
cross over cables connecting 2 boxes -- PIV with fxp and rl nics and and 
PIII with fxp and four port D-Link running the dc driver.  netperf client 
on the PIII and the server on the PIV.

I ran poll enabled vs no poll enabled on dc to fxp, dc to rl and fxp to 
fxp, and dc via switch port to a vlan interface on the PIV's fxp nic in 
802.1q trunk mode connected to a compaq switch 10/100 switch.  Much to my 
surprise and disappointment, the d-link was throughput wise quite an 
under-performer.  I am not sure its the driver, it could very well be the 
card thats the problem. (Its a DFE-570TX 4 port). All the above tests were 
done with options HZ=1000 in the kernel.  To see what difference it made, I 
re-ran the tests without the HZ option.  These text files have the .no-hz 
extension

One nice surprise (for me anyways) was the relatively good performance of 
the fxp card in 802.1q mode.  With the prices of switches being so low 
(especially used), its almost cheaper to make a "24 port network card" as 
opposed to something like the quad port D-link.

	---Mike
--------------------------------------------------------------------
Mike Tancsa,                          	          tel +1 519 651 3400
Sentex Communications,     			  mike@sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada			  www.sentex.net/mike


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29 21:56:47 2001
Delivered-To: freebsd-net@freebsd.org
Received: from tomts12-srv.bellnexxia.net (tomts12.bellnexxia.net [209.226.175.56])
	by hub.freebsd.org (Postfix) with ESMTP id 56F3037B416
	for <freebsd-net@FreeBSD.ORG>; Thu, 29 Nov 2001 21:56:44 -0800 (PST)
Received: from xena.gsicomp.on.ca ([199.243.149.34])
          by tomts12-srv.bellnexxia.net
          (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP
          id <20011130055643.IIHH18252.tomts12-srv.bellnexxia.net@xena.gsicomp.on.ca>;
          Fri, 30 Nov 2001 00:56:43 -0500
Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18])
	by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id fAU5mTW65662;
	Fri, 30 Nov 2001 00:48:29 -0500 (EST)
	(envelope-from matt@gsicomp.on.ca)
Message-ID: <002b01c17963$c8df5fd0$1200a8c0@gsicomp.on.ca>
From: "Matthew Emmerton" <matt@gsicomp.on.ca>
To: "Matthew Emmerton" <matt@gsicomp.on.ca>,
	"Andre Oppermann" <oppermann@pipeline.ch>, <julian@elischer.org>
Cc: <freebsd-net@FreeBSD.ORG>
References: <Pine.BSF.4.21.0111271041160.56896-100000@xena.gsicomp.on.ca>
Subject: Re: Very strange network behaviour - can anyone help me analyse tcpdump  output?
Date: Fri, 30 Nov 2001 00:56:39 -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.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

> > Matthew Emmerton wrote:
> > >
> > > Hi all,
> > >
> > > In the continuing saga of IPSec over PPPoE for a retail POS
environment that
> > > I'm maintaing, the problems seem to become more complex as time goes
on.
> > >
> > > The network is quite simple:
> > > [ LAN #1 ] - [ FreeBSD Gateway #1 ] - [ ISP ] - [ FreeBSD Gateway
#2 ] - [
> > > LAN #2 ]
> > >
> > > Both LANs connect using PPPoE with the same ISP, and are one hop apart
> > > (according to traceroute).
> >
> > This smells like MTU problems. Try to set the MTU on your physical LAN
> > interfaces to something like 1480 or so any try again.
>
> That's what I thought too.  I checked, and ppp is doing the TPC MSS
> fixup.  Even after removing the gif/ipsec stuff that I was doing
> (less overhead, and converting this installation into a plain
> LAN-behind-NAT setup), the problem persists.
>
> I tried dropping the MTU on my LAN interface to 1200 (from 1500), but that
> didn't change anything.
>
> If my ISP installed a bunch of really buggy hardware, would that explain
> why this started happening recently without any changes on my side?

The answer turned out to be quite obvious.  If I didn't make any changes on
the FreeBSD end, and the ISP didn't make any changes on their end, then it
must have been the telco (since these are DSL links.)

It turned out that the telco upgraded a bunch of line equipment recently
which didn't play nice with the DSL equipment that the ISP was using.  After
6 hours of testing the wiring between our DSL modem and various points all
the way back to the CO, the telco figured out the problem and the
strangeness that we saw has gone away.

Thanks for all the helpful hints and suggestions - it surely kept me from
going mad.

--
Matt Emmerton


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29 22:50:12 2001
Delivered-To: freebsd-net@freebsd.org
Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7ADF437B419; Thu, 29 Nov 2001 22:50:07 -0800 (PST)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.11.0/8.11.0) id fAU6l9K60404;
	Fri, 30 Nov 2001 00:47:09 -0600 (CST)
	(envelope-from jlemon)
Date: Fri, 30 Nov 2001 00:47:09 -0600 (CST)
From: Jonathan Lemon <jlemon@flugsvamp.com>
Message-Id: <200111300647.fAU6l9K60404@prism.flugsvamp.com>
To: bmah@FreeBSD.ORG, net@FreeBSD.ORG
Subject: Re: TCP anomalies (was Re: FreeBSD performing worse than Linux?)
X-Newsgroups: local.mail.freebsd-net
In-Reply-To: <local.mail.freebsd-net/200111300518.fAU5IXx11078@c527597-a.cstvl1.sfba.home.com>
References: <local.mail.freebsd-net/20011128102241.6887B380A@overcee.netplex.com.au>
	<local.mail.freebsd-net/20011128112006.195983808@overcee.netplex.com.au>
	<local.mail.freebsd-net/20011129105321.C74413@monorchid.lemis.com>
	<local.mail.freebsd-net/200111290113.fAT1DnH04474@khavrinen.lcs.mit.edu>
Organization: 
Cc: 
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

In article <local.mail.freebsd-net/200111300518.fAU5IXx11078@c527597-a.cstvl1.sfba.home.com> you write:
>-=-=-=-=-=-
>test4 was the only trace I looked at.  One thing that caught my eye is
>that the receiver seems to be sending a bunch of dupacks (in some cases,
>many more than needed to trigger fast retransmit) but no retransmit
>happens.  In *most* cases, the receiver somehow gets the missing data
>because you can later see it acking later sequence numbers.  The first
>place I saw this was at :41.504152.
>
>This looks a little odd, but it *could* be explained by data segments
>getting misordered somewhere and the dupacks getting lost.
>
>Another place to look is the large number of consecutive dupacks
>starting around :41.978767.  I don't know what's happening here, but
>after a long time (about a second?!?) the sender finally gives up and
>sends the receiver what it wants.

Yes, I think that area (I was looking at it too) provides a fairly
good illustration that fast retransmits are broken.  The transmit 
at 14:01:42.969338 appears to be the retransmit timer finally kicking in.

I wonder if we can figure out which -RELEASE this started happening in.
-- 
Jonathan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Thu Nov 29 23:37:38 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id E1A9D37B405
	for <net@FreeBSD.ORG>; Thu, 29 Nov 2001 23:37:32 -0800 (PST)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA22025;
	Fri, 30 Nov 2001 18:37:27 +1100
Date: Fri, 30 Nov 2001 18:37:33 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender:  <bde@gamplex.bde.org>
To: Luigi Rizzo <rizzo@aciri.org>
Cc: <net@FreeBSD.ORG>
Subject: Re: Revised polling code for STABLE
In-Reply-To: <20011129063116.B19430@iguana.aciri.org>
Message-ID: <20011130174232.R347-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Thu, 29 Nov 2001, Luigi Rizzo wrote:

> The call to update_poll_threshold() however needs to be done by
> either hardclock() or statclock() (i am experimenting with that
> right now) because the purpose is to sample what the CPU is doing
> when we get that particular interrupt.

Why in that particular interrupt?  If you do it in a timeout routine,
then you will normally do it in sync with hardclock interrupts
but delayed by some fraction of a hardclock interrupt.  I think the
fraction can be compensated for if necessary.  Doing it in sync with
statclock interrupts might be slightly better, but statclock interrupts
are _supposed_ to be non-periodic (FreeBSD just doesn't implement this),
so adjustments for fair sampling are strictly required.

In -current, hardclock() and softclock() are called in fast interrupt
context, so adding to them is both nontrivial and BAD (it requires
aquiring sched_lock because all write accesses and certain read accesses
to variables accessed by the fast interrupt handler, and this is still
not done for at least all of the ntptime variables).

> I do not know how/if I can replace the schednetisr() with an ordinary timeout:
> i need the handler to be invoked as soon as possible after the
> clock ticks, as the task it performs are as urgent as interrupt requests.

As urgent as hardclock interrupts?

> Certainly I do not want it to be run after other netisr handlers
> (this is also why NETISR_POLL is lower than any other NETISR, so
> the corresponding handler is called first).
> It looked like the schednetisr() was the simplest (one-line change) and
> more effective way to achieve this, if you know of other ways involving
> timeouts please let me know.

schedsoftnet() doesn't quite work, but you could add another interrupt
class (`poll' instead of `net') in RELENG_4.  This takes about 1 line
of changes in each of 6 files.  All hardware interrupts would have
higher priority (sort of), but it is easy to make the new priority
higher than all SWI priorities.  SWIs are easier to add in -current,
but have much higher overheads (which is not a problem for polling
every 100 seconds but very bad for much higher rates).

> Re. the first one, yes the code might probably benefit from
> a bit of rearrangement, such as below
>
>     #ifdef     XORP_ETHER_POLLING
> 	call	_idle_poll
>     #else
>         call    _vm_page_zero_idle
>     #endif
>         testl   %eax, %eax
>         jnz     idle_loop
>
> with idle_poll being
>
> 	int idle_poll() {
> 	{
> 		idle_done=1;
> 		if (poll_handlers > 0) {
> 		    int s = splimp();
> 		    __asm __volatile("sti" : : : "memory");

Ugh.  Use a standard FreeBSD C interface for this (critical_exit() in
-current; enable_intr() for i386's only in RELENG_4).

> 		    retval = ether_poll(poll_burst);
> 		    __asm __volatile("cli" : : : "memory");
> 		    splx(s);
> 		    vm_page_zero_idle();
> 		    return 1;
> 		} else
> 		    return vm_page_zero_idle();
> 	}

It's ugly for idle_poll() to know about all the other poll routines
(we've had other there before, e.g., one for apm).

> The thing is, with polling you cannot halt the CPU if there are handlers
> registered for polling. You can try and deregister polling on
> interfaces which are idle, which then should be handled correctly
> by the above function.

Yes, it's hard to reach hlt if there are any active interfaces.  Maybe
limit the polling and switch to interrupt mode to wake up from hlt.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30  2:35:40 2001
Delivered-To: freebsd-net@freebsd.org
Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65])
	by hub.freebsd.org (Postfix) with ESMTP
	id CD62437B41D; Fri, 30 Nov 2001 02:35:16 -0800 (PST)
Received: (from ru@localhost)
	by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fAUAYv076775;
	Fri, 30 Nov 2001 12:34:57 +0200 (EET)
	(envelope-from ru)
Date: Fri, 30 Nov 2001 12:34:57 +0200
From: Ruslan Ermilov <ru@FreeBSD.org>
To: Igor M Podlesny <poige@morning.ru>
Cc: bug-followup@FreeBSD.org, net@FreeBSD.org
Subject: Re: kern/31575: wrong src ip address for some ICMPs
Message-ID: <20011130123457.B70651@sunbay.com>
References: <200110290410.f9T4APo65440@freefall.freebsd.org> <20011129192500.A74956@sunbay.com> <92140220606.20011130110156@morning.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <92140220606.20011130110156@morning.ru>
User-Agent: Mutt/1.3.23i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

[Redirected to -net]
[Category changed to "kern"]

On Fri, Nov 30, 2001 at 11:01:56AM +0700, Igor M Podlesny wrote:
[...]
> [router]
>   |
>   X---->|backbone|-->
>   |
>   |
>   Yip1----|the same media|------[some another ip-network]
>   |ip2----|the same media|------|some box|
> 
> Here  is "router" with FreeBSD (OpenBSD, and, probably *BSD) and "Some
> box"  doing traceroute to (for e.g.) a host which is _reachable_ _via_
> _backbone_.   X,  Y  --  NICs.  Y  has  several  IPs,  making  several
> ip-networks on "the same media".
> 
> The  problem: traceroute being run on "somebox" will hear respond from
> "router"  coming  from  Y.ip1  address  which  isn't  on its (somebox)
> IP-network.  (well,  I  deem  icmp.echoreply isn't alone in this.) And
> this happens because wrong IP-addr is passed to ifaof_ifpforaddr(). My
> patch  fixes  namely  this problem -- I have worked out and applied it
> and  I  believe  I know what I'm talking about. Look at it, and you'll
> realize what I mean...
> 
> You  may  ask  me  for  details,  but,  please,  don't  make different
> situations  asking  me  how  does  it  correlate  with -- damn lack of
> time...
> 
Yeah, now I see what's screwed up.  I even thought about this myself
this morning (well, you know the saying we use for that :-), before
even reading your mail.  But your fix is not quite correct, as we may
have an individual routing table entry on "router" pointing back to
"somebox" with a specific interface address (IFA) given, as reported
by the "route -vn get -host <somebox>" command, and we should actually
use that as the source.  The correct fix is a bit more complicated,
and fortunately I have one.


Cheers,
-- 
Ruslan Ermilov		Oracle Developer/DBA,
ru@sunbay.com		Sunbay Software AG,
ru@FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30  7: 1:32 2001
Delivered-To: freebsd-net@freebsd.org
Received: from web.cs.ndsu.nodak.edu (web.cs.ndsu.NoDak.edu [134.129.125.7])
	by hub.freebsd.org (Postfix) with ESMTP id CB37137B422
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 07:01:28 -0800 (PST)
Received: (from tinguely@localhost)
	by web.cs.ndsu.nodak.edu (8.11.4/8.11.4) id fAUF1L146802;
	Fri, 30 Nov 2001 09:01:21 -0600 (CST)
	(envelope-from tinguely)
Date: Fri, 30 Nov 2001 09:01:21 -0600 (CST)
From: mark tinguely <tinguely@web.cs.ndsu.nodak.edu>
Message-Id: <200111301501.fAUF1L146802@web.cs.ndsu.nodak.edu>
To: jlemon@flugsvamp.com, rizzo@aciri.org
Subject: Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
Cc: cfliu@realtek.com.tw, freebsd-net@FreeBSD.ORG
In-Reply-To: <20011129083005.C19821@iguana.aciri.org>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Thu, Nov 29, 2001 at 10:05:34AM -0600, Jonathan Lemon wrote:
> On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> > Thanks...I know where my problem is now...It's indeed   a duplicate SYN.
> > 
> > By the way, the tcp_input function is so long and large and there are
> > several goto statements which make reading the code even more difficult. Is
> > this intened to be like this? Even with Steven's TCP/IP Vol.2, it took me
> > three whole days to draw a Visio flow chart of this function. Has anybody
> > ever considered of reorganizing this module?
> 
> I don't believe so; the code was originally designned to avoid function 
> calls, and is essentially a couple of large switch statements.  The flow
> pretty much mirrors the original RFC, and shouldn't be too hard to follow.

want to make the process harder by adding Early Congestion Notification,
Duplicate Selective Acknologment, Rate Halfing congestion control? Of
course add [Adaptive] Random Early Detection in the input queues. Heck
if we are asking for a heculian effort, I might as well pile up the
requests.

Eventually these features will be needed to keep the TCP stack competitive.
The Pittsburgh Supercompter Center's Rate-Halfing, SAK (not DSAK), ECN
code looks even more complex (with all the ifdefs, etc) than the FreeBSD
code, and I did not remeber seeing the changes for IPv6.

Too bad there are not companies throwing money around to fund a good
rewrite...of course there is some competative advatange to do so only
for themselves.

time to go back to (my) reality...

--mark tinguely.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30  8:40:14 2001
Delivered-To: freebsd-net@freebsd.org
Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9])
	by hub.freebsd.org (Postfix) with ESMTP id AD74C37B419
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 08:40:05 -0800 (PST)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.11.0/8.11.0) id fAUGaqT79027;
	Fri, 30 Nov 2001 10:36:52 -0600 (CST)
	(envelope-from jlemon)
Date: Fri, 30 Nov 2001 10:36:52 -0600
From: Jonathan Lemon <jlemon@flugsvamp.com>
To: mark tinguely <tinguely@web.cs.ndsu.nodak.edu>
Cc: jlemon@flugsvamp.com, rizzo@aciri.org, cfliu@realtek.com.tw,
	freebsd-net@FreeBSD.ORG
Subject: Re: Does 4.4 FreeBSD kernel supports TCP simultaneous open?
Message-ID: <20011130103652.Z75389@prism.flugsvamp.com>
References: <20011129083005.C19821@iguana.aciri.org> <200111301501.fAUF1L146802@web.cs.ndsu.nodak.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <200111301501.fAUF1L146802@web.cs.ndsu.nodak.edu>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Fri, Nov 30, 2001 at 09:01:21AM -0600, mark tinguely wrote:
> On Thu, Nov 29, 2001 at 10:05:34AM -0600, Jonathan Lemon wrote:
> > On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> > > Thanks...I know where my problem is now...It's indeed   a duplicate SYN.
> > > 
> > > By the way, the tcp_input function is so long and large and there are
> > > several goto statements which make reading the code even more difficult. Is
> > > this intened to be like this? Even with Steven's TCP/IP Vol.2, it took me
> > > three whole days to draw a Visio flow chart of this function. Has anybody
> > > ever considered of reorganizing this module?
> > 
> > I don't believe so; the code was originally designned to avoid function 
> > calls, and is essentially a couple of large switch statements.  The flow
> > pretty much mirrors the original RFC, and shouldn't be too hard to follow.
> 
> want to make the process harder by adding Early Congestion Notification,
> Duplicate Selective Acknologment, Rate Halfing congestion control? Of
> course add [Adaptive] Random Early Detection in the input queues. Heck
> if we are asking for a heculian effort, I might as well pile up the
> requests.

Haha.  I already scheduled work for ECN at one point, but that got put
on hold.  Yes, I'm aware of all of these things, and am quite willing to
restructure the stack for them.  But these are large tasks, and there 
are only so many things I can work on.  Funded work, or work of direct
relevance to me, usually takes priority.


> Eventually these features will be needed to keep the TCP stack competitive.
> The Pittsburgh Supercompter Center's Rate-Halfing, SAK (not DSAK), ECN
> code looks even more complex (with all the ifdefs, etc) than the FreeBSD
> code, and I did not remeber seeing the changes for IPv6.
> 
> Too bad there are not companies throwing money around to fund a good
> rewrite...of course there is some competative advatange to do so only
> for themselves.

Anyone want to fund a network hacker to do all of these?  Seriously?  :-(
-- 
Jonathan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30  8:48:44 2001
Delivered-To: freebsd-net@freebsd.org
Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36])
	by hub.freebsd.org (Postfix) with ESMTP id E8A5937B416
	for <net@FreeBSD.ORG>; Fri, 30 Nov 2001 08:48:37 -0800 (PST)
Received: (from rizzo@localhost)
	by iguana.aciri.org (8.11.3/8.11.1) id fAUGiLn30884;
	Fri, 30 Nov 2001 08:44:21 -0800 (PST)
	(envelope-from rizzo)
Date: Fri, 30 Nov 2001 08:44:21 -0800
From: Luigi Rizzo <rizzo@aciri.org>
To: Bruce Evans <bde@zeta.org.au>
Cc: net@FreeBSD.ORG
Subject: Re: Revised polling code for STABLE
Message-ID: <20011130084421.A30672@iguana.aciri.org>
References: <20011129063116.B19430@iguana.aciri.org> <20011130174232.R347-100000@gamplex.bde.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011130174232.R347-100000@gamplex.bde.org>
User-Agent: Mutt/1.3.23i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Fri, Nov 30, 2001 at 06:37:33PM +1100, Bruce Evans wrote:
> On Thu, 29 Nov 2001, Luigi Rizzo wrote:
> 
> > The call to update_poll_threshold() however needs to be done by
> > either hardclock() or statclock() (i am experimenting with that
...
> Why in that particular interrupt?  If you do it in a timeout routine,

i'll try to explain.

One of the goal of polling is to be able to adapt the fraction of
CPU dedicated to polling so that it matches some user-programmable
threshold -- and in any case, make sure that you are never using
100% of the CPU doing polling because in this case you would have
livelock and a non-responsive system.

The amount of polling is (roughly) controlled by a variable, "poll_burst",
which tells each driver how many packets to grab at most from the card
at each xxx_poll() invocation. The goal of the control system is to
dynamically adjust poll_burst depending on actual CPU speed, incoming
traffic etc.

Out of the infinitely many ways of doing this, i am experimenting with
a couple:

 + (what is implemented now) Make sure that ether_poll() is run
   as the first thing after hardclock. Then in hardclock(), check
   if the CPU is still in the previous instance of ether_poll().
   If so, reduce poll_burst (currently, halve it), otherwise
   increase it by one every N clock ticks.
   This serves to detect potential livelock (ether_poll() consuming
   an entire tick) and react accordingly.

 + (what i want to test next). Use the profiling clock to sample
   cpu state, and determine (over the long term) what fraction of
   these samples finds the CPU busy in ether_poll(). If the fraction
   is higher than a programmed threshold then reduce poll_burst,
   otherwise increment it.
   This might give a more fine-grained control, but only works
   on a longer scale term, and still I should check 

The first scheme is just a stopgap measure, it works, but it is
rather coarse. And it needs to run ether_poll() right after
hardclock() otherwise i would have to deal with the extra delay
and I am not very clear on how to do that.

For the second scheme i probably do not need to run ether_poll()
from hardclock. But as you notice there are issues on how fair the
sampling would be, which I haven't had the time to deal with yet.

> In -current, hardclock() and softclock() are called in fast interrupt
> context, so adding to them is both nontrivial and BAD (it requires

well the code i am adding is really short, look at the patch!
It boils down to reading one variable and updating poll_burst
accordingly.
Plus the polling code is not designed for SMP anyways, you cannot
specify both ETHER_POLLING and SMP options (I already tried to
explain why i think polling is mostly useless with SMP).

> > I do not know how/if I can replace the schednetisr() with an ordinary timeout:
> > i need the handler to be invoked as soon as possible after the
> > clock ticks, as the task it performs are as urgent as interrupt requests.
> 
> As urgent as hardclock interrupts?

I'd say yes: as urgent, but with a lower priority.
If there are packets to fetch from the cards, those are packets
for which there would be an interrupt pending in a traditional
system, so they would be processed after hardclock but before
pending soft interrupts.  I would like to keep this prioritization
as much as possible.

I have considered adding another interrupt class (as a matter of fact,
i even did that) with higher priority than other SWI, but i thought
it was overkill because splsoftnet(NETISR_POLL) still seems to be
the highest priority soft interrupt and the change is less intrusive.
Am I wrong on this ?

> Ugh.  Use a standard FreeBSD C interface for this (critical_exit() in
> -current; enable_intr() for i386's only in RELENG_4).

ok, i just copied the "sti"/"cli" from vm_page_zero_idle() !

> > 		    retval = ether_poll(poll_burst);
> > 		    __asm __volatile("cli" : : : "memory");
> > 		    splx(s);
> > 		    vm_page_zero_idle();
> > 		    return 1;
> > 		} else
> > 		    return vm_page_zero_idle();
> > 	}
> 
> It's ugly for idle_poll() to know about all the other poll routines
> (we've had other there before, e.g., one for apm).

Someone has to know-- this idle_poll() is basically a part of the
idle_loop written in C instead of assembler, the logic can be a bit
convoluted so i think this is much more readable this way.

Does the above make sense ?

	cheers
	luigi
----------------------------------+-----------------------------------------
 Luigi RIZZO, luigi@iet.unipi.it  . ACIRI/ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone: (510) 666 2927
----------------------------------+-----------------------------------------

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30  9:27: 9 2001
Delivered-To: freebsd-net@freebsd.org
Received: from measurement-factory.com (measurement-factory.com [206.168.0.5])
	by hub.freebsd.org (Postfix) with ESMTP id 31E8537B416
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 09:27:06 -0800 (PST)
Received: (from rousskov@localhost)
	by measurement-factory.com (8.9.3/8.9.3) id KAA10968;
	Fri, 30 Nov 2001 10:27:04 -0700 (MST)
	(envelope-from rousskov)
Date: Fri, 30 Nov 2001 10:27:04 -0700 (MST)
From: Alex Rousskov <rousskov@measurement-factory.com>
To: Jonathan Lemon <jlemon@flugsvamp.com>
Cc: freebsd-net@FreeBSD.ORG
Subject: funding TCP stack rewrite
In-Reply-To: <20011130103652.Z75389@prism.flugsvamp.com>
Message-ID: <Pine.BSF.4.10.10111301012590.7584-100000@measurement-factory.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Fri, 30 Nov 2001, Jonathan Lemon wrote:
> On Fri, Nov 30, 2001 at 09:01:21AM -0600, mark tinguely wrote:
> > Too bad there are not companies throwing money around to fund a good
> > rewrite...of course there is some competative advatange to do so only
> > for themselves.
>
> Anyone want to fund a network hacker to do all of these?  Seriously?  :-(

What kind of sum of money are we talking about here? Can you estimate
what hacker/month effort is required? Would it make sense to setup a
[paypal] fund of some kind, hosted on freebsd.org to raise the
required sum? That way small companies and even individuals can
contribute even if the total is more than they can afford...

Is there a guru with enough unallocated time to concentrate on the
rewrite?

Will the dedicated work of the said guru get a high priority as far as
review and commit steps are concerned? A public semi-formal commitment
or encouragement from FreeBSD core group may be in order to raise
support from the community. Otherwise, folks may worry that these big
changes, once implemented, will get stuck in the commit queue forever.

Thanks,

Alex.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30  9:57:20 2001
Delivered-To: freebsd-net@freebsd.org
Received: from ardbeg.meer.net (ardbeg.meer.net [209.157.152.23])
	by hub.freebsd.org (Postfix) with ESMTP id 4858937B416
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 09:57:18 -0800 (PST)
Received: from meer.meer.net (mail.meer.net [209.157.152.14])
	by ardbeg.meer.net (8.11.3/8.11.3) with ESMTP id fAUHvHp79229;
	Fri, 30 Nov 2001 09:57:17 -0800 (PST)
Received: from neville-neil.com ([209.157.133.226])
	by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id JAA2847316;
	Fri, 30 Nov 2001 09:56:57 -0800 (PST)
Message-Id: <200111301756.JAA2847316@meer.meer.net>
X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4
To: Alex Rousskov <rousskov@measurement-factory.com>
Cc: Jonathan Lemon <jlemon@flugsvamp.com>, freebsd-net@FreeBSD.ORG
Subject: Re: funding TCP stack rewrite 
In-Reply-To: Message from Alex Rousskov <rousskov@measurement-factory.com> 
   of "Fri, 30 Nov 2001 10:27:04 MST." <Pine.BSF.4.10.10111301012590.7584-100000@measurement-factory.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 30 Nov 2001 09:56:56 -0800
From: "George V. Neville-Neil" <gnn@neville-neil.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

> On Fri, 30 Nov 2001, Jonathan Lemon wrote:
> > On Fri, Nov 30, 2001 at 09:01:21AM -0600, mark tinguely wrote:
> > > Too bad there are not companies throwing money around to fund a good
> > > rewrite...of course there is some competative advatange to do so only
> > > for themselves.
> >
> > Anyone want to fund a network hacker to do all of these?  Seriously?  :-(

There are people doing this, for themselves.  But it's not a rewrite, it's 
porting.

There are well known recent failures (not specifically on FreeBSD but
of rewrites of network stacks to achieve more modern ends).  Nortel's
Open IP comes immediately to mind.

> What kind of sum of money are we talking about here? Can you estimate
> what hacker/month effort is required? Would it make sense to setup a
> [paypal] fund of some kind, hosted on freebsd.org to raise the
> required sum? That way small companies and even individuals can
> contribute even if the total is more than they can afford...
> 

There is a more important question to be answered:

What is the exact set of goals to be achieved by the rewrite?

Many people/companies forget this and end in a muddle.  I'm a big
fan of rewriting/reworking the BSD stack because I've seen it
pushed to its very edges and know the difficulties but unless
there is a strong goal that can be stuck to the effort is doomed from
the start.

> Will the dedicated work of the said guru get a high priority as far as
> review and commit steps are concerned? A public semi-formal commitment
> or encouragement from FreeBSD core group may be in order to raise
> support from the community. Otherwise, folks may worry that these big
> changes, once implemented, will get stuck in the commit queue forever.

What we need is a sub-project here.

Later,
George




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30  9:58:32 2001
Delivered-To: freebsd-net@freebsd.org
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP id 3A15C37B419
	for <net@FreeBSD.ORG>; Fri, 30 Nov 2001 09:58:30 -0800 (PST)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fAUHwSP28351;
	Fri, 30 Nov 2001 12:58:28 -0500 (EST)
	(envelope-from wollman)
Date: Fri, 30 Nov 2001 12:58:28 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200111301758.fAUHwSP28351@khavrinen.lcs.mit.edu>
To: Jonathan Lemon <jlemon@flugsvamp.com>
Cc: net@FreeBSD.ORG
Subject: Re: TCP anomalies (was Re: FreeBSD performing worse than Linux?)
In-Reply-To: <200111300647.fAU6l9K60404@prism.flugsvamp.com>
References: <local.mail.freebsd-net/20011128102241.6887B380A@overcee.netplex.com.au>
	<local.mail.freebsd-net/20011128112006.195983808@overcee.netplex.com.au>
	<local.mail.freebsd-net/20011129105321.C74413@monorchid.lemis.com>
	<local.mail.freebsd-net/200111290113.fAT1DnH04474@khavrinen.lcs.mit.edu>
	<local.mail.freebsd-net/200111300518.fAU5IXx11078@c527597-a.cstvl1.sfba.home.com>
	<200111300647.fAU6l9K60404@prism.flugsvamp.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

<<On Fri, 30 Nov 2001 00:47:09 -0600 (CST), Jonathan Lemon <jlemon@flugsvamp.com> said:

[Quoting Bruce Mah:]

>> happens.  In *most* cases, the receiver somehow gets the missing data
>> because you can later see it acking later sequence numbers.  The first
>> place I saw this was at :41.504152.

Those are not duplicate acks because the window is still getting updated.

>> Another place to look is the large number of consecutive dupacks
>> starting around :41.978767.  I don't know what's happening here, but
>> after a long time (about a second?!?) the sender finally gives up and
>> sends the receiver what it wants.

> Yes, I think that area (I was looking at it too) provides a fairly
> good illustration that fast retransmits are broken.  The transmit 
> at 14:01:42.969338 appears to be the retransmit timer finally kicking in.

Yes, that's the conclusion Tim Shepard and I came to as well.

-GAWollman


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 10: 0:18 2001
Delivered-To: freebsd-net@freebsd.org
Received: from elvis.mu.org (elvis.mu.org [216.33.66.196])
	by hub.freebsd.org (Postfix) with ESMTP id 5650537B41A
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 10:00:14 -0800 (PST)
Received: by elvis.mu.org (Postfix, from userid 1098)
	id D0E0F81D04; Fri, 30 Nov 2001 12:00:08 -0600 (CST)
Date: Fri, 30 Nov 2001 12:00:08 -0600
From: Bill Fumerola <billf@mu.org>
To: Alex Rousskov <rousskov@measurement-factory.com>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: funding TCP stack rewrite
Message-ID: <20011130120008.G32521@elvis.mu.org>
References: <20011130103652.Z75389@prism.flugsvamp.com> <Pine.BSF.4.10.10111301012590.7584-100000@measurement-factory.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.BSF.4.10.10111301012590.7584-100000@measurement-factory.com>; from rousskov@measurement-factory.com on Fri, Nov 30, 2001 at 10:27:04AM -0700
X-Operating-System: FreeBSD 4.4-FEARSOME-20011125 i386
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Fri, Nov 30, 2001 at 10:27:04AM -0700, Alex Rousskov wrote:

> What kind of sum of money are we talking about here? Can you estimate
> what hacker/month effort is required? Would it make sense to setup a
> [paypal] fund of some kind, hosted on freebsd.org to raise the
> required sum? That way small companies and even individuals can
> contribute even if the total is more than they can afford...
> 
> Is there a guru with enough unallocated time to concentrate on the
> rewrite?
> 
> Will the dedicated work of the said guru get a high priority as far as
> review and commit steps are concerned? A public semi-formal commitment
> or encouragement from FreeBSD core group may be in order to raise
> support from the community. Otherwise, folks may worry that these big
> changes, once implemented, will get stuck in the commit queue forever.

the freebsd foundation is supposed to be an a not-for-profit organization
that (amongst other things) delegates donated money to developers for
this kind of work.  at their current speed, they will be ready to provide
such a service in the year 2018.

core has nothing to do with preventing or allowing completed work to
enter the tree. the quality of the code does. presumably, the people
that the foundation (or NAI or whoever) contracts to do FreeBSD work
are of high calibur and that isn't a problem.

-- 
- bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org / billf@mu.org
- my anger management counselor can beat up your self-affirmation therapist



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 10: 5:39 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172])
	by hub.freebsd.org (Postfix) with ESMTP
	id F2B5F37B417; Fri, 30 Nov 2001 10:05:36 -0800 (PST)
Received: from milk.yahoo.com (milk.yahoo.com [216.145.52.137])
	by mrout2.yahoo.com (8.11.6/8.11.6/y.out) with ESMTP id fAUI5Fu60686;
	Fri, 30 Nov 2001 10:05:15 -0800 (PST)
Received: (from root@localhost)
	by milk.yahoo.com (8.11.0/8.11.0) id fAUI5FT69793;
	Fri, 30 Nov 2001 10:05:15 -0800 (PST)
	(envelope-from jayanth)
Date: Fri, 30 Nov 2001 10:05:15 -0800
From: jayanth <jayanth@yahoo-inc.com>
To: "Bruce A. Mah" <bmah@FreeBSD.ORG>
Cc: net@FreeBSD.ORG
Subject: Re: FreeBSD performing worse than Linux?
Message-ID: <20011130100515.C63426@yahoo-inc.com>
References: <20011128153817.T61580@monorchid.lemis.com> <15364.38174.938500.946169@caddis.yogotech.com> <20011129004234.A16101@exuma.irbs.com> <200111300527.fAU5R0s11199@c527597-a.cstvl1.sfba.home.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <200111300527.fAU5R0s11199@c527597-a.cstvl1.sfba.home.com>; from bmah@FreeBSD.ORG on Thu, Nov 29, 2001 at 09:27:00PM -0800
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Hmm, this is what has broken fast retransmit.
I should probably replace 
	if (tp->t_dupacks < tcprexmtthresh)
                        tp->t_dupacks = 0;

	with
	if (tcp_do_newreno && (tp->t_dupacks < tcprexmtthresh))
			tp->t_dupacks = 0;

jayanth

Bruce A. Mah (bmah@FreeBSD.ORG) wrote:
> If memory serves me right, John Capo wrote:
> 
> [TCP weirdness]
> 
> > I see exactly the same behavior on 3 -stable machines running kernels
> > from late October and early November.  Another -stable machine with
> > a kernel from late September does pause but not as consistently as
> > the later kernel machines do.  The client machine is running a
> > kernel from early November.
> 
> How early in November?  I'm staring at this commit message and 
> wondering if it has any relevance to your situation:
> 
> -----
> revision 1.107.2.18
> date: 2001/11/12 22:11:24;  author: nate;  state: Exp;  lines: +3 -1
> MFH: V1.139
>    when newreno is turned on, if dupacks = 1 or dupacks = 2 and
>    new data is acknowledged, reset the dupacks to 0.
>    The problem was spotted when a connection had its send buffer full
>    because the congestion window was only 1 MSS and was not being incremented
>    because dupacks was not reset to 0.
> 
> Reviewed by:    jlemon
> -----
> 
> Bruce.
> 
> 
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 10:13:11 2001
Delivered-To: freebsd-net@freebsd.org
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2F58337B405; Fri, 30 Nov 2001 10:13:09 -0800 (PST)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fAUID8I28553;
	Fri, 30 Nov 2001 13:13:08 -0500 (EST)
	(envelope-from wollman)
Date: Fri, 30 Nov 2001 13:13:08 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200111301813.fAUID8I28553@khavrinen.lcs.mit.edu>
To: bmah@FreeBSD.ORG
Cc: net@FreeBSD.ORG
Subject: TCP anomalies (was Re: FreeBSD performing worse than Linux?)
In-Reply-To: <200111300518.fAU5IXx11078@c527597-a.cstvl1.sfba.home.com>
References: <20011128102241.6887B380A@overcee.netplex.com.au>
	<20011128112006.195983808@overcee.netplex.com.au>
	<20011129105321.C74413@monorchid.lemis.com>
	<200111290113.fAT1DnH04474@khavrinen.lcs.mit.edu>
	<200111300518.fAU5IXx11078@c527597-a.cstvl1.sfba.home.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

<<On Thu, 29 Nov 2001 21:18:33 -0800, "Bruce A. Mah" <bmah@FreeBSD.ORG> said:

> Your 4.4-STABLE machine, is it from before or after rev 1.107.2.18 of
> sys/netinet/tcp_input.c?

Before.

> Also...where did you do the trace (i.e. sender, receiver, or a third
> machine)?

Sender, of course -- that's the only place some of these phenomena
could possibly be observed.

I've now made available another trace, which involves the same
machines but this time with newreno turned off on the sender.  Note
that the 40-packet bursts are still there, as are the problems with
fast retransmit.

-GAWollman


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 10:30:19 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id 6F0DF37B405
	for <net@FreeBSD.ORG>; Fri, 30 Nov 2001 10:30:12 -0800 (PST)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA09269;
	Sat, 1 Dec 2001 05:30:06 +1100
Date: Sat, 1 Dec 2001 05:30:14 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender:  <bde@gamplex.bde.org>
To: Luigi Rizzo <rizzo@aciri.org>
Cc: <net@FreeBSD.ORG>
Subject: Re: Revised polling code for STABLE
In-Reply-To: <20011130084421.A30672@iguana.aciri.org>
Message-ID: <20011201042322.O2240-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Fri, 30 Nov 2001, Luigi Rizzo wrote:

> On Fri, Nov 30, 2001 at 06:37:33PM +1100, Bruce Evans wrote:
> > On Thu, 29 Nov 2001, Luigi Rizzo wrote:
> >
> > > The call to update_poll_threshold() however needs to be done by
> > > either hardclock() or statclock() (i am experimenting with that
> ...
> > Why in that particular interrupt?  If you do it in a timeout routine,
>
> i'll try to explain.
>
> One of the goal of polling is to be able to adapt the fraction of
> CPU dedicated to polling so that it matches some user-programmable
> threshold -- and in any case, make sure that you are never using
> 100% of the CPU doing polling because in this case you would have
> livelock and a non-responsive system.

But this doesn't require _very_ accurate syncing with the hardclock
interrupt.  It's similar to scheduling.  The scheduler runs approximately
every 5 seconds and uses its load average calculation to adapt the
fraction (sort of) of the CPU dedicated (sort of) to each process.  It
just uses timeout().  Ian Dowse recently found that this sometimes
gave too accurate syncing and added some jitter (+-0.5 sec -- too much,
I think).  For your polling, I think the only significant difference
is that the polling should not get too far behind because there are
real- time requirements.  Timeout routines will only get behind if the
system is so overloaded that it doesn't call softclock() for every
hardclock(), and dropping packets by simply missing polling deadlines
may be the best way to reduce the load.

> Out of the infinitely many ways of doing this, i am experimenting with
> a couple:
> ...
>  + (what i want to test next). Use the profiling clock to sample
>    cpu state, and determine (over the long term) what fraction of
>    these samples finds the CPU busy in ether_poll(). If the fraction
>    is higher than a programmed threshold then reduce poll_burst,
>    otherwise increment it.
>    This might give a more fine-grained control, but only works
>    on a longer scale term, and still I should check
> ...
> For the second scheme i probably do not need to run ether_poll()
> from hardclock. But as you notice there are issues on how fair the
> sampling would be, which I haven't had the time to deal with yet.

I would try putting the sampling in a timeout routine, and handle the
real-time issues in hardclock(), but hope that they aren't important
and and up not handling them.  hardclock() would just check that the
polling routines got called enough during the previous N hardclock
interrupt periods (N small enough), and arrange for some polling to
be done at a very high priority as soon as possible.

> > In -current, hardclock() and softclock() are called in fast interrupt
> > context, so adding to them is both nontrivial and BAD (it requires
>
> well the code i am adding is really short, look at the patch!
> It boils down to reading one variable and updating poll_burst
> accordingly.

Sorry, I deleted the patch.  Everything that writes the variable
would need locking or something to give atomic accesses.  I don't
remember where it is written.

> > > I do not know how/if I can replace the schednetisr() with an ordinary timeout:
> > > i need the handler to be invoked as soon as possible after the
> > > clock ticks, as the task it performs are as urgent as interrupt requests.
> >
> > As urgent as hardclock interrupts?
>
> I'd say yes: as urgent, but with a lower priority.
> If there are packets to fetch from the cards, those are packets
> for which there would be an interrupt pending in a traditional
> system, so they would be processed after hardclock but before
> pending soft interrupts.  I would like to keep this prioritization
> as much as possible.

With polling from timeout routines, doubling HZ would reduce the average
latency to below that for polling from hardclock() or soon after.  I
think you need to increase HZ anyway, so increasing it even more would
be acceptable.  But you want the _worst-case_ latency to be not much
larger than 1/(original HZ).  See above about different polling in
hardclock to handle this and why handling it might not be necessary.

> I have considered adding another interrupt class (as a matter of fact,
> i even did that) with higher priority than other SWI, but i thought
> it was overkill because splsoftnet(NETISR_POLL) still seems to be
> the highest priority soft interrupt and the change is less intrusive.
> Am I wrong on this ?

A little.  splsoftty() is higher.  Also, polling might be useful for
non-net drivers.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 11:20:34 2001
Delivered-To: freebsd-net@freebsd.org
Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6E5EC37B405; Fri, 30 Nov 2001 11:20:20 -0800 (PST)
Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [fec0::1:12])
	by Awfulhak.org (8.11.6/8.11.6) with ESMTP id fAUJKIR76096;
	Fri, 30 Nov 2001 19:20:18 GMT
	(envelope-from brian@freebsd-services.com)
Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1])
	by hak.lan.Awfulhak.org (8.11.6/8.11.6) with ESMTP id fAUJKGE02104;
	Fri, 30 Nov 2001 19:20:16 GMT
	(envelope-from brian@freebsd-services.com)
Message-Id: <200111301920.fAUJKGE02104@hak.lan.Awfulhak.org>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: Brian Somers <brian@FreeBSD.org>
Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org,
	freebsd-net@FreeBSD.org
Subject: Re: cvs commit: src/sys/netinet in.c 
In-Reply-To: Message from Brian Somers <brian@FreeBSD.org> 
   of "Fri, 30 Nov 2001 06:00:55 PST." <200111301400.fAUE0tj62293@freefall.freebsd.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 30 Nov 2001 19:20:16 +0000
From: Brian Somers <brian@freebsd-services.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

> brian       2001/11/30 06:00:55 PST
> 
>   Modified files:
>     sys/netinet          in.c 
>   Log:
>   During SIOCAIFADDR, if in_ifinit() fails and we've already added an
>   interface address, blow the address away again before returning the
>   error.
>   
>   In in_ifinit(), if we get an error from rtinit() and we've also got
>   a destination address, return the error rather than masking EEXISTS.
>   Failing to create a host route when configuring an interface should
>   be treated as an error.
>   
>   Revision  Changes    Path
>   1.61      +39 -24    src/sys/netinet/in.c

It's possible that EEXIST being returned from in_ifinit() should not 
be masked at all, except for the ``netmask == 0xffffffff'' case so that 
we can't have conflicting interface addresses....

I'm not sure about this though, so I've cc'd  freebsd-net.
-- 
Brian <brian@freebsd-services.com>                <brian@Awfulhak.org>
      http://www.freebsd-services.com/        <brian@[uk.]FreeBSD.org>
Don't _EVER_ lose your sense of humour !      <brian@[uk.]OpenBSD.org>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 11:31: 4 2001
Delivered-To: freebsd-net@freebsd.org
Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36])
	by hub.freebsd.org (Postfix) with ESMTP id 8491737B416
	for <net@FreeBSD.ORG>; Fri, 30 Nov 2001 11:31:00 -0800 (PST)
Received: (from rizzo@localhost)
	by iguana.aciri.org (8.11.3/8.11.1) id fAUJQeQ32024;
	Fri, 30 Nov 2001 11:26:40 -0800 (PST)
	(envelope-from rizzo)
Date: Fri, 30 Nov 2001 11:26:40 -0800
From: Luigi Rizzo <rizzo@aciri.org>
To: Bruce Evans <bde@zeta.org.au>
Cc: net@FreeBSD.ORG
Subject: Re: Revised polling code for STABLE
Message-ID: <20011130112640.I30981@iguana.aciri.org>
References: <20011130084421.A30672@iguana.aciri.org> <20011201042322.O2240-100000@gamplex.bde.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20011201042322.O2240-100000@gamplex.bde.org>
User-Agent: Mutt/1.3.23i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Sat, Dec 01, 2001 at 05:30:14AM +1100, Bruce Evans wrote:

> But this doesn't require _very_ accurate syncing with the hardclock
> interrupt.  It's similar to scheduling.  The scheduler runs approximately

Maybe there is a misunderstanding here.
What i want to call from hardclock() is the threshold adjustment,
not ether_poll(). ether_poll() is scheduled as a soft interrupt,
and I do want it to have priority over other soft interrupts for
reasons that i tried to explain.

Re. the threshold adjustment, the fact is that i am working on
much finer timescales than the seconds you mention for the scheduler.
And, especially, i want to detect that i am overloading the system
as soon as possible, that is at the first available clock interrupt.

> > well the code i am adding is really short, look at the patch!
> > It boils down to reading one variable and updating poll_burst
> > accordingly.
> 
> Sorry, I deleted the patch.  Everything that writes the variable
> would need locking or something to give atomic accesses.  I don't
> remember where it is written.

You see, this is one of the problems i am having with this code
review!  I get regularly summoned on what my code is supposed to
do or not to do, even when I am doing something very close or
exactly like what is being suggested.  Sure that happens because
the patch touches many files, and so one is tempted (with
the genuine intention to help) to give generic suggestions as
opposed to look at the actual details of the code.

But this is not good for the project. The poster has the impression
that there is something wrong with the code, the author feels
mistreated, and then it takes a fair bit of energy, time and email
exchange to clarify the issues, and more often than not things
stall because one gives up, or sometimes in the discussion people
(including myself) get upset because they take things as a personal
critique (which i am sure is nowhere near anyone intentions, but
we are human...).

In this case, apart from the critique on keeping the code short
(which is already) you mention locking (which i do not do). Do i
need to lock variables ? I really don't think so.  I said a number
of times that

	this code is not supposed to run with SMP.

If you specify both ETHER_POLL and SMP kernel options, the compiler
will spit out an error message saying they are incompatible.  So
nothing that i can think of can cause consistency problems on
the specific variables i am using.

> With polling from timeout routines, doubling HZ would reduce the average
> latency to below that for polling from hardclock() or soon after.  I
> think you need to increase HZ anyway, so increasing it even more would
> be acceptable.  But you want the _worst-case_ latency to be not much
> larger than 1/(original HZ).  See above about different polling in

I do not really follow. Original latency (with interrupts) is
unrelated to HZ, it's just the interrupt dispatch time plus delays
from higher priority handlers being run. Yes I am raising HZ with
polling, but the latency might still be higher than in the
interrupt-based system.

> > I have considered adding another interrupt class (as a matter of fact,
> > i even did that) with higher priority than other SWI, but i thought
> > it was overkill because splsoftnet(NETISR_POLL) still seems to be
> > the highest priority soft interrupt and the change is less intrusive.
> > Am I wrong on this ?
> 
> A little.  splsoftty() is higher.  Also, polling might be useful for
> non-net drivers.

next step... i cannot do all at once!

	cheers
	luigi
----------------------------------+-----------------------------------------
 Luigi RIZZO, luigi@iet.unipi.it  . ACIRI/ICSI (on leave from Univ. di Pisa)
 http://www.iet.unipi.it/~luigi/  . 1947 Center St, Berkeley CA 94704
 Phone: (510) 666 2927
----------------------------------+-----------------------------------------

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 11:50:19 2001
Delivered-To: freebsd-net@freebsd.org
Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9])
	by hub.freebsd.org (Postfix) with ESMTP id E7BE037B416
	for <net@freebsd.org>; Fri, 30 Nov 2001 11:50:06 -0800 (PST)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.11.0/8.11.0) id fAUJl3Z85729;
	Fri, 30 Nov 2001 13:47:03 -0600 (CST)
	(envelope-from jlemon)
Date: Fri, 30 Nov 2001 13:47:03 -0600 (CST)
From: Jonathan Lemon <jlemon@flugsvamp.com>
Message-Id: <200111301947.fAUJl3Z85729@prism.flugsvamp.com>
To: jayanth@yahoo-inc.com, net@freebsd.org
Subject: Re: FreeBSD performing worse than Linux?
X-Newsgroups: local.mail.freebsd-net
In-Reply-To: <local.mail.freebsd-net/20011130100515.C63426@yahoo-inc.com>
References: <local.mail.freebsd-net/20011128153817.T61580@monorchid.lemis.com>
	<local.mail.freebsd-net/15364.38174.938500.946169@caddis.yogotech.com>
	<local.mail.freebsd-net/20011129004234.A16101@exuma.irbs.com>
	<local.mail.freebsd-net/200111300527.fAU5R0s11199@c527597-a.cstvl1.sfba.home.com>
Organization: 
Cc: 
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

In article <local.mail.freebsd-net/20011130100515.C63426@yahoo-inc.com> you write:
>Hmm, this is what has broken fast retransmit.
>I should probably replace 
>	if (tp->t_dupacks < tcprexmtthresh)
>                        tp->t_dupacks = 0;
>
>	with
>	if (tcp_do_newreno && (tp->t_dupacks < tcprexmtthresh))
>			tp->t_dupacks = 0;

I don't think that's it.  The original (pre-NewReno) code had:

                /*
                 * If the congestion window was inflated to account
                 * for the other side's cached packets, retract it.
                 */
                if (tp->t_dupacks >= tcprexmtthresh &&
                    tp->snd_cwnd > tp->snd_ssthresh)
                        tp->snd_cwnd = tp->snd_ssthresh;
                tp->t_dupacks = 0;

So t_dupacks was always getting set to 0 on this codepath.  In the
existing code, the 'if' statement you point out above is only relevant
if newreno is turned on.  However, the pathologies happen regardless
of the setting of the newreno flag.
-- 
Jonathan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 12: 9:45 2001
Delivered-To: freebsd-net@freebsd.org
Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98])
	by hub.freebsd.org (Postfix) with ESMTP id C219337B416
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 12:09:42 -0800 (PST)
Received: from winston.freebsd.org (jkh@localhost [127.0.0.1])
	by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fAUK9Kq02051;
	Fri, 30 Nov 2001 12:09:36 -0800 (PST)
	(envelope-from jkh@winston.freebsd.org)
To: Alex Rousskov <rousskov@measurement-factory.com>
Cc: Jonathan Lemon <jlemon@flugsvamp.com>, freebsd-net@FreeBSD.ORG
Subject: Re: funding TCP stack rewrite 
In-Reply-To: Message from Alex Rousskov <rousskov@measurement-factory.com> 
   of "Fri, 30 Nov 2001 10:27:04 MST." <Pine.BSF.4.10.10111301012590.7584-100000@measurement-factory.com> 
Date: Fri, 30 Nov 2001 12:09:20 -0800
Message-ID: <2047.1007150960@winston.freebsd.org>
From: Jordan Hubbard <jkh@winston.freebsd.org>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

> Will the dedicated work of the said guru get a high priority as far as
> review and commit steps are concerned? A public semi-formal commitment
> or encouragement from FreeBSD core group may be in order to raise
> support from the community. Otherwise, folks may worry that these big
> changes, once implemented, will get stuck in the commit queue forever.

I think it's an absolutely terrible idea, frankly.

One of the areas most ignored by engineers when contemplating paid
development is the management aspect - e.g. we as engineers would all
like to believe that we're personally motivated and focused enough to
accurately size a job, set to work on it and complete it on time
without anybody poking us or running interference between us and the
"customer" (in this case, all the users/developers with strong views
on what a "TCP stack rewrite" should mean).  In reality, all of these
things generally trip engineers up and seriously endanger the projects
they're working on without others to take on those "meta engineering"
tasks so that the actual engineers can focus on hacking code and
nothing else.

So you'd need to add managers to the mix, both to work on nailing down
just what the heck is being committed to and how much it will cost and
then managing the milestones so that it actually arrives on time and
within the budget.  That adds even more expense to the problem and
would also start reminding various FreeBSD folks too much of Real Work,
one of the benefits of working on FreeBSD being that you don't have
to contend with engineering managers. :)

If someone has a re-written TCP/IP stack to present to the user
community and some arguments as to why it should replace the current
one, let them approach it that way.  If several people have re-written
TCP/IP stacks, let's take the darwinistic approach to figuring out
which one is best.  If nobody has a re-written TCP/IP stack but thinks
a pile of money would help them write one then they're probably better
off going to work for some company which does that and not trying to
do this purely in the open source space.

- Jordan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 12:32:25 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172])
	by hub.freebsd.org (Postfix) with ESMTP id 60DCF37B416
	for <net@FreeBSD.ORG>; Fri, 30 Nov 2001 12:32:23 -0800 (PST)
Received: from milk.yahoo.com (milk.yahoo.com [216.145.52.137])
	by mrout2.yahoo.com (8.11.6/8.11.6/y.out) with ESMTP id fAUKWHu14184;
	Fri, 30 Nov 2001 12:32:17 -0800 (PST)
Received: (from root@localhost)
	by milk.yahoo.com (8.11.0/8.11.0) id fAUKWHg70995;
	Fri, 30 Nov 2001 12:32:17 -0800 (PST)
	(envelope-from jayanth)
Date: Fri, 30 Nov 2001 12:32:17 -0800
From: jayanth <jayanth@yahoo-inc.com>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: Jonathan Lemon <jlemon@flugsvamp.com>, net@FreeBSD.ORG
Subject: Re: TCP anomalies (was Re: FreeBSD performing worse than Linux?)
Message-ID: <20011130123217.A70081@yahoo-inc.com>
References: <local.mail.freebsd-net/20011128102241.6887B380A@overcee.netplex.com.au> <local.mail.freebsd-net/20011128112006.195983808@overcee.netplex.com.au> <local.mail.freebsd-net/20011129105321.C74413@monorchid.lemis.com> <local.mail.freebsd-net/200111290113.fAT1DnH04474@khavrinen.lcs.mit.edu> <local.mail.freebsd-net/200111300518.fAU5IXx11078@c527597-a.cstvl1.sfba.home.com> <200111300647.fAU6l9K60404@prism.flugsvamp.com> <200111301758.fAUHwSP28351@khavrinen.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <200111301758.fAUHwSP28351@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Fri, Nov 30, 2001 at 12:58:28PM -0500
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Garrett,

Can you run these tests again with rfc1323 off ?

jayanth

Garrett Wollman (wollman@khavrinen.lcs.mit.edu) wrote:
> <<On Fri, 30 Nov 2001 00:47:09 -0600 (CST), Jonathan Lemon <jlemon@flugsvamp.com> said:
> 
> [Quoting Bruce Mah:]
> 
> >> happens.  In *most* cases, the receiver somehow gets the missing data
> >> because you can later see it acking later sequence numbers.  The first
> >> place I saw this was at :41.504152.
> 
> Those are not duplicate acks because the window is still getting updated.
> 
> >> Another place to look is the large number of consecutive dupacks
> >> starting around :41.978767.  I don't know what's happening here, but
> >> after a long time (about a second?!?) the sender finally gives up and
> >> sends the receiver what it wants.
> 
> > Yes, I think that area (I was looking at it too) provides a fairly
> > good illustration that fast retransmits are broken.  The transmit 
> > at 14:01:42.969338 appears to be the retransmit timer finally kicking in.
> 
> Yes, that's the conclusion Tim Shepard and I came to as well.
> 
> -GAWollman
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
> 
> 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 12:40:19 2001
Delivered-To: freebsd-net@freebsd.org
Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9])
	by hub.freebsd.org (Postfix) with ESMTP id 0F2F137B41F
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 12:40:14 -0800 (PST)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.11.0/8.11.0) id fAUKb7487492;
	Fri, 30 Nov 2001 14:37:07 -0600 (CST)
	(envelope-from jlemon)
Date: Fri, 30 Nov 2001 14:37:07 -0600
From: Jonathan Lemon <jlemon@flugsvamp.com>
To: Jordan Hubbard <jkh@winston.freebsd.org>
Cc: Alex Rousskov <rousskov@measurement-factory.com>,
	Jonathan Lemon <jlemon@flugsvamp.com>, freebsd-net@FreeBSD.ORG
Subject: Re: funding TCP stack rewrite
Message-ID: <20011130143707.E75389@prism.flugsvamp.com>
References: <rousskov@measurement-factory.com> <2047.1007150960@winston.freebsd.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <2047.1007150960@winston.freebsd.org>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

On Fri, Nov 30, 2001 at 12:09:20PM -0800, Jordan Hubbard wrote:
> > Will the dedicated work of the said guru get a high priority as far as
> > review and commit steps are concerned? A public semi-formal commitment
> > or encouragement from FreeBSD core group may be in order to raise
> > support from the community. Otherwise, folks may worry that these big
> > changes, once implemented, will get stuck in the commit queue forever.
> 
> I think it's an absolutely terrible idea, frankly.

 [ sweeping generalizations omitted ]

An open ended request of "rewrite the stack!" is certainly bound to
fail.  However, a carefully targeted one to add specific, well-defined
features within a fixed timeline is quite feasible, depending on the
the engineers involved.
-- 
Jonathan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 12:41:21 2001
Delivered-To: freebsd-net@freebsd.org
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP id 14AB937B444
	for <net@FreeBSD.ORG>; Fri, 30 Nov 2001 12:41:01 -0800 (PST)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id fAUKeww30283;
	Fri, 30 Nov 2001 15:40:58 -0500 (EST)
	(envelope-from wollman)
Date: Fri, 30 Nov 2001 15:40:58 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200111302040.fAUKeww30283@khavrinen.lcs.mit.edu>
To: jayanth <jayanth@yahoo-inc.com>
Cc: net@FreeBSD.ORG
Subject: Re: TCP anomalies (was Re: FreeBSD performing worse than Linux?)
In-Reply-To: <20011130123217.A70081@yahoo-inc.com>
References: <local.mail.freebsd-net/20011128102241.6887B380A@overcee.netplex.com.au>
	<local.mail.freebsd-net/20011128112006.195983808@overcee.netplex.com.au>
	<local.mail.freebsd-net/20011129105321.C74413@monorchid.lemis.com>
	<local.mail.freebsd-net/200111290113.fAT1DnH04474@khavrinen.lcs.mit.edu>
	<local.mail.freebsd-net/200111300518.fAU5IXx11078@c527597-a.cstvl1.sfba.home.com>
	<200111300647.fAU6l9K60404@prism.flugsvamp.com>
	<200111301758.fAUHwSP28351@khavrinen.lcs.mit.edu>
	<20011130123217.A70081@yahoo-inc.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

<<On Fri, 30 Nov 2001 12:32:17 -0800, jayanth <jayanth@yahoo-inc.com> said:

> Can you run these tests again with rfc1323 off ?

Not any time soon.

-GAWollman


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 12:55: 5 2001
Delivered-To: freebsd-net@freebsd.org
Received: from elvis.mu.org (elvis.mu.org [216.33.66.196])
	by hub.freebsd.org (Postfix) with ESMTP id F1B7637B41C
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 12:55:00 -0800 (PST)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id 7311A81D06; Fri, 30 Nov 2001 14:54:55 -0600 (CST)
Date: Fri, 30 Nov 2001 14:54:55 -0600
From: Alfred Perlstein <bright@mu.org>
To: Jonathan Lemon <jlemon@flugsvamp.com>
Cc: Jordan Hubbard <jkh@winston.freebsd.org>,
	Alex Rousskov <rousskov@measurement-factory.com>,
	freebsd-net@FreeBSD.ORG
Subject: Re: funding TCP stack rewrite
Message-ID: <20011130145455.K46769@elvis.mu.org>
References: <rousskov@measurement-factory.com> <2047.1007150960@winston.freebsd.org> <20011130143707.E75389@prism.flugsvamp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20011130143707.E75389@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Fri, Nov 30, 2001 at 02:37:07PM -0600
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

* Jonathan Lemon <jlemon@flugsvamp.com> [011130 14:40] wrote:
> On Fri, Nov 30, 2001 at 12:09:20PM -0800, Jordan Hubbard wrote:
> > > Will the dedicated work of the said guru get a high priority as far as
> > > review and commit steps are concerned? A public semi-formal commitment
> > > or encouragement from FreeBSD core group may be in order to raise
> > > support from the community. Otherwise, folks may worry that these big
> > > changes, once implemented, will get stuck in the commit queue forever.
> > 
> > I think it's an absolutely terrible idea, frankly.
> 
>  [ sweeping generalizations omitted ]
> 
> An open ended request of "rewrite the stack!" is certainly bound to
> fail.  However, a carefully targeted one to add specific, well-defined
> features within a fixed timeline is quite feasible, depending on the
> the engineers involved.

I don't think a rewrite is ever going to be much of a good idea,
a restructuring might, meaning that fixing up all the layering
and making it more flat like Van Jacobson suggested (and Linux
implemented in one of their stack of the year projects) might
gain us performance.

A rewrite is only necessary when you can't solve a particular
semantic or performance problem without a major kludge.  Right
now we don't have any of those problems and a rewrite would
mearly throw away years apon years of testing along with making
our implementation incompatible with the texts out there which
would raise the bar for anyone attempting to base their code on
ours.

I agree that a rewrite without a clearly stated goal is almost always
just a euphamism for "i didn't like the variable names and indenting
of the old system" or "i want my name on the top of each file in
the sys/netinet directory".

Lastly, I wish we just drop it until we come up with a solid reason,
all this is doing is second guessing stuff that has worked for
years.  This code has existed in mostly working order for half of
my lifetime I really don't feel much anyone has the skills necessary
to duplicate the equivelant of several hundered man years of
developement in just a couple of months no matter how highly they
think of themselves.

In summary, I completely agree with Jonathan and all the others
opposing such a motion.  Your time would be much better spent
analyzing the current issues and seeking optimizations to completment
the current design.

-- 
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
                           http://www.morons.org/rants/gpl-harmful.php3

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 13: 4:26 2001
Delivered-To: freebsd-net@freebsd.org
Received: from pcslink.com (pcslink.com [206.43.160.1])
	by hub.freebsd.org (Postfix) with ESMTP id 918EF37B416
	for <freebsd-net@freebsd.org>; Fri, 30 Nov 2001 13:04:12 -0800 (PST)
Received: (from ryan@localhost)
	by pcslink.com (8.9.3/8.9.2) id OAA33617
	for freebsd-net@freebsd.org; Fri, 30 Nov 2001 14:04:12 -0700 (MST)
	(envelope-from ryan)
Date: Fri, 30 Nov 2001 11:04:12 -1000
From: Ryan Mooney <ryan@pcslink.com>
To: freebsd-net@freebsd.org
Subject: Capturing packets w/ bad CRC's?
Message-ID: <20011130110412.D2514@pcslink.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


Hello,

I'm trying to write an ethernet level network tester to test a wireless
gigabit product the company I'm working for has developed.  I need
to be able to get packets off a Gig-E interface that have bad CRC
checksums so I can see how badly mangled they are.  I've tried using
pcap and ng_ether int: lowerboth of which are giving me just the "good" 
packets.

Right now they are being discarded somewhere below the bpf interface.
I'm not sure where, I've read through a bunch of the *if* code, but
I don't see it there.  I did see some stuff in the 100Mb cards, but
thats not really going to work here, since I'm pushing ~600Mb/s
on the box doing the packet generation..

I'm using ti and sk cards (either/or...)

If anyone knows how I can get the bad packets to examine them, I'd much
appreciate it.

Thanks.

-- 
>-=-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-=-<
Ryan Mooney          				 ryan@pcslink.com 
<-=-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-=-> 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 13:15:35 2001
Delivered-To: freebsd-net@freebsd.org
Received: from ardbeg.meer.net (ardbeg.meer.net [209.157.152.23])
	by hub.freebsd.org (Postfix) with ESMTP id 560F937B41A
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 13:15:24 -0800 (PST)
Received: from meer.meer.net (mail.meer.net [209.157.152.14])
	by ardbeg.meer.net (8.11.3/8.11.3) with ESMTP id fAULFNp18981;
	Fri, 30 Nov 2001 13:15:23 -0800 (PST)
Received: from neville-neil.com ([209.157.133.226])
	by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id NAA3026638;
	Fri, 30 Nov 2001 13:14:51 -0800 (PST)
Message-Id: <200111302114.NAA3026638@meer.meer.net>
X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4
To: Alfred Perlstein <bright@mu.org>
Cc: Jonathan Lemon <jlemon@flugsvamp.com>,
	Jordan Hubbard <jkh@winston.freebsd.org>,
	Alex Rousskov <rousskov@measurement-factory.com>,
	freebsd-net@FreeBSD.ORG
Subject: Re: funding TCP stack rewrite 
In-Reply-To: Message from Alfred Perlstein <bright@mu.org> 
   of "Fri, 30 Nov 2001 14:54:55 CST." <20011130145455.K46769@elvis.mu.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 30 Nov 2001 13:14:51 -0800
From: "George V. Neville-Neil" <gnn@neville-neil.com>
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

> I don't think a rewrite is ever going to be much of a good idea,
> a restructuring might, meaning that fixing up all the layering
> and making it more flat like Van Jacobson suggested (and Linux
> implemented in one of their stack of the year projects) might
> gain us performance.

I would disagree, and I'll say why in a second.

> A rewrite is only necessary when you can't solve a particular
> semantic or performance problem without a major kludge.  Right
> now we don't have any of those problems and a rewrite would
> mearly throw away years apon years of testing along with making
> our implementation incompatible with the texts out there which
> would raise the bar for anyone attempting to base their code on
> ours.

Please tell me how to solve the following problems with the current
stack:

1) Adding a new bit of processing in the input side of IP
WITHOUT modifying ip_input.  The solution should be generic.

2) Running the stack in a true multi-threaded and multi-instance
environment but still within the kernel.  (This is a project currently
under way in several places, all commercial.)

3) Run the same stack in the kernel and in user space so that it can
more easily be debugged.

I submit that all of these require a rewrite and if done the resulting stack
could compete quite well in the non-core router market and actually
create new markets by bringing the barrier to creating incremental
changes to the system down.

> I agree that a rewrite without a clearly stated goal is almost always
> just a euphamism for "i didn't like the variable names and indenting
> of the old system" or "i want my name on the top of each file in
> the sys/netinet directory".

Agreed.

> Lastly, I wish we just drop it until we come up with a solid reason,
> all this is doing is second guessing stuff that has worked for
> years.  This code has existed in mostly working order for half of
> my lifetime I really don't feel much anyone has the skills necessary
> to duplicate the equivelant of several hundered man years of
> developement in just a couple of months no matter how highly they
> think of themselves.
> 

There may not be a SINGLE solid reason, but it must be an issue
otherwise it would never have come up.

I think it's a good idea, if done carefully.  The original TCP/IP stack
and the changes since then were created in a different software
era.  I'm not saying to build the whole thing again in Java but I am
saying that there comes a time when you have to stop putting on 
band aids and actually have the bone reset.

Later,
George



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 13:19:18 2001
Delivered-To: freebsd-net@freebsd.org
Received: from fledge.watson.org (fledge.watson.org [204.156.12.50])
	by hub.freebsd.org (Postfix) with ESMTP id 287B737B417
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 13:19:16 -0800 (PST)
Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3])
	by fledge.watson.org (8.11.6/8.11.5) with SMTP id fAULIui91678;
	Fri, 30 Nov 2001 16:18:56 -0500 (EST)
	(envelope-from robert@fledge.watson.org)
Date: Fri, 30 Nov 2001 16:18:55 -0500 (EST)
From: Robert Watson <rwatson@FreeBSD.ORG>
X-Sender: robert@fledge.watson.org
To: Bill Fumerola <billf@mu.org>
Cc: Alex Rousskov <rousskov@measurement-factory.com>,
	freebsd-net@FreeBSD.ORG
Subject: Re: funding TCP stack rewrite
In-Reply-To: <20011130120008.G32521@elvis.mu.org>
Message-ID: <Pine.NEB.3.96L.1011130161307.88343D-100000@fledge.watson.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


On Fri, 30 Nov 2001, Bill Fumerola wrote:

> core has nothing to do with preventing or allowing completed work to
> enter the tree. the quality of the code does. presumably, the people
> that the foundation (or NAI or whoever) contracts to do FreeBSD work are
> of high calibur and that isn't a problem. 

For reference, the NAI Labs model has been to identify specific areas of
the stack where we felt further work was needed in order to meet our,
DARPA's, and general US .mil needs, and to contract out to an
appropriately qualified developer to do implementation (in the case of the
network stack, Jonathan Lemon).  Right now, I don't think we have any
interest in funding a complete rewrite of the network stack, as there is
really not much motivation to.  An evolutionary model means that you can
address the specific needs at hand without investing rediculous amounts of
money in a potential failure :-).

The main reasons I might might be interested in a major rewrite or
restructuring would be to see better support for threading, better support
for extensibility, or better resistance to attack.  However, it seems to
me that at least in the short term, this work can be done in the context
of the current stack without starting from scratch, which seems to be what
is being proposed.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org      NAI Labs, Safeport Network Services



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 13:22:31 2001
Delivered-To: freebsd-net@freebsd.org
Received: from elvis.mu.org (elvis.mu.org [216.33.66.196])
	by hub.freebsd.org (Postfix) with ESMTP id 6608637B417
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 13:22:29 -0800 (PST)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id 0478281D04; Fri, 30 Nov 2001 15:22:29 -0600 (CST)
Date: Fri, 30 Nov 2001 15:22:28 -0600
From: Alfred Perlstein <bright@mu.org>
To: "George V. Neville-Neil" <gnn@neville-neil.com>
Cc: Jonathan Lemon <jlemon@flugsvamp.com>,
	Jordan Hubbard <jkh@winston.freebsd.org>,
	Alex Rousskov <rousskov@measurement-factory.com>,
	freebsd-net@FreeBSD.ORG
Subject: Re: funding TCP stack rewrite
Message-ID: <20011130152228.M46769@elvis.mu.org>
References: <bright@mu.org> <200111302114.NAA3026638@meer.meer.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200111302114.NAA3026638@meer.meer.net>; from gnn@neville-neil.com on Fri, Nov 30, 2001 at 01:14:51PM -0800
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

* George V. Neville-Neil <gnn@neville-neil.com> [011130 15:15] wrote:
> > I don't think a rewrite is ever going to be much of a good idea,
> > a restructuring might, meaning that fixing up all the layering
> > and making it more flat like Van Jacobson suggested (and Linux
> > implemented in one of their stack of the year projects) might
> > gain us performance.
> 
> I would disagree, and I'll say why in a second.

You're allowed to disagree, it's just not as productive as actually
dictating design.  If you were to prosose how this rewrite should/would
be done, not just the goals then  people would pick various pieces
and do them, but just stating goals without the means to achieve
those goals isn't very productive.

-Alfred

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 13:34:27 2001
Delivered-To: freebsd-net@freebsd.org
Received: from herbelot.dyndns.org (d211.dhcp212-26.cybercable.fr [212.198.26.211])
	by hub.freebsd.org (Postfix) with ESMTP id 9227537B417
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 13:34:24 -0800 (PST)
Received: from herbelot.com (multi.herbelot.nom [192.168.1.2])
	by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id XAA75067;
	Fri, 30 Nov 2001 23:11:21 +0100 (CET)
	(envelope-from thierry@herbelot.com)
Message-ID: <3C07FB4B.E7D10D4E@herbelot.com>
Date: Fri, 30 Nov 2001 22:34:03 +0100
From: Thierry Herbelot <thierry@herbelot.com>
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.2 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Ryan Mooney <ryan@pcslink.com>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: Capturing packets w/ bad CRC's?
References: <20011130110412.D2514@pcslink.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Ryan Mooney wrote:
> 
> Hello,
> 
> I'm trying to write an ethernet level network tester to test a wireless
> gigabit product the company I'm working for has developed.  I need
> to be able to get packets off a Gig-E interface that have bad CRC
> checksums so I can see how badly mangled they are.  I've tried using
> pcap and ng_ether int: lowerboth of which are giving me just the "good"
> packets.
> 
> Right now they are being discarded somewhere below the bpf interface.
> I'm not sure where, I've read through a bunch of the *if* code, but

they are discarded by the Ethernet chipset itself, and this the reason
why you don't see any source code for managing bad frames.

[SNIP]
> 
> If anyone knows how I can get the bad packets to examine them, I'd much
> appreciate it.

typically by tweaking the chipset, if at all possible, in order to see
also bea frames

-- 
Thierry Herbelot

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Fri Nov 30 14: 8:19 2001
Delivered-To: freebsd-net@freebsd.org
Received: from freebie.atkielski.com (ASt-Lambert-101-2-1-14.abo.wanadoo.fr [193.251.59.14])
	by hub.freebsd.org (Postfix) with ESMTP id 62E2237B416
	for <freebsd-net@FreeBSD.ORG>; Fri, 30 Nov 2001 14:08:16 -0800 (PST)
Received: from contactdish (win.atkielski.com [10.0.0.10])
	by freebie.atkielski.com (8.11.3/8.11.3) with SMTP id fAUM89x09075;
	Fri, 30 Nov 2001 23:08:09 +0100 (CET)
	(envelope-from anthony@freebie.atkielski.com)
Message-ID: <004301c179eb$7f564440$0a00000a@atkielski.com>
From: "Anthony Atkielski" <anthony@freebie.atkielski.com>
To: "George V. Neville-Neil" <gnn@neville-neil.com>
Cc: <freebsd-net@FreeBSD.ORG>
References: <200111301756.JAA2847316@meer.meer.net>
Subject: Re: funding TCP stack rewrite 
Date: Fri, 30 Nov 2001 23:08:02 +0100
Organization: Anthony's Home Page (development site)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

George writes:

> What is the exact set of goals to be achieved
> by the rewrite?

It will give developers some cool code to write.  After all, there isn't any
other reason to rewrite something if it already works.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message


From owner-freebsd-net  Sat Dec  1 13:26:32 2001
Delivered-To: freebsd-net@freebsd.org
Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130])
	by hub.freebsd.org (Postfix) with ESMTP
	id 0D57937B417; Sat,  1 Dec 2001 13:26:26 -0800 (PST)
Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13])
	by wall.polstra.com (8.11.3/8.11.3) with ESMTP id fB1LQP086355;
	Sat, 1 Dec 2001 13:26:25 -0800 (PST)
	(envelope-from jdp@wall.polstra.com)
Received: (from jdp@localhost)
	by vashon.polstra.com (8.11.6/8.11.0) id fB1LQOu79138;
	Sat, 1 Dec 2001 13:26:24 -0800 (PST)
	(envelope-from jdp)
Date: Sat, 1 Dec 2001 13:26:24 -0800 (PST)
Message-Id: <200112012126.fB1LQOu79138@vashon.polstra.com>
To: net@freebsd.org
From: John Polstra <jdp@polstra.com>
Cc: billf@mu.org
Subject: Re: funding TCP stack rewrite
In-Reply-To: <20011130120008.G32521@elvis.mu.org>
References: <20011130103652.Z75389@prism.flugsvamp.com> <Pine.BSF.4.10.10111301012590.7584-100000@measurement-factory.com> <20011130120008.G32521@elvis.mu.org>
Organization: Polstra & Co., Seattle, WA
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

In article <20011130120008.G32521@elvis.mu.org>, Bill Fumerola
<billf@mu.org> wrote:
> the freebsd foundation is supposed to be an a not-for-profit
> organization that (amongst other things) delegates donated money to
> developers for this kind of work. at their current speed, they will
> be ready to provide such a service in the year 2018.

Bill, it's a real shame you felt the need to fire off one of your
uninformed potshots like this.

The FreeBSD Foundation has in fact been working very actively on
finalizing the license with Sun Microsystems for a FreeBSD version of
the Java Development Kit.  This involves lawyers on both sides, and a
lot of back and forth.  The folks at Sun have been very reasonable,
but they need to protect Sun's interests just as we need to protect
the FreeBSD project's interests.  Hence it takes some time to get the
terms of the license just right as far as both sides are concerned.
We think we are getting pretty close to having it all wrapped up.

We have deliberately held back from asking for more donations in
the meantime, because we'd like to be able to show the community
that we've accomplished something valuable for the project with the
contributions we've already received.

We chose the JDK license as our first project because it is
something that will benefit a lot of FreeBSD users and it requires
legally-recognized entities (which the Foundation is) as parties to
the license agreement.  We obviously don't have the resources to
tackle a dozen projects at once yet, so we are focusing our efforts.
You can rest assured that, with the support of the FreeBSD community,
we will be funding worthwhile development efforts in the future too.

John Polstra
Vice President
The FreeBSD Foundation

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message