From owner-freebsd-net Sun May 12 15:26:58 2002
Delivered-To: freebsd-net@freebsd.org
Received: from spontoon.braithwaite.net (spontoon.braithwaite.net [207.135.122.130])
by hub.freebsd.org (Postfix) with ESMTP id ADE5137B403
for <freebsd-net@FreeBSD.ORG>; Sun, 12 May 2002 15:26:54 -0700 (PDT)
Received: from dogberry.braithwaite.net (foo82.dsl.alink.net [207.135.112.82])
(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
(Client CN "dogberry.braithwaite.net", Issuer "Braithwaite's Certifying Authority" (verified OK))
by spontoon.braithwaite.net (Postfix) with ESMTP
id 557FE7DF01; Sun, 12 May 2002 15:26:53 -0700 (PDT)
Received: by dogberry.braithwaite.net (Postfix, from userid 1001)
id 2534E924F; Sun, 12 May 2002 15:26:51 -0700 (PDT)
From: Matthew Braithwaite <matt@braithwaite.net>
To: Matthew Braithwaite <matt@braithwaite.net>
Cc: Archie Cobbs <archie@dellroad.org>, dgilbert@velocet.ca,
freebsd-net@FreeBSD.ORG
Subject: Re: mpd-netgraph problem. (SOLVED)
References: <200205092357.g49Nvb204332@arch20m.dellroad.org>
<86bsbo6696.fsf@limekiller.braithwaite.net>
Date: 12 May 2002 15:26:51 -0700
In-Reply-To: <86bsbo6696.fsf@limekiller.braithwaite.net>
Message-ID: <86r8khypck.fsf_-_@limekiller.braithwaite.net>
Lines: 39
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
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
I solved my problem, but I need to retract a few things I said about
it earlier:
1. Although I was told (by the folks who operate my VPN server) that I
had to negotiate 128-bit encryption, I've succeeded with 40-bit
encryption, using the ``LAN Manager'' hash.
2. Therefore, this whole business about MSCHAPv1/MSCHAPv2 is totally
irrelevant, since the LAN Manager hash depends only on my password.
3. I have an alternate method of getting into my private network; I
used that to ping the address I was assigned by the VPN server.
When I did this I noticed that mpd was able to decrypt those pings
successfully. In other words, only my transmit direction was
broken: I could receive MPPE just fine. This test may be very
useful for others who encounter the same symptoms, since the
symptoms seem to have many possible causes.
Anyway, the solution was to change the following function in ng_ppp.c
(note, part of the kernel, not mpd) by removing the marked lines:
static struct mbuf *
ng_ppp_addproto(struct mbuf *m, int proto, int compOK)
{
- if (compOK && PROT_COMPRESSABLE(proto)) {
- u_char pbyte = (u_char)proto;
-
- return ng_ppp_prepend(m, &pbyte, 1);
- } else {
u_int16_t pword = htons((u_int16_t)proto);
return ng_ppp_prepend(m, &pword, 2);
- }
}
If I had to make a wild-ass guess about why this works, it'd be that
mpd supports MPPE but doesn't know how to do MPPC compression, so the
peer isn't expecting the protocol field to be compressed. I don't
care; it works now. :-)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Mon May 13 4:14:32 2002
Delivered-To: freebsd-net@freebsd.org
Received: from www.example.org (dhcp-nic-val-26-84.cisco.com [64.103.26.84])
by hub.freebsd.org (Postfix) with SMTP id 4061237B400
for <freebsd-net@freebsd.org>; Mon, 13 May 2002 04:14:23 -0700 (PDT)
Received: (qmail 24199 invoked by uid 1000); 13 May 2002 11:14:19 -0000
Message-ID: <20020513111419.24198.qmail@cobweb.example.org>
Date: Mon, 13 May 2002 13:14:19 +0200
From: Marco Molteni <molter@tin.it>
To: freebsd-net@freebsd.org
Subject: [OT] symbology for network elements?
X-Mailer: Sylpheed version 0.7.5 (GTK+ 1.2.10; i386-portbld-freebsd4.5)
Mime-Version: 1.0
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
Hi all,
sorry for the off-topic question. Suggestions for a better place to ask
are welcome.
Are you aware of any "standard" network symbology? By this I mean having
a graphical symbol for each network component, in the same spirit of the
symbols of the various electronics components.
If you look at RFCs and IDs each uses its own symbology to mean node,
router, host, link, tunnel and so on.
I would be interested in both ASCII art and real graphical symbols.
thanks
marco
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue May 14 5:30:57 2002
Delivered-To: freebsd-net@freebsd.org
Received: from atropos.snu.ac.kr (atropos.snu.ac.kr [147.46.106.37])
by hub.freebsd.org (Postfix) with ESMTP id 06E3A37B400
for <freebsd-net@freebsd.org>; Tue, 14 May 2002 05:30:49 -0700 (PDT)
Received: (from redjade@localhost)
by atropos.snu.ac.kr (8.11.6/8.11.6) id g4ECUYB07778;
Tue, 14 May 2002 21:30:34 +0900 (KST)
Date: Tue, 14 May 2002 21:30:34 +0900
From: Kyunghwan Kim <redjade@atropos.snu.ac.kr>
To: freebsd-net@freebsd.org
Subject: Bandwidth reservation?
Message-ID: <20020514213034.A7529@atropos.snu.ac.kr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
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've used dummynet bridge for bandwidth manangement in my company.
Dummynet provides bandwidth management service by limiting specified
traffic. Maybe limiting ability of dummynet is derived from its
origin of network delay simulator.
But I really want to use (or implement if I can) is bandwidth reservation.
(I'm not sure it is appropriate term for that.)
Assume that bandwidth is reserved for some traffic. If there is
no traffic in specified traffic, then other kinds of traffic should
be able to use the bandwidth. When the specified traffic occurs,
reserved bandwidth should be guaranteed. In other words, bandwidth
guarantee by reserving not by limiting.
How should dummynet be modified to meet the need?
If there is related works or papers, please let me know.
--
Kyunghwan Kim
redjade@atropos.snu.ac.kr
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue May 14 8:35:26 2002
Delivered-To: freebsd-net@freebsd.org
Received: from flint.asdis.com (flint.asdis.com [212.222.145.99])
by hub.freebsd.org (Postfix) with ESMTP id 280B637B406
for <freebsd-net@freebsd.org>; Tue, 14 May 2002 08:35:23 -0700 (PDT)
Received: from sarek.itp.asdis.de ([10.63.192.115])
by flint.asdis.com with esmtp (Exim 3.22 #1)
id 177eKg-000DbR-00
for freebsd-net@freebsd.org; Tue, 14 May 2002 17:35:22 +0200
Received: from castillo.w2k.asdis.de ([10.63.193.193] helo=asdis.de)
by sarek.itp.asdis.de with esmtp (Exim 3.33 #1)
id 177drj-000514-00
for freebsd-net@freebsd.org; Tue, 14 May 2002 17:05:27 +0200
Message-ID: <3CE12EB9.8030508@asdis.de>
Date: Tue, 14 May 2002 17:35:21 +0200
From: Matthias Kranz <mkranz@asdis.de>
Organization: ASDIS Software AG
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: de-DE
MIME-Version: 1.0
To: freebsd-net@freebsd.org
Subject: Enabling Directed Broadcasts
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
Hi!
We try to start a PC in a different subnet through using a
WakeOnLan. The packet is addressed to the broadcast address of the
client PC net. The FreeBSD router in between does not forward this
packet. I read that FreeBSD is not supporting directed broadcasts
since 2.2.5. Is there any parameter for chanching this behaviour?
Any help is very much appreciated.
Thank you,
Matthias
--
matthias kranz____________________phone: +49 30 20631418
consultant________________________mobile: +49 172 3843414
asdis software ag_________________fax: +49 30 20631199
neue gruenstrasse 25______________mailto: mkranz@asdis.de
10179 berlin-mitte____________________http://www.asdis.de
http://www.stadtplandienst.de/query;ORT=b;LL=13.406735x52.512448;GR=3
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue May 14 16:50:36 2002
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 26D3537B407
for <net@freebsd.org>; Tue, 14 May 2002 16:50:30 -0700 (PDT)
Received: from isi.edu (2vdr11luai8pqlgo@hbo.isi.edu [128.9.160.75])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4ENoTF06342;
Tue, 14 May 2002 16:50:29 -0700 (PDT)
Message-ID: <3CE1A2C0.8050201@isi.edu>
Date: Tue, 14 May 2002 16:50:24 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: net@freebsd.org, snap-users@kame.net
Subject: tun device & IPv6
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070805020908090809060708"
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 cryptographically signed message in MIME format.
--------------ms070805020908090809060708
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
could someone with more knowledge of the tun device please take a look
at the code around line 387 in net/if_tun.c? It looks like tunoutput()
drops all packets here that aren't of the AF_INET family - most notably,
it drops IPv6 packets.
We hacked around this with the simple fix below, but I'm not sure if
there are any drawbacks...
--- if_tun.c.old Tue May 14 15:40:30 2002
+++ if_tun.c Tue May 14 15:48:15 2002
@@ -384,7 +384,7 @@
*(u_int32_t *)m0->m_data = htonl(dst->sa_family);
} else {
#ifdef INET
- if (dst->sa_family != AF_INET)
+ if (dst->sa_family != AF_INET && dst->sa_family != AF_INET6)
#endif
{
m_freem(m0);
Thanks,
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms070805020908090809060708
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC
ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP
MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc
MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1
1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU
SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB
BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud
EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT
vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d
6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC
HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD
VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV
BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq
hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL
ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA
jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv
0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy
dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E
AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ
d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX
frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB
AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo
MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl
bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE
AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/
+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC
UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx
GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P
BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE
H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX
tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC
AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2
aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG
BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTAyMDUxNDIzNTAyNFowIwYJKoZIhvcNAQkEMRYEFF7ad57HcBITqFLm3C/Dc9HkE7HdMFIG
CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB
BQAEgYBSxh1xBp4xjrNuMW2WYR/jtI8xJdf0iO/ucaJHVes+IiYPuNuRwQWerMNbjq3uh95M
IXZpYrM3Texo0DWM/yVtAi5hWkn0TjDeAQQs21BlicekrAYQ7X0Dbc0THP7nlGjzk5YCsE+0
hcz/AYfats0++DKiun1jh0uoGcWvLju1awAAAAAAAA==
--------------ms070805020908090809060708--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue May 14 17: 4:50 2002
Delivered-To: freebsd-net@freebsd.org
Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97])
by hub.freebsd.org (Postfix) with ESMTP id 6C22F37B403
for <net@freebsd.org>; Tue, 14 May 2002 17:04:48 -0700 (PDT)
Received: from itojun.org (localhost [127.0.0.1])
by coconut.itojun.org (Postfix) with ESMTP
id 592D24B22; Wed, 15 May 2002 09:04:46 +0900 (JST)
To: snap-users@kame.net
Cc: net@freebsd.org
In-reply-to: larse's message of Tue, 14 May 2002 16:50:24 MST.
<3CE1A2C0.8050201@isi.edu>
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2
Subject: Re: tun device & IPv6
From: itojun@iijlab.net
Date: Wed, 15 May 2002 09:04:46 +0900
Message-ID: <29485.1021421086@itojun.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
>could someone with more knowledge of the tun device please take a look
>at the code around line 387 in net/if_tun.c? It looks like tunoutput()
>drops all packets here that aren't of the AF_INET family - most notably,
>it drops IPv6 packets.
just to make sure, which platform? from cc: it seems to be freebsd,
but which revision?
itojun
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue May 14 17:14:50 2002
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 1B97337B400
for <net@freebsd.org>; Tue, 14 May 2002 17:14:45 -0700 (PDT)
Received: from isi.edu (22d8k2oe1oeprqmn@hbo.isi.edu [128.9.160.75])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4F0C0F19935;
Tue, 14 May 2002 17:12:00 -0700 (PDT)
Message-ID: <3CE1A7CE.4070205@isi.edu>
Date: Tue, 14 May 2002 17:11:58 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: snap-users@kame.net
Cc: net@freebsd.org
Subject: Re: (KAME-snap 6382) Re: tun device & IPv6
References: <29485.1021421086@itojun.org>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010205020100070405080300"
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 cryptographically signed message in MIME format.
--------------ms010205020100070405080300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
itojun@iijlab.net wrote:
>>could someone with more knowledge of the tun device please take a look
>>at the code around line 387 in net/if_tun.c? It looks like tunoutput()
>>drops all packets here that aren't of the AF_INET family - most notably,
>>it drops IPv6 packets.
>
>
> just to make sure, which platform? from cc: it seems to be freebsd,
> but which revision?
Sorry, yes, FreeBSD-4.5, but from looking at the CVS tree, it also seems
to be present in -CURRENT still.
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms010205020100070405080300
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC
ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP
MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc
MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1
1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU
SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB
BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud
EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT
vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d
6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC
HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD
VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV
BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq
hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL
ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA
jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv
0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy
dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E
AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ
d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX
frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB
AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo
MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl
bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE
AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/
+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC
UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx
GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P
BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE
H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX
tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC
AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2
aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG
BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTAyMDUxNTAwMTIwMFowIwYJKoZIhvcNAQkEMRYEFM2o+7KjzEdsAFADE/MtYVh3RdvLMFIG
CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB
BQAEgYAdsLE7jHUhbCvYDF6Qm0pt1QNlp0TCpgsbAXc+7i0o/TagrvCFHZDImyUhjM2i6Ace
T0PbTCGYYHx6VEJqZuMJyR7lSHjaqDlRbI3qO+rwiKmYgEmG2NtKFHWOGxwtIeVDOUfqw/5O
5qTYI+CkH4mv5b8rfCWFGy8tE4sQbETqzAAAAAAAAA==
--------------ms010205020100070405080300--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue May 14 18:29: 4 2002
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 2091437B405
for <net@freebsd.org>; Tue, 14 May 2002 18:28:47 -0700 (PDT)
Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12])
by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F1SifK089637;
Wed, 15 May 2002 02:28:44 +0100 (BST)
(envelope-from brian@Awfulhak.org)
Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1])
by hak.lan.Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F1Sf20006584;
Wed, 15 May 2002 02:28:41 +0100 (BST)
(envelope-from brian@hak.lan.Awfulhak.org)
Message-Id: <200205150128.g4F1Sf20006584@hak.lan.Awfulhak.org>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: snap-users@kame.net
Cc: net@freebsd.org
Subject: Re: (KAME-snap 6381) tun device & IPv6
In-Reply-To: Message from Lars Eggert <larse@ISI.EDU>
of "Tue, 14 May 2002 16:50:24 PDT." <3CE1A2C0.8050201@isi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6579.1021426120.1@hak.lan.Awfulhak.org>
Date: Wed, 15 May 2002 02:28:41 +0100
From: Brian Somers <brian@Awfulhak.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
> Hi,
>
> could someone with more knowledge of the tun device please take a look
> at the code around line 387 in net/if_tun.c? It looks like tunoutput()
> drops all packets here that aren't of the AF_INET family - most notably,
> it drops IPv6 packets.
>
> We hacked around this with the simple fix below, but I'm not sure if
> there are any drawbacks...
>
> --- if_tun.c.old Tue May 14 15:40:30 2002
> +++ if_tun.c Tue May 14 15:48:15 2002
> @@ -384,7 +384,7 @@
> *(u_int32_t *)m0->m_data = htonl(dst->sa_family);
> } else {
> #ifdef INET
> - if (dst->sa_family != AF_INET)
> + if (dst->sa_family != AF_INET && dst->sa_family != AF_INET6)
> #endif
> {
> m_freem(m0);
>
> Thanks,
> Lars
> --
> Lars Eggert <larse@isi.edu> USC Information Sciences Institute
If you look at the larger picture....
if (tp->tun_flags & TUN_IFHEAD) {
/* Prepend the address family */
M_PREPEND(m0, 4, M_DONTWAIT);
/* if allocation failed drop packet */
if (m0 == NULL) {
ifp->if_iqdrops++;
ifp->if_oerrors++;
return (ENOBUFS);
} else
*(u_int32_t *)m0->m_data = htonl(dst->sa_family);
} else {
#ifdef INET
if (dst->sa_family != AF_INET)
#endif
{
m_freem(m0);
return (EAFNOSUPPORT);
}
}
The tun device, when given the TUNSIFHEAD ioctl, will prepend the
address family. If TUNSIFHEAD is turned off, it will drop non IPv4
packets.
This was done for backwards compatibility. To use IPv6 with tun, you
must use the TUNSIFHEAD ioctl and prepend/strip the address family on
the front of each packet (see bundle_Create() in
src/usr.sbin/ppp/bundle.c).
--
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 Tue May 14 18:48:34 2002
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 BD51237B406
for <net@freebsd.org>; Tue, 14 May 2002 18:48:22 -0700 (PDT)
Received: from isi.edu (cq3i3xw1q7oi0tqa@hbo.isi.edu [128.9.160.75])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4F1jeF07750;
Tue, 14 May 2002 18:45:40 -0700 (PDT)
Message-ID: <3CE1BDBC.4010609@isi.edu>
Date: Tue, 14 May 2002 18:45:32 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: snap-users@kame.net
Cc: net@freebsd.org
Subject: Re: (KAME-snap 6384) Re: tun device & IPv6
References: <200205150128.g4F1Sf20006584@hak.lan.Awfulhak.org>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010003040500070001040100"
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 cryptographically signed message in MIME format.
--------------ms010003040500070001040100
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Brian Somers wrote:
> The tun device, when given the TUNSIFHEAD ioctl, will prepend the
> address family. If TUNSIFHEAD is turned off, it will drop non IPv4
> packets.
>
> This was done for backwards compatibility. To use IPv6 with tun, you
> must use the TUNSIFHEAD ioctl and prepend/strip the address family on
> the front of each packet (see bundle_Create() in
> src/usr.sbin/ppp/bundle.c).
Ah, that makes sense. The tag is so the tun device knows who to toss the
packet to when it comes back from the process? Guess I'll have to patch
vtund, then...
Thanks,
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms010003040500070001040100
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC
ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP
MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc
MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1
1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU
SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB
BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud
EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT
vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d
6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC
HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD
VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV
BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq
hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL
ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA
jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv
0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy
dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E
AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ
d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX
frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB
AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo
MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl
bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE
AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/
+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC
UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx
GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P
BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE
H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX
tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC
AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2
aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG
BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTAyMDUxNTAxNDUzNVowIwYJKoZIhvcNAQkEMRYEFOFMvRedWga8Nz7wOdx4Bf5lgWJMMFIG
CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB
BQAEgYCsupp1bJna/E4Rm4uuJtKaLXmVrAxcqXOdmP9Af93T68KNdKM1U1NC7QOOZOuTxmum
54diYeUEEqi3PVnZBN4cusU/qSafLwdvBZ69Ds6KbGF7a8jcNCQ2otQSRr6Mr29G9XzGvFb1
iJtmOwGDFIVofdozppEx+yzWqhSHltEauQAAAAAAAA==
--------------ms010003040500070001040100--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Tue May 14 19:45:55 2002
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 BFC6337B406; Tue, 14 May 2002 19:45:48 -0700 (PDT)
Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12])
by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F2jdfK090241;
Wed, 15 May 2002 03:45:39 +0100 (BST)
(envelope-from brian@Awfulhak.org)
Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1])
by hak.lan.Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F2ja20007959;
Wed, 15 May 2002 03:45:36 +0100 (BST)
(envelope-from brian@hak.lan.Awfulhak.org)
Message-Id: <200205150245.g4F2ja20007959@hak.lan.Awfulhak.org>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: Baldur Gislason <baldur@foo.is>
Cc: Dan Protich <silveradmin@shell-box.com>,
freebsd-gnats-submit@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
Subject: Re: misc/37696: Virtual hosts broken
In-Reply-To: Message from Baldur Gislason <baldur@foo.is>
of "Fri, 03 May 2002 13:37:39 -0000." <20020503133856.9D6DD2744@tesla.foo.is>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 15 May 2002 03:45:36 +0100
From: Brian Somers <brian@Awfulhak.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
> Problem exists between keyboard and chair.
> The reason why ifconfig complains is that you're assigning a point-to-point
> address to an ethernet interface and both addresses have the same
> point-to-point address.
>
> This is how you add ips to an interface:
> ifconfig xl0 192.168.1.1 netmask 255.255.255.0 # this is the primary
> ifconfig xl0 add 192.168.1.254 netmask 255.255.255.255 # All extra addresses
You forgot ``alias''.
> within the same subnet MUST have netmask 0xffffffff or 255.255.255.255 to
> prevent routing problems.
No, they must have a non-conflicting IP/mask combination. A netmask
of 0xffffffff will make it non-conflicting, and is usually what you
mean, but it's also possible to
ifconfig xl0 192.168.1.1 netmask 255.255.255.0
ifconfig xl0 add 192.168.1.254 netmask 255.255.255.128 alias
which means that data sent to (say) 192.168.1.200 will go with a
source IP of 192.168.1.254, and not 192.168.1.1.
> Baldur
>
> On Friday 03 May 2002 05:39, you wrote:
> > >Number: 37696
> > >Category: misc
> > >Synopsis: Virtual hosts broken
> > >Confidential: no
> > >Severity: serious
> > >Priority: high
> > >Responsible: freebsd-bugs
> > >State: open
> > >Quarter:
> > >Keywords:
> > >Date-Required:
> > >Class: sw-bug
> > >Submitter-Id: current-users
> > >Arrival-Date: Thu May 02 22:40:01 PDT 2002
> > >Closed-Date:
> > >Last-Modified:
> > >Originator: Dan Protich
> > >Release: 4.6-PRERELEASE
> > >Organization:
> >
> > Shell-box Computers Inc.
> >
> > >Environment:
> >
> > bash-2.05a$ uname -a
> > FreeBSD sinister.shell-box.com 4.6-PRERELEASE FreeBSD 4.6-PRERELEASE #0:
> > Sat Mar 2 02:32:42 EST 2002
> > root@sinister.shell-box.com:/usr/obj/usr/src/sys/GENERIC i386 bash-2.05a$
> >
> > >Description:
> >
> > Thought that i would upgrade freebsd box and main dns server was on it only
> > accepted 1 virtual host and not a 2nd and wouldnt allow manual add of vhost
> > rc.conf network information wouldn't accept did a upgrade from 4.5-release
> > also kernel upgrade.
> >
> > >How-To-Repeat:
> >
> > sinister# ifconfig vr0 66.118.153.201 66.118.153.255 alias
> > sinister# ifconfig vr0 66.118.153.254 66.118.153.255 alias
> > ifconfig: ioctl (SIOCAIFADDR): File exists
> > sinister#
> > doesn't exist?
> > sinister# ifconfig
> > vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> > inet 66.118.153.66 netmask 0xffffff00 broadcast 66.118.153.255
> > inet6 fe80::207:95ff:fea8:153b%vr0 prefixlen 64 scopeid 0x1
> > inet 66.118.153.201 netmask 0xff000000 broadcast 66.118.153.255
> > ether 00:07:95:a8:15:3b
> > media: Ethernet autoselect (100baseTX <full-duplex>)
> > status: active
> > lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
> > sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552
> > faith0: flags=8002<BROADCAST,MULTICAST> mtu 1500
> > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
> > inet6 ::1 prefixlen 128
> > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
> > inet 127.0.0.1 netmask 0xff000000
> > ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
> > sinister#
> >
> > >Fix:
> > >
> > >Release-Note:
> > >Audit-Trail:
> > >Unformatted:
--
Brian <brian@Awfulhak.org> <brian@freebsd-services.com>
<http://www.Awfulhak.org> <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 Tue May 14 19:55:42 2002
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 7533E37B404
for <freebsd-net@FreeBSD.ORG>; Tue, 14 May 2002 19:55:36 -0700 (PDT)
Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12])
by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F2tZfK090268;
Wed, 15 May 2002 03:55:35 +0100 (BST)
(envelope-from brian@Awfulhak.org)
Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1])
by hak.lan.Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F2tW20008086;
Wed, 15 May 2002 03:55:32 +0100 (BST)
(envelope-from brian@hak.lan.Awfulhak.org)
Message-Id: <200205150255.g4F2tW20008086@hak.lan.Awfulhak.org>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: "ipver4" <ipver4@hotmail.com>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: CCP does not work between Linux ppp client and FreeBSD ppp server
In-Reply-To: Message from "ipver4" <ipver4@hotmail.com>
of "Mon, 29 Apr 2002 23:27:29 EDT." <OE56o0nQZEMO6y4I5Jv00002a73@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 15 May 2002 03:55:32 +0100
From: Brian Somers <brian@Awfulhak.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
Hi,
You're correct. The linux machine should not REQ the compression
schemes that were REJected.
> (This is a PPP related question.)
>
> It seems the RedHat Linux 7.2 PPP client does not work with the FreeBSD =
> 4.5 PPP server in the CCP (Compression Control Protocol) negotiation. =
> Briefly, the problem looks like the following:
>
> Linux ---> CCP conf request (with 3 compression schemes, A, B and C) --> =
> PPP server
> Linux <-- CCP conf reject (schemes, B and C) <-- PPP server
> (That is, the PPP server picked the compression scheme A, and rejected =
> the rest.)
>
> Linux ---> CCP conf request (with 3 compression schemes, A, B and C) --> =
> PPP server
> Linux <-- CCP conf reject (schemes, B and C) <-- PPP server
> (repeat may times without progress.)
>
> It seems the Linux client did not follow the PPP protocol and ignored =
> the CCP reject messages.
> The correct message exchange should look like the following:
>
> Linux ---> CCP conf request (with 3 compression schemes, A, B and C) --> =
> PPP server
> Linux <-- CCP conf reject (schemes, B and C) <-- PPP server
> ---> CCP conf request (scheme A) --> PPP server
> <--- CCP conf ACK (scheme A) <-- PPP server
>
> Comments?
>
> P.S. I am using PPPoE for the testing.
--
Brian <brian@Awfulhak.org> <brian@freebsd-services.com>
<http://www.Awfulhak.org> <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 Tue May 14 19:58:54 2002
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 99A4937B40C
for <freebsd-net@FreeBSD.ORG>; Tue, 14 May 2002 19:58:25 -0700 (PDT)
Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12])
by Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F2wNfK090278;
Wed, 15 May 2002 03:58:23 +0100 (BST)
(envelope-from brian@Awfulhak.org)
Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1])
by hak.lan.Awfulhak.org (8.12.3/8.12.3) with ESMTP id g4F2wJ20008115;
Wed, 15 May 2002 03:58:19 +0100 (BST)
(envelope-from brian@hak.lan.Awfulhak.org)
Message-Id: <200205150258.g4F2wJ20008115@hak.lan.Awfulhak.org>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: Larry Baird <lab@gta.com>
Cc: freebsd-net@FreeBSD.ORG, brian@Awfulhak.org
Subject: Re: PPPoE performance difference
In-Reply-To: Message from Larry Baird <lab@gta.com>
of "Tue, 30 Apr 2002 16:32:37 EDT." <20020430163237.A71846@gta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 15 May 2002 03:58:19 +0100
From: Brian Somers <brian@Awfulhak.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
Hi,
The performance problem here is due to deflate compression being
used. Compression is quite expensive (more so than decompression)
and the slow machine is losing out here.
If you ``disable deflate pred1 mppe'' and ``deny deflate pred1 mppe''
you should see better results.
> I had a friend that was claiming that they were seeing poor PPPoE
> performance from FreeBSD 4.4 as compared to Win2K. Since he is in
> Japan and I am in the US its a bit difficult to do hands on trouble
> shooting. So I decided to set up my on PPPoE server and see if I
> could reduplicate any of his claims.
>
> I setup a 4.5-RELEASE box as my PPPoE server and a 4.5-STABLE box as
> my PPPoE client. Both hosts are using Intel Pro 10/100 (fxp) nics.
> The client is a relatively fast 999.72-MHz 686-class CPU. The server
> is a slow 133.27-MHz 586-class CPU.
>
> I am seeing a performance difference that I can't explain. Coping of
> a large file (2.6MB) using scp to the server from the client takes
> about 7 seconds. Coping the same file from the server to the client
> takes 14 seconds. Any body have any idea why the two directions are
> so different?
>
> BTW, copying the file over ethernet (not PPPoE) takes 3 seconds in
> both directions between the same hosts using the same nics.
>
> The ppp.conf file for the server is:
> default:
> # set log Phase Chat LCP IPCP CCP tun command
> enable mssfixup
> set log error
> ident user-ppp VERSION (built COMPILATIONDATE)
> set dns 10.10.1.7 10.10.1.9
> accept dns
> allow users
> enable chap
> enable pap
> set timeout 0
> enable lqr
> accept lqr
> enable sroutes
>
> gta3:
> allow mode direct
> set mru 1492
> set mtu 1492
> set speed sync
> set ifaddr 10.199.2.1 10.199.2.110-10.199.2.200 255.255.255.255
>
> For the client I used the following ppp.conf
> default:
> set socket none
>
> PPP0:
> set redial 0 0
> set timeout 0
> set reconnect 20 50000
> set ifaddr 0.0.0.0/0 0.0.0.0/0
> accept chap
> disable pap
> set authname testuser3
> set authkey testpass
> set ctsrts off
> enable dns
> set dns 10.0.0.1 10.0.0.2
> resolv readonly
> enable lqr
> set lqrperiod 20
> accept lqr
> accept acfcomp
> accept protocomp
> accept pred1
> accept vjcomp
> set log error
> set openmode active
> enable mssfixup
> set device PPPoE:fxp0:gta3
> set speed sync
> set dial
> set cd 10
> set login
> set mru 1492
> set mtu 1492
>
>
> Thanks for your time,
> Larry
>
>
> --
> ------------------------------------------------------------------------
> Larry Baird | http://www.gnatbox.com
> Global Technology Associates, Inc. | Orlando, FL
> Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080
--
Brian <brian@Awfulhak.org> <brian@freebsd-services.com>
<http://www.Awfulhak.org> <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 Wed May 15 1:46:36 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mail.engr.ucsb.edu (mail.engr.ucsb.edu [128.111.27.5])
by hub.freebsd.org (Postfix) with ESMTP id 0143D37B408
for <freebsd-net@freebsd.org>; Wed, 15 May 2002 01:46:31 -0700 (PDT)
Received: from ecipc056.engr.ucsb.edu ([128.111.53.119])
by mail.engr.ucsb.edu with esmtp (Exim 3.11 #2)
id 177uQX-0002yd-00
for freebsd-net@freebsd.org; Wed, 15 May 2002 01:46:29 -0700
Date: Wed, 15 May 2002 01:45:47 -0700 (PDT)
From: Anshuman Kanwar <akanwar@engineering.ucsb.edu>
X-X-Sender: <akanwar@ecipc056.engr.ucsb.edu>
To: <freebsd-net@freebsd.org>
Subject: 4.4 route add default problem
Message-ID: <Pine.LNX.4.33.0205150125370.12581-100000@ecipc056.engr.ucsb.edu>
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
Summary:
--------
The -ifp option in route add default does not seem to have any effect, and
it is impossible to set a default route in certain conditions.
Is there a work around for route in 4.4 ?
Details
--------
I have 2 interfaces (fxp0 and 1) on my FreeBSD box. Initially only one of
the interfaces is UP. I am trying to write a high availability script that
automatically flops over to the 2nd interface, when the active interface
fails.
Here is (roughly) what I am doing:
# Bring failed interface down
ifconfig $old_intf down
# Clear ARP cache
arp -a -d
# Fail Over to Other Interface
ifconfig $new_intf inet xx.xx.xx.xxx netmask 255.255.255.224
broadcast xx.xx.xxx.xxx
# Delete old route
route delete default
# Bring new interface up
ifconfig $new_intf up
# Add new route
route add -ifp $new_intf default $DEF_ROUTE <<<<<< (1)
PROBLEM
-------
After the interface fails over, the default route (1 above) still points
out through the $old_intf. Here is a listing of netstat and ifconfig
before and after the switch:
before
--------
Destination Gateway Flags Refs Use Netif Expire
default 61.74.4.193 UGSc 4 487 fxp0
61.74.4.192/27 link#1 UC 1 0 fxp0
61.74.4.193 0:0:ac:7:ac:a4 UHLW 4 112 fxp0 955
127.0.0.1 127.0.0.1 UH 1 6 lo0
#ifconfig -a
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 61.74.4.212 netmask 0xffffffe0 broadcast 61.74.4.223
ether 00:02:b3:87:35:f2
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
fxp1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
inet 61.74.4.212 netmask 0xffffffe0 broadcast 61.74.4.223
ether 00:02:b3:87:35:f3
media: Ethernet autoselect (none)
after
-------
dell350-6# netstat -rn
Destination Gateway Flags Refs Use Netif Expire
default 64.74.4.193 UGSc 4 24 fxp0 <<<<<
61.74.4.192/27 link#2 UC 1 0 fxp1
61.74.4.193 0:0:c:7:ac:a4 UHLW 4 2 fxp1 1189
127.0.0.1 127.0.0.1 UH 1 6 lo0
# ifconfig -a
fxp0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
inet 61.74.4.212 netmask 0xffffffe0 broadcast 61.74.4.223
ether 00:02:b3:87:35:f2
media: Ethernet autoselect (none)
status: no carrier
fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 61.74.4.212 netmask 0xffffffe0 broadcast 61.74.4.223
ether 00:02:b3:87:35:f3
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
In the second listing notice that the default route STILL points to the
fxp0 interface which is down.
I googled the topic but not of much avail. Does anyone have any idea what
is happening and how to set the proper route?
My system is:
# uname -a
FreeBSD host.nyc 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Thu Apr 11 14:38:21
PDT 2002
Thanks for your time.
-ansh.
P.S. I am not on the list so please cc you reply.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed May 15 3:31:56 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mail2.rol.it (mail2.rol.it [193.41.7.204])
by hub.freebsd.org (Postfix) with SMTP id 57C0437B408
for <freebsd-net@freebsd.org>; Wed, 15 May 2002 03:31:52 -0700 (PDT)
From: subscribe_verba@logos.net
To: freebsd-net@freebsd.org
Subject: Verba Volant
Message-Id: <20020515103152.57C0437B408@hub.freebsd.org>
Date: Wed, 15 May 2002 03:31:52 -0700 (PDT)
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
The following email address, "freebsd-net@freebsd.org" has been removed from the Verba Volant Newsletter list.
If you did not cancel your email address or you wish to continue receiving Verba Volant, please send an e-mail to subscribe_verba@logos.net
Thank you and best regards,
Verba Volant
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed May 15 9: 6: 0 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mighty.grot.org (mighty.grot.org [204.182.56.120])
by hub.freebsd.org (Postfix) with ESMTP id 8694637B400
for <freebsd-net@freebsd.org>; Wed, 15 May 2002 09:05:55 -0700 (PDT)
Received: by mighty.grot.org (Postfix, from userid 515)
id 1C0B05E7E; Wed, 15 May 2002 09:05:50 -0700 (PDT)
Date: Wed, 15 May 2002 09:05:50 -0700
From: Aditya <aditya@mighty.grot.org>
To: Anshuman Kanwar <akanwar@engineering.ucsb.edu>
Cc: freebsd-net@freebsd.org
Subject: Re: 4.4 route add default problem
Message-ID: <20020515160549.GA37073@mighty.grot.org>
Reply-To: Aditya <aditya@grot.org>
References: <Pine.LNX.4.33.0205150125370.12581-100000@ecipc056.engr.ucsb.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.33.0205150125370.12581-100000@ecipc056.engr.ucsb.edu>
X-PGP-Key: http://www.grot.org/pubkey.asc
X-PGP-Key-ID: 0x6405D8D5
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, May 15, 2002 at 01:45:47AM -0700, Anshuman Kanwar wrote:
> # Bring failed interface down
> ifconfig $old_intf down
why not move the route delete default here rather than later?
> # Delete old route
> route delete default
>
> # Clear ARP cache
> arp -a -d
>
> # Fail Over to Other Interface
> ifconfig $new_intf inet xx.xx.xx.xxx netmask 255.255.255.224
> broadcast xx.xx.xxx.xxx
>
> # Bring new interface up
> ifconfig $new_intf up
>
> # Add new route
> route add -ifp $new_intf default $DEF_ROUTE <<<<<< (1)
and why do you need -ifp $new_intf here?
Adi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed May 15 11:51:20 2002
Delivered-To: freebsd-net@freebsd.org
Received: from moab.cs.utah.edu (moab.cs.utah.edu [155.99.212.88])
by hub.freebsd.org (Postfix) with ESMTP id 7025537B40B
for <freebsd-net@FreeBSD.ORG>; Wed, 15 May 2002 11:51:15 -0700 (PDT)
Received: from localhost (bwhite@localhost)
by moab.cs.utah.edu (8.9.1/8.9.1) with ESMTP id MAA28251;
Wed, 15 May 2002 12:51:09 -0600 (MDT)
Date: Wed, 15 May 2002 12:51:09 -0600 (MDT)
From: Brian White <bwhite@moab.cs.utah.edu>
To: mark tinguely <tinguely@web.cs.ndsu.nodak.edu>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: FBSD 4.3 New Reno Fast Retransmit Behavior
In-Reply-To: <200205061641.g46GfCX78428@web.cs.ndsu.nodak.edu>
Message-ID: <Pine.BSF.4.21.0205151233370.24776-100000@moab.cs.utah.edu>
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
I've been comparing simple ns drop experiments with FreeBSD. Based on
your explanation (below), I've accounted for one difference and switched
to FreeBSD 4.5.
I'm seeing another discrepancy and would like to verify that it is
intended behavior. Though this is related to my original questioning of
False Fast Retransmit, I don't believe the explanation below covers it.
I unearthed the Dec 2001 thread in -net you refer to which was either
over my head or addresses a separate problem.
Based on the code, the following reflects my understanding:
After beginning a Fast Retransmit phase, FreeBSD will only send
retransmissions while dupacks >= tcprextmthresh. Fast retransmissions
occur in tcp_newreno, which is guarded by this conditional.
Once a new ACK arrives during Fast Retransmit, dupacks
is set to zero. Further, FreeBSD implements a False Fast Retransmit
suppression algorithm, triggered when
++tp->t_dupacks == tcprexmtthresh
and
the current ACK is less than snd_recover.
This algorithm sets dupacks to zero, ensuring that tcp_newreno can not
fire. Therefore, no more Fast Retransmissions will occur until the
Fast Retransmit phase ends.
I believe this is consistent with Janey Hoe's discussion of False Fast
Retransmits in section 3.2 of the SIGCOMM'96 paper.
But is inconsistent with ns, which does not guard the
tcp_newreno-equivalent partialnewack_helper.
Thanks again.
Brian
On Mon, 6 May 2002, mark tinguely wrote:
> > There seem to be two problematic cases. In the first, _both_ of these
> > conditions fire in tcp_input.c:
> >
> > else if (++tp->t_dupacks == tcprexmtthresh) {
> >
> > and
> >
> > if (tcp_do_newreno && SEQ_LT(th->th_ack,
> > tp->snd_recover)) {
>
> yes, this is a problem because FreeBSD 4.[34 and before?] did not
> always initialized tp->snd_recover on the session startup and
> presented a problem when the initial segment sequence is greater
> than 0x7fffffff.
>
> The only other way to tigger this error is if you went half way
> through the sequence without a duplicate ack. We talked about this
> a little on -net and decided the prevention would have more overhead
> than it would effectively cure.
>
> FreeBSD 4.5 and greater fixed the initialization of snd_recover with the
> addition of the "syncache" code.
>
> FreeBSD 4.5 also fixed some serious socket errors that would cause more
> even greater performance problems. I suggest you upgrade.
>
> --mark tinguely.
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed May 15 12: 6:12 2002
Delivered-To: freebsd-net@freebsd.org
Received: from morphy.iki.fi (baana-pppoes-213-139-166-84.suomi.net [213.139.166.84])
by hub.freebsd.org (Postfix) with SMTP id 2276D37B40C
for <net@freebsd.org>; Wed, 15 May 2002 12:05:48 -0700 (PDT)
Received: (qmail 14097 invoked by uid 1000); 15 May 2002 19:05:41 -0000
Date: Wed, 15 May 2002 22:05:41 +0300
From: Mikko Hyvarinen <mikko.hyvarinen@morphy.iki.fi>
To: Lars Eggert <larse@ISI.EDU>
Cc: net@freebsd.org, snap-users@kame.net
Subject: Re: tun device & IPv6
Message-ID: <20020515220541.C95759@morphy.iki.fi>
References: <3CE1A2C0.8050201@isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3CE1A2C0.8050201@isi.edu>; from larse@ISI.EDU on Tue, May 14, 2002 at 04:50:24PM -0700
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, May 14, 2002 at 04:50:24PM -0700, Lars Eggert wrote:
> Hi,
>
> could someone with more knowledge of the tun device please take a look
> at the code around line 387 in net/if_tun.c? It looks like tunoutput()
> drops all packets here that aren't of the AF_INET family - most notably,
> it drops IPv6 packets.
>
> We hacked around this with the simple fix below, but I'm not sure if
> there are any drawbacks...
>
[clip]
Is there a specific reason why you are not using the "multi-af" mode?
IPv6 works just nicely with /usr/sbin/ppp (PPPoE), which uses if_tun in
"multi-af" mode.
Regards,
Mikko
--
All opinions expressed above are mine alone and do not express the views
of my employer or any other organizations that I am affiliated with.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed May 15 13:23:33 2002
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 5F19237B406
for <net@freebsd.org>; Wed, 15 May 2002 13:23:01 -0700 (PDT)
Received: from isi.edu (1f835yum9sb2nilf@hbo.isi.edu [128.9.160.75])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4FKMvF01536;
Wed, 15 May 2002 13:22:57 -0700 (PDT)
Message-ID: <3CE2C39A.2010803@isi.edu>
Date: Wed, 15 May 2002 13:22:50 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: Mikko Hyvarinen <mikko.hyvarinen@morphy.iki.fi>
Cc: net@freebsd.org, snap-users@kame.net
Subject: Re: tun device & IPv6
References: <3CE1A2C0.8050201@isi.edu> <20020515220541.C95759@morphy.iki.fi>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030207000104030401080906"
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 cryptographically signed message in MIME format.
--------------ms030207000104030401080906
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Mikko Hyvarinen wrote:
>>could someone with more knowledge of the tun device please take a look
>>at the code around line 387 in net/if_tun.c? It looks like tunoutput()
>>drops all packets here that aren't of the AF_INET family - most notably,
>>it drops IPv6 packets.
>>
>>We hacked around this with the simple fix below, but I'm not sure if
>>there are any drawbacks...
>>
> Is there a specific reason why you are not using the "multi-af" mode?
> IPv6 works just nicely with /usr/sbin/ppp (PPPoE), which uses if_tun in
> "multi-af" mode.
The specific reason was that I didn't know about it :-) I'm currently
patching net/vtund so it uses multi-af mode.
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms030207000104030401080906
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIInzCC
ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP
MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc
MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1
1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU
SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB
BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud
EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT
vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d
6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC
HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD
VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV
BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq
hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL
ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA
jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv
0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy
dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E
AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ
d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX
frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDKTCCApKgAwIB
AgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4g
Q2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo
MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhh
d3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl
bWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJ
BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEP
MA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE
AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50bzC8M5B/
+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avgGAOofENC
UFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIwIKQeMBwx
GjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAwCwYDVR0P
BAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWomKmKE
H7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX
tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMYICpjCCAqIC
AQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2
aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkG
BSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTAyMDUxNTIwMjI1MlowIwYJKoZIhvcNAQkEMRYEFFVRn4sJY7hrYGPNPFijfq6A63xaMFIG
CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD
VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEB
BQAEgYBmv4Ea0vSrNN2sGE0CpT1FjUbOY1kQsCF//X+gBPYdGif1SZsyZa2dfkPMHQ9Yk+K4
6PQNCWc0G6Zs7gaPdQf+dHmRGYOeOn2JXUxUeQXlHz4SzHGrUiQ2kZBoCx3Gl965gsNgJXmW
vtMHzxeCxR+Lm45j9QyUi1wZE80TgkIQdgAAAAAAAA==
--------------ms030207000104030401080906--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Wed May 15 17:45: 2 2002
Delivered-To: freebsd-net@freebsd.org
Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186])
by hub.freebsd.org (Postfix) with ESMTP id DFD1337B404
for <freebsd-net@FreeBSD.ORG>; Wed, 15 May 2002 17:44:57 -0700 (PDT)
Received: from databus.com (localhost.databus.com [127.0.0.1])
by tp.databus.com (8.12.3/8.12.2) with ESMTP id g4G0iop7059218;
Wed, 15 May 2002 20:44:50 -0400 (EDT)
(envelope-from barney@databus.com)
Received: (from barney@localhost)
by databus.com (8.12.3/8.12.3/Submit) id g4G0inis059217;
Wed, 15 May 2002 20:44:49 -0400 (EDT)
Date: Wed, 15 May 2002 20:44:49 -0400
From: Barney Wolff <barney@tp.databus.com>
To: Anshuman Kanwar <akanwar@engineering.ucsb.edu>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: 4.4 route add default problem
Message-ID: <20020515204449.A59148@tp.databus.com>
References: <Pine.LNX.4.33.0205150125370.12581-100000@ecipc056.engr.ucsb.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.LNX.4.33.0205150125370.12581-100000@ecipc056.engr.ucsb.edu>; from akanwar@engineering.ucsb.edu on Wed, May 15, 2002 at 01:45:47AM -0700
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
If you want a stupid hack that I believe will work, do
ifconfig fxp0 1.1.1.1
instead of downing it. That will delete the default route, as the
address will not be reachable.
You can then bring up fxp1 and add back the default route, which should
be reachable through it.
--
Barney Wolff
I never met a computer I didn't like.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu May 16 5: 4:14 2002
Delivered-To: freebsd-net@freebsd.org
Received: from smtp.completel.fr (smtp.completel.fr [213.244.0.12])
by hub.freebsd.org (Postfix) with ESMTP
id 3AD9E37B404; Thu, 16 May 2002 05:04:06 -0700 (PDT)
Received: from netasq.com (unknown [213.30.137.178])
by smtp.completel.fr (Postfix) with ESMTP
id 45FD7179E71; Thu, 16 May 2002 14:03:58 +0200 (CEST)
Received: from netasq.com
by completel.fr (8.10.1/8.10.1) with ESMTP id g4GCAqJ01947;
Thu, 16 May 2002 14:10:52 +0200 (CEST)
Date: Thu, 16 May 2002 14:03:52 +0200
From: Fabien THOMAS <fabien.thomas@netasq.com>
X-Mailer: The Bat! (v1.60c)
Organization: NETASQ
X-Priority: 3 (Normal)
Message-ID: <10168589031.20020516140352@netasq.com>
To: freebsd-stable@freebsd.org
Cc: freebsd-net@freebsd.org
Subject: bge drivers does not work for 3COM 3C996-SX / 3C996B-T
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="----------F715B11A13651A97"
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 cryptographically signed message in MIME format.
------------F715B11A13651A97
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I've some problems with bge driver with 3COM 3C996-SX fiber card and
3C996B-T copper card under -stable:
The fiber card is detected correctly but the link does not go up (i've
tested the same card between two Win2K and it works well).
The copper card is detected but the link goes up/down and sometimes lock the
machine (reboot is needed to restart) when i start a 'ping -i0 -q'.
Does someone experienced the same problems ?
for the missing splx: i think i've found a new one in bge_init:
static void
bge_init(xsc)
void *xsc;
{
struct bge_softc *sc = xsc;
struct ifnet *ifp;
u_int16_t *m;
int s;
s = splimp();
ifp = &sc->arpcom.ac_if;
if (ifp->if_flags & IFF_RUNNING)
--> missing splx ?
return;
Fabien
------------F715B11A13651A97
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIGRgYJKoZIhvcNAQcCoIIGNzCCBjMCAQMxCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBHEw
ggRtMIIDVaADAgECAgEEMA0GCSqGSIb3DQEBBQUAMIGRMQswCQYDVQQGEwJGUjENMAsGA1UECBME
Tm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBkJ0FzY3ExLjAsBgNVBAoTJU5FVEFTUSAtIFNlY3Vy
ZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAlBgNVBAsTHk5FVEFTUSBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eTAeFw0wMjAyMTkxNDQ4NDRaFw0wMzAyMTkxNDQ4NDRaMIHSMQswCQYDVQQGEwJGUjEN
MAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBkJ0FzY3ExLjAsBgNVBAoTJU5ldEFz
cSAtIFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAlBgNVBAsTHk5ldEFzcSBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTEWMBQGA1UEAxMNRmFiaWVuIFRIT01BUzEnMCUGCSqGSIb3DQEJARYY
ZmFiaWVuLnRob21hc0BuZXRhc3EuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDnmO6H
h5Nm3OOE7+k3zSP3/cWDBGbxVh5PInSwQeKW43cKKE0MH8Y5erHIhVVchaMRsvxBfJrB6T8s2vGN
l+ZRnFVP2Ug8+xLYFFJONlkY1YnHTZJ/VGx/lsf2ZDR7ZKqgcnuvbrLra4Np062oED1xwEpzbJnT
emmbOGTqscUvcwIDAQABo4IBDzCCAQswCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwHQYDVR0OBBYE
FLJEqzTrOFxg8EONNUey1yGm2kWjMIG+BgNVHSMEgbYwgbOAFCcq6x3ZRNo6F3NqCSAgySWo+X+y
oYGXpIGUMIGRMQswCQYDVQQGEwJGUjENMAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2
ZSBkJ0FzY3ExLjAsBgNVBAoTJU5FVEFTUSAtIFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkx
JzAlBgNVBAsTHk5FVEFTUSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIBADARBglghkgBhvhCAQEE
BAMCBaAwDQYJKoZIhvcNAQEFBQADggEBAERHjAkf5L/cZH/n0GTKyptbyr4ro7aGfOFyvyTCxeDN
kL3v4gtD2itXx88JbThmsAHAiECjWhI8AUTBRsEpcPa9zbbQEnQqX+cdLnvgaZjCpAErSbrR3TN1
ToSahIFXYc5Ao+1K0fwMdZSmjbPS7J0gZPWdqLLFf214qOmMxAaw3zGRnSmcMUbwKGbfcyMT0KsK
7u82raxnKSgk/VzUzS26aXPbRHW4RguHOY40RLyyZJDjG883uBeOaOLvmmov5eFpcdkHlGav4wun
0ARGo1N/PUo+UntWkzPNWD1EXRxOE0iz3n7Bb8NwlS6A339TSi5lw14SfvbCg28QTfVGFKMxggGd
MIIBmQIBATCBlzCBkTELMAkGA1UEBhMCRlIxDTALBgNVBAgTBE5vcmQxGjAYBgNVBAcTEVZpbGxl
bmV1dmUgZCdBc2NxMS4wLAYDVQQKEyVORVRBU1EgLSBTZWN1cmUgSW50ZXJuZXQgQ29ubmVjdGl2
aXR5MScwJQYDVQQLEx5ORVRBU1EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAQQwCQYFKw4DAhoF
AKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkEMRYEFAV2hiawCrly/jwe
dir/SCFrmJobMBwGCSqGSIb3DQEJBTEPFw0wMjA1MTYxMjAzNTJaMA0GCSqGSIb3DQEBAQUABIGA
fAL2Kwhj+2A1b+VoG+JaR8AA5i0NY114rHKbqUnPNgjNExvZWXEmEGGUt/11qK+z7JOyQbdkHRgz
lxWOIp1ZH3E+cBsFhOTx7YO3yaJ3MsXepp39kAjR7VRHDnJL2QCpS0yUWCHYfXQF/Fvq7nxdqywX
AEzBXdYPCt5UMdFeh4c=
------------F715B11A13651A97--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu May 16 9:33: 7 2002
Delivered-To: freebsd-net@freebsd.org
Received: from hottub.hottub.org (hottub.org [66.60.164.74])
by hub.freebsd.org (Postfix) with ESMTP id 2255B37B408
for <freebsd-net@freebsd.org>; Thu, 16 May 2002 09:32:58 -0700 (PDT)
Received: by hottub.hottub.org (Postfix, from userid 1100)
id E0B1E213BC; Thu, 16 May 2002 09:30:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by hottub.hottub.org (Postfix) with ESMTP id D301B213BB
for <freebsd-net@freebsd.org>; Thu, 16 May 2002 09:30:58 -0700 (PDT)
Date: Thu, 16 May 2002 09:30:58 -0700 (PDT)
From: Matthew Zahorik <matt@hottub.org>
X-X-Sender: matt@hottub
To: freebsd-net@freebsd.org
Subject: IPsec and dynamically assigned IPs
Message-ID: <Pine.GSO.4.40.0205160858030.10618-100000@hottub>
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
All:
I am unclear regarding spdadd arguments and my VPN setup.
I'm attempting to replace Nortel's Contivity Extranet Client on Windows
with a racoon/ipsec solution.
I'm unsure if this is a "tunnel" or "transport" connection.
I contact a fixed server at 205.173.93.x. This is a contivity switch.
My client is an IP address assigned by RoadRunner.
During IKE (user w/ SecureID hard token, aggressive mode) another IP
address is assigned (3.179.89.x) by the contivity.
How do I express this in spdadd so that I can fire off racoon?
[client] 66.67.157.x (RoadRunner IP, dynamic, known at spdadd time)
|
[tunnel? endpoint] 3.179.89.x (dynamic, assigned during/after IKE)
|
{ Internet }
|
[tunnel? endpoint] ?.?.?.? (fixed, traceroute shows 3.179.68.x 1st hop)
|
[server] 205.173.93.x (fixed, known at spdadd time)
Thanks!
- Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu May 16 16:20: 3 2002
Delivered-To: freebsd-net@freebsd.org
Received: from ady.warpnet.ro (ady.warpnet.ro [217.156.25.2])
by hub.freebsd.org (Postfix) with ESMTP
id 1501837B406; Thu, 16 May 2002 16:19:50 -0700 (PDT)
Received: from localhost (ady@localhost)
by ady.warpnet.ro (8.9.3/8.9.3) with ESMTP id CAA30507;
Fri, 17 May 2002 02:17:45 +0300 (EEST)
(envelope-from ady@freebsd.ady.ro)
X-RAV-AntiVirus: This e-mail has been scanned for viruses on host: ady.warpnet.ro
Date: Fri, 17 May 2002 02:17:45 +0300 (EEST)
From: Adrian Penisoara <ady@freebsd.ady.ro>
X-Sender: ady@ady.warpnet.ro
To: freebsd-arch@freebsd.org, freebsd-net@freebsd.org
Subject: HEADS UP: ALTQ integration developer preview
Message-ID: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro>
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
We have started a "ALTQ integration in FreeBSD" project which is
headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD
5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been
advised and we have received on principle approval. We are looking
for help with committing these bits to the CVS tree.
Please have a look at the proposed ALTQ package for 5.0-current,
which is found here:
http://www.rofug.ro/projects/freebsd-altq/altq-freebsd-5.0-current-May14.tar.gz
Installation details are found in the README file; for further
details consult the documentation referenced below. Please send us any
comments you have, your feedback is valuable.
ALTQ integration implies some changes in the network drivers code and
in the design of the the network queues management. Here is a summary of
the ALTQ design document:
The BSD systems need better output queueing abstraction to support
packet scheduling (e.g., CBQ) or active queue management (e.g., RED).
To introduce a new model, we need to convert the existing code to be
conformant to the new model. But the problem is that there are too
many drivers to convert all at once.
This is a proposal that allows incremental transition to the
new model. (If we are going to modify the existing drivers, we need
to get it right.)
The model is designed for ALTQ but it is general enough for other
implementations so that we can make the driver conversion once and
for all.
The new model removes direct references to the fields
within ifp->if_snd, and defines the following macros to manipulate
ifp->if_snd:
IFQ_ENQUEUE(ifq, m, err)
IFQ_DEQUEUE(ifq, m)
IFQ_POLL(ifq, m)
IFQ_PURGE(ifq)
IFQ_IS_EMPTY(ifq)
The new model also enforces some rules regarding how to use these
macros.
Another requirement for a driver is to work under rate-limiting.
- IFQ_DEQUEUE() could return NULL even when IFQ_IS_EMPTY() is FALSE
under rate-limiting. a driver should always check if (m == NULL).
- a driver is supposed to call if_start from the tx complete
interrupt under late-limiting (in order to trigger the next
dequeue).
For most drivers, it is a simple task of replacing old-style lines by
the corresponding new-style lines, and usually just a few lines need
to be modified. But some drivers need more than that.
The old-style drivers still work with the original FIFO queue but
they cannot take advantage of new queueing disciplines.
For locking an output queue to support SMP, ALTQ uses the same model
as in FreeBSD-5.0. One restriction is that, if a driver uses
poll-and-dequeue, the driver needs to explicitly lock the queue
between the poll operation and the dequeue operation.
You can find more details here:
http://www.csl.sony.co.jp/person/kjc/kjc/software/altq-new-design.txt
http://www.csl.sony.co.jp/person/kjc/kjc/software.html#ALTQ
Current development is headed by Kenjiro Cho and myself. If you want
to join our efforts please subscribe to our mailing list by sending
"subscribe" in the body of a message to freebsd-altq-request@rofug.ro.
Adrian Penisoara
Ady (@freebsd.ady.ro, @rofug.ro)
_______________________________________________________________________
| Programming in BASIC causes brain damage. |
| (Edsger Wybe Dijkstra) |
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu May 16 17:22:38 2002
Delivered-To: freebsd-net@freebsd.org
Received: from stono.cs.cofc.edu (stono.cs.cofc.edu [153.9.17.3])
by hub.freebsd.org (Postfix) with ESMTP id B4DA337B40A
for <freebsd-net@freebsd.org>; Thu, 16 May 2002 17:22:30 -0700 (PDT)
Received: from [153.9.17.27] (burton.cs.cofc.edu [153.9.17.27])
by stono.cs.cofc.edu (8.11.6/8.11.6) with ESMTP id g4H0JfG14302
for <freebsd-net@freebsd.org>; Thu, 16 May 2002 20:19:41 -0400
Mime-Version: 1.0
X-Sender: jimmy@stono.cs.cofc.edu
Message-Id: <a05100306b909fd9084b5@[153.9.17.27]>
Date: Thu, 16 May 2002 20:24:45 -0400
To: freebsd-net@freebsd.org
From: "James B. Wilkinson" <jimmy@CS.cofc.EDU>
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
I've got to teach a new graduate course in networking this fall. I'm
looking at using vol 1 and maybe vol 2 of "TCP/IP Illustrated" by
Richard Stevens. The basic premise of the book seems to be to do
experiments on a working network in order to learn about the
protocols. One thing that I thought about doing is to have them do
that sort of thing here as well as to read about what he did to do
the book. It seemed useful to me to have some of the machines set up
with a version of FreeBSD that let you fool around with what the IP
and TCP layers were doing. E.g. introduce delays in the transmission
of ack's so that packets get retransmitted or so that you can watch
the RTT estimate catch up. Maybe pick out particular TCP segments and
lose them. When I started looking at how one might do this, it seemed
like it might be hard. So I got to wondering if somebody had already
done it so that I don't have to. I have no idea how to do a Google
search for something like that.
Do any of you guys know about any software like that. I spose it
would have to be a hacked version of a kernel.
Thanks
--
-------------------------------------------------------------
Jimmy Wilkinson | Perfesser of Computer Science
jimmy@cs.CofC.edu | The College of Charleston
(843) 953-8160 | Charleston SC 29424
If there is one word to describe me,
that word would have to be "profectionist".
Any form of incompitence is an athema to me.
Metathesis??? Don't ax me.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu May 16 20:34:20 2002
Delivered-To: freebsd-net@freebsd.org
Received: from cc.kmu.edu.tw (cc.kmu.edu.tw [163.15.154.1])
by hub.freebsd.org (Postfix) with ESMTP id 90E0737B40B
for <freebsd-net@FreeBSD.org>; Thu, 16 May 2002 20:34:16 -0700 (PDT)
Received: from cc.kmu.edu.tw (c198.cc.kmu.edu.tw [163.15.154.198])
by cc.kmu.edu.tw (8.11.6/8.11.6) with ESMTP id g4H3XvQ91848
for <freebsd-net@FreeBSD.org>; Fri, 17 May 2002 11:33:58 +0800 (CST)
(envelope-from cch@cc.kmu.edu.tw)
Message-ID: <3CE47A2B.70807@cc.kmu.edu.tw>
Date: Fri, 17 May 2002 11:34:03 +0800
From: Chih-Chang Hsieh <cch@cc.kmu.edu.tw>
Reply-To: cch@cc.kmu.edu.tw
Organization: KMU Computer Center
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc2) Gecko/20020514
X-Accept-Language: zh-tw, en-us
MIME-Version: 1.0
To: freebsd-net@FreeBSD.org
Subject: A question about racoon with multi-homed IPSec box
Content-Type: text/plain; charset=Big5
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
We are setting up two tunneled-IPSec VPN boxes.
One of the boxes has 2 IPs, and another one (plus
firewall functions) has 3.
Could someone tell us how to assign a local address for
racoon to bind? Because the 3-IP box's outgoing interface
is assigned by a private IP which connects to a router.
But we want racoon to bind the public IP.
Thanks in advance!
--
Chih-Chang Hsieh
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu May 16 20:43: 8 2002
Delivered-To: freebsd-net@freebsd.org
Received: from garple.migus.org (pcp243391pcs.howard01.md.comcast.net [68.55.83.143])
by hub.freebsd.org (Postfix) with ESMTP id 238DC37B409
for <freebsd-net@freebsd.org>; Thu, 16 May 2002 20:42:53 -0700 (PDT)
Received: from ganyopa (ganyopa.migus.org [192.168.4.2])
by garple.migus.org (8.12.2/8.12.2) with SMTP id g4H3h4cq014421
for <freebsd-net@freebsd.org>; Thu, 16 May 2002 23:43:04 -0400 (EDT)
From: "Adam Migus" <adam@migus.org>
To: <freebsd-net@freebsd.org>
Subject: RE:
Date: Thu, 16 May 2002 23:42:40 -0400
Message-ID: <HGEBLKNLFOJKKBGJBAKDGEBECAAA.adam@migus.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <a05100306b909fd9084b5@[153.9.17.27]>
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
James,
You could use dummynet(4) to introduce delays, limit throughput, etc. You
could also play with the various sysctl(8) variables.
net.inet.ip.rtexpire
net.inet.ip.rtminexpire
net.inet.ip.rtmaxcache
net.inet.tcp.delacktime
net.inet.tcp.delayed_ack
Just to name a few. Trying doing:
sysctl -A | grep "net.inet"
You can even mess around with some of the ipc related variables:
sysctl -A | grep "kern.ipc"
You should be able to manipulate the stack enough with that but there is
always the source. :-)
--
Adam Migus (adam@migus.org) (amigus@FreeBSD.org)
FreeBSD (http://www.freebsd.org) | The Power to Serve
-----Original Message-----
From: owner-freebsd-net@FreeBSD.ORG
[mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of James B. Wilkinson
Sent: Thursday, May 16, 2002 8:25 PM
To: freebsd-net@FreeBSD.ORG
Subject:
I've got to teach a new graduate course in networking this fall. I'm
looking at using vol 1 and maybe vol 2 of "TCP/IP Illustrated" by
Richard Stevens. The basic premise of the book seems to be to do
experiments on a working network in order to learn about the
protocols. One thing that I thought about doing is to have them do
that sort of thing here as well as to read about what he did to do
the book. It seemed useful to me to have some of the machines set up
with a version of FreeBSD that let you fool around with what the IP
and TCP layers were doing. E.g. introduce delays in the transmission
of ack's so that packets get retransmitted or so that you can watch
the RTT estimate catch up. Maybe pick out particular TCP segments and
lose them. When I started looking at how one might do this, it seemed
like it might be hard. So I got to wondering if somebody had already
done it so that I don't have to. I have no idea how to do a Google
search for something like that.
Do any of you guys know about any software like that. I spose it
would have to be a hacked version of a kernel.
Thanks
--
-------------------------------------------------------------
Jimmy Wilkinson | Perfesser of Computer Science
jimmy@cs.CofC.edu | The College of Charleston
(843) 953-8160 | Charleston SC 29424
If there is one word to describe me,
that word would have to be "profectionist".
Any form of incompitence is an athema to me.
Metathesis??? Don't ax me.
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 May 16 21: 9:10 2002
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 9D82C37B40B
for <freebsd-net@freebsd.org>; Thu, 16 May 2002 21:09:02 -0700 (PDT)
Received: from keg (c1-vpn1.isi.edu [128.9.176.27])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4H492F23608;
Thu, 16 May 2002 21:09:02 -0700 (PDT)
From: "Lars Eggert" <larse@ISI.EDU>
To: "'Matthew Zahorik'" <matt@hottub.org>, <freebsd-net@freebsd.org>
Subject: RE: IPsec and dynamically assigned IPs
Date: Thu, 16 May 2002 21:08:58 -0700
Organization: USC Information Sciences Institute
MIME-Version: 1.0
Message-ID: <001501c1fd58$91abf680$b27ba8c0@isi.edu>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Content-Type: multipart/signed;
protocol="application/x-pkcs7-signature";
micalg=SHA1;
boundary="----=_NextPart_000_0010_01C1FD1D.E484EC80"
In-Reply-To: <Pine.GSO.4.40.0205160858030.10618-100000@hottub>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.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
This is a multi-part message in MIME format.
------=_NextPart_000_0010_01C1FD1D.E484EC80
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
> I'm attempting to replace Nortel's Contivity Extranet
> Client on Windows with a racoon/ipsec solution.
>
> I'm unsure if this is a "tunnel" or "transport" connection.
I can't help you with the racoon part, but as for tunnel vs. transport
mode: If it isn't end-to-end, it's tunnel mode. Transport mode is
allowed between a host pair only.
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
------=_NextPart_000_0010_01C1FD1D.E484EC80
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJFzCCArUw
ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT
FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw
MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0
MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy
c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4
qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf
tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA
AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE
ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ
A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2
OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4
fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV
MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0
ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw
IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv
bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB
kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD
Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y
8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU
ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp
dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN
AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt
UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2
lhglTWr0ncXDkS+plrgFPFL83eliA0gwggMtMIIClqADAgECAgEAMA0GCSqGSIb3DQEBBAUAMIHR
MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x
GjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp
Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkq
hkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTYwMTAxMDAwMDAwWhcN
MjAxMjMxMjM1OTU5WjCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG
A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2Vy
dGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZy
ZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUadfUsJRkW3HpR9gMUbbqcpGwhF59LQ2PexLfhSV1
KHQ6QixjJ5+Ve0vvfhmHHYbqo925zpZkGsIUbkSsfOaP6E0PcR9AOKYAo4d49vmUhl6t6sBeduvZ
FKNdbnp8DKVLVX8GGSl/npom1Wq7OCQIapjHsdqjmJH9edvlWsQcuQIDAQABoxMwETAPBgNVHRMB
Af8EBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAMfskn5O+PWWpWdiKqTwTRFg0G+NYFhhrCa7UjVc
CM8w+6hKloofYkIjjBcP9LpknBesRynfnZhe0mxgcVyirNx54+duAEcftQ0o6AKd5Jr9E/Sm2Xyx
+NxfIyYJkYBz0BQb3kOpgyXy5pwvFcr+pquKB3WLDN1RhGvk+NHOd6KBMYIDaTCCA2UCAQEwgZow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93
bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UE
AxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggIkMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDUxNzA0MDg1N1owIwYJ
KoZIhvcNAQkEMRYEFAFFBGXeGmdvlZDm4JuUpbb1etp0MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI
hvcNAwcwBwYFKw4DAhowDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAoGCCqGSIb3DQIFMIGrBgkrBgEEAYI3EAQxgZ0wgZowgZIxCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMG
VGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDBYFHMIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkG
A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYD
VQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJz
b25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZIhvcNAQEBBQAEgYBL6Mz64iOV
aFIwCfeR9t06eEJKkmLWQiBsaBvy2tHPgk/HnaGgSW0mlTiSCi9xvHxFMt5NQpRp++3H3gC+7lUA
ZLkjIUKxrGVpirTD8qF6tYJwI2Ti3Wn7LLU00/bAE7X64yV6H5d6vidydd6BYKwirECvDm0ZflL2
Wf0v1knj/AAAAAAAAA==
------=_NextPart_000_0010_01C1FD1D.E484EC80--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu May 16 22:30:22 2002
Delivered-To: freebsd-net@freebsd.org
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
by hub.freebsd.org (Postfix) with ESMTP id A8A9637B406
for <freebsd-net@FreeBSD.ORG>; Thu, 16 May 2002 22:30:18 -0700 (PDT)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id WAA35123;
Thu, 16 May 2002 22:16:10 -0700 (PDT)
Received: (from archie@localhost)
by arch20m.dellroad.org (8.11.6/8.11.6) id g4H5Fqe36428;
Thu, 16 May 2002 22:15:52 -0700 (PDT)
(envelope-from archie)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200205170515.g4H5Fqe36428@arch20m.dellroad.org>
Subject: Re: A question about racoon with multi-homed IPSec box
In-Reply-To: <3CE47A2B.70807@cc.kmu.edu.tw> "from Chih-Chang Hsieh at May 17,
2002 11:34:03 am"
To: cch@cc.kmu.edu.tw
Date: Thu, 16 May 2002 22:15:52 -0700 (PDT)
Cc: freebsd-net@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
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
Chih-Chang Hsieh writes:
> Could someone tell us how to assign a local address for
> racoon to bind? Because the 3-IP box's outgoing interface
> is assigned by a private IP which connects to a router.
> But we want racoon to bind the public IP.
man racoon.conf...
listen
{
isakmp x.x.x.x; <-- your ip address goes here
}
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Thu May 16 22:48:38 2002
Delivered-To: freebsd-net@freebsd.org
Received: from cc.kmu.edu.tw (cc.kmu.edu.tw [163.15.154.1])
by hub.freebsd.org (Postfix) with ESMTP id BD71937B40E
for <freebsd-net@FreeBSD.ORG>; Thu, 16 May 2002 22:48:18 -0700 (PDT)
Received: from cc.kmu.edu.tw (c198.cc.kmu.edu.tw [163.15.154.198])
by cc.kmu.edu.tw (8.11.6/8.11.6) with ESMTP id g4H5mCQ03304;
Fri, 17 May 2002 13:48:13 +0800 (CST)
(envelope-from cch@cc.kmu.edu.tw)
Message-ID: <3CE499A3.8030807@cc.kmu.edu.tw>
Date: Fri, 17 May 2002 13:48:19 +0800
From: Chih-Chang Hsieh <cch@cc.kmu.edu.tw>
Reply-To: cch@cc.kmu.edu.tw
Organization: KMU Computer Center
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc2) Gecko/20020514
X-Accept-Language: zh-tw, en-us
MIME-Version: 1.0
To: Archie Cobbs <archie@dellroad.org>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: A question about racoon with multi-homed IPSec box
References: <200205170515.g4H5Fqe36428@arch20m.dellroad.org>
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
Archie Cobbs wrote:
> Chih-Chang Hsieh writes:
>
>>Could someone tell us how to assign a local address for
>>racoon to bind? Because the 3-IP box's outgoing interface
>>is assigned by a private IP which connects to a router.
>>But we want racoon to bind the public IP.
>
> man racoon.conf...
>
> listen
> {
> isakmp x.x.x.x; <-- your ip address goes here
> }
Sorry, I forgot to say that we had tried this.
But it not works. :( We are using racoon-20020507a.
Anyway, thank you very much.
--
Chih-Chang Hsieh
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 1: 6:21 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.dev.itouchnet.net (devco.net [196.15.188.2])
by hub.freebsd.org (Postfix) with ESMTP id 08DCD37B40A
for <freebsd-net@freebsd.org>; Fri, 17 May 2002 01:06:16 -0700 (PDT)
Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.33 #2)
id 178cp8-000EwV-00
for freebsd-net@freebsd.org; Fri, 17 May 2002 10:10:50 +0200
Received: from shell.devco.net ([196.15.188.7])
by mx1.dev.itouchnet.net with esmtp (Exim 3.33 #2)
id 178cp4-000Ew8-00; Fri, 17 May 2002 10:10:46 +0200
Received: from bvi by shell.devco.net with local (Exim 3.33 #4)
id 178cke-00074K-00; Fri, 17 May 2002 10:06:12 +0200
Date: Fri, 17 May 2002 10:06:12 +0200
From: Barry Irwin <bvi@itouchlabs.com>
To: Chih-Chang Hsieh <cch@cc.kmu.edu.tw>
Cc: Archie Cobbs <archie@dellroad.org>, freebsd-net@FreeBSD.ORG
Subject: Re: A question about racoon with multi-homed IPSec box
Message-ID: <20020517100612.G17719@itouchlabs.com>
References: <200205170515.g4H5Fqe36428@arch20m.dellroad.org> <3CE499A3.8030807@cc.kmu.edu.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3CE499A3.8030807@cc.kmu.edu.tw>; from cch@cc.kmu.edu.tw on Fri, May 17, 2002 at 01:48:19PM +0800
X-Checked: This message has been scanned for any virusses and unauthorized attachments.
X-iScan-ID: 57439-1021623049-04073@mx1.dev.itouchnet.net version $Name: REL_2_0_2 $
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 2002-05-17 (13:48), Chih-Chang Hsieh wrote:
> Archie Cobbs wrote:
> > Chih-Chang Hsieh writes:
> >
> >>Could someone tell us how to assign a local address for
> >>racoon to bind? Because the 3-IP box's outgoing interface
> >>is assigned by a private IP which connects to a router.
> >>But we want racoon to bind the public IP.
> >
> > man racoon.conf...
> >
> > listen
> > {
> > isakmp x.x.x.x; <-- your ip address goes here
> > }
>
> Sorry, I forgot to say that we had tried this.
>
> But it not works. :( We are using racoon-20020507a.
>
> Anyway, thank you very much.
I am running this on a number of my production firewalls and in cases where
I ahev specifically bound and IP for Racoon to use it works. In most Cases
I let it bind all interfaces - in which case the interface 'closest' to the
other system is used. Where this doesnt work, and where I assume you are
having the problem si swhere you have two IP's bound to an interface and you
want racoon to use an IP that is not the primary bound address on the
interface.
racoon-20010322a KAME racoon IKE daemon
racoon-20011215a KAME racoon IKE daemon
Barry
--
Barry Irwin bvi@itouchlabs.com +27214875177
Systems Administrator: Networks And Security
Itouch Labs http://www.itouchlabs.com South Africa
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 1:58:59 2002
Delivered-To: freebsd-net@freebsd.org
Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95])
by hub.freebsd.org (Postfix) with SMTP id 88B9B37B40A
for <freebsd-net@freebsd.org>; Fri, 17 May 2002 01:58:54 -0700 (PDT)
Received: (qmail 2557 invoked by uid 1000); 17 May 2002 09:00:02 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
by localhost with SMTP; 17 May 2002 09:00:02 -0000
Date: Fri, 17 May 2002 11:00:02 +0200 (CEST)
From: Attila Nagy <bra@fsn.hu>
To: Adrian Penisoara <ady@freebsd.ady.ro>
Cc: freebsd-arch@freebsd.org, <freebsd-net@freebsd.org>
Subject: Re: HEADS UP: ALTQ integration developer preview
In-Reply-To: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro>
Message-ID: <Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu>
References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro>
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
Hello,
> We have started a "ALTQ integration in FreeBSD" project which is
> headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD
> 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been
> advised and we have received on principle approval. We are looking for
> help with committing these bits to the CVS tree.
Great. Do you have plans to merge OpenBSD's TCP_ECN stuff, committed
yesterday to the tree?
> Please have a look at the proposed ALTQ package for 5.0-current, which
> is found here:
> http://www.rofug.ro/projects/freebsd-altq/altq-freebsd-5.0-current-May14.tar.gz
Although I'm not a coder myself, I would also look for the way to patch
the "em" driver (if "gx" is already in the initial plan), because it
reportedly works better (for example I couldn't do NFS serving with UDP
packets bigger than the MTU with that, while the "em" driver works OK).
Thanks!
--------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]-------
Attila Nagy e-mail: Attila.Nagy@fsn.hu
Free Software Network (FSN.HU) phone @work: +361 210 1415 (194)
cell.: +3630 306 6758
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 2:20:29 2002
Delivered-To: freebsd-net@freebsd.org
Received: from ady.warpnet.ro (ady.warpnet.ro [217.156.25.2])
by hub.freebsd.org (Postfix) with ESMTP id D5D0337B405
for <freebsd-net@freebsd.org>; Fri, 17 May 2002 02:20:16 -0700 (PDT)
Received: from localhost (ady@localhost)
by ady.warpnet.ro (8.9.3/8.9.3) with ESMTP id MAA65309;
Fri, 17 May 2002 12:18:09 +0300 (EEST)
(envelope-from ady@freebsd.ady.ro)
X-RAV-AntiVirus: This e-mail has been scanned for viruses on host: ady.warpnet.ro
Date: Fri, 17 May 2002 12:18:09 +0300 (EEST)
From: Adrian Penisoara <ady@freebsd.ady.ro>
X-Sender: ady@ady.warpnet.ro
To: Attila Nagy <bra@fsn.hu>
Cc: freebsd-net@freebsd.org,
freebsd-altq list <freebsd-altq@rofug.ro>
Subject: Re: HEADS UP: ALTQ integration developer preview
In-Reply-To: <Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu>
Message-ID: <Pine.BSF.4.10.10205171213020.51675-100000@ady.warpnet.ro>
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
Hi,
On Fri, 17 May 2002, Attila Nagy wrote:
> > We have started a "ALTQ integration in FreeBSD" project which is
> > headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD
> > 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been
> > advised and we have received on principle approval. We are looking for
> > help with committing these bits to the CVS tree.
> Great. Do you have plans to merge OpenBSD's TCP_ECN stuff, committed
> yesterday to the tree?
Thanks for the pointer !
I don't know yet if we will merge it, but be sure we will review it.
BTW, who does the integration/maintainance of ALTQ in OpenBSD ?
>
> > Please have a look at the proposed ALTQ package for 5.0-current, which
> > is found here:
> > http://www.rofug.ro/projects/freebsd-altq/altq-freebsd-5.0-current-May14.tar.gz
> Although I'm not a coder myself, I would also look for the way to patch
> the "em" driver (if "gx" is already in the initial plan), because it
> reportedly works better (for example I couldn't do NFS serving with UDP
> packets bigger than the MTU with that, while the "em" driver works OK).
Our goal is to have _all_ the drivers modified and new drivers to
use by default the new queueing handling scheme :).
Ady (@freebsd.ady.ro)
_______________________________________________________________________
| Programming in BASIC causes brain damage. |
| (Edsger Wybe Dijkstra) |
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 2:52: 1 2002
Delivered-To: freebsd-net@freebsd.org
Received: from inetfw.csl.sony.co.jp (inetfw.SonyCSL.CO.JP [218.216.66.146])
by hub.freebsd.org (Postfix) with ESMTP id E778F37B403
for <freebsd-net@freebsd.org>; Fri, 17 May 2002 02:51:56 -0700 (PDT)
Received: from hotaka.csl.sony.co.jp (hotaka.csl.sony.co.jp [43.27.98.57])
by inetfw.sonycsl.co.jp (8.11.6+3.4W/3.7Ws3/inetfw/2001101620/smtpfeed 1.12) with ESMTP id g4H9ps081369;
Fri, 17 May 2002 18:51:54 +0900 (JST)
Received: from localhost (hotaka.csl.sony.co.jp [43.27.101.57] (may be forged))
by hotaka.csl.sony.co.jp (8.11.6+3.4W/3.7Ws3/hotaka/2000061722) with ESMTP id g4H9psn26807;
Fri, 17 May 2002 18:51:54 +0900 (JST)
Date: Fri, 17 May 2002 18:51:54 +0900 (JST)
Message-Id: <20020517.185154.68053992.kjc@csl.sony.co.jp>
To: ady@freebsd.ady.ro
Cc: bra@fsn.hu, freebsd-net@freebsd.org, freebsd-altq@rofug.ro
Subject: Re: HEADS UP: ALTQ integration developer preview
From: Kenjiro Cho <kjc@csl.sony.co.jp>
In-Reply-To: <Pine.BSF.4.10.10205171213020.51675-100000@ady.warpnet.ro>
References: <Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu>
<Pine.BSF.4.10.10205171213020.51675-100000@ady.warpnet.ro>
X-Mailer: Mew version 2.2 on Emacs 20.6 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
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
Adrian Penisoara wrote:
> On Fri, 17 May 2002, Attila Nagy wrote:
> > > We have started a "ALTQ integration in FreeBSD" project which is
> > > headed towards integrating Mr. Kejiro's ALTQ framework into FreeBSD
> > > 5.0-current (and perhaps 4-stable later). The FreeBSD Core Team has been
> > > advised and we have received on principle approval. We are looking for
> > > help with committing these bits to the CVS tree.
> > Great. Do you have plans to merge OpenBSD's TCP_ECN stuff, committed
> > yesterday to the tree?
>
> Thanks for the pointer !
> I don't know yet if we will merge it, but be sure we will review it.
ECN support in TCP is independent from ALTQ, and it can be done
separately.
An ECN patch for 4.5 which doesn't require ALTQ is included in
altq-3.1. It's been in KAME since December.
If there are interests, I can make a patch for -current.
> BTW, who does the integration/maintainance of ALTQ in OpenBSD ?
I do.
-Kenjiro
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 3:22:41 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.dev.itouchnet.net (devco.net [196.15.188.2])
by hub.freebsd.org (Postfix) with ESMTP id 8B6EF37B404
for <freebsd-net@freebsd.org>; Fri, 17 May 2002 03:22:36 -0700 (PDT)
Received: from nobody by mx1.dev.itouchnet.net with scanned_ok (Exim 3.33 #2)
id 178ex3-000IZr-00
for freebsd-net@freebsd.org; Fri, 17 May 2002 12:27:09 +0200
Received: from shell.devco.net ([196.15.188.7])
by mx1.dev.itouchnet.net with esmtp (Exim 3.33 #2)
id 178ex1-000IZb-00; Fri, 17 May 2002 12:27:07 +0200
Received: from bvi by shell.devco.net with local (Exim 3.33 #4)
id 178esa-0007Sr-00; Fri, 17 May 2002 12:22:32 +0200
Date: Fri, 17 May 2002 12:22:32 +0200
From: Barry Irwin <bvi@itouchlabs.com>
To: Matthew Zahorik <matt@hottub.org>
Cc: freebsd-net@freebsd.org
Subject: Re: IPsec and dynamically assigned IPs
Message-ID: <20020517122232.A28402@itouchlabs.com>
References: <Pine.GSO.4.40.0205160858030.10618-100000@hottub>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.40.0205160858030.10618-100000@hottub>; from matt@hottub.org on Thu, May 16, 2002 at 09:30:58AM -0700
X-Checked: This message has been scanned for any virusses and unauthorized attachments.
X-iScan-ID: 71411-1021631228-21120@mx1.dev.itouchnet.net version $Name: REL_2_0_2 $
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 2002-05-16 (09:30), Matthew Zahorik wrote:
> I am unclear regarding spdadd arguments and my VPN setup.
>
> I'm attempting to replace Nortel's Contivity Extranet Client on Windows
> with a racoon/ipsec solution.
>
> I'm unsure if this is a "tunnel" or "transport" connection.
>
> I contact a fixed server at 205.173.93.x. This is a contivity switch.
> My client is an IP address assigned by RoadRunner.
>
> During IKE (user w/ SecureID hard token, aggressive mode) another IP
> address is assigned (3.179.89.x) by the contivity.
>
> How do I express this in spdadd so that I can fire off racoon?
>
>
> [client] 66.67.157.x (RoadRunner IP, dynamic, known at spdadd time)
> |
> [tunnel? endpoint] 3.179.89.x (dynamic, assigned during/after IKE)
> |
> { Internet }
> |
> [tunnel? endpoint] ?.?.?.? (fixed, traceroute shows 3.179.68.x 1st hop)
> |
> [server] 205.173.93.x (fixed, known at spdadd time)
If it is two endpoints talking directly then its transport mode
Tunnel would be somethign along the lines of:
A [client] -[vpn gw] - {internet} - [vpngw] - [server]
or
B [client] - {internet} - [vpngw] - [server]
In case A, the client and server are completely unaware of the fact there is
IPSEC involved, as all the work is performed by the gateways.
in case B the client tunnels traffic destined for server to the vpngw where
it is decapsulated adn passed onto the server.
On the case of dynamic IP's have a look at the "generate policy on;"
statement in racoon.conf. However you either need to authenticte using
aggressive mode ( in which case you can provide a username or somethign else
to look up against the password) or main mode using certificates.
On another point, I spent a couple of days hacking around with the Nortel
Client and didnt have much success :< would be great to hear if you do
Barry
--
Barry Irwin bvi@itouchlabs.com +27214875177
Systems Administrator: Networks And Security
Itouch Labs http://www.itouchlabs.com South Africa
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 3:40:36 2002
Delivered-To: freebsd-net@freebsd.org
Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95])
by hub.freebsd.org (Postfix) with SMTP id BF91C37B403
for <freebsd-net@freebsd.org>; Fri, 17 May 2002 03:40:32 -0700 (PDT)
Received: (qmail 3622 invoked by uid 1000); 17 May 2002 10:41:41 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
by localhost with SMTP; 17 May 2002 10:41:41 -0000
Date: Fri, 17 May 2002 12:41:41 +0200 (CEST)
From: Attila Nagy <bra@fsn.hu>
To: Kenjiro Cho <kjc@csl.sony.co.jp>
Cc: ady@freebsd.ady.ro, <freebsd-net@freebsd.org>,
<freebsd-altq@rofug.ro>
Subject: Re: HEADS UP: ALTQ integration developer preview
In-Reply-To: <20020517.185154.68053992.kjc@csl.sony.co.jp>
Message-ID: <Pine.LNX.4.44.0205171240360.2091-100000@scribble.fsn.hu>
References: <Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu>
<Pine.BSF.4.10.10205171213020.51675-100000@ady.warpnet.ro>
<20020517.185154.68053992.kjc@csl.sony.co.jp>
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
Hello,
> ECN support in TCP is independent from ALTQ, and it can be done
> separately. An ECN patch for 4.5 which doesn't require ALTQ is included
> in altq-3.1. It's been in KAME since December. If there are interests,
> I can make a patch for -current.
I think it would be very good to catch up on that front.
Thanks a lot.
--------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]-------
Attila Nagy e-mail: Attila.Nagy@fsn.hu
Free Software Network (FSN.HU) phone @work: +361 210 1415 (194)
cell.: +3630 306 6758
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 7:42:13 2002
Delivered-To: freebsd-net@freebsd.org
Received: from arjun.niksun.com (gwnew.niksun.com [63.148.27.34])
by hub.freebsd.org (Postfix) with ESMTP id CC7BA37B40A
for <freebsd-net@freebsd.org>; Fri, 17 May 2002 07:42:05 -0700 (PDT)
Received: from there (localhost.niksun.com [127.0.0.1])
by arjun.niksun.com (8.9.3/8.9.3) with SMTP id KAA15877;
Fri, 17 May 2002 10:41:52 -0400 (EDT)
(envelope-from arao@niksun.com)
Message-Id: <200205171441.KAA15877@arjun.niksun.com>
Content-Type: text/plain;
charset="iso-8859-1"
From: Amit Rao <arao@niksun.com>
To: jimmy@CS.cofc.EDU
Subject: for networking course exercises Re: [freebsd-net]
Date: Fri, 17 May 2002 10:45:59 -0400
X-Mailer: KMail [version 1.3.2]
References: <1021596067.311.91849.m12@yahoogroups.com>
In-Reply-To: <1021596067.311.91849.m12@yahoogroups.com>
Cc: freebsd-net@freebsd.org
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
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
Jimmy,
Take a look at http://www.netlab.ohio-state.edu/cise/
On Thursday 16 May 2002 08:41 pm, you wrote:
> Date: Thu, 16 May 2002 20:24:45 -0400
> From: "James B. Wilkinson" <jimmy@CS.cofc.EDU>
> Subject: (unknown)
>
> I've got to teach a new graduate course in networking this fall. I'm
> looking at using vol 1 and maybe vol 2 of "TCP/IP Illustrated" by
> Richard Stevens. The basic premise of the book seems to be to do
> experiments on a working network in order to learn about the
> protocols. One thing that I thought about doing is to have them do
> that sort of thing here as well as to read about what he did to do
> the book. It seemed useful to me to have some of the machines set up
> with a version of FreeBSD that let you fool around with what the IP
> and TCP layers were doing. E.g. introduce delays in the transmission
> of ack's so that packets get retransmitted or so that you can watch
> the RTT estimate catch up. Maybe pick out particular TCP segments and
> lose them. When I started looking at how one might do this, it seemed
> like it might be hard. So I got to wondering if somebody had already
> done it so that I don't have to. I have no idea how to do a Google
> search for something like that.
>
> Do any of you guys know about any software like that. I spose it
> would have to be a hacked version of a kernel.
>
> Thanks
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 8:19:27 2002
Delivered-To: freebsd-net@freebsd.org
Received: from hottub.hottub.org (hottub.org [66.60.164.74])
by hub.freebsd.org (Postfix) with ESMTP id 5198E37B40A
for <freebsd-net@freebsd.org>; Fri, 17 May 2002 08:19:24 -0700 (PDT)
Received: by hottub.hottub.org (Postfix, from userid 1100)
id DCFC8213BC; Fri, 17 May 2002 08:17:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by hottub.hottub.org (Postfix) with ESMTP
id D07EC213BB; Fri, 17 May 2002 08:17:22 -0700 (PDT)
Date: Fri, 17 May 2002 08:17:22 -0700 (PDT)
From: Matthew Zahorik <matt@hottub.org>
X-X-Sender: matt@hottub
To: Barry Irwin <bvi@itouchlabs.com>
Cc: freebsd-net@freebsd.org
Subject: Re: IPsec and dynamically assigned IPs
In-Reply-To: <20020517122232.A28402@itouchlabs.com>
Message-ID: <Pine.GSO.4.40.0205170812160.10618-100000@hottub>
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, 17 May 2002, Barry Irwin wrote:
> B [client] - {internet} - [vpngw] - [server]
It would be a tunnel like B. The "[vpngw]" on the client side is software
running on the client. The "[vpngw]" on the other side is a contivity
switch. I'm trying to reach servers on the other side of the contivity.
> On the case of dynamic IP's have a look at the "generate policy on;"
> statement in racoon.conf. However you either need to authenticte using
> aggressive mode ( in which case you can provide a username or somethign else
> to look up against the password) or main mode using certificates.
I'm pretty confident about racoon configuration. spdadd (seems to)
require(s) fixed tunnel endpoints before I can start racoon, and that's
the mystery.
When I have a spare moment (not this week) I'll futz with spdadd and see
if giving bogus values to spdadd to start and then using generate policy
on; will work.
Thanks for the replies!
- Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 11: 1:39 2002
Delivered-To: freebsd-net@freebsd.org
Received: from patrocles.silby.com (d68.as4.nwbl0.wi.voyager.net [169.207.137.68])
by hub.freebsd.org (Postfix) with ESMTP id A919437B400
for <freebsd-net@freebsd.org>; Fri, 17 May 2002 11:01:34 -0700 (PDT)
Received: from patrocles.silby.com (localhost [127.0.0.1])
by patrocles.silby.com (8.12.3/8.12.3) with ESMTP id g4HHxHUm024870;
Fri, 17 May 2002 12:59:17 -0500 (CDT)
(envelope-from silby@silby.com)
Received: from localhost (silby@localhost)
by patrocles.silby.com (8.12.3/8.12.3/Submit) with ESMTP id g4HHwVHX024867;
Fri, 17 May 2002 12:58:35 -0500 (CDT)
X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs
Date: Fri, 17 May 2002 12:58:31 -0500 (CDT)
From: Mike Silbersack <silby@silby.com>
To: Kenjiro Cho <kjc@csl.sony.co.jp>
Cc: ady@freebsd.ady.ro, <bra@fsn.hu>, <freebsd-net@freebsd.org>,
<freebsd-altq@rofug.ro>
Subject: Re: HEADS UP: ALTQ integration developer preview
In-Reply-To: <20020517.185154.68053992.kjc@csl.sony.co.jp>
Message-ID: <20020517125609.O24469-100000@patrocles.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 Fri, 17 May 2002, Kenjiro Cho wrote:
> ECN support in TCP is independent from ALTQ, and it can be done
> separately.
> An ECN patch for 4.5 which doesn't require ALTQ is included in
> altq-3.1. It's been in KAME since December.
> If there are interests, I can make a patch for -current.
Personally, I hope we keep ECN support out of the tree; it's unlikely to
provide any benefit over the internet in general, and will just make
integrating other TCP changes more difficult.
I haven't looked over the ALTQ patches, but integration of those changes
sounds 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 Fri May 17 12:32:24 2002
Delivered-To: freebsd-net@freebsd.org
Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12])
by hub.freebsd.org (Postfix) with ESMTP
id 11B2237B40D; Fri, 17 May 2002 12:32:20 -0700 (PDT)
Received: from pool0392.cvx22-bradley.dialup.earthlink.net ([209.179.199.137] helo=mindspring.com)
by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #2)
id 178nST-0003Jv-00; Fri, 17 May 2002 12:32:09 -0700
Message-ID: <3CE55A9B.73EA3DE4@mindspring.com>
Date: Fri, 17 May 2002 12:31:39 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Attila Nagy <bra@fsn.hu>
Cc: Adrian Penisoara <ady@freebsd.ady.ro>, freebsd-arch@freebsd.org,
freebsd-net@freebsd.org
Subject: Re: HEADS UP: ALTQ integration developer preview
References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro> <Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu>
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
Attila Nagy wrote:
> Although I'm not a coder myself, I would also look for the way to patch
> the "em" driver (if "gx" is already in the initial plan), because it
> reportedly works better (for example I couldn't do NFS serving with UDP
> packets bigger than the MTU with that, while the "em" driver works OK).
???
It *does* frag packets bigger than the MTU, right?
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 22:39:57 2002
Delivered-To: freebsd-net@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
by hub.freebsd.org (Postfix) with ESMTP
id D8CC337B408; Fri, 17 May 2002 22:39:51 -0700 (PDT)
Received: (from ken@localhost)
by panzer.kdm.org (8.11.6/8.9.1) id g4I5dot36191;
Fri, 17 May 2002 23:39:50 -0600 (MDT)
(envelope-from ken)
Date: Fri, 17 May 2002 23:39:50 -0600
From: "Kenneth D. Merry" <ken@kdm.org>
To: current@FreeBSD.org
Cc: net@FreeBSD.org
Subject: new zero copy sockets patches available
Message-ID: <20020517233950.A36169@panzer.kdm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
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 released a new set of zero copy sockets patches, against -current
from today (May 17th, 2002).
The main change is to deal with the vfs_ioopt changes that Alan Cox made in
kern_subr.c. (They conflicted a bit with the zero copy receive code.)
The patches and the FAQ are available here:
http://people.freebsd.org/~ken/zero_copy/
Comments, questions and reviews are all welcome!
Ken
--
Kenneth Merry
ken@kdm.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 22:45: 6 2002
Delivered-To: freebsd-net@freebsd.org
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
by hub.freebsd.org (Postfix) with ESMTP id 4501937B406
for <freebsd-net@FreeBSD.ORG>; Fri, 17 May 2002 22:45:03 -0700 (PDT)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id WAA43342;
Fri, 17 May 2002 22:30:14 -0700 (PDT)
Received: (from archie@localhost)
by arch20m.dellroad.org (8.11.6/8.11.6) id g4I5TqI41036;
Fri, 17 May 2002 22:29:52 -0700 (PDT)
(envelope-from archie)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200205180529.g4I5TqI41036@arch20m.dellroad.org>
Subject: Re: IPsec and dynamically assigned IPs
In-Reply-To: <20020517122232.A28402@itouchlabs.com> "from Barry Irwin at May
17, 2002 12:22:32 pm"
To: Barry Irwin <bvi@itouchlabs.com>
Date: Fri, 17 May 2002 22:29:52 -0700 (PDT)
Cc: Matthew Zahorik <matt@hottub.org>, freebsd-net@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
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
Barry Irwin writes:
> On another point, I spent a couple of days hacking around with the Nortel
> Client and didnt have much success :< would be great to hear if you do
It is not normally possible to get the Nortel client to work with
non-Nortel IPSec servers because they purposefully mangle the shared
secret in a proprietary way so that their clients only work with
their servers.
The Nortel clients come free; they make money by selling the server
(not other companies' servers :-)
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 23: 3: 4 2002
Delivered-To: freebsd-net@freebsd.org
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
by hub.freebsd.org (Postfix) with ESMTP
id E877937B403; Fri, 17 May 2002 23:02:55 -0700 (PDT)
Received: by elvis.mu.org (Postfix, from userid 1192)
id B9EA6AE1FB; Fri, 17 May 2002 23:02:55 -0700 (PDT)
Date: Fri, 17 May 2002 23:02:55 -0700
From: Alfred Perlstein <bright@mu.org>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: current@FreeBSD.org, net@FreeBSD.org
Subject: Re: new zero copy sockets patches available
Message-ID: <20020518060255.GN20683@elvis.mu.org>
References: <20020517233950.A36169@panzer.kdm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020517233950.A36169@panzer.kdm.org>
User-Agent: Mutt/1.3.27i
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
* Kenneth D. Merry <ken@kdm.org> [020517 22:40] wrote:
>
> I have released a new set of zero copy sockets patches, against -current
> from today (May 17th, 2002).
>
> The main change is to deal with the vfs_ioopt changes that Alan Cox made in
> kern_subr.c. (They conflicted a bit with the zero copy receive code.)
>
> The patches and the FAQ are available here:
>
> http://people.freebsd.org/~ken/zero_copy/
>
> Comments, questions and reviews are all welcome!
jumbo_vm_init() has a bunch of bugs
first it doesn't work right if called concurrently.
you need to protect the initialization of jumbo_vm_object otherwise
bad things can happen. my suggestion is to store the results of
vm_object_allocate into a temporary, grab the mutex and then check
to see if jumbo_vm_object has been initialized again if it has then
free the object, otherwise store the allocated object into the
global and continue.
you may not call malloc(9) with M_WAITOK while holding a mutex.
---
entry = jumbo_kmap_inuse.slh_first;
I'm sure that should use a list macro.
---
That's all I see off the bat. :) Looks cool though.
--
-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.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Fri May 17 23:31:12 2002
Delivered-To: freebsd-net@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
by hub.freebsd.org (Postfix) with ESMTP
id 46D8F37B400; Fri, 17 May 2002 23:30:49 -0700 (PDT)
Received: (from ken@localhost)
by panzer.kdm.org (8.11.6/8.9.1) id g4I6UkX36632;
Sat, 18 May 2002 00:30:46 -0600 (MDT)
(envelope-from ken)
Date: Sat, 18 May 2002 00:30:46 -0600
From: "Kenneth D. Merry" <ken@kdm.org>
To: Alfred Perlstein <bright@mu.org>
Cc: current@FreeBSD.org, net@FreeBSD.org
Subject: Re: new zero copy sockets patches available
Message-ID: <20020518003046.A36510@panzer.kdm.org>
References: <20020517233950.A36169@panzer.kdm.org> <20020518060255.GN20683@elvis.mu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20020518060255.GN20683@elvis.mu.org>; from bright@mu.org on Fri, May 17, 2002 at 11:02:55PM -0700
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, May 17, 2002 at 23:02:55 -0700, Alfred Perlstein wrote:
> * Kenneth D. Merry <ken@kdm.org> [020517 22:40] wrote:
> >
> > I have released a new set of zero copy sockets patches, against -current
> > from today (May 17th, 2002).
> >
> > The main change is to deal with the vfs_ioopt changes that Alan Cox made in
> > kern_subr.c. (They conflicted a bit with the zero copy receive code.)
> >
> > The patches and the FAQ are available here:
> >
> > http://people.freebsd.org/~ken/zero_copy/
> >
> > Comments, questions and reviews are all welcome!
>
> jumbo_vm_init() has a bunch of bugs
>
> first it doesn't work right if called concurrently.
> you need to protect the initialization of jumbo_vm_object otherwise
> bad things can happen. my suggestion is to store the results of
> vm_object_allocate into a temporary, grab the mutex and then check
> to see if jumbo_vm_object has been initialized again if it has then
> free the object, otherwise store the allocated object into the
> global and continue.
The problem here is that the mutex needs to be initialized before I can
acquire it, and there's going to be a race between checking to see
whether it has been initialized and actually initializing it.
e.g.:
if (!mtx_initialized(&jumbo_mutex))
mtx_init(&jumbo_mutex, "jumbo mutex", NULL, MTX_DEF);
mtx_lock(&jumbo_mutex);
if (jumbo_vm_object != NULL) {
mtx_unlock(&jumbo_mutex);
return (1);
}
/* allocate our object */
jumbo_vm_object = vm_object_allocate(OBJT_DEFAULT, JUMBO_MAX_PAGES);
The above would work, I think, if it weren't for the race in the mutex
initialization, and assuming I can allocate a vm object while holding
the jumbo mutex.
Suggestions?
> you may not call malloc(9) with M_WAITOK while holding a mutex.
Ahh, okay.
> entry = jumbo_kmap_inuse.slh_first;
>
> I'm sure that should use a list macro.
Yes, SLIST_FIRST(), thanks.
> That's all I see off the bat. :) Looks cool though.
Cool, thanks for the feedback!
Ken
--
Kenneth Merry
ken@kdm.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 1:20:44 2002
Delivered-To: freebsd-net@freebsd.org
Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95])
by hub.freebsd.org (Postfix) with SMTP id AFAC237B408
for <freebsd-net@freebsd.org>; Sat, 18 May 2002 01:20:39 -0700 (PDT)
Received: (qmail 10131 invoked by uid 1000); 18 May 2002 08:21:55 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
by localhost with SMTP; 18 May 2002 08:21:55 -0000
Date: Sat, 18 May 2002 10:21:55 +0200 (CEST)
From: Attila Nagy <bra@fsn.hu>
To: Terry Lambert <tlambert2@mindspring.com>
Cc: freebsd-arch@freebsd.org, <freebsd-net@freebsd.org>
Subject: Re: HEADS UP: ALTQ integration developer preview
In-Reply-To: <3CE55A9B.73EA3DE4@mindspring.com>
Message-ID: <Pine.LNX.4.44.0205181018300.10011-100000@scribble.fsn.hu>
References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro>
<Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu>
<3CE55A9B.73EA3DE4@mindspring.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
Hello,
> > the "em" driver (if "gx" is already in the initial plan), because it
> > reportedly works better (for example I couldn't do NFS serving with UDP
> > packets bigger than the MTU with that, while the "em" driver works OK).
> It *does* frag packets bigger than the MTU, right?
netstat didn't show any errors regarding to that. If I used an NFS
readsize, smaller than the 1500 bytes MTU it worked (was slow, but
worked).
netstat's frag counters were increased.
I couldn't use tcpdump (I had no bpf support) to see what happens on the
wire...
--------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]-------
Attila Nagy e-mail: Attila.Nagy@fsn.hu
Free Software Network (FSN.HU) phone @work: +361 210 1415 (194)
cell.: +3630 306 6758
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 1:54: 0 2002
Delivered-To: freebsd-net@freebsd.org
Received: from goose.prod.itd.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18])
by hub.freebsd.org (Postfix) with ESMTP
id 3E8B837B40F; Sat, 18 May 2002 01:53:45 -0700 (PDT)
Received: from pool0026.cvx40-bradley.dialup.earthlink.net ([216.244.42.26] helo=mindspring.com)
by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #2)
id 178zyA-0004Pw-00; Sat, 18 May 2002 01:53:43 -0700
Message-ID: <3CE61675.BCE2A9E1@mindspring.com>
Date: Sat, 18 May 2002 01:53:09 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Attila Nagy <bra@fsn.hu>
Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org
Subject: Re: HEADS UP: ALTQ integration developer preview
References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro>
<Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu>
<3CE55A9B.73EA3DE4@mindspring.com> <Pine.LNX.4.44.0205181018300.10011-100000@scribble.fsn.hu>
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
Attila Nagy wrote:
> > > the "em" driver (if "gx" is already in the initial plan), because it
> > > reportedly works better (for example I couldn't do NFS serving with UDP
> > > packets bigger than the MTU with that, while the "em" driver works OK).
> >
> > It *does* frag packets bigger than the MTU, right?
>
> netstat didn't show any errors regarding to that. If I used an NFS
> readsize, smaller than the 1500 bytes MTU it worked (was slow, but
> worked).
> netstat's frag counters were increased.
> I couldn't use tcpdump (I had no bpf support) to see what happens on the
> wire...
Sending datagrams bigger than the MTU is a bad idea.
I would be real tempted to drop the packets and send "don't fragment"
ICMP responses to beat up anyone who abused UDP by sending larger
than the MTU.
I guess this is about Linux UDP NFS clients, in particular.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 2: 0:37 2002
Delivered-To: freebsd-net@freebsd.org
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
by hub.freebsd.org (Postfix) with ESMTP
id 0264037B405; Sat, 18 May 2002 02:00:33 -0700 (PDT)
Received: by elvis.mu.org (Postfix, from userid 1192)
id D5EDEAE1D1; Sat, 18 May 2002 02:00:32 -0700 (PDT)
Date: Sat, 18 May 2002 02:00:32 -0700
From: Alfred Perlstein <bright@mu.org>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: current@FreeBSD.org, net@FreeBSD.org
Subject: Re: new zero copy sockets patches available
Message-ID: <20020518090032.GO20683@elvis.mu.org>
References: <20020517233950.A36169@panzer.kdm.org> <20020518060255.GN20683@elvis.mu.org> <20020518003046.A36510@panzer.kdm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020518003046.A36510@panzer.kdm.org>
User-Agent: Mutt/1.3.27i
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
* Kenneth D. Merry <ken@kdm.org> [020517 23:31] wrote:
>
> The problem here is that the mutex needs to be initialized before I can
> acquire it, and there's going to be a race between checking to see
> whether it has been initialized and actually initializing it.
>
...
> Suggestions?
*slaps forhead*
Probably a SYSINIT?
> Cool, thanks for the feedback!
np, this is promising work!
--
-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.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 2: 9:37 2002
Delivered-To: freebsd-net@freebsd.org
Received: from goose.prod.itd.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18])
by hub.freebsd.org (Postfix) with ESMTP
id 4F1C637B405; Sat, 18 May 2002 02:09:33 -0700 (PDT)
Received: from pool0026.cvx40-bradley.dialup.earthlink.net ([216.244.42.26] helo=mindspring.com)
by goose.prod.itd.earthlink.net with esmtp (Exim 3.33 #2)
id 1790DP-0002Gf-00; Sat, 18 May 2002 02:09:27 -0700
Message-ID: <3CE61A25.61C789FA@mindspring.com>
Date: Sat, 18 May 2002 02:08:53 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alfred Perlstein <bright@mu.org>
Cc: "Kenneth D. Merry" <ken@kdm.org>, current@FreeBSD.org,
net@FreeBSD.org
Subject: Re: new zero copy sockets patches available
References: <20020517233950.A36169@panzer.kdm.org> <20020518060255.GN20683@elvis.mu.org> <20020518003046.A36510@panzer.kdm.org> <20020518090032.GO20683@elvis.mu.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
Alfred Perlstein wrote:
> * Kenneth D. Merry <ken@kdm.org> [020517 23:31] wrote:
> > The problem here is that the mutex needs to be initialized before I can
> > acquire it, and there's going to be a race between checking to see
> > whether it has been initialized and actually initializing it.
> >
> ...
> > Suggestions?
>
> *slaps forhead*
>
> Probably a SYSINIT?
God, it's annoying that a statically declared mutex is not
defacto initialized.
Yeah, I understand the "witness" crap (if it's there); that
doesn't make it any less annoying.
Actually, a linker set (not a SYSINIT) could fix that... you
would still need one sysinit to do the linkage of the statically
declared structures, but it's at least doable.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 3:13:28 2002
Delivered-To: freebsd-net@freebsd.org
Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58])
by hub.freebsd.org (Postfix) with ESMTP
id 7D9F037B40C; Sat, 18 May 2002 03:13:14 -0700 (PDT)
Received: (from jhay@localhost)
by zibbi.icomtek.csir.co.za (8.11.6/8.11.6) id g4IACfe52918;
Sat, 18 May 2002 12:12:41 +0200 (SAT)
(envelope-from jhay)
From: John Hay <jhay@icomtek.csir.co.za>
Message-Id: <200205181012.g4IACfe52918@zibbi.icomtek.csir.co.za>
Subject: Re: HEADS UP: ALTQ integration developer preview
In-Reply-To: <3CE61675.BCE2A9E1@mindspring.com> from Terry Lambert at "May 18, 2002 01:53:09 am"
To: tlambert2@mindspring.com (Terry Lambert)
Date: Sat, 18 May 2002 12:12:41 +0200 (SAT)
Cc: bra@fsn.hu (Attila Nagy), freebsd-arch@FreeBSD.ORG,
freebsd-net@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
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
> Attila Nagy wrote:
> > > > the "em" driver (if "gx" is already in the initial plan), because it
> > > > reportedly works better (for example I couldn't do NFS serving with UDP
> > > > packets bigger than the MTU with that, while the "em" driver works OK).
> > >
> > > It *does* frag packets bigger than the MTU, right?
> >
> > netstat didn't show any errors regarding to that. If I used an NFS
> > readsize, smaller than the 1500 bytes MTU it worked (was slow, but
> > worked).
> > netstat's frag counters were increased.
> > I couldn't use tcpdump (I had no bpf support) to see what happens on the
> > wire...
>
> Sending datagrams bigger than the MTU is a bad idea.
>
> I would be real tempted to drop the packets and send "don't fragment"
> ICMP responses to beat up anyone who abused UDP by sending larger
> than the MTU.
>
> I guess this is about Linux UDP NFS clients, in particular.
If this is the same "problem" nfs had all the years, then nobody is
violating the MTU. What was happening is this: NFS sends a big packet (for
efficiency) and that gets fragmented by the ip layer and then sent as so
many back to back packets. If the card on the receiving could not receive
so many back to back packets and looses one or more, nfs will get stuck
retrying the same big packet and the same thing happening over and over.
John
--
John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 3:20: 4 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138])
by hub.freebsd.org (Postfix) with ESMTP id C8C0A37B405
for <freebsd-net@freebsd.org>; Sat, 18 May 2002 03:19:56 -0700 (PDT)
Received: from areilly.bpc-users.org ([144.135.25.78]) by
mta06ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP
id GWAY1600.D3G for <freebsd-net@freebsd.org>; Sat, 18 May 2002
20:19:54 +1000
Received: from CPE-144-132-243-222.nsw.bigpond.net.au ([144.132.243.222]) by PSMAM04.mailsvc.email.bigpond.com(MailRouter V3.0m 92/2528095); 18 May 2002 20:19:54
Received: (qmail 2268 invoked from network); 18 May 2002 10:19:54 -0000
Received: from localhost (andrew@127.0.0.1)
by localhost with SMTP; 18 May 2002 10:19:54 -0000
Subject: Re: HEADS UP: ALTQ integration developer preview
From: Andrew Reilly <areilly@bigpond.net.au>
To: Terry Lambert <tlambert2@mindspring.com>
Cc: Attila Nagy <bra@fsn.hu>, freebsd-arch@freebsd.org,
freebsd-net@freebsd.org
In-Reply-To: <3CE61675.BCE2A9E1@mindspring.com>
References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro>
<Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu>
<3CE55A9B.73EA3DE4@mindspring.com>
<Pine.LNX.4.44.0205181018300.10011-100000@scribble.fsn.hu>
<3CE61675.BCE2A9E1@mindspring.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5
Date: 18 May 2002 20:19:54 +1000
Message-Id: <1021717195.1466.4.camel@gurney.reilly.home>
Mime-Version: 1.0
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, 2002-05-18 at 18:53, Terry Lambert wrote:
>
> Sending datagrams bigger than the MTU is a bad idea.
>
> I would be real tempted to drop the packets and send "don't fragment"
> ICMP responses to beat up anyone who abused UDP by sending larger
> than the MTU.
>
> I guess this is about Linux UDP NFS clients, in particular.
Eh? Isn't the original, traditional and best NFS configuration 8k UDP
packets?
Sure worked fine that way on SunOS-4 those many years ago. (On LANs, of
course. No one does NFS over the internet. I hope.)
--
Andrew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 4:41:53 2002
Delivered-To: freebsd-net@freebsd.org
Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95])
by hub.freebsd.org (Postfix) with SMTP id 0201937B411
for <freebsd-net@freebsd.org>; Sat, 18 May 2002 04:41:47 -0700 (PDT)
Received: (qmail 11036 invoked by uid 1000); 18 May 2002 11:43:04 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
by localhost with SMTP; 18 May 2002 11:43:04 -0000
Date: Sat, 18 May 2002 13:43:04 +0200 (CEST)
From: Attila Nagy <bra@fsn.hu>
To: Terry Lambert <tlambert2@mindspring.com>
Cc: freebsd-arch@freebsd.org, <freebsd-net@freebsd.org>
Subject: Re: HEADS UP: ALTQ integration developer preview
In-Reply-To: <3CE61675.BCE2A9E1@mindspring.com>
Message-ID: <Pine.LNX.4.44.0205181336380.10862-100000@scribble.fsn.hu>
References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro>
<Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu>
<3CE55A9B.73EA3DE4@mindspring.com> <Pine.LNX.4.44.0205181018300.10011-100000@scribble.fsn.hu>
<3CE61675.BCE2A9E1@mindspring.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
Hello,
> Sending datagrams bigger than the MTU is a bad idea.
It depends on what do you want to do with that NFS server :)
I want to get out from that several hundred megabits per second, so I
can't use <1500 bytes MTU.
Just for comparison:
when using <1500 bytes MTU (as close as possible to the limit) I can
achieve about 1-1.5 MBps throughput.
When using 32768 bytes MTU I can get around 190 Mbps out from a PIII 450.
(and only 190 Mbps because the two frontends have fast ethernet cards)
So why this is so bad? If the other end can keep up, it will increase
throughput.
BTW, the default UDP readsize is above 1500 bytes, so I couldn't use the
server with a simple NFS mount.
When I replaced the gx driver to em it just started to work. Now I am
using TCP and 32k readsize with 64k tcp.sendspace and recvspace (I could
nearly double the performance with setting these from the default values).
So I am happy with it, I just took a note that the gx driver has some
problems in these cases.
> I would be real tempted to drop the packets and send "don't fragment"
> ICMP responses to beat up anyone who abused UDP by sending larger than
> the MTU.
That's another point. I want performance :)
> I guess this is about Linux UDP NFS clients, in particular.
Nope, both the server and the client side is FreeBSD stable.
--------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]-------
Attila Nagy e-mail: Attila.Nagy@fsn.hu
Free Software Network (FSN.HU) phone @work: +361 210 1415 (194)
cell.: +3630 306 6758
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 4:43:35 2002
Delivered-To: freebsd-net@freebsd.org
Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95])
by hub.freebsd.org (Postfix) with SMTP id A5EBE37B40F
for <freebsd-net@FreeBSD.ORG>; Sat, 18 May 2002 04:43:30 -0700 (PDT)
Received: (qmail 11048 invoked by uid 1000); 18 May 2002 11:44:48 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
by localhost with SMTP; 18 May 2002 11:44:48 -0000
Date: Sat, 18 May 2002 13:44:48 +0200 (CEST)
From: Attila Nagy <bra@fsn.hu>
To: John Hay <jhay@icomtek.csir.co.za>
Cc: freebsd-arch@FreeBSD.ORG, <freebsd-net@FreeBSD.ORG>
Subject: Re: HEADS UP: ALTQ integration developer preview
In-Reply-To: <200205181012.g4IACfe52918@zibbi.icomtek.csir.co.za>
Message-ID: <Pine.LNX.4.44.0205181343360.10862-100000@scribble.fsn.hu>
References: <200205181012.g4IACfe52918@zibbi.icomtek.csir.co.za>
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
Hello,
> If the card on the receiving could not receive so many back to back
> packets and looses one or more, nfs will get stuck retrying the same big
> packet and the same thing happening over and over.
Yep, but that's not my case. If this would be the problem, I guess
changing from gx to em wouldn't help me...
--------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]-------
Attila Nagy e-mail: Attila.Nagy@fsn.hu
Free Software Network (FSN.HU) phone @work: +361 210 1415 (194)
cell.: +3630 306 6758
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 5:39:59 2002
Delivered-To: freebsd-net@freebsd.org
Received: from charon.0x54434D.net (pD95353C7.dip.t-dialin.net [217.83.83.199])
by hub.freebsd.org (Postfix) with ESMTP id 6BB4537B40C
for <freebsd-net@freebsd.org>; Sat, 18 May 2002 05:39:56 -0700 (PDT)
Received: from 0x54434D.net (powerbox.tcm.lan [192.168.1.11])
by charon.0x54434D.net (Postfix) with ESMTP id F36463E29
for <freebsd-net@freebsd.org>; Sat, 18 May 2002 14:39:53 +0200 (CEST)
Message-ID: <3CE64B9B.1040407@0x54434D.net>
Date: Sat, 18 May 2002 14:39:55 +0200
From: Nino Dehne <freebsd-net@0x54434D.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-net@freebsd.org
Subject: Intel Etherexpress Pro/100S settings
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
hi -net,
recently i acquired a pair of above cards, one of which i use with w2k
and the other with freebsd's fxp(4). with w2k i am able to set various
options using intel's proset utility (cpu usage vs. throughput, pci bus
efficiency etc.). my question is: are these settings stored into the
system config or into the card itself? i.e. does it make sense to config
a card with w2k first and then put it into the freebsd box? or is
ifconfig(8)'s link0 option for the fxp driver the only knob to twiddle?
tia
nino
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 6: 4:17 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216])
by hub.freebsd.org (Postfix) with ESMTP id 3CE0837B407
for <net@FreeBSD.org>; Sat, 18 May 2002 06:03:54 -0700 (PDT)
Received: (qmail 23564 invoked from network); 18 May 2002 13:03:52 -0000
Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender <jhb@FreeBSD.org>)
by mail16.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP
for <bright@mu.org>; 18 May 2002 13:03:52 -0000
Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4])
by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g4ID3oF82147;
Sat, 18 May 2002 09:03:50 -0400 (EDT)
(envelope-from jhb@FreeBSD.org)
Message-ID: <XFMail.20020518090338.jhb@FreeBSD.org>
X-Mailer: XFMail 1.5.2 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20020518003046.A36510@panzer.kdm.org>
Date: Sat, 18 May 2002 09:03:38 -0400 (EDT)
From: John Baldwin <jhb@FreeBSD.org>
To: "Kenneth D. Merry" <ken@kdm.org>
Subject: Re: new zero copy sockets patches available
Cc: net@FreeBSD.org, current@FreeBSD.org,
Alfred Perlstein <bright@mu.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 18-May-2002 Kenneth D. Merry wrote:
> On Fri, May 17, 2002 at 23:02:55 -0700, Alfred Perlstein wrote:
>> * Kenneth D. Merry <ken@kdm.org> [020517 22:40] wrote:
>> >
>> > I have released a new set of zero copy sockets patches, against -current
>> > from today (May 17th, 2002).
>> >
>> > The main change is to deal with the vfs_ioopt changes that Alan Cox made
>> > in
>> > kern_subr.c. (They conflicted a bit with the zero copy receive code.)
>> >
>> > The patches and the FAQ are available here:
>> >
>> > http://people.freebsd.org/~ken/zero_copy/
>> >
>> > Comments, questions and reviews are all welcome!
>>
>> jumbo_vm_init() has a bunch of bugs
>>
>> first it doesn't work right if called concurrently.
>> you need to protect the initialization of jumbo_vm_object otherwise
>> bad things can happen. my suggestion is to store the results of
>> vm_object_allocate into a temporary, grab the mutex and then check
>> to see if jumbo_vm_object has been initialized again if it has then
>> free the object, otherwise store the allocated object into the
>> global and continue.
>
> The problem here is that the mutex needs to be initialized before I can
> acquire it, and there's going to be a race between checking to see
> whether it has been initialized and actually initializing it.
>
> e.g.:
>
> if (!mtx_initialized(&jumbo_mutex))
> mtx_init(&jumbo_mutex, "jumbo mutex", NULL, MTX_DEF);
>
> mtx_lock(&jumbo_mutex);
>
> if (jumbo_vm_object != NULL) {
> mtx_unlock(&jumbo_mutex);
> return (1);
> }
>
> /* allocate our object */
> jumbo_vm_object = vm_object_allocate(OBJT_DEFAULT, JUMBO_MAX_PAGES);
>
> The above would work, I think, if it weren't for the race in the mutex
> initialization, and assuming I can allocate a vm object while holding
> the jumbo mutex.
>
> Suggestions?
Either use a sysinit or something gross like this:
static int jumbo_init = 0;
...
while (jumbo_init != 2) {
if (atomic_cmpset_acq_int(&jumbo_init, 0, 1) {
mtx_init(&jumbo_mutex, "jumbo_mutex", NULL, MTX_DEF);
atomic_store_rel_int(&jumbo_init, 2);
}
}
mtx_lock(&jumbo_mutex);
...
a sysinit is probably best though.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 6: 4:59 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217])
by hub.freebsd.org (Postfix) with ESMTP id E6FD637B409
for <net@FreeBSD.org>; Sat, 18 May 2002 06:03:54 -0700 (PDT)
Received: (qmail 23408 invoked from network); 18 May 2002 13:03:54 -0000
Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender <jhb@FreeBSD.org>)
by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP
for <bright@mu.org>; 18 May 2002 13:03:54 -0000
Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4])
by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g4ID3qF82151;
Sat, 18 May 2002 09:03:52 -0400 (EDT)
(envelope-from jhb@FreeBSD.org)
Message-ID: <XFMail.20020518090340.jhb@FreeBSD.org>
X-Mailer: XFMail 1.5.2 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <3CE61A25.61C789FA@mindspring.com>
Date: Sat, 18 May 2002 09:03:40 -0400 (EDT)
From: John Baldwin <jhb@FreeBSD.org>
To: Terry Lambert <tlambert2@mindspring.com>
Subject: Re: new zero copy sockets patches available
Cc: net@FreeBSD.org, current@FreeBSD.org,
"Kenneth D. Merry" <ken@kdm.org>, Alfred Perlstein <bright@mu.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 18-May-2002 Terry Lambert wrote:
> Alfred Perlstein wrote:
>> * Kenneth D. Merry <ken@kdm.org> [020517 23:31] wrote:
>> > The problem here is that the mutex needs to be initialized before I can
>> > acquire it, and there's going to be a race between checking to see
>> > whether it has been initialized and actually initializing it.
>> >
>> ...
>> > Suggestions?
>>
>> *slaps forhead*
>>
>> Probably a SYSINIT?
>
> God, it's annoying that a statically declared mutex is not
> defacto initialized.
Is it in solaris?
> Yeah, I understand the "witness" crap (if it's there); that
> doesn't make it any less annoying.
>
> Actually, a linker set (not a SYSINIT) could fix that... you
> would still need one sysinit to do the linkage of the statically
> declared structures, but it's at least doable.
a SYSINIT just is a linker set, and there is a convenience SYSINIT
MTX_SYSINIT() or what not that just registers a sysinit to initialize
a mutex.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 7:42:43 2002
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 89D4037B401; Sat, 18 May 2002 07:42:31 -0700 (PDT)
Received: from fledge.watson.org (localhost [127.0.0.1])
by fledge.watson.org (8.12.3/8.12.3) with ESMTP id g4IEZGb4072709;
Sat, 18 May 2002 10:35:16 -0400 (EDT)
(envelope-from arr@FreeBSD.org)
Received: from localhost (arr@localhost)
by fledge.watson.org (8.12.3/8.12.3/Submit) with SMTP id g4IEZFuK072706;
Sat, 18 May 2002 10:35:16 -0400 (EDT)
X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs
Date: Sat, 18 May 2002 10:35:15 -0400 (EDT)
From: "Andrew R. Reiter" <arr@FreeBSD.org>
X-Sender: arr@fledge.watson.org
To: Alfred Perlstein <bright@mu.org>
Cc: "Kenneth D. Merry" <ken@kdm.org>, current@FreeBSD.org,
net@FreeBSD.org
Subject: Re: new zero copy sockets patches available
In-Reply-To: <3CE61A25.61C789FA@mindspring.com>
Message-ID: <Pine.NEB.3.96L.1020518103433.72698A-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
:Alfred Perlstein wrote:
:> * Kenneth D. Merry <ken@kdm.org> [020517 23:31] wrote:
:> > The problem here is that the mutex needs to be initialized before I can
:> > acquire it, and there's going to be a race between checking to see
:> > whether it has been initialized and actually initializing it.
:> >
:> ...
:> > Suggestions?
:>
:> *slaps forhead*
:>
:> Probably a SYSINIT?
mutex(9) and sx(9) describe two macros for this purpose.
--
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 Sat May 18 9:28:35 2002
Delivered-To: freebsd-net@freebsd.org
Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3])
by hub.freebsd.org (Postfix) with ESMTP id 5207837B40F
for <freebsd-net@freebsd.org>; Sat, 18 May 2002 09:28:29 -0700 (PDT)
Received: from localhost (eddy@localhost)
by a.mx.everquick.net (8.11.6/8.10.2) with ESMTP id g4IGSSf15678
for <freebsd-net@freebsd.org>; Sat, 18 May 2002 16:28:28 GMT
X-EverQuick-No-Abuse: Report any e-mail abuse to <abuse@noc.everquick.net>
Date: Sat, 18 May 2002 16:28:28 +0000 (GMT)
From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net>
To: freebsd-net@freebsd.org
Subject: VRRP and SIOCSIFLLADDR
Message-ID: <Pine.LNX.4.20.0205181621430.15609-100000@www.everquick.net>
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
Greetings all,
I'm currently STFWing for info on proper VRRP implementation on
FreeBSD.
My motivations are those mentioned by Terry in a -net thread last
July... Win2000 Advanced Server clustering is rather cool. I'd
like FreeBSD to similarly support multiple MAC addresses (and
emulate via multicast when the NIC only allows a single MAC).
This IMHO obviously would be a big plus.
As an aside... it seems that anything for which I seek info { has
been | is being } done by Terry. ;-)
Bottom line: Any developments, hints, tips, et cetera of which
one should know? Or do I continue STFWing? ;-)
--
Eddy
Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@brics.com>
To: blacklist@brics.com
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@brics.com>, or you are likely to
be blocked.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 10:12:48 2002
Delivered-To: freebsd-net@freebsd.org
Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1])
by hub.freebsd.org (Postfix) with ESMTP
id 0381037B40C; Sat, 18 May 2002 10:12:40 -0700 (PDT)
Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30])
by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id NAA14847;
Sat, 18 May 2002 13:12:39 -0400 (EDT)
Received: (from gallatin@localhost)
by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g4IHC9S82047;
Sat, 18 May 2002 13:12:09 -0400 (EDT)
(envelope-from gallatin@cs.duke.edu)
From: Andrew Gallatin <gallatin@cs.duke.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15590.35689.201153.550505@grasshopper.cs.duke.edu>
Date: Sat, 18 May 2002 13:12:09 -0400 (EDT)
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: current@FreeBSD.org, net@FreeBSD.org
Subject: Re: new zero copy sockets patches available
In-Reply-To: <20020517233950.A36169@panzer.kdm.org>
References: <20020517233950.A36169@panzer.kdm.org>
X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid
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
Kenneth D. Merry writes:
>
> I have released a new set of zero copy sockets patches, against -current
> from today (May 17th, 2002).
>
> The main change is to deal with the vfs_ioopt changes that Alan Cox made in
> kern_subr.c. (They conflicted a bit with the zero copy receive code.)
>
> The patches and the FAQ are available here:
>
> http://people.freebsd.org/~ken/zero_copy/
>
> Comments, questions and reviews are all welcome!
>
Hi Ken,
I'm glad to see that you're still maintining this!
Assuming the mutex issues get sorted out, what do you think the odds
are of getting this into the tree? The only possible issue I see is
with the tigon firmware. Is the firmware you're using of the same
vintage as what's in the tree now? Does it contain all the same
fixes?
Thanks again for keeping this alive,
Drew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 10:15:59 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mail.sandvine.com (sandvine.com [209.167.74.226])
by hub.freebsd.org (Postfix) with ESMTP
id 3759737B408; Sat, 18 May 2002 10:15:45 -0700 (PDT)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19)
id <LBLD8HAM>; Sat, 18 May 2002 13:15:44 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337676208@mail.sandvine.com>
From: Don Bowman <don@sandvine.com>
To: 'Andrew Gallatin' <gallatin@cs.duke.edu>,
"Kenneth D. Merry" <ken@kdm.org>
Cc: current@FreeBSD.org, net@FreeBSD.org
Subject: RE: new zero copy sockets patches available
Date: Sat, 18 May 2002 13:15:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
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
> Andrew Gallatin writes:
>> Kenneth D. Merry writes:
>> >
>> > I have released a new set of zero copy sockets patches, against
-current
>> > from today (May 17th, 2002).
>
> Hi Ken,
>
> I'm glad to see that you're still maintining this!
>
> Assuming the mutex issues get sorted out, what do you think the odds
> are of getting this into the tree? The only possible issue I see is
> with the tigon firmware. Is the firmware you're using of the same
> vintage as what's in the tree now? Does it contain all the same
> fixes?
As a related question, will this work with the broadcom gigabit (bge)
driver, which is the Tigon III? If not, what would it take to get
it working?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 15:29:28 2002
Delivered-To: freebsd-net@freebsd.org
Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123])
by hub.freebsd.org (Postfix) with ESMTP
id 6432837B40E; Sat, 18 May 2002 15:29:14 -0700 (PDT)
Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com)
by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2)
id 179ChE-0004Gt-00; Sat, 18 May 2002 15:29:04 -0700
Message-ID: <3CE6D592.DCF73743@mindspring.com>
Date: Sat, 18 May 2002 15:28:34 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Reilly <areilly@bigpond.net.au>
Cc: Attila Nagy <bra@fsn.hu>, freebsd-arch@freebsd.org,
freebsd-net@freebsd.org
Subject: Re: HEADS UP: ALTQ integration developer preview
References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro>
<Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu>
<3CE55A9B.73EA3DE4@mindspring.com>
<Pine.LNX.4.44.0205181018300.10011-100000@scribble.fsn.hu>
<3CE61675.BCE2A9E1@mindspring.com> <1021717195.1466.4.camel@gurney.reilly.home>
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
Andrew Reilly wrote:
> On Sat, 2002-05-18 at 18:53, Terry Lambert wrote:
> > Sending datagrams bigger than the MTU is a bad idea.
> >
> > I would be real tempted to drop the packets and send "don't fragment"
> > ICMP responses to beat up anyone who abused UDP by sending larger
> > than the MTU.
> >
> > I guess this is about Linux UDP NFS clients, in particular.
>
> Eh? Isn't the original, traditional and best NFS configuration 8k UDP
> packets?
>
> Sure worked fine that way on SunOS-4 those many years ago. (On LANs, of
> course. No one does NFS over the internet. I hope.)
No. TCP. RPC over UDP is really a silly idea. If you need
reliable delivery, then don't use a protocol with "unreliable"
as the first word of it's name. 8-).
In any case, the best UDP packet size is always "The largest possible
amount of data which fits in the MTU". There's no retransmit timeout
to deal with incomplete fragment sets pending reassembly.
If you want to get technical, TCP also has a bug; in the move
from FIN-WAIT-1 to FIN-WAIT-2, there's an assumption of two
responses for a single request. That's just intrinsically bad
protocol design. The workaround is to pretend you didn't get
the first FIN, resend, and then either get re-ACK'ed, or get
an RST. NT does this. So did Paul Vixie's "Interceptor"
product (transparent proxy cache appliance using NetBSD).
Putting yourself in a situation where protocol bugs result in
effective attacks is, well, "a bad idea".
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 15:45:54 2002
Delivered-To: freebsd-net@freebsd.org
Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123])
by hub.freebsd.org (Postfix) with ESMTP
id 80C9237B408; Sat, 18 May 2002 15:45:46 -0700 (PDT)
Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com)
by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2)
id 179CxH-0002JV-00; Sat, 18 May 2002 15:45:40 -0700
Message-ID: <3CE6D976.3264DE53@mindspring.com>
Date: Sat, 18 May 2002 15:45:10 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Attila Nagy <bra@fsn.hu>
Cc: freebsd-arch@freebsd.org, freebsd-net@freebsd.org
Subject: Re: HEADS UP: ALTQ integration developer preview
References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro>
<Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu>
<3CE55A9B.73EA3DE4@mindspring.com> <Pine.LNX.4.44.0205181018300.10011-100000@scribble.fsn.hu>
<3CE61675.BCE2A9E1@mindspring.com> <Pine.LNX.4.44.0205181336380.10862-100000@scribble.fsn.hu>
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
Attila Nagy wrote:
> > Sending datagrams bigger than the MTU is a bad idea.
>
> It depends on what do you want to do with that NFS server :)
Sure. Maybe you want to use up it's mbufs by jamming the frag
reassembly queue for IP full of N-1 frags using 64K USP packets.
> I want to get out from that several hundred megabits per second, so I
> can't use <1500 bytes MTU.
NFS works over TCP for a reason. TCP has sliding windows for a
reason.
> Just for comparison:
> when using <1500 bytes MTU (as close as possible to the limit) I can
> achieve about 1-1.5 MBps throughput.
> When using 32768 bytes MTU I can get around 190 Mbps out from a PIII 450.
> (and only 190 Mbps because the two frontends have fast ethernet cards)
> So why this is so bad? If the other end can keep up, it will increase
> throughput.
And you could get even better by getting rid of the request/response
turnaround stall by using TCP instead of UDP. Rather than having a
packet overhead of latency per packet, you get two packet latencies
over an arbitrary number of packets (unless you hit the window size,
in which case, you probably needed to have a larger window.
> BTW, the default UDP readsize is above 1500 bytes, so I couldn't use the
> server with a simple NFS mount.
> When I replaced the gx driver to em it just started to work. Now I am
> using TCP and 32k readsize with 64k tcp.sendspace and recvspace (I could
> nearly double the performance with setting these from the default values).
>
> So I am happy with it, I just took a note that the gx driver has some
> problems in these cases.
Most traffic is supposed to be at the MTU. You want to avoid
fragging. The only reason you want fragging in the UDP case is
so you can pretend you have a window, without having to use a
windowing protocol: you use the fragment reassembly queue as a
window buffer.
This really only gives you an amortization of 32K/MTU (maximum),
and you still have stalls every N packets, which you would not
get with a windowed protocol.
> > I would be real tempted to drop the packets and send "don't fragment"
> > ICMP responses to beat up anyone who abused UDP by sending larger than
> > the MTU.
>
> That's another point. I want performance :)
Then don't add the fragment reassmbly code to the code path for
packets you send to the server. That way you'll have less overhead.
8-).
> > I guess this is about Linux UDP NFS clients, in particular.
>
> Nope, both the server and the client side is FreeBSD stable.
I run all my NFS over TCP. If I avoid intentionally triggering
fragmentation, it works out to a little over 100 machine
instructions in the fast path. Done any cycle counting on your
use of UDP yet?
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 15:48:35 2002
Delivered-To: freebsd-net@freebsd.org
Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123])
by hub.freebsd.org (Postfix) with ESMTP
id 0A97B37B40C; Sat, 18 May 2002 15:48:28 -0700 (PDT)
Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com)
by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2)
id 179Czl-0004W1-00; Sat, 18 May 2002 15:48:13 -0700
Message-ID: <3CE6DA0F.C4D8C289@mindspring.com>
Date: Sat, 18 May 2002 15:47:43 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Attila Nagy <bra@fsn.hu>
Cc: John Hay <jhay@icomtek.csir.co.za>, freebsd-arch@FreeBSD.ORG,
freebsd-net@FreeBSD.ORG
Subject: Re: HEADS UP: ALTQ integration developer preview
References: <200205181012.g4IACfe52918@zibbi.icomtek.csir.co.za> <Pine.LNX.4.44.0205181343360.10862-100000@scribble.fsn.hu>
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
Attila Nagy wrote:
> > If the card on the receiving could not receive so many back to back
> > packets and looses one or more, nfs will get stuck retrying the same big
> > packet and the same thing happening over and over.
>
> Yep, but that's not my case. If this would be the problem, I guess
> changing from gx to em wouldn't help me...
The really cool thing is that this means I can shout on the wire at
the right time, cause a collision, and effectively stace an undetectable
denial of service attack against your servers, by making it drop large
UDP datagrams IP frags.
Way to open yourself up to attack!
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 15:58:52 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47])
by hub.freebsd.org (Postfix) with ESMTP
id 73D5D37B404; Sat, 18 May 2002 15:58:49 -0700 (PDT)
Received: from pc01 ([12.77.153.90]) by mtiwmhc22.worldnet.att.net
(InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
id <20020518225845.OLMF11146.mtiwmhc22.worldnet.att.net@pc01>;
Sat, 18 May 2002 22:58:45 +0000
Reply-To: <tate@att.net>
From: "Andrew Tate" <tate@att.net>
To: <freebsd-arch@freebsd.org>, <freebsd-net@freebsd.org>
Subject: kernel profiling in FreeBSD 5.0DP - is it working?
Date: Sat, 18 May 2002 18:55:36 -0400
Message-ID: <000101c1febf$213ab9f0$5a994d0c@pc01>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.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
Does anyone know if kernel profiling is working in FreeBSD 5.0DP?
Andrew Tate
mailto:tate@att.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 16: 3:13 2002
Delivered-To: freebsd-net@freebsd.org
Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123])
by hub.freebsd.org (Postfix) with ESMTP
id CF79A37B40B; Sat, 18 May 2002 16:03:07 -0700 (PDT)
Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com)
by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #2)
id 179DEA-0001yS-00; Sat, 18 May 2002 16:03:07 -0700
Message-ID: <3CE6DD8C.FC95386F@mindspring.com>
Date: Sat, 18 May 2002 16:02:36 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: John Baldwin <jhb@FreeBSD.org>
Cc: net@FreeBSD.org, current@FreeBSD.org,
"Kenneth D. Merry" <ken@kdm.org>, Alfred Perlstein <bright@mu.org>
Subject: Re: new zero copy sockets patches available
References: <XFMail.20020518090340.jhb@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
John Baldwin wrote:
> > God, it's annoying that a statically declared mutex is not
> > defacto initialized.
>
> Is it in solaris?
It isn't in FreeBSD because of the need to link mutex'es into
the "witness protection program". 8-).
> > Yeah, I understand the "witness" crap (if it's there); that
> > doesn't make it any less annoying.
> >
> > Actually, a linker set (not a SYSINIT) could fix that... you
> > would still need one sysinit to do the linkage of the statically
> > declared structures, but it's at least doable.
>
> a SYSINIT just is a linker set, and there is a convenience SYSINIT
> MTX_SYSINIT() or what not that just registers a sysinit to initialize
> a mutex.
What you want to do is implement a:
MUTEX_DECLARE(mutex_name).
This would implicitly add the mutex into the limker set containing
the addresses of statically declared mutex'es.
The SYSINIT()'s purpose would be to traverse this linker set,
calling the moral equivalent of "mutex_init" on each one of them.
You could do this with a SYSINIT(), as has been suggested, but
that would add a relatively large per mutex overhead for each
one you want to declare, since you'd basically be repeating the
common components for doing the job for each and every mutex,
instead of sharing them.
Technically, some later programmer could come along and recover
the linker set memory, actually, since it's only used once, for
the traversal, at kernel startup.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 16:22:56 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215])
by hub.freebsd.org (Postfix) with ESMTP id 9661D37B409
for <net@FreeBSD.org>; Sat, 18 May 2002 16:22:47 -0700 (PDT)
Received: (qmail 11331 invoked from network); 18 May 2002 23:22:43 -0000
Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender <jhb@FreeBSD.org>)
by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP
for <net@FreeBSD.org>; 18 May 2002 23:22:43 -0000
Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4])
by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g4INLxF83616;
Sat, 18 May 2002 19:21:59 -0400 (EDT)
(envelope-from jhb@FreeBSD.org)
Message-ID: <XFMail.20020518192148.jhb@FreeBSD.org>
X-Mailer: XFMail 1.5.2 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <3CE6DD8C.FC95386F@mindspring.com>
Date: Sat, 18 May 2002 19:21:48 -0400 (EDT)
From: John Baldwin <jhb@FreeBSD.org>
To: Terry Lambert <tlambert2@mindspring.com>
Subject: Re: new zero copy sockets patches available
Cc: Alfred Perlstein <bright@mu.org>,
"Kenneth D. Merry" <ken@kdm.org>, current@FreeBSD.org,
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
On 18-May-2002 Terry Lambert wrote:
> John Baldwin wrote:
>> > God, it's annoying that a statically declared mutex is not
>> > defacto initialized.
>>
>> Is it in solaris?
>
> It isn't in FreeBSD because of the need to link mutex'es into
> the "witness protection program". 8-).
Actually, there is more to it than that. Or at least, there will be
when turnstiles are added (turnstiles require some function callouts
to work properly).
> MUTEX_DECLARE(mutex_name).
Umm, yes, like MTX_SYSINIT(). :)
> You could do this with a SYSINIT(), as has been suggested, but
> that would add a relatively large per mutex overhead for each
> one you want to declare, since you'd basically be repeating the
> common components for doing the job for each and every mutex,
> instead of sharing them.
Umm, this is a boot-up thing so it's not that big of a deal, plus
the actual code isn't duplicated, we call a common function for
the actual mutex initialization.
> Technically, some later programmer could come along and recover
> the linker set memory, actually, since it's only used once, for
> the traversal, at kernel startup.
Erm, they could do the same with the little mtx_args structs if
they want to as well, but I think it's more effor than its worth.
> -- Terry
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 16:23:57 2002
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 BB5CB37B403; Sat, 18 May 2002 16:23:51 -0700 (PDT)
Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com)
by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2)
id 179DY9-0001UX-00; Sat, 18 May 2002 16:23:46 -0700
Message-ID: <3CE6E263.77E337E0@mindspring.com>
Date: Sat, 18 May 2002 16:23:15 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Don Bowman <don@sandvine.com>
Cc: 'Andrew Gallatin' <gallatin@cs.duke.edu>,
"Kenneth D. Merry" <ken@kdm.org>, current@FreeBSD.org,
net@FreeBSD.org
Subject: Re: new zero copy sockets patches available
References: <FE045D4D9F7AED4CBFF1B3B813C85337676208@mail.sandvine.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
Don Bowman wrote:
> > Andrew Gallatin writes:
> >> Kenneth D. Merry writes:
> >> >
> >> > I have released a new set of zero copy sockets patches, against
> -current
> >> > from today (May 17th, 2002).
> >
> > Hi Ken,
> >
> > I'm glad to see that you're still maintining this!
> >
> > Assuming the mutex issues get sorted out, what do you think the odds
> > are of getting this into the tree? The only possible issue I see is
> > with the tigon firmware. Is the firmware you're using of the same
> > vintage as what's in the tree now? Does it contain all the same
> > fixes?
>
> As a related question, will this work with the broadcom gigabit (bge)
> driver, which is the Tigon III? If not, what would it take to get
> it working?
Broadcom is a bit more anal about people having access to their
firmware to make their products meet their design capabilities.
Really annoying about the whole Broadcom/Alteon thing...
To do the work, you'd have to do it on your own, after licensing
the firmware, after signing an NDA. Unlike the rather public
Tigon II firmware, the Tigon III doesn't have a lot of synergy
or interesting work going for it. Most people doing interesting
work tend to use Tigon II cards, because of this.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 16:42:36 2002
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 E354137B41C; Sat, 18 May 2002 16:41:54 -0700 (PDT)
Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com)
by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2)
id 179Dph-0002IH-00; Sat, 18 May 2002 16:41:53 -0700
Message-ID: <3CE6E6A2.4A42228B@mindspring.com>
Date: Sat, 18 May 2002 16:41:22 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: John Baldwin <jhb@FreeBSD.org>
Cc: Alfred Perlstein <bright@mu.org>,
"Kenneth D. Merry" <ken@kdm.org>, current@FreeBSD.org,
net@FreeBSD.org
Subject: Re: new zero copy sockets patches available
References: <XFMail.20020518192148.jhb@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
John Baldwin wrote:
> On 18-May-2002 Terry Lambert wrote:
> > John Baldwin wrote:
> >> > God, it's annoying that a statically declared mutex is not
> >> > defacto initialized.
> >>
> >> Is it in solaris?
> >
> > It isn't in FreeBSD because of the need to link mutex'es into
> > the "witness protection program". 8-).
>
> Actually, there is more to it than that. Or at least, there will be
> when turnstiles are added (turnstiles require some function callouts
> to work properly).
It's the function callouts that are the problem. 8-(.
> > MUTEX_DECLARE(mutex_name).
>
> Umm, yes, like MTX_SYSINIT(). :)
No. An MTX_SYSINIT() that wrapped a declaration and a SYSINIT()
would als imply the definition of an static function to do the
initialization, that then got called by the SYSINIT() itself.
This is actually what I was saying was bad: a static function
per mutex declaration.
You really want to avoid the pthreads "mutex initializer" thing;
the compiler doesn't have code that can attach to data declarations
to fix the problem.
So, among other things, you want to use the same initializer function
instance for all statically declared mutexes.
So you have to use something other than a SYSINIT() for the declarations,
but you could use *one SYSINIT()* to do the pre-use initialization of
*all* declarations.
> > You could do this with a SYSINIT(), as has been suggested, but
> > that would add a relatively large per mutex overhead for each
> > one you want to declare, since you'd basically be repeating the
> > common components for doing the job for each and every mutex,
> > instead of sharing them.
>
> Umm, this is a boot-up thing so it's not that big of a deal, plus
> the actual code isn't duplicated, we call a common function for
> the actual mutex initialization.
Maybe. I don't think a large sysinit structure is as useful as an
array of addresses of mutexes needing initialization. There would
be a serious tempation in the former case to provide for some type
of non-uniform initialization of statically declared sysinit objects.
It would be nice if the non-uniformity could be limited to the fact
that if the WITNESS code was there, it needed to be linked onto the
list.
With the WITNESS code not compiled into the kernel, I'd prefer not
to include the initialization code at all. It would encorage bad
practice, if it weren't conditional on WITNESS.
> > Technically, some later programmer could come along and recover
> > the linker set memory, actually, since it's only used once, for
> > the traversal, at kernel startup.
>
> Erm, they could do the same with the little mtx_args structs if
> they want to as well, but I think it's more effor than its worth.
Actually, I don't think they could.
The intermediate stage for that would really suck. The only way
to handle it is to use different ELF sections for that datam so
that you could discard the section later.
This is worthwhile for device probe code, maybe attach code, any
linker set contents, but not really for individial small structures
each getting jammed into their own page size object. 8-). You'd
need to do a lot more work, including KVA defragmentation by being
able to sectionally attribute anything in the paging path, to keep
it from being moved around, or the move-it-around code itself.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 16:53:40 2002
Delivered-To: freebsd-net@freebsd.org
Received: from mail.speakeasy.net (mail15.speakeasy.net [216.254.0.215])
by hub.freebsd.org (Postfix) with ESMTP id A065E37B416
for <net@FreeBSD.org>; Sat, 18 May 2002 16:53:28 -0700 (PDT)
Received: (qmail 27112 invoked from network); 18 May 2002 23:53:25 -0000
Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender <jhb@FreeBSD.org>)
by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP
for <bright@mu.org>; 18 May 2002 23:53:25 -0000
Received: from laptop.baldwin.cx (laptop.baldwin.cx [192.168.0.4])
by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g4INqkF83718;
Sat, 18 May 2002 19:52:46 -0400 (EDT)
(envelope-from jhb@FreeBSD.org)
Message-ID: <XFMail.20020518195236.jhb@FreeBSD.org>
X-Mailer: XFMail 1.5.2 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <3CE6E6A2.4A42228B@mindspring.com>
Date: Sat, 18 May 2002 19:52:36 -0400 (EDT)
From: John Baldwin <jhb@FreeBSD.org>
To: Terry Lambert <tlambert2@mindspring.com>
Subject: Re: new zero copy sockets patches available
Cc: net@FreeBSD.org, current@FreeBSD.org,
"Kenneth D. Merry" <ken@kdm.org>, Alfred Perlstein <bright@mu.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 18-May-2002 Terry Lambert wrote:
> John Baldwin wrote:
>> On 18-May-2002 Terry Lambert wrote:
>> > John Baldwin wrote:
>> >> > God, it's annoying that a statically declared mutex is not
>> >> > defacto initialized.
>> >>
>> >> Is it in solaris?
>> >
>> > It isn't in FreeBSD because of the need to link mutex'es into
>> > the "witness protection program". 8-).
>>
>> Actually, there is more to it than that. Or at least, there will be
>> when turnstiles are added (turnstiles require some function callouts
>> to work properly).
>
> It's the function callouts that are the problem. 8-(.
Unfortunately there aren't easy solutions to this. Even solaris 7
uses callouts. We would use fewer of them at least.
>> > MUTEX_DECLARE(mutex_name).
>>
>> Umm, yes, like MTX_SYSINIT(). :)
>
> No. An MTX_SYSINIT() that wrapped a declaration and a SYSINIT()
> would als imply the definition of an static function to do the
> initialization, that then got called by the SYSINIT() itself.
This is a false implication.
> This is actually what I was saying was bad: a static function
> per mutex declaration.
Umm, no, there is _one_ global function that we call. Why not check
the actual code?
> So, among other things, you want to use the same initializer function
> instance for all statically declared mutexes.
Um, we already do this.
> So you have to use something other than a SYSINIT() for the declarations,
> but you could use *one SYSINIT()* to do the pre-use initialization of
> *all* declarations.
Why don't you read the code?
Here, I'll quote it for you:
struct mtx_args {
struct mtx *ma_mtx;
const char *ma_desc;
int ma_opts;
};
#define MTX_SYSINIT(name, mtx, desc, opts) \
static struct mtx_args name##_args = { \
mtx, \
desc, \
opts \
}; \
SYSINIT(name##_mtx_sysinit, SI_SUB_LOCK, SI_ORDER_MIDDLE, \
mtx_sysinit, &name##_args)
Note no static function, instead we use the global function mtx_sysinit()
in kern_mutex.c:
/*
* General init routine used by the MTX_SYSINIT() macro.
*/
void
mtx_sysinit(void *arg)
{
struct mtx_args *margs = arg;
mtx_init(margs->ma_mtx, margs->ma_desc, NULL, margs->ma_opts);
}
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 17: 1:57 2002
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 A641C37B400; Sat, 18 May 2002 17:01:42 -0700 (PDT)
Received: from isi.edu (u3xit41xo3mv53gd@hbo.isi.edu [128.9.160.75])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4J01TF08127;
Sat, 18 May 2002 17:01:29 -0700 (PDT)
Message-ID: <3CE6EB56.5080506@isi.edu>
Date: Sat, 18 May 2002 17:01:26 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: Terry Lambert <tlambert2@mindspring.com>
Cc: Andrew Reilly <areilly@bigpond.net.au>, Attila Nagy <bra@fsn.hu>,
freebsd-arch@freebsd.org, freebsd-net@freebsd.org
Subject: Re: HEADS UP: ALTQ integration developer preview
References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro> <Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu> <3CE55A9B.73EA3DE4@mindspring.com> <Pine.LNX.4.44.0205181018300.10011-100000@scribble.fsn.hu> <3CE61675.BCE2A9E1@mindspring.com> <1021717195.1466.4.camel@gurney.reilly.home> <3CE6D592.DCF73743@mindspring.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060500030403020908090605"
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 cryptographically signed message in MIME format.
--------------ms060500030403020908090605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Terry Lambert wrote:
> No. TCP. RPC over UDP is really a silly idea. If you need
> reliable delivery, then don't use a protocol with "unreliable"
> as the first word of it's name. 8-).
The U in UDP is for "User". See RFC768.
NFS over UDP works just fine in the majority of cases, and for slow
receivers (the problem John Hay described), there's TCP mounts.
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms060500030403020908090605
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC
ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP
MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc
MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1
1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU
SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB
BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud
EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT
vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d
6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC
HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD
VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV
BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq
hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL
ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA
jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv
0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy
dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E
AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ
d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX
frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB
AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3
dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv
bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB
FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy
NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT
ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq
bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC
9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww
KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI
MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15
1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s
ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY
yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD
ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw
MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTAyMDUxOTAwMDEyOFowIwYJKoZIhvcNAQkEMRYEFAWiQcCpxpLF
oQuF3XIVXtdd8iLSMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B
CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG
A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl
IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF
gUcwDQYJKoZIhvcNAQEBBQAEgYCScN2EqE27P0v1UFcY8u8sVFO9ezzSc0xyo4r2ZkcZ2wvy
guZ7X3D4rU/FHfVWiEdRFtZ+ZvYUFtJAB/J3c0g4ZJkVtAj97ppl9xiHU2DpMrmwfAZpfHRW
fINmvWAgYbwCWkiZiWoz5aAETPMl2amwJlOoQg6pEhEOjbVpZIWAKQAAAAAAAA==
--------------ms060500030403020908090605--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 17: 6:37 2002
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 200C237B400; Sat, 18 May 2002 17:06:26 -0700 (PDT)
Received: from isi.edu (5oso8ry8i01hla2b@hbo.isi.edu [128.9.160.75])
by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g4J05wF10558;
Sat, 18 May 2002 17:05:58 -0700 (PDT)
Message-ID: <3CE6EC64.3060704@isi.edu>
Date: Sat, 18 May 2002 17:05:56 -0700
From: Lars Eggert <larse@ISI.EDU>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020404
X-Accept-Language: en-us, de-de
MIME-Version: 1.0
To: Terry Lambert <tlambert2@mindspring.com>
Cc: Attila Nagy <bra@fsn.hu>, John Hay <jhay@icomtek.csir.co.za>,
freebsd-arch@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
Subject: Re: HEADS UP: ALTQ integration developer preview
References: <200205181012.g4IACfe52918@zibbi.icomtek.csir.co.za> <Pine.LNX.4.44.0205181343360.10862-100000@scribble.fsn.hu> <3CE6DA0F.C4D8C289@mindspring.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080506050809060506010809"
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 cryptographically signed message in MIME format.
--------------ms080506050809060506010809
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Terry Lambert wrote:
> The really cool thing is that this means I can shout on the wire at
> the right time, cause a collision, and effectively stace an undetectable
> denial of service attack against your servers, by making it drop large
> UDP datagrams IP frags.
This "attack" works against any other protocol as well, including TCP.
If you can create collisions "at the right time", you can disable all
retransmission schemes. The kicker is - how?
Lars
--
Lars Eggert <larse@isi.edu> USC Information Sciences Institute
--------------ms080506050809060506010809
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIrjCC
ArUwggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEP
MA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEc
MBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA0AvLBsD78nxcUHeHkaMgl3b4qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD1
1uZDy4CNNJUu3gKxKSb+zRV70O+lkwwftuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcU
SF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIB
BAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1Ud
EwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQA8zI7U2K1ZIAl11j0a1DKxnp3GtT
vOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2OhB+jeKEqY7IDAJE4/fI0e+d
6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4fdcOo1S34r4wggK1MIIC
HqADAgECAgMFgUcwDQYJKoZIhvcNAQECBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX
ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYD
VQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg
UlNBIDIwMDAuOC4zMDAeFw0wMTA4MjQxNjQwMDBaFw0wMjA4MjQxNjQwMDBaMFQxDzANBgNV
BAQTBkVnZ2VydDENMAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkq
hkiG9w0BCQEWDWxhcnNlQGlzaS5lZHUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANAL
ywbA+/J8XFB3h5GjIJd2+KmD534G3/C4fh0D/EYBjERv2G/r06ZBns5cLfaZCcYg9dbmQ8uA
jTSVLt4CsSkm/s0Ve9DvpZMMH7bh6Cx6B+McKNy3ENixg6XfiPebVDeHXyd05nhHFEhedHQv
0rlCOMPAJYV0PCMa4YHWsk6RAgMBAAGjVjBUMCoGBStlAQQBBCEwHwIBADAaMBgCAQQEE0wy
dU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVkdTAMBgNVHRMBAf8E
AjAAMA0GCSqGSIb3DQEBAgUAA4GBAIXmYZ9KUAPMyO1NitWSAJddY9GtQysZ6dxrU7zlKxkQ
d1r2MYnb3WdZIs4RLFnl1PNU5DQx9A2karThHrukNjoQfo3ihKmOyAwCROP3yNHvnej5xtYX
frxL2JrCh5JswYT3PeF1DijVjvqlTT9jRsjSN0CA8ucF+H3XDqNUt+K+MIIDODCCAqGgAwIB
AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3
dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv
bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB
FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy
NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT
ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq
bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC
9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww
KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI
MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15
1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s
ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY
yWJirQXGMYICpjCCAqICAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu
IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD
ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw
MDAuOC4zMAIDBYFHMAkGBSsOAwIaBQCgggFhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTAyMDUxOTAwMDU1OFowIwYJKoZIhvcNAQkEMRYEFPMfjzE/co70
jJv9FbMBvMh01eUYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGtBgsqhkiG9w0B
CRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG
A1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRl
IFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMF
gUcwDQYJKoZIhvcNAQEBBQAEgYBP7HmKO1R/2/qLwYcCY4adLXyusOPBzeiFABj5u5unljNi
Tg1jCac2y1p92xSEbGrEXdQakKrCRJrk3hhWmh8jZ0UyKAYnhDTwh4dep6uexuCsLYafwugP
uvU2zLoabeU30DL148hRCIbWJc3iZNtaKCYGGa6TxeGzqjHeUKcs8QAAAAAAAA==
--------------ms080506050809060506010809--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 17: 7: 4 2002
Delivered-To: freebsd-net@freebsd.org
Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22])
by hub.freebsd.org (Postfix) with ESMTP
id 9CF1337B40A; Sat, 18 May 2002 17:06:55 -0700 (PDT)
Received: from pool0271.cvx22-bradley.dialup.earthlink.net ([209.179.199.16] helo=mindspring.com)
by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2)
id 179EDu-0000VZ-00; Sat, 18 May 2002 17:06:54 -0700
Message-ID: <3CE6EC7F.F75B00F9@mindspring.com>
Date: Sat, 18 May 2002 17:06:23 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: John Baldwin <jhb@FreeBSD.org>
Cc: net@FreeBSD.org, current@FreeBSD.org,
"Kenneth D. Merry" <ken@kdm.org>, Alfred Perlstein <bright@mu.org>
Subject: Re: new zero copy sockets patches available
References: <XFMail.20020518195236.jhb@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
John Baldwin wrote:
> > This is actually what I was saying was bad: a static function
> > per mutex declaration.
>
> Umm, no, there is _one_ global function that we call. Why not check
> the actual code?
Are you talking about a P4 branch, and not the main repository?
> Why don't you read the code?
>
> Here, I'll quote it for you:
>
> struct mtx_args {
> struct mtx *ma_mtx;
> const char *ma_desc;
> int ma_opts;
> };
>
> #define MTX_SYSINIT(name, mtx, desc, opts) \
> static struct mtx_args name##_args = { \
> mtx, \
> desc, \
> opts \
> }; \
> SYSINIT(name##_mtx_sysinit, SI_SUB_LOCK, SI_ORDER_MIDDLE, \
> mtx_sysinit, &name##_args)
This is *EXACTLY* what I thought should be avoided. The linker
set should not contain the address of a bunch of static mtx_args
structs, because there shouldn't *be* a bunch of static mtx_args
structs.
And the ability to pass different initialization values to different
mutex instances is broken, in that it makes it impossible to look at
a mutex, and know what you need to know about it, merely because it's
a mutex.
Minimally, you are going to add 12 bytes per mutex (24 on 64 bit
machines), plus however much memory is taken up by the "ma_desc",
plus it makes the memory unrecoverable, because the address of the
string that's in the supposedly "recoverable" data segment can't be
recovered any more, because making the data segment "go away" would
invalidate dereferences of the pointer.
This is about as ugly the mutex code taking parameters (we've had
that discussion before).
> Note no static function, instead we use the global function mtx_sysinit()
> in kern_mutex.c:
>
> /*
> * General init routine used by the MTX_SYSINIT() macro.
> */
> void
> mtx_sysinit(void *arg)
> {
> struct mtx_args *margs = arg;
>
> mtx_init(margs->ma_mtx, margs->ma_desc, NULL, margs->ma_opts);
> }
On a per instance basis. For which you create not only an mtx_args
structure, but also a sysinit structure, to act as a container for
the reference to the mtx_args struct address, and the mtx_sysinit
function, etc..
Bleh. 8-).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 17:13: 0 2002
Delivered-To: freebsd-net@freebsd.org
Received: from yello.shallow.net (yello.shallow.net [203.18.243.120])
by hub.freebsd.org (Postfix) with ESMTP id 18D3037B403
for <freebsd-net@freebsd.org>; Sat, 18 May 2002 17:12:57 -0700 (PDT)
Received: by yello.shallow.net (Postfix, from userid 1001)
id 23A5B2A6D; Sun, 19 May 2002 10:12:50 +1000 (EST)
Date: Sun, 19 May 2002 10:12:50 +1000
From: Joshua Goodall <joshua@roughtrade.net>
To: Terry Lambert <tlambert2@mindspring.com>
Cc: Andrew Reilly <areilly@bigpond.net.au>, Attila Nagy <bra@fsn.hu>,
freebsd-net@freebsd.org
Subject: Re: HEADS UP: ALTQ integration developer preview
Message-ID: <20020519001249.GA24012@roughtrade.net>
References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro> <Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu> <3CE55A9B.73EA3DE4@mindspring.com> <Pine.LNX.4.44.0205181018300.10011-100000@scribble.fsn.hu> <3CE61675.BCE2A9E1@mindspring.com> <1021717195.1466.4.camel@gurney.reilly.home> <3CE6D592.DCF73743@mindspring.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3CE6D592.DCF73743@mindspring.com>
User-Agent: Mutt/1.3.28i
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, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> No. TCP. RPC over UDP is really a silly idea. If you need
> reliable delivery, then don't use a protocol with "unreliable"
> as the first word of it's name. 8-).
UDP may well be perfectly viable as a RPC transport, but Terry's
misinforming statement is not a good justification.
UDP is the User Datagram Protocol.
Joshua
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 17:49:12 2002
Delivered-To: freebsd-net@freebsd.org
Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232])
by hub.freebsd.org (Postfix) with ESMTP id 9319F37B403
for <freebsd-net@freebsd.org>; Sat, 18 May 2002 17:49:10 -0700 (PDT)
Received: from dialup-209.247.138.189.dial1.sanjose1.level3.net ([209.247.138.189] helo=mindspring.com)
by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #2)
id 179Esi-000496-00; Sat, 18 May 2002 17:49:04 -0700
Message-ID: <3CE6F653.CDE9D2B4@mindspring.com>
Date: Sat, 18 May 2002 17:48:19 -0700
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Joshua Goodall <joshua@roughtrade.net>
Cc: Andrew Reilly <areilly@bigpond.net.au>, Attila Nagy <bra@fsn.hu>,
freebsd-net@freebsd.org
Subject: Re: HEADS UP: ALTQ integration developer preview
References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro> <Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu> <3CE55A9B.73EA3DE4@mindspring.com> <Pine.LNX.4.44.0205181018300.10011-100000@scribble.fsn.hu> <3CE61675.BCE2A9E1@mindspring.com> <1021717195.1466.4.camel@gurney.reilly.home> <3CE6D592.DCF73743@mindspring.com> <20020519001249.GA24012@roughtrade.net>
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
Joshua Goodall wrote:
> On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> > No. TCP. RPC over UDP is really a silly idea. If you need
> > reliable delivery, then don't use a protocol with "unreliable"
> > as the first word of it's name. 8-).
>
> UDP may well be perfectly viable as a RPC transport, but Terry's
> misinforming statement is not a good justification.
>
> UDP is the User Datagram Protocol.
Was that a "miss" or an "ignore" on the "8-)"?
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 18: 7: 7 2002
Delivered-To: freebsd-net@freebsd.org
Received: from yello.shallow.net (yello.shallow.net [203.18.243.120])
by hub.freebsd.org (Postfix) with ESMTP id 4E4EB37B403
for <freebsd-net@freebsd.org>; Sat, 18 May 2002 18:07:04 -0700 (PDT)
Received: by yello.shallow.net (Postfix, from userid 1001)
id 4B70C2A6D; Sun, 19 May 2002 11:07:03 +1000 (EST)
Date: Sun, 19 May 2002 11:07:03 +1000
From: Joshua Goodall <joshua@roughtrade.net>
To: Terry Lambert <tlambert2@mindspring.com>
Cc: Andrew Reilly <areilly@bigpond.net.au>, Attila Nagy <bra@fsn.hu>,
freebsd-net@freebsd.org
Subject: Re: HEADS UP: ALTQ integration developer preview
Message-ID: <20020519010703.GE24468@roughtrade.net>
References: <Pine.BSF.4.10.10205170216500.29826-100000@ady.warpnet.ro> <Pine.LNX.4.44.0205171056200.2091-100000@scribble.fsn.hu> <3CE55A9B.73EA3DE4@mindspring.com> <Pine.LNX.4.44.0205181018300.10011-100000@scribble.fsn.hu> <3CE61675.BCE2A9E1@mindspring.com> <1021717195.1466.4.camel@gurney.reilly.home> <3CE6D592.DCF73743@mindspring.com> <20020519001249.GA24012@roughtrade.net> <3CE6F653.CDE9D2B4@mindspring.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3CE6F653.CDE9D2B4@mindspring.com>
User-Agent: Mutt/1.3.28i
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, May 18, 2002 at 05:48:19PM -0700, Terry Lambert wrote:
> Joshua Goodall wrote:
> > On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> > > No. TCP. RPC over UDP is really a silly idea. If you need
> > > reliable delivery, then don't use a protocol with "unreliable"
> > > as the first word of it's name. 8-).
> >
> > UDP may well be perfectly viable as a RPC transport, but Terry's
> > misinforming statement is not a good justification.
> >
> > UDP is the User Datagram Protocol.
>
> Was that a "miss" or an "ignore" on the "8-)"?
Definitely an ignore. An incorrect statement remains incorrect no
matter how many irrelevant smilies are appended in a feeble attempt
at irony. Particularly when it reverses the sense of the preceeding
statement.
Joshua
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 20:36: 8 2002
Delivered-To: freebsd-net@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
by hub.freebsd.org (Postfix) with ESMTP
id 6CC7C37B40F; Sat, 18 May 2002 20:35:56 -0700 (PDT)
Received: (from ken@localhost)
by panzer.kdm.org (8.11.6/8.9.1) id g4J3ZtU46246;
Sat, 18 May 2002 21:35:55 -0600 (MDT)
(envelope-from ken)
Date: Sat, 18 May 2002 21:35:55 -0600
From: "Kenneth D. Merry" <ken@kdm.org>
To: John Baldwin <jhb@FreeBSD.org>
Cc: net@FreeBSD.org, current@FreeBSD.org,
Alfred Perlstein <bright@mu.org>
Subject: Re: new zero copy sockets patches available
Message-ID: <20020518213555.A46216@panzer.kdm.org>
References: <20020518003046.A36510@panzer.kdm.org> <XFMail.20020518090338.jhb@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <XFMail.20020518090338.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Sat, May 18, 2002 at 09:03:38AM -0400
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, May 18, 2002 at 09:03:38 -0400, John Baldwin wrote:
>
> On 18-May-2002 Kenneth D. Merry wrote:
> > On Fri, May 17, 2002 at 23:02:55 -0700, Alfred Perlstein wrote:
> >> * Kenneth D. Merry <ken@kdm.org> [020517 22:40] wrote:
> >> >
> >> > I have released a new set of zero copy sockets patches, against -current
> >> > from today (May 17th, 2002).
> >> >
> >> > The main change is to deal with the vfs_ioopt changes that Alan Cox made
> >> > in
> >> > kern_subr.c. (They conflicted a bit with the zero copy receive code.)
> >> >
> >> > The patches and the FAQ are available here:
> >> >
> >> > http://people.freebsd.org/~ken/zero_copy/
> >> >
> >> > Comments, questions and reviews are all welcome!
> >>
> >> jumbo_vm_init() has a bunch of bugs
> >>
> >> first it doesn't work right if called concurrently.
> >> you need to protect the initialization of jumbo_vm_object otherwise
> >> bad things can happen. my suggestion is to store the results of
> >> vm_object_allocate into a temporary, grab the mutex and then check
> >> to see if jumbo_vm_object has been initialized again if it has then
> >> free the object, otherwise store the allocated object into the
> >> global and continue.
> >
> > The problem here is that the mutex needs to be initialized before I can
> > acquire it, and there's going to be a race between checking to see
> > whether it has been initialized and actually initializing it.
> >
> > e.g.:
> >
> > if (!mtx_initialized(&jumbo_mutex))
> > mtx_init(&jumbo_mutex, "jumbo mutex", NULL, MTX_DEF);
> >
> > mtx_lock(&jumbo_mutex);
> >
> > if (jumbo_vm_object != NULL) {
> > mtx_unlock(&jumbo_mutex);
> > return (1);
> > }
> >
> > /* allocate our object */
> > jumbo_vm_object = vm_object_allocate(OBJT_DEFAULT, JUMBO_MAX_PAGES);
> >
> > The above would work, I think, if it weren't for the race in the mutex
> > initialization, and assuming I can allocate a vm object while holding
> > the jumbo mutex.
> >
> > Suggestions?
>
> Either use a sysinit or something gross like this:
>
> static int jumbo_init = 0;
>
> ...
> while (jumbo_init != 2) {
> if (atomic_cmpset_acq_int(&jumbo_init, 0, 1) {
> mtx_init(&jumbo_mutex, "jumbo_mutex", NULL, MTX_DEF);
> atomic_store_rel_int(&jumbo_init, 2);
> }
> }
>
> mtx_lock(&jumbo_mutex);
>
> ...
>
> a sysinit is probably best though.
Sounds like a sysinit is probably the way to go.
I'll give it a try, thanks!
Ken
--
Kenneth Merry
ken@kdm.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 20:39:38 2002
Delivered-To: freebsd-net@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
by hub.freebsd.org (Postfix) with ESMTP
id 30E8137B400; Sat, 18 May 2002 20:39:30 -0700 (PDT)
Received: (from ken@localhost)
by panzer.kdm.org (8.11.6/8.9.1) id g4J3dKe46299;
Sat, 18 May 2002 21:39:20 -0600 (MDT)
(envelope-from ken)
Date: Sat, 18 May 2002 21:39:20 -0600
From: "Kenneth D. Merry" <ken@kdm.org>
To: Andrew Gallatin <gallatin@cs.duke.edu>
Cc: current@FreeBSD.org, net@FreeBSD.org
Subject: Re: new zero copy sockets patches available
Message-ID: <20020518213920.B46216@panzer.kdm.org>
References: <20020517233950.A36169@panzer.kdm.org> <15590.35689.201153.550505@grasshopper.cs.duke.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <15590.35689.201153.550505@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Sat, May 18, 2002 at 01:12:09PM -0400
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, May 18, 2002 at 13:12:09 -0400, Andrew Gallatin wrote:
>
> Kenneth D. Merry writes:
> >
> > I have released a new set of zero copy sockets patches, against -current
> > from today (May 17th, 2002).
> >
> > The main change is to deal with the vfs_ioopt changes that Alan Cox made in
> > kern_subr.c. (They conflicted a bit with the zero copy receive code.)
> >
> > The patches and the FAQ are available here:
> >
> > http://people.freebsd.org/~ken/zero_copy/
> >
> > Comments, questions and reviews are all welcome!
> >
>
> Hi Ken,
>
> I'm glad to see that you're still maintining this!
>
> Assuming the mutex issues get sorted out, what do you think the odds
> are of getting this into the tree? The only possible issue I see is
> with the tigon firmware. Is the firmware you're using of the same
> vintage as what's in the tree now? Does it contain all the same
> fixes?
I think the odds of getting into the tree are pretty good. I certainly
plan to give it a shot.
The firmware is basically identical to what we currently have in the tree
(12.4.11 plus some fixes Bill Paul picked out from 12.4.13), plus the
header splitting patches.
There have been some newer firmware releases, up to 12.4.18 I think, but I
haven't yet been able to get anything from 3Com.
I know 12.4.18 at least fixes some checksum offloading issues in a few
strange cases.
> Thanks again for keeping this alive,
>
> Drew
Ken
--
Kenneth Merry
ken@kdm.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
From owner-freebsd-net Sat May 18 20:45:28 2002
Delivered-To: freebsd-net@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
by hub.freebsd.org (Postfix) with ESMTP
id C82B137B40B; Sat, 18 May 2002 20:45:20 -0700 (PDT)
Received: (from ken@localhost)
by panzer.kdm.org (8.11.6/8.9.1) id g4J3j9m46348;
Sat, 18 May 2002 21:45:09 -0600 (MDT)
(envelope-from ken)
Date: Sat, 18 May 2002 21:45:09 -0600
From: "Kenneth D. Merry" <ken@kdm.org>
To: Don Bowman <don@sandvine.com>
Cc: "'Andrew Gallatin'" <gallatin@cs.duke.edu>, current@FreeBSD.org,
net@FreeBSD.org
Subject: Re: new zero copy sockets patches available
Message-ID: <20020518214509.C46216@panzer.kdm.org>
References: <FE045D4D9F7AED4CBFF1B3B813C85337676208@mail.sandvine.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <FE045D4D9F7AED4CBFF1B3B813C85337676208@mail.sandvine.com>; from don@sandvine.com on Sat, May 18, 2002 at 01:15:43PM -0400
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, May 18, 2002 at 13:15:43 -0400, Don Bowman wrote:
> > Andrew Gallatin writes:
> >> Kenneth D. Merry writes:
> >> >
> >> > I have released a new set of zero copy sockets patches, against
> -current
> >> > from today (May 17th, 2002).
> >
> > Hi Ken,
> >
> > I'm glad to see that you're still maintining this!
> >
> > Assuming the mutex issues get sorted out, what do you think the odds
> > are of getting this into the tree? The only possible issue I see is
> > with the tigon firmware. Is the firmware you're using of the same
> > vintage as what's in the tree now? Does it contain all the same
> > fixes?
>
> As a related question, will this work with the broadcom gigabit (bge)
> driver, which is the Tigon III? If not, what would it take to get
> it working?
Unfortunately, it won't work with the Tigon III.
If you can get firmware source for the Tigon III, I can probably get header
splitting working. (The only way it wouldn't work is if they've offloaded
most of the packet processing into the hardware.)
The send side code will work on any NIC, and you can kludge up special case
header splitting on the receive side if the NIC allows you to break jumbo
frames into multiple chunks of data. (This is what Drew originally did for
the Tigon II -- you just size the initial chunk of data so that it'll just
hold the ethernet header, IP header, TCP header and TCP options, and the
payload will "magically" end up page aligned. This doesn't work for
protocols other than TCP, and it won't work if your TCP header changes in
length.)
Ken
--
Kenneth Merry
ken@kdm.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message