From owner-freebsd-net@FreeBSD.ORG Sun Jan 2 13:11:04 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D61216A4CE for ; Sun, 2 Jan 2005 13:11:04 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 174A943D1D for ; Sun, 2 Jan 2005 13:11:04 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id j02D7SQM029114; Sun, 2 Jan 2005 08:07:28 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)j02D7OQs029110; Sun, 2 Jan 2005 13:07:28 GMT (envelope-from robert@fledge.watson.org) Date: Sun, 2 Jan 2005 13:07:24 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Gerald Pfeifer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: PATCH: /usr/include/netipx/ipx.h and Linux compatibility X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2005 13:11:04 -0000 (blast from the past e-mail) On Wed, 22 Jan 2003, Gerald Pfeifer wrote: > In /usr/include/netipx/ipx.h we already have #defined sipx_port, > presumably for compatibility with Linux. > > Could we please also add two other #defines as per the patch below? > > (This would have reduced my head-ache maintaining ports/emulators/wine > resp. feeding patches upstream quite a bit.) > > Gerald -- gerald@FreeBSD.org, but I'd need a src committer for this FYI: It looks like Bruce Simpson applied this change (or one very much like it) to HEAD (5-CURRENT) ipx.h as 1.18, and I recently merged it RELENG_4 ipx.h as 1.15.2.1. Thanks! Robert N M Watson > Index: ipx.h > =================================================================== > RCS file: /sw/FreeBSD/CVSUP/src/sys/netipx/ipx.h,v > retrieving revision 1.17 > diff -u -3 -p -r1.17 ipx.h > --- ipx.h 20 Mar 2002 02:39:13 -0000 1.17 > +++ ipx.h 22 Jan 2003 12:14:05 -0000 > @@ -130,7 +130,9 @@ struct sockaddr_ipx { > struct ipx_addr sipx_addr; > char sipx_zero[2]; > }; > -#define sipx_port sipx_addr.x_port > +#define sipx_port sipx_addr.x_port > +#define sipx_network sipx_addr.x_net > +#define sipx_node sipx_addr.x_host.c_host > > /* > * Definitions for IPX Internetwork Packet Exchange Protocol > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > From owner-freebsd-net@FreeBSD.ORG Sun Jan 2 13:16:19 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B445816A4CE for ; Sun, 2 Jan 2005 13:16:19 +0000 (GMT) Received: from poczta.o2.pl (mx2.go2.pl [193.17.41.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DC1E43D1F for ; Sun, 2 Jan 2005 13:16:18 +0000 (GMT) (envelope-from knockefreebsd@o2.pl) Received: from ALFA (aaf223.warszawa.sdi.tpnet.pl [217.97.85.223]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by poczta.o2.pl (Postfix) with ESMTP id D331660292 for ; Sun, 2 Jan 2005 14:16:15 +0100 (CET) Message-ID: <002e01c4f0cd$8e986350$df5561d9@ALFA> From: "Heinz Knocke" To: Date: Sun, 2 Jan 2005 14:17:45 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: Speed problem - smbclient doesn't send duplicate ACKs in case of pacekt loss X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Heinz Knocke List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2005 13:16:19 -0000 Hi! I'm not sure if this is an OS or Samba problem, so I send similar questions to both: FreeBSD related list and Samba. I'm trying to tune samba on my two directly linked boxes and encountered a strange problem. When serving one big (1-2GB file) locally over lo0 transmission reaches speed of about 32 MB/s which is OK. But when doing the very same thing over the network, speed drops to 10 MB/s. It's so because of quite often single packet drops, which are detected by the server only using RTO timeout. Smbclient simply doesn't send duplicate ACKs to show that sth is missing, so server needs to wait whole RTO (as long as ab. 300ms) and then resends missing packet, transmissions resumes. Such beahovior appears every few seconds. Of course in result of congestion window drop, speed is very unstable, raising with the cwnd and dropping rapidly after RTO timeout. Thats why i think the average speed is so low. My general question is why it happens and what can I do about it? Is it a samba side problem or OS' ? I don't expect to be the latter, because netperf TCP stream gives as much as 720 Mbps. One thing that specially makes me wonder, is that theoretically client doesnt need to send duplicate ACK, because the missing segment is the last in the burst sent (see packet dump extract below). So it may not know if it's just missing or never sent. What should the TCP do then, what may I tune? Samba: 3.0.7 both smbclient and server, compiled from FreeBSD ports totaly basic, default smb.conf, with TCP_NODELAY socket option only hardware details: Intel P4 2.8 Ghz , 512 MB RAM SATA HDDs (capable of giving the test file with a speed of 52 MB/s when writing to RAM directly) net: Marvell Gigabit Ethernet 32bit PCI NICs, using 9K jumbograms capable of doing about 720 Mbps bandwith for TCP application (meassured with netperf after link layer tuning). OS: FreeBSD 5-STABLE (Dec 19 20:48:37) packet dumps: server: 1104512342.542532 IP 10.10.10.1.445 > 10.10.10.2.49821: P 3807194718:3807198814(4096) ack 1971888923 win 32768 1104512342.542541 IP 10.10.10.1.445 > 10.10.10.2.49821: P 3807198814:3807202910(4096) ack 1971888923 win 32768 1104512342.542872 IP 10.10.10.2.49821 > 10.10.10.1.445: . ack 3807194718 win 31744 1104512342.635501 IP 10.10.10.2.49821 > 10.10.10.1.445: . ack 3807198814 win 32768 1104512342.956050 IP 10.10.10.1.445 > 10.10.10.2.49821: P 3807198814:3807202910(4096) ack 1971888923 win 32768 client: 1104516217.899613 IP 10.10.10.1.445 > 10.10.10.2.49821: P 3807194718:3807198814(4096) ack 1971888923 win 32768 1104516217.899629 IP 10.10.10.2.49821 > 10.10.10.1.445: . ack 3807194718 win 31744 1104516217.992217 IP 10.10.10.2.49821 > 10.10.10.1.445: . ack 3807198814 win 32768 1104516218.313000 IP 10.10.10.1.445 > 10.10.10.2.49821: P 3807198814:3807202910(4096) ack 1971888923 win 32768 smb.conf: [global] workgroup = MYGROUP server string = Samba Server security = user interfaces = 10.10.1.98,10.10.10.1 log file = /var/log/samba/log.%m max log size = 50000 log level = 1 socket options = TCP_NODELAY dns proxy = no [homes] comment = Home Directories browseable = no writable = yes [test] comment = export SATA path = /mnt/sata/test guest ok = yes read only = yes From owner-freebsd-net@FreeBSD.ORG Sun Jan 2 21:14:57 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81E4116A4CE; Sun, 2 Jan 2005 21:14:57 +0000 (GMT) Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at [128.131.111.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1348943D1F; Sun, 2 Jan 2005 21:14:57 +0000 (GMT) (envelope-from gerald@pfeifer.com) Received: from [128.131.111.60] (acrux [128.131.111.60]) by vexpert.dbai.tuwien.ac.at (Postfix) with ESMTP id CA13213797; Sun, 2 Jan 2005 22:14:55 +0100 (CET) Date: Sun, 2 Jan 2005 22:15:01 +0100 (CET) From: Gerald Pfeifer To: Robert Watson In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: PATCH: /usr/include/netipx/ipx.h and Linux compatibility X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2005 21:14:57 -0000 On Sun, 2 Jan 2005, Robert Watson wrote: > FYI: It looks like Bruce Simpson applied this change (or one very much > like it) to HEAD (5-CURRENT) ipx.h as 1.18, and I recently merged it > RELENG_4 ipx.h as 1.15.2.1. Thanks! Gerald -- Gerald Pfeifer (Jerry) gerald@pfeifer.com http://www.pfeifer.com/gerald/ From owner-freebsd-net@FreeBSD.ORG Mon Jan 3 07:31:31 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BA0B16A4CE for ; Mon, 3 Jan 2005 07:31:31 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 17E7643D3F for ; Mon, 3 Jan 2005 07:31:31 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 99572 invoked from network); 3 Jan 2005 07:31:30 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 3 Jan 2005 07:31:30 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 3 Jan 2005 01:31:29 -0600 (CST) From: Mike Silbersack To: net@freebsd.org Message-ID: <20050103012325.A62262@odysseus.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-127286633-1104737489=:62262" Subject: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 07:31:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-127286633-1104737489=:62262 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed With re's permission, I'm going to commit FreeBSD's fix for the RST part of the slipping in the window attack to 4.11 in the next few days. That's not a big deal, we seem to have an acceptable solution there. (See tcp_input.c rev 1.235 for more info.) The SYN side of the equation, however, is a bit more tricky. The proposed RFC recommends ACKing SYN packets in the window, just like we do to SYN packets to the left of the window right now. For the life of me, I can't figure out why SYN packets (other than delayed retransmissions of the original SYN) would ever show up once a connection is in the ESTABLISHED state. So, I'm proposing the attached patch, which simply ignores any packet with the SYN flag on it while a connection is in the ESTABLISHED state. This means that SYN packets left of the window will no longer receive an ACK, and SYN packets in the window will no longer reset the connection. In all states other than ESTABLISHED, SYN packets are handled as they were before, in case there's some edge case where that could happen. What are people's thoughts on this? I'm especially interested how stateful firewalls like IPF or PF would handle such a situation. How do they respond to unexpected SYN packets? Mike "Silby" Silbersack --0-127286633-1104737489=:62262 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="tcp_input.c-insecure_syn.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20050103013129.F62262@odysseus.silby.com> Content-Description: Content-Disposition: attachment; filename="tcp_input.c-insecure_syn.patch" ZGlmZiAtdSAtciAvdXNyL3NyYy9zeXMub2xkL25ldGluZXQvdGNwX2lucHV0 LmMgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX2lucHV0LmMNCi0tLSAvdXNy L3NyYy9zeXMub2xkL25ldGluZXQvdGNwX2lucHV0LmMJTW9uIEphbiAgMyAw MToxMTo0MCAyMDA1DQorKysgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX2lu cHV0LmMJTW9uIEphbiAgMyAwMToxNzowMyAyMDA1DQpAQCAtMTM2LDYgKzEz NiwxMSBAQA0KICAgICAmdGNwX2luc2VjdXJlX3JzdCwgMCwNCiAgICAgIkZv bGxvdyB0aGUgb2xkIChpbnNlY3VyZSkgY3JpdGVyaWEgZm9yIGFjY2VwdGlu ZyBSU1QgcGFja2V0cy4iKTsNCiANCitzdGF0aWMgaW50IHRjcF9pbnNlY3Vy ZV9zeW4gPSAwOw0KK1NZU0NUTF9JTlQoX25ldF9pbmV0X3RjcCwgT0lEX0FV VE8sIGluc2VjdXJlX3N5biwgQ1RMRkxBR19SVywNCisgICAgJnRjcF9pbnNl Y3VyZV9zeW4sIDAsDQorICAgICJGb2xsb3cgdGhlIG9sZCBjcml0ZXJpYSBh bGxvd2luZyBTWU4gcGFja2V0cyB0byByZXNldCBhIGNvbm5lY3Rpb24uIik7 DQorDQogU1lTQ1RMX05PREUoX25ldF9pbmV0X3RjcCwgT0lEX0FVVE8sIHJl YXNzLCBDVExGTEFHX1JXLCAwLA0KIAkgICAgIlRDUCBTZWdtZW50IFJlYXNz ZW1ibHkgUXVldWUiKTsNCiANCkBAIC0xNTYwLDYgKzE1NjUsMTMgQEANCiAJ CQl9DQogCQl9DQogCQlnb3RvIGRyb3A7DQorCX0NCisNCisJaWYgKHRoZmxh Z3MgJiBUSF9TWU4pIHsNCisJCWlmICh0cC0+dF9zdGF0ZSA9PSBUQ1BTX0VT VEFCTElTSEVEICYmDQorCQkgICAgdGNwX2luc2VjdXJlX3N5biA9PSAwKSB7 DQorCQkJZ290byBkcm9wOw0KKwkJfQ0KIAl9DQogDQogCS8qDQo= --0-127286633-1104737489=:62262-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 3 10:54:30 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD92F16A4CE for ; Mon, 3 Jan 2005 10:54:30 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88E7B43D49 for ; Mon, 3 Jan 2005 10:54:30 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) j03AsTwN022946; Mon, 3 Jan 2005 02:54:30 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id j03AsQIa088642; Mon, 3 Jan 2005 02:54:27 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Mon, 03 Jan 2005 19:54:21 +0900 Message-ID: From: gnn@FreeBSD.org To: Mike Silbersack In-Reply-To: <20050103012325.A62262@odysseus.silby.com> References: <20050103012325.A62262@odysseus.silby.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: net@FreeBSD.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 10:54:30 -0000 At Mon, 3 Jan 2005 01:31:29 -0600 (CST), Mike Silbersack wrote: > For the life of me, I can't figure out why SYN packets (other than delayed > retransmissions of the original SYN) would ever show up once a connection > is in the ESTABLISHED state. They "shouldn't" and I think ignoring them makes sense, but that's just me. I gather you did a search of Stevens to see if there had ever been a justification for dealing with SYN once established? The only thing I could think of was to go look again at how half open connections are handled. I have not taken a look at that, but it sticks in my mind as the only thing that could cause an issue. > So, I'm proposing the attached patch, which simply ignores any > packet with the SYN flag on it while a connection is in the > ESTABLISHED state. That sounds fine to me. > What are people's thoughts on this? I'm especially interested how > stateful firewalls like IPF or PF would handle such a situation. How do > they respond to unexpected SYN packets? Well, those I cannot comment on. > diff -u -r /usr/src/sys.old/netinet/tcp_input.c > /usr/src/sys/netinet/tcp_input.c One quick comment on the patch. Do we want to count these kinds of drops separately? Later, George From owner-freebsd-net@FreeBSD.ORG Mon Jan 3 11:02:03 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4480316A4F6 for ; Mon, 3 Jan 2005 11:02:03 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F9E143D1D for ; Mon, 3 Jan 2005 11:02:03 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j03B23G7006143 for ; Mon, 3 Jan 2005 11:02:03 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j03B220P006137 for freebsd-net@freebsd.org; Mon, 3 Jan 2005 11:02:02 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 3 Jan 2005 11:02:02 GMT Message-Id: <200501031102.j03B220P006137@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 11:02:03 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/07/26] kern/41007 net overfull traffic on third and fourth adap o [2003/10/14] kern/57985 net [patch] Missing splx in ether_output_fram 2 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 3 12:30:15 2005 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A32916A4CE; Mon, 3 Jan 2005 12:30:15 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2586443D48; Mon, 3 Jan 2005 12:30:15 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (rwatson@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j03CUFsY021133; Mon, 3 Jan 2005 12:30:15 GMT (envelope-from rwatson@freefall.freebsd.org) Received: (from rwatson@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j03CUEY5021129; Mon, 3 Jan 2005 12:30:14 GMT (envelope-from rwatson) Date: Mon, 3 Jan 2005 12:30:14 GMT From: Robert Watson Message-Id: <200501031230.j03CUEY5021129@freefall.freebsd.org> To: rwatson@FreeBSD.org, freebsd-net@FreeBSD.org, rwatson@FreeBSD.org Subject: Re: kern/57985: [patch] Missing splx in ether_output_frame (-stable) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 12:30:15 -0000 Synopsis: [patch] Missing splx in ether_output_frame (-stable) Responsible-Changed-From-To: freebsd-net->rwatson Responsible-Changed-By: rwatson Responsible-Changed-When: Mon Jan 3 12:25:48 GMT 2005 Responsible-Changed-Why: Grab ownership of this PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=57985 From owner-freebsd-net@FreeBSD.ORG Mon Jan 3 18:02:30 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E0BA16A4CE for ; Mon, 3 Jan 2005 18:02:30 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21DD543D5D for ; Mon, 3 Jan 2005 18:02:30 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id j03I2Tta023994; Mon, 3 Jan 2005 10:02:29 -0800 (PST) Received: from [10.1.1.245] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)j03I2R7i003947; Mon, 3 Jan 2005 10:02:28 -0800 (PST) In-Reply-To: <20050103012325.A62262@odysseus.silby.com> References: <20050103012325.A62262@odysseus.silby.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Mon, 3 Jan 2005 13:02:26 -0500 To: Mike Silbersack X-Mailer: Apple Mail (2.619) cc: net@freebsd.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 18:02:30 -0000 On Jan 3, 2005, at 2:31 AM, Mike Silbersack wrote: > For the life of me, I can't figure out why SYN packets (other than > delayed retransmissions of the original SYN) would ever show up once a > connection is in the ESTABLISHED state. So, I'm proposing the > attached patch, which simply ignores any packet with the SYN flag on > it while a connection is in the ESTABLISHED state. Are you relying on the IPID or the connection tuple of srcIP+srcPort+destIP+destPort to identify the SYN packet as being associated with an already established connection? I suppose that if the sending TCP stack has poor IPID sequence generation, maybe it could be reusing IPIDs and thus breaking the uniqueness assumption. > This means that SYN packets left of the window will no longer receive > an ACK, and SYN packets in the window will no longer reset the > connection. In all states other than ESTABLISHED, SYN packets are > handled as they were before, in case there's some edge case where that > could happen. This seems to be a reasonable improvement: the stack shouldn't be ACK'ing data outside of a valid connection window to begin with. > What are people's thoughts on this? I'm especially interested how > stateful firewalls like IPF or PF would handle such a situation. How > do they respond to unexpected SYN packets? Generally, each bare SYN packet is treated as a seperate new connection request, and they expect the destination TCP stack to handle any duplicate SYNs resulting from duplicated packets. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Mon Jan 3 18:40:50 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6626016A4CE for ; Mon, 3 Jan 2005 18:40:50 +0000 (GMT) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46A1E43D1F for ; Mon, 3 Jan 2005 18:40:50 +0000 (GMT) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id j03IenBC002023; Mon, 3 Jan 2005 10:40:49 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 471E477B0CC; Mon, 3 Jan 2005 13:40:48 -0500 (EST) To: Mike Silbersack From: Mark Allman In-Reply-To: <20050103012325.A62262@odysseus.silby.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Just the Way You Are MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 03 Jan 2005 13:40:48 -0500 Sender: mallman@icir.org Message-Id: <20050103184048.471E477B0CC@guns.icir.org> cc: net@freebsd.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 18:40:50 -0000 --=-=-= Content-Type: text/plain > The SYN side of the equation, however, is a bit more tricky. The > proposed RFC recommends ACKing SYN packets in the window, just like > we do to SYN packets to the left of the window right now. > > For the life of me, I can't figure out why SYN packets (other than > delayed retransmissions of the original SYN) would ever show up once > a connection is in the ESTABLISHED state. So, I'm proposing the > attached patch, which simply ignores any packet with the SYN flag on > it while a connection is in the ESTABLISHED state. This means that > SYN packets left of the window will no longer receive an ACK, and > SYN packets in the window will no longer reset the connection. In > all states other than ESTABLISHED, SYN packets are handled as they > were before, in case there's some edge case where that could happen. This sounds OK to me. FWIW. allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB2ZGwWyrrWs4yIs4RAnE2AJ9kz9hIaqfpTQNzBGH4qwTWXBQXRQCghDNA gDnWFNkuM1aYvf64BSX/OOc= =vpD3 -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 3 18:55:57 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E260C16A4CE for ; Mon, 3 Jan 2005 18:55:57 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F9CF43D2D for ; Mon, 3 Jan 2005 18:55:57 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j03Itnmh002076; Mon, 3 Jan 2005 10:55:53 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501031855.j03Itnmh002076@gw.catspoiler.org> Date: Mon, 3 Jan 2005 10:55:49 -0800 (PST) From: Don Lewis To: silby@silby.com In-Reply-To: <20050103012325.A62262@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: net@FreeBSD.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 18:55:58 -0000 On 3 Jan, Mike Silbersack wrote: > > With re's permission, I'm going to commit FreeBSD's fix for the RST part > of the slipping in the window attack to 4.11 in the next few days. That's > not a big deal, we seem to have an acceptable solution there. (See > tcp_input.c rev 1.235 for more info.) > > The SYN side of the equation, however, is a bit more tricky. The proposed > RFC recommends ACKing SYN packets in the window, just like we do to > SYN packets to the left of the window right now. > > For the life of me, I can't figure out why SYN packets (other than delayed > retransmissions of the original SYN) would ever show up once a connection > is in the ESTABLISHED state. It can happen if one side of the connection crashes and tries to reconnect using the same source port. The BGP case, which is the case where attacks are of most concern, likes to connect from port 179 to port 179. > So, I'm proposing the attached patch, which > simply ignores any packet with the SYN flag on it while a connection is in > the ESTABLISHED state. This means that SYN packets left of the window > will no longer receive an ACK, and SYN packets in the window will no > longer reset the connection. In all states other than ESTABLISHED, > SYN packets are handled as they were before, in case there's some edge > case where that could happen. That'll hose things in the case I mentioned above. A client that reboots and loses it's connection state won't be able to reconnect until the server transmits something that provkes a RST response that causes the server to drop the connection. It's probably safer to just defang the code that handles the in-window case, which would reduce the probability of a reconnection attempt failing. /* * If a SYN is in the window, then this is an * error and we send an RST and drop the connection. */ if (thflags & TH_SYN) { if (tcp_insecure_syn == 0) goto drop; else { tp = tcp_drop(tp, ECONNRESET); rstreason = BANDLIM_UNLIMITED; goto dropwithreset; } I'd also be hesitant to change the default behaviour. > What are people's thoughts on this? I'm especially interested how > stateful firewalls like IPF or PF would handle such a situation. How do > they respond to unexpected SYN packets? > > Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Mon Jan 3 20:14:43 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B66AD16A4CE for ; Mon, 3 Jan 2005 20:14:43 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76BF443D49 for ; Mon, 3 Jan 2005 20:14:43 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j03KEZdB002233; Mon, 3 Jan 2005 12:14:40 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501032014.j03KEZdB002233@gw.catspoiler.org> Date: Mon, 3 Jan 2005 12:14:35 -0800 (PST) From: Don Lewis To: silby@silby.com In-Reply-To: <200501031855.j03Itnmh002076@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: net@FreeBSD.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 20:14:43 -0000 On 3 Jan, Don Lewis wrote: > /* > * If a SYN is in the window, then this is an > * error and we send an RST and drop the connection. > */ > if (thflags & TH_SYN) { > if (tcp_insecure_syn == 0) > goto drop; > else { > tp = tcp_drop(tp, ECONNRESET); > rstreason = BANDLIM_UNLIMITED; > goto dropwithreset; > } Writing and posting while sleepy is not a good thing. The braces are unbalanced and the else after the goto drop isn't necessary, so just adding if (tcp_insecure_syn == 0) goto drop; in the obvious place would do the trick. This is probably the same section of code that would need to be modified to implement the behaviour recommended in the Internet Draft. A new version of the draft was release in November, but I haven't had a chance to look at it yet. It is at: . There was a presentation at an IETF meeting about the issues relating to the Cisco IPR claims: . From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 01:43:28 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FF5816A4CE for ; Tue, 4 Jan 2005 01:43:28 +0000 (GMT) Received: from mail23-kan-R.bigfish.com (mail-kan.bigfish.com [63.161.60.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id F07AF43D1F for ; Tue, 4 Jan 2005 01:43:27 +0000 (GMT) (envelope-from yfeng@verniernetworks.com) Received: from mail23-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail23-kan-R.bigfish.com (Postfix) with ESMTP id 5403D2E50D6 for ; Tue, 4 Jan 2005 01:43:27 +0000 (UCT) X-BigFish: VC Received: by mail23-kan (MessageSwitch) id 1104803007264277_21350; Tue, 4 Jan 2005 01:43:27 +0000 (UCT) Received: from exch2.verniernetworks.com (dns.verniernetworks.com [65.200.185.165]) by mail23-kan.bigfish.com (Postfix) with ESMTP id F3A9E2E3031 for ; Tue, 4 Jan 2005 01:43:26 +0000 (UCT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Jan 2005 17:43:16 -0800 Message-ID: <12394E9FCB7C8441BB238D7F67B402E407E5E1@exch2.verniernetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: User process starvation under heavy network traffic in FreeBSD 5.3 Thread-Index: AcTx/sKgb83W/4tDRuOSDUpWKB83uw== From: "Youlin Feng" To: Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: User process starvation under heavy network traffic in FreeBSD 5.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 01:43:28 -0000 Hello, =20 I posted this question to freebsd-arch earlier. Stefan Bethke suggested that I try freebsd-net instead. =20 We are building a network appliance running FreeBSD 5.3 and under very heavy network traffic the user processes don't get scheduled for an unacceptable period of time. Marking the user process/thread real-time class doesn't help since the real-time user threads priorities are still lower than the interrupt threads. BTW, in our case, the CPU spends very long time at PI_NET (16) priority level, instead of at the (PI_SOFT + 4) soft intr level due to the packet forwarding nature. Either way, the user processes don't have a chance. In the following discussion I'll use PI_NET to represent the network interrupt threads priority. =20 I am experimenting with improving the real-time threads scheduling performance and would like to hear from you. =20 Here is what I am doing: 1. Raise the minimum real-time user threads priority to a value higher than PI_NET, e.g.=20 #define PRI_MIN_REALTIME 0 And use the rtprio() syscall or command to set the priority to be higher than PI_NET, e.g. "rtprio 10 " =20 This didn't turn out to be enough, since the real-time user process still uses system services or drivers that run at a lower priority than PI_NET, e.g. disk, tty, etc. =20 2. Change the PI_NET value to be the highest of all interrupt threads. Potential performance impact isn't a concern here since we have relatively rare non-network events. So PI_NET is changed to (PRI_MIN_ITHD + 32) from (PRI_MIN_ITHD + 16). This should give preference to all other I/O interrupt threads. I am assuming the software interrupt scheduling isn't the bottleneck.=20 =20 I haven't got a chance to reproduce the problem using the 2nd change yet. I suspect that it isn't enough to get what I want, since lots of kernel code do msleep(...,pri,...) with "pri" bigger than the changed PI_NET. But, if this thinking of changing the priority ranges makes sense, PI_NET can always be changed to the highest value of all kernel priority values, ie the lowest kernel priority. =20 Hopefully this change would work and not be intrusive to the kernel. =20 Thank you for your comments in advance. =20 Youlin Feng =20 From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 05:02:50 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2BC716A4CE for ; Tue, 4 Jan 2005 05:02:50 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 4BD8F43D39 for ; Tue, 4 Jan 2005 05:02:50 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 25591 invoked from network); 4 Jan 2005 05:02:49 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 4 Jan 2005 05:02:49 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 3 Jan 2005 23:02:48 -0600 (CST) From: Mike Silbersack To: Charles Swiger In-Reply-To: Message-ID: <20050103230044.X68869@odysseus.silby.com> References: <20050103012325.A62262@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: net@freebsd.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 05:02:50 -0000 On Mon, 3 Jan 2005, Charles Swiger wrote: > Are you relying on the IPID or the connection tuple of > srcIP+srcPort+destIP+destPort to identify the SYN packet as being associated > with an already established connection? Connection tuple. >> This means that SYN packets left of the window will no longer receive an >> ACK, and SYN packets in the window will no longer reset the connection. In >> all states other than ESTABLISHED, SYN packets are handled as they were >> before, in case there's some edge case where that could happen. > > This seems to be a reasonable improvement: the stack shouldn't be ACK'ing > data outside of a valid connection window to begin with. I spoke inaccurately above. We trim the ACK to the left edge of our window, then ACK that value. So, it *shouldn't* affect the state of the connection, but it will cause us to flood ACKs. More comments coming, see upcoming reply to Don... Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 05:21:58 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62D8616A4CE for ; Tue, 4 Jan 2005 05:21:58 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id CA71F43D46 for ; Tue, 4 Jan 2005 05:21:57 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 16555 invoked from network); 4 Jan 2005 05:21:57 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 4 Jan 2005 05:21:57 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 3 Jan 2005 23:21:55 -0600 (CST) From: Mike Silbersack To: Don Lewis In-Reply-To: <200501031855.j03Itnmh002076@gw.catspoiler.org> Message-ID: <20050103230259.G68869@odysseus.silby.com> References: <200501031855.j03Itnmh002076@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: net@FreeBSD.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 05:21:58 -0000 On Mon, 3 Jan 2005, Don Lewis wrote: >> For the life of me, I can't figure out why SYN packets (other than delayed >> retransmissions of the original SYN) would ever show up once a connection >> is in the ESTABLISHED state. > > It can happen if one side of the connection crashes and tries to > reconnect using the same source port. The BGP case, which is the case > where attacks are of most concern, likes to connect from port 179 to > port 179. Argh. I was assuming that the client would be using ephemeral ports, and therefore pick a different one after the crashed. Apps like BGP throw a wrench into this, I guess. :) I just went and took a look at the REVISED version of the draft for this issue: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-02.txt And it turns out that I should have looked at it earlier; this version actually provides useful advice on the SYN case. Specifically, it suggests that in response to all SYNs, an ACK for the left edge of the window be sent; no SYNs are allowed to reset the connection. Sounds like that's the way to go, with the addition of rate limiting those ACKs. The TCP state machine is pretty complex, so it seems like we'd better use something which does not alter the state in any way to send out the ACKs here. Does this look like it'd do the trick? (Stolen from the keepalive code): t_template = tcpip_maketemplate(inp); if (t_template) { tcp_respond(tp, t_template->tt_ipgen, &t_template->tt_t, (struct mbuf *)NULL, tp->rcv_nxt, tp->snd_una - 1, 0); (void) m_free(dtom(t_template)); } Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 06:03:28 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D71F416A4CE for ; Tue, 4 Jan 2005 06:03:28 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5191443D1D for ; Tue, 4 Jan 2005 06:03:28 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j0463Kx4003063; Mon, 3 Jan 2005 22:03:25 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501040603.j0463Kx4003063@gw.catspoiler.org> Date: Mon, 3 Jan 2005 22:03:20 -0800 (PST) From: Don Lewis To: silby@silby.com In-Reply-To: <20050103230259.G68869@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: net@FreeBSD.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 06:03:28 -0000 On 3 Jan, Mike Silbersack wrote: > > On Mon, 3 Jan 2005, Don Lewis wrote: > >>> For the life of me, I can't figure out why SYN packets (other than delayed >>> retransmissions of the original SYN) would ever show up once a connection >>> is in the ESTABLISHED state. >> >> It can happen if one side of the connection crashes and tries to >> reconnect using the same source port. The BGP case, which is the case >> where attacks are of most concern, likes to connect from port 179 to >> port 179. > > Argh. I was assuming that the client would be using ephemeral ports, and > therefore pick a different one after the crashed. Apps like BGP throw a > wrench into this, I guess. :) > > I just went and took a look at the REVISED version of the draft for this > issue: > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-02.txt > > And it turns out that I should have looked at it earlier; this version > actually provides useful advice on the SYN case. Specifically, it > suggests that in response to all SYNs, an ACK for the left edge of the > window be sent; no SYNs are allowed to reset the connection. That's pretty much what previous versions of the draft suggested. The earlier versions made some suggestions about how to deal with the corner case by adjusting the sequence number in ACK, but these schemes added a bunch of complexity and had some fatal flaws. I believe that sending the ACK challenge is the Cisco IPR claim. > Sounds like that's the way to go, with the addition of rate limiting those > ACKs. I'm not sure that it makes sense to rate limit the ACKs in this special case. If an attacker has enough information to trigger an ACK response flood from the hardened stack, he could still produce a flood by turning off the SYN bit. A general way of rate limiting ACKs triggered by the reception of out of window data could be a good idea, but this would have to be done very carefully to avoid breaking the algorithms that look at ACKs to sense network congestion. > The TCP state machine is pretty complex, so it seems like we'd better > use something which does not alter the state in any way to send out the > ACKs here. Does this look like it'd do the trick? (Stolen from the > keepalive code): > > t_template = tcpip_maketemplate(inp); > if (t_template) { > tcp_respond(tp, t_template->tt_ipgen, > &t_template->tt_t, (struct mbuf *)NULL, > tp->rcv_nxt, tp->snd_una - 1, 0); > (void) m_free(dtom(t_template)); > } I was going to suggest just doing a goto dropafterack; but there's a lot of code in tcp_output() that might unnecessarily perturb things. I think you can get away without creating a template for this. Take a look at the code under the dropwithreset label. I'd put this code down with dropafterack and dropwithreset. There may be other cases where it should be used in place of the dropafterack code. From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 06:35:58 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04DE916A4CE for ; Tue, 4 Jan 2005 06:35:57 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 55CB843D2F for ; Tue, 4 Jan 2005 06:35:57 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 34222 invoked from network); 4 Jan 2005 06:35:56 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 4 Jan 2005 06:35:56 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 4 Jan 2005 00:35:55 -0600 (CST) From: Mike Silbersack To: Don Lewis In-Reply-To: <200501040603.j0463Kx4003063@gw.catspoiler.org> Message-ID: <20050104002732.D68869@odysseus.silby.com> References: <200501040603.j0463Kx4003063@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: net@FreeBSD.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 06:35:58 -0000 On Mon, 3 Jan 2005, Don Lewis wrote: > That's pretty much what previous versions of the draft suggested. The > earlier versions made some suggestions about how to deal with the corner > case by adjusting the sequence number in ACK, but these schemes added a > bunch of complexity and had some fatal flaws. > > I believe that sending the ACK challenge is the Cisco IPR claim. The goofy special cases in the previous draft could have potentially been unique. In the current draft, however, their description of the ACK challenge to an incoming SYN follows RFC 793 Figure 10 (page 34) exactly. I think we're safe here. >> Sounds like that's the way to go, with the addition of rate limiting those >> ACKs. > > I'm not sure that it makes sense to rate limit the ACKs in this special > case. If an attacker has enough information to trigger an ACK response > flood from the hardened stack, he could still produce a flood by turning > off the SYN bit. A general way of rate limiting ACKs triggered by the > reception of out of window data could be a good idea, but this would > have to be done very carefully to avoid breaking the algorithms that > look at ACKs to sense network congestion. I probably agree here... but I want to just fix this one problem for 4.11, and I don't want to touch the rest of the TCP stack whatsoever. If integrating this case with others in rate limiting makes sense, we could do that in 6.x and 5.x, but I don't want to risk breaking 4.x by rewriting dropafterack at this point in time. > I was going to suggest just doing a > goto dropafterack; > but there's a lot of code in tcp_output() that might unnecessarily > perturb things. I think you can get away without creating a template > for this. Take a look at the code under the dropwithreset label. Hm, tcp_respond does look like a good candidate... BTW, that tcp template code should probably have been removed years ago, it's only used by keepalives now. I just haven't gotten around to replacing it. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 07:49:32 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4EB016A4CE for ; Tue, 4 Jan 2005 07:49:32 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D1A543D31 for ; Tue, 4 Jan 2005 07:49:32 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j047nOKC003234; Mon, 3 Jan 2005 23:49:29 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501040749.j047nOKC003234@gw.catspoiler.org> Date: Mon, 3 Jan 2005 23:49:24 -0800 (PST) From: Don Lewis To: silby@silby.com In-Reply-To: <20050104002732.D68869@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: net@FreeBSD.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 07:49:32 -0000 On 4 Jan, Mike Silbersack wrote: > > On Mon, 3 Jan 2005, Don Lewis wrote: >> I'm not sure that it makes sense to rate limit the ACKs in this special >> case. If an attacker has enough information to trigger an ACK response >> flood from the hardened stack, he could still produce a flood by turning >> off the SYN bit. A general way of rate limiting ACKs triggered by the >> reception of out of window data could be a good idea, but this would >> have to be done very carefully to avoid breaking the algorithms that >> look at ACKs to sense network congestion. > > I probably agree here... but I want to just fix this one problem for 4.11, > and I don't want to touch the rest of the TCP stack whatsoever. If > integrating this case with others in rate limiting makes sense, we could > do that in 6.x and 5.x, but I don't want to risk breaking 4.x by rewriting > dropafterack at this point in time. Agreed. Tweaking the dropafterack stuff would need to be thoroughly discussed, and it would need to soak for quite a while in 6.x to make sure that it didn't cause an interoperability problems. From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 11:05:30 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6F9316A4CE for ; Tue, 4 Jan 2005 11:05:30 +0000 (GMT) Received: from manian.sics.se (manian.sics.se [193.10.66.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2127543D49 for ; Tue, 4 Jan 2005 11:05:30 +0000 (GMT) (envelope-from bg@sics.se) Received: from manian.sics.se (localhost [127.0.0.1]) by manian.sics.se (8.13.1/8.13.1) with SMTP id j04B5SRC048822; Tue, 4 Jan 2005 12:05:28 +0100 (CET) (envelope-from bg@sics.se) Date: Tue, 4 Jan 2005 12:05:28 +0100 From: =?ISO-8859-1?Q?Bj=F6rn_Gr=F6nvall?= To: freebsd-net@freebsd.org Message-ID: <20050104120528.04e48bcc@manian.sics.se> In-Reply-To: <12394E9FCB7C8441BB238D7F67B402E407E5E1@exch2.verniernetworks.com> References: <12394E9FCB7C8441BB238D7F67B402E407E5E1@exch2.verniernetworks.com> Organization: SICS X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; i386-portbld-freebsd5.3) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: User process starvation under heavy network traffic in FreeBSD 5.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 11:05:30 -0000 On Mon, 3 Jan 2005 17:43:16 -0800 "Youlin Feng" wrote: > We are building a network appliance running FreeBSD 5.3 and under very > heavy network traffic the user processes don't get scheduled for an > unacceptable period of time. Did you try polling(4)? It does not affect scheduling the way you would like it to happen but it often it frees enough of the CPU resources to make the problem go away. Your milage may wary though. Cheers, Björn -- _ _ ,_______________. Bjorn Gronvall (Björn Grönvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg@sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 '---------------' From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 12:51:59 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C3CD16A4CE; Tue, 4 Jan 2005 12:51:59 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4DF843D1D; Tue, 4 Jan 2005 12:51:58 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 3E3A1ACC47; Tue, 4 Jan 2005 13:51:51 +0100 (CET) Date: Tue, 4 Jan 2005 13:51:51 +0100 From: Pawel Jakub Dawidek To: Andre Oppermann Message-ID: <20050104125151.GJ784@darkness.comp.waw.pl> References: <344de28704120412333e70fb76@mail.gmail.com> <344de28704120413306b410608@mail.gmail.com> <41B23C51.5B4207AC@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6iqOn7HZPWKXx18" Content-Disposition: inline In-Reply-To: <41B23C51.5B4207AC@freebsd.org> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: meno.abels@adviser.com cc: freebsd-net@freebsd.org Subject: Re: INADDR_ANY bind in a multiip jail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 12:51:59 -0000 --d6iqOn7HZPWKXx18 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 04, 2004 at 11:38:09PM +0100, Andre Oppermann wrote: +> Meno Abels wrote: +> >=20 +> > Hello, +> >=20 +> > i just found a patch from Pawel Jakub Dawidek(mijail5) which do not +> > need the pcb bind +> > to multiple ip's. He solve the problem my marking the socket that is b= ound to a +> > jail with inaddr_any. With this mark he is filtering the incoming +> > connection lookup to +> > the pcb structure on jail bases. This should enable the behavior that +> > i requested. +>=20 +> Do you have a link? I'd like to have a look at the code. There is a branch in perforce (pjd_jail) and the lastest patch is at: http://people.freebsd.org/~pjd/patches/jail_2004120901.patch --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --d6iqOn7HZPWKXx18 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFB2pFnForvXbEpPzQRAjXDAJ9SbYhdUcKSBJoabhtKaDVlmOttTwCgj599 hn3W9iXiCpctg9JhkmFq+5g= =u+Le -----END PGP SIGNATURE----- --d6iqOn7HZPWKXx18-- From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 15:22:10 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94A0916A4CE for ; Tue, 4 Jan 2005 15:22:10 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16BDE43D48 for ; Tue, 4 Jan 2005 15:22:10 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id j04FIUpj041122; Tue, 4 Jan 2005 10:18:30 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)j04FIUUL041119; Tue, 4 Jan 2005 15:18:30 GMT (envelope-from robert@fledge.watson.org) Date: Tue, 4 Jan 2005 15:18:30 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Youlin Feng In-Reply-To: <12394E9FCB7C8441BB238D7F67B402E407E5E1@exch2.verniernetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: User process starvation under heavy network traffic in FreeBSD 5.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 15:22:10 -0000 On Mon, 3 Jan 2005, Youlin Feng wrote: > We are building a network appliance running FreeBSD 5.3 and under very > heavy network traffic the user processes don't get scheduled for an > unacceptable period of time. Marking the user process/thread real-time > class doesn't help since the real-time user threads priorities are still > lower than the interrupt threads. BTW, in our case, the CPU spends very > long time at PI_NET (16) priority level, instead of at the (PI_SOFT + 4) > soft intr level due to the packet forwarding nature. Either way, the > user processes don't have a chance. In the following discussion I'll use > PI_NET to represent the network interrupt threads priority. I've seen some similar live lock issues with large quantities of local IPC traffic on SMP systems. Could you tell me if you are using an SMP system or SMP kernel? Are you using direct dispatch or link layer bridging that's running in the ithread as opposed to the netisr swi? Robert N M Watson > > > > I am experimenting with improving the real-time threads scheduling > performance and would like to hear from you. > > > > Here is what I am doing: > > 1. Raise the minimum real-time user threads priority to a value > higher than PI_NET, e.g. > > #define PRI_MIN_REALTIME 0 > > And use the rtprio() syscall or command to set the priority to be higher > than PI_NET, e.g. "rtprio 10 " > > > > This didn't turn out to be enough, since the real-time user process > still uses system services or drivers that run at a lower priority than > PI_NET, e.g. disk, tty, etc. > > > > 2. Change the PI_NET value to be the highest of all interrupt > threads. Potential performance impact isn't a concern here since we have > relatively rare non-network events. So PI_NET is changed to > (PRI_MIN_ITHD + 32) from (PRI_MIN_ITHD + 16). This should give > preference to all other I/O interrupt threads. I am assuming the > software interrupt scheduling isn't the bottleneck. > > > > I haven't got a chance to reproduce the problem using the 2nd change > yet. I suspect that it isn't enough to get what I want, since lots of > kernel code do msleep(...,pri,...) with "pri" bigger than the changed > PI_NET. But, if this thinking of changing the priority ranges makes > sense, PI_NET can always be changed to the highest value of all kernel > priority values, ie the lowest kernel priority. > > > > Hopefully this change would work and not be intrusive to the kernel. > > > > Thank you for your comments in advance. > > > > Youlin Feng > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 19:19:11 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0362416A4CE; Tue, 4 Jan 2005 19:19:11 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id A59A643D55; Tue, 4 Jan 2005 19:19:10 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id C4CAAA8121; Tue, 4 Jan 2005 11:18:04 -0800 (PST) Received: from mail.trippynames.com ([127.0.0.1]) by localhost (rand.nxad.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 33568-01; Tue, 4 Jan 2005 11:17:47 -0800 (PST) Received: from [192.168.1.5] (dsl081-069-073.sfo1.dsl.speakeasy.net [64.81.69.73]) by mail.trippynames.com (Postfix) with ESMTP id B0480A81B2; Tue, 4 Jan 2005 11:17:27 -0800 (PST) In-Reply-To: <7632915A8F000C4FAEFCF272A880344165164F@Ehost067.exch005intermedia.net> References: <7632915A8F000C4FAEFCF272A880344165164F@Ehost067.exch005intermedia.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <69A7A6D4-5E85-11D9-ACFF-000A95C705DC@chittenden.org> Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Tue, 4 Jan 2005 11:18:28 -0800 To: "Jeff Behl" X-Mailer: Apple Mail (2.619) cc: freebsd-net@freebsd.org cc: freebsd-performance@freebsd.org Subject: Re: %cpu in system - squid performance in FreeBSD 5.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 19:19:11 -0000 > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU > COMMAND > 474 squid 96 0 68276K 62480K select 0 53:38 16.80% 16.80% > squid > 311 bind 20 0 10628K 6016K kserel 0 12:28 0.00% 0.00% > named > > It's actually so good that one machine can now handle all traffic > (around 180 Mb/s) at < %50 cpu utilization. Seems like something in > the > network stack is responsible for the high %system cpu util... OH!!!! Wow, I should've noticed that earlier. Your hint about someone on Linux having the same problem tipped me off to look at the process state again. Anyway, you nearly answered your own question, save you probably aren't familiar with select(2)'s lack of scalability. Read these: http://www.kegel.com/c10k.html Specifically the four methods mentioned here: http://www.kegel.com/c10k.html#nb.select Then look at the benchmarks done using libevent(3): http://www.monkey.org/~provos/libevent/ Dime to dollar you're spending all of your time copying file descriptor arrays in and out of the kernel because squid uses select(2) instead of kqueue(2). Might be an interesting project for someone to take up to convert that to kqueue(2). Until then, any local TCP load balancer that uses kqueue(2) would also solve your problem (I'm not aware of any off the top of my head... pound(8) does, but it is only used for HTTP and is not a reverse proxy) and would likely prevent you from having your problems. -sc -- Sean Chittenden From owner-freebsd-net@FreeBSD.ORG Tue Jan 4 22:22:31 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8424316A4CF for ; Tue, 4 Jan 2005 22:22:31 +0000 (GMT) Received: from mail2.dbitech.ca (radius.wavefire.com [64.141.13.252]) by mx1.FreeBSD.org (Postfix) with SMTP id D850543D1F for ; Tue, 4 Jan 2005 22:22:30 +0000 (GMT) (envelope-from darcy@wavefire.com) Received: (qmail 10522 invoked from network); 4 Jan 2005 23:35:47 -0000 Received: from dbitech.wavefire.com (HELO ?64.141.15.253?) (darcy@64.141.15.253) by radius.wavefire.com with SMTP; 4 Jan 2005 23:35:47 -0000 From: Darcy Buskermolen Organization: Wavefire Technologies Corp. To: freebsd-net@freebsd.org Date: Tue, 4 Jan 2005 14:22:29 -0800 User-Agent: KMail/1.6.2 References: <7632915A8F000C4FAEFCF272A880344165164F@Ehost067.exch005intermedia.net> <69A7A6D4-5E85-11D9-ACFF-000A95C705DC@chittenden.org> In-Reply-To: <69A7A6D4-5E85-11D9-ACFF-000A95C705DC@chittenden.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501041422.29131.darcy@wavefire.com> cc: Jeff Behl cc: freebsd-performance@freebsd.org Subject: Re: %cpu in system - squid performance in FreeBSD 5.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2005 22:22:31 -0000 On January 4, 2005 11:18 am, Sean Chittenden wrote: > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU > > COMMAND > > 474 squid 96 0 68276K 62480K select 0 53:38 16.80% 16.80% > > squid > > 311 bind 20 0 10628K 6016K kserel 0 12:28 0.00% 0.00% > > named > > > > It's actually so good that one machine can now handle all traffic > > (around 180 Mb/s) at < %50 cpu utilization. Seems like something in > > the > > network stack is responsible for the high %system cpu util... > > OH!!!! Wow, I should've noticed that earlier. Your hint about someone > on Linux having the same problem tipped me off to look at the process > state again. Anyway, you nearly answered your own question, save you > probably aren't familiar with select(2)'s lack of scalability. Read > these: > > http://www.kegel.com/c10k.html > > > Specifically the four methods mentioned here: > > http://www.kegel.com/c10k.html#nb.select > > > Then look at the benchmarks done using libevent(3): > > http://www.monkey.org/~provos/libevent/ > > > Dime to dollar you're spending all of your time copying file descriptor > arrays in and out of the kernel because squid uses select(2) instead of > kqueue(2). Might be an interesting project for someone to take up to > convert that to kqueue(2). Until then, any local TCP load balancer > that uses kqueue(2) would also solve your problem (I'm not aware of any > off the top of my head... pound(8) does, but it is only used for HTTP > and is not a reverse proxy) and would likely prevent you from having > your problems. -sc squid-dev has kqueue support already. ./configure --disable-select --disable-poll --enable-kqueue -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com From owner-freebsd-net@FreeBSD.ORG Wed Jan 5 05:33:04 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D29E916A4CE for ; Wed, 5 Jan 2005 05:33:04 +0000 (GMT) Received: from web8404.mail.in.yahoo.com (web8404.mail.in.yahoo.com [202.43.219.152]) by mx1.FreeBSD.org (Postfix) with SMTP id 8F4B743D1F for ; Wed, 5 Jan 2005 05:33:03 +0000 (GMT) (envelope-from nehavrce@yahoo.co.in) Received: (qmail 85553 invoked by uid 60001); 5 Jan 2005 05:33:02 -0000 Message-ID: <20050105053301.85548.qmail@web8404.mail.in.yahoo.com> Received: from [202.54.13.146] by web8404.mail.in.yahoo.com via HTTP; Tue, 04 Jan 2005 21:33:01 PST Date: Tue, 4 Jan 2005 21:33:01 -0800 (PST) From: neha agrawal To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-860778746-1104903181=:84496" Content-Transfer-Encoding: 8bit Subject: Replaying a TCP connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2005 05:33:04 -0000 --0-860778746-1104903181=:84496 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Id: Content-Disposition: inline hello! i want to implement smtp protocol on the same machine.i have a libpcap trace file..in which i have captured mail traffic..(single session).and i want to develop a program which can read this trace file..and communicate with the smtp server... first packet is Sync packet in trace file..so i want to send it to smtp server...and then i want my progrem to handle the reply sent by server..(say it sent Syn-Ack) anf then my prgm should reply accordingly.. for doing this i am using PF_PACKET , SOCK_RAW and using sendto function...i am sending the packet..im able to see it through tcpdump...but theserver is not replying...why??i am wrking with linux Redhat 9 kernel 2.4.20-8 (...if u r familiar with flowreplay tool..i want to do something similar ...but mine is single session..so less complicated...) attching source code... do let me know..if i am on correct track... thnks Neha __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 --0-860778746-1104903181=:84496 Content-Type: application/octet-stream; name="tcp1.c" Content-Transfer-Encoding: base64 Content-Description: tcp1.c Content-Disposition: attachment; filename="tcp1.c" Lyp0aCBhIEZJTiBmbGFnIGFuZCBwYXNzIGl0IHRocm91Z2ggYSByYXcgc29j a2V0LgogKiAKICogVGhhbWVyIEFsLUhlcmJpc2ggc2hhZG93c0B3aGl0ZWZh bmcuY29tCiAqLwoKI2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8c3Rk aW8uaD4KCiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KI2luY2x1ZGUgPHN5cy9z b2NrZXQuaD4KCiNpbmNsdWRlIDxuZXRpbmV0L2luLmg+CiNpbmNsdWRlIDxh cnBhL2luZXQuaD4KCiNpbmNsdWRlIDxuZXRpbmV0L2luX3N5c3RtLmg+Cgoj aWYgZGVmaW5lZChMSU5VWCkKI2luY2x1ZGUgPGxpbnV4L2lwLmg+CiNpbmNs dWRlIDxsaW51eC90Y3AuaD4KI2Vsc2UKI2luY2x1ZGUgPG5ldGluZXQvaXAu aD4KI2luY2x1ZGUgPG5ldGluZXQvdGNwLmg+CiNlbmRpZgoKI2luY2x1ZGUg PHN0cmluZy5oPgojaW5jbHVkZSA8dW5pc3RkLmg+CiNpbmNsdWRlIDx0aW1l Lmg+CgojaW5jbHVkZSA8cmF3c29ja191dGlscy5oPgoKaW50IG1haW4oaW50 IGFyZ2MsY2hhciAqYXJndltdKQp7CiAgdW5zaWduZWQgY2hhciBwYWNrZXRb CiNpZiAhZGVmaW5lZChMSU5VWCkKICBzaXplb2Yoc3RydWN0IGlwKSArCiNl bHNlIC8qIExJTlVYICovCiAgc2l6ZW9mKHN0cnVjdCBpcGhkcikgKwojZW5k aWYgLyogTElOVVggKi8KICBzaXplb2Yoc3RydWN0IHRjcGhkcildOwogIHN0 cnVjdCBzb2NrYWRkcl9pbiBteXNvY2tldDsKICB1bnNpZ25lZCBzaG9ydCBz cG9ydCwgZHBvcnQ7CiAgc3RydWN0IGluX2FkZHIgc2FkZHIsIGRhZGRyOwog IHN0cnVjdCB0Y3BoZHIgKnRjcDsKICB1bnNpZ25lZCBsb25nIHNlcSwgYWNr OwogIGludCBzb2NrZCwgb24gPSAxOwogIAogIGlmKGFyZ2MgPCA1KSAgewog ICAgZnByaW50ZihzdGRlcnIsInVzYWdlOiAlcyBzb3VyY2VfcG9ydCBzb3Vy Y2VfYWRkcmVzcyBkZXN0X3BvcnQgZGVzdF9hZGRyZXNzXG4iLAoJICAgIGFy Z3ZbMF0pOwogICAgZXhpdCgxKTsKICB9CiAgCiAgc3BvcnQgPSAodW5zaWdu ZWQgc2hvcnQpYXRvaShhcmd2WzFdKTsKICBzYWRkci5zX2FkZHIgPSBpbmV0 X2FkZHIoYXJndlsyXSk7CiAgCiAgZHBvcnQgPSAodW5zaWduZWQgc2hvcnQp YXRvaShhcmd2WzNdKTsKICBkYWRkci5zX2FkZHIgPSBpbmV0X2FkZHIoYXJn dls0XSk7CiAgCiAgaWYoKHNvY2tkID0gc29ja2V0KEFGX0lORVQsU09DS19S QVcsSVBQUk9UT19SQVcpKSA8IDApICB7CiAgICBwZXJyb3IoInNvY2tldCIp OwogICAgZXhpdCgxKTsKICB9CiAgCiAgaWYoc2V0c29ja29wdChzb2NrZCxJ UFBST1RPX0lQLElQX0hEUklOQ0wsKGNoYXIgKikmb24sc2l6ZW9mKG9uKSkg PCAwKSAgewogICAgcGVycm9yKCJzZXRzb2Nrb3B0Iik7CiAgICBleGl0KDEp OwogIH0KICAKICAvKiBWZXJ5IGJhZCByYW5kb20gc2VxdWVuY2UgbnVtYmVy IGdlbmVyYXRvciAqLwogIAogIHNyYW5kKGdldHBpZCgpKTsKICAKICBzZXEg PSByYW5kKCkldGltZShOVUxMKTsKICBhY2sgPSByYW5kKCkldGltZShOVUxM KTsKICAKICBpcF9nZW4ocGFja2V0LElQUFJPVE9fVENQLHNhZGRyLGRhZGRy LHNpemVvZihwYWNrZXQpKTsKICAKI2lmICFkZWZpbmVkKExJTlVYKQoKICB0 Y3AgPSAoc3RydWN0IHRjcGhkciAqKShwYWNrZXQgKyBzaXplb2Yoc3RydWN0 IGlwKSk7CgogIHRjcF9nZW4oKGNoYXIgKil0Y3Asc3BvcnQsZHBvcnQsc2Vx LGFjayk7CgojaWYgIWRlZmluZWQoU09MQVJJU19DS1NVTV9CVUcpCiAgdGNw LT50aF9zdW0gPSB0cmFuc19jaGVjayhJUFBST1RPX1RDUCwoY2hhciAqKXRj cCwKCQkJICAgIHNpemVvZihzdHJ1Y3QgdGNwaGRyKSwKCQkJICAgIHNhZGRy LAoJCQkgICAgZGFkZHIpOwogIAojZWxzZSAvKiBTT0xBUklTX0NLU1VNX0JV RyAqLwoKICB0Y3AtPnRoX3N1bSA9IHNpemVvZihzdHJ1Y3QgdGNwaGRyKTsK CiNlbmRpZiAvKiBTT0xBUklTX0NLU1VNX0JVRyAqLwoKI2Vsc2UgLyogTElO VVggKi8KICAKICB0Y3AgPSAoc3RydWN0IHRjcGhkciAqKShwYWNrZXQgKyBz aXplb2Yoc3RydWN0IGlwaGRyKSk7CgogIHRjcF9nZW4oKGNoYXIgKil0Y3As c3BvcnQsZHBvcnQsc2VxLGFjayk7CiAgCiNpZiAhZGVmaW5lZChTT0xBUklT X0NLU1VNX0JVRykKICB0Y3AtPmNoZWNrID0gdHJhbnNfY2hlY2soSVBQUk9U T19UQ1AsKGNoYXIgKil0Y3AsCgkJCSAgIHNpemVvZihzdHJ1Y3QgdGNwaGRy KSwKCQkJICAgc2FkZHIsCgkJCSAgIGRhZGRyKTsKI2Vsc2UgLyogU09MQVJJ U19DS1NVTV9CVUcgKi8KCiAgdGNwLT5jaGVjayA9IHNpemVvZihzdHJ1Y3Qg dGNwaGRyKTsKCiNlbmRpZiAvKiBTT0xBUklTX0NLU1VNX0JVRyAqLwoKI2Vu ZGlmIC8qIExJTlVYICovCiAgCiAgbWVtc2V0KCZteXNvY2tldCwnXDAnLHNp emVvZihteXNvY2tldCkpOwogIAogIG15c29ja2V0LnNpbl9mYW1pbHkgPSBB Rl9JTkVUOwogIG15c29ja2V0LnNpbl9wb3J0ID0gaHRvbnMoZHBvcnQpOwog IG15c29ja2V0LnNpbl9hZGRyID0gZGFkZHI7CiAgCiAgaWYoc2VuZHRvKHNv Y2tkLCZwYWNrZXQsc2l6ZW9mKHBhY2tldCksMHgwLChzdHJ1Y3Qgc29ja2Fk ZHIgKikmbXlzb2NrZXQsCgkgICAgc2l6ZW9mKG15c29ja2V0KSkgIT0gc2l6 ZW9mKHBhY2tldCkpICB7CiAgICBwZXJyb3IoInNlbmR0byIpOwogICAgZXhp dCgxKTsKICB9CiAgCiAgZXhpdCgwKTsKfQo= --0-860778746-1104903181=:84496-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 5 09:53:45 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3EF716A4CE for ; Wed, 5 Jan 2005 09:53:45 +0000 (GMT) Received: from smtp1.wizzbit.nl (mail01.wizzbit.nl [62.58.54.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F20043D1D for ; Wed, 5 Jan 2005 09:53:44 +0000 (GMT) (envelope-from peter@soeteharing.nl) Received: from Spooler by smtp1.wizzbit.nl (Mercury/32 v4.01a) ID MO0009C3; 5 Jan 2005 10:48:49 +0100 Received: from spooler by wizzbit.nl (Mercury/32 v4.01a); 5 Jan 2005 10:48:17 +0100 Received: from [62.58.54.84] (62.58.54.84) by smtp1.wizzbit.nl (Mercury/32 v4.01a) with ESMTP ID MG0009C2; 5 Jan 2005 10:48:04 +0100 Message-ID: <41DBB8F8.4060206@soeteharing.nl> Date: Wed, 05 Jan 2005 10:52:56 +0100 From: Peter Rog User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CC-Diagnostic: Content contains "FREE" (5) Subject: Bridge and router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2005 09:53:45 -0000 Gents, I will first tell you my situation:(Sorry for my weak english) Internet --- Cisco 5200 VXR router(not manageble) --- Hub --- FreeBSD Bridge(IPFW firewall) --- LAN This situation works fine... In this situation i have 1 c-class subnet (255 address routed to the hub) 2 months ago the was configured a second c-class subnet on the same segment. Only different configured; one c-class subnet split in to 4 subnets with 64 addresses each. The first 2 are located on the same segment behind the FreeBSD Bridge. The 3th is routed like this: x.x.2.128 - 192 is by the router send to the x.x.1.2. This FreeBSD Router, located next to the FreeBSD Bridge, is connected to the Hub. The otherside to the intranet. Now i want to combine these two machine`s. I have a HP DL 140 (pizzabox) with 3 network interfaces. One for the hub(bge0), one for the LAN(bge1) and one for the intranet(xl0). This al works,... only nog more than a minute. It seems that the firewall hangs itself by looping packets or something. The machine has 3 interfaces, bge0 - WAN - x.x.1.2 - bridge activated bge1 - LAN - no ip - bridge activated xl0 - intranet - x.x.2.129 - no bridge The Sysctl has the bge0 and bge1 in promisc ! the rc.conf has the "Gateway_enable="YES". Can somebody tell me if there is a solution,...? Thanks. Peter Rog From owner-freebsd-net@FreeBSD.ORG Wed Jan 5 15:13:59 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 443E616A4CE for ; Wed, 5 Jan 2005 15:13:59 +0000 (GMT) Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB6DB43D4C for ; Wed, 5 Jan 2005 15:13:58 +0000 (GMT) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-68-76-113-50.dsl.bcvloh.ameritech.net [68.76.113.50]) by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id j05FDrBC031955; Wed, 5 Jan 2005 07:13:53 -0800 (PST) (envelope-from mallman@guns.icir.org) Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 87D2A77B0CC; Wed, 5 Jan 2005 10:13:52 -0500 (EST) To: Mike Silbersack , net@freebsd.org From: Mark Allman In-Reply-To: <20050103184048.471E477B0CC@guns.icir.org> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Into the Great Wide Open MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 05 Jan 2005 10:13:52 -0500 Sender: mallman@icir.org Message-Id: <20050105151352.87D2A77B0CC@guns.icir.org> cc: rrs@cisco.com Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2005 15:13:59 -0000 --=-=-= Content-Type: text/plain Folks- > > The SYN side of the equation, however, is a bit more tricky. The > > proposed RFC recommends ACKing SYN packets in the window, just like > > we do to SYN packets to the left of the window right now. > > > > For the life of me, I can't figure out why SYN packets (other than > > delayed retransmissions of the original SYN) would ever show up once > > a connection is in the ESTABLISHED state. So, I'm proposing the > > attached patch, which simply ignores any packet with the SYN flag on > > it while a connection is in the ESTABLISHED state. This means that > > SYN packets left of the window will no longer receive an ACK, and > > SYN packets in the window will no longer reset the connection. In > > all states other than ESTABLISHED, SYN packets are handled as they > > were before, in case there's some edge case where that could happen. > > This sounds OK to me. FWIW. I ran this idea by Randall Stewart who has done a bunch of thinking on this topic (and, helped produce one of the current internet-drafts on the topic). He swayed me that my initial hit (above) might not be quite right. Below is Randall's response to my forward of Mike's note (forwarded with permission). This is a case that had not occurred to me and leaves me thinking maybe ignoring SYNs is not quite the right approach. However, I think there could be times when ignoring SYNs might be fine. E.g., if the connection is moving right along and there are other packets being transmitted and ACKed and we see a SYN that it should be ignored. FWIW. allman --- Begin Randall's note --- Anyway.. we discussed this very option in GORY detail last year about this time.. and we discarded the idea for a number of important reasons.. a) It is NOT uncommon for a machine to be rebooted (there are a lot of windoz boxes out there.. not everyone uses FreeBSD) b) When a machine reboots that was a client, it is likely to pick the same starting port... so say if not many connections have been made.. I make some connection out of my windoz box to my favorite server "telnet my.favorite.server" .. and start working.. Of course my windoz box crashes.. chances are that if I do the same telnet again.. I get the same starting port (if port randomization is not in place.. which most O/S's dont' do). Guess what happens to my SYN ->>... dumpper. Now this means I must depend on the TCP endpoint that still has the hanging TCB to cleanup before I can connect on that port set. c) This is a nasty inconvience for a lot of apps.. for our internal ones that use the same ports often on each side.. (don't ask why since i don't understand all the reasoning.. but its the way it is) and guess what I get things that can't connect since all my SYN's upon reboot are ignored (not that a router ever crashes :-D) So... this is when we came up with the SYN idea... yes its possible you would never notice the SYN being dropped.. but, there will be SOME apps that do.. especially the more long term things such as banking ... routing... ip telephoney... etc. It might work ok most of the time.. but when it does not work and a crash as occured it will fail at the MOST miserable time. It would be far better to send back the ACK .. thus cleaning up the TCB and then allowing the connection to progress... at least IMO... --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFB3AQwWyrrWs4yIs4RAg/3AJ4ojLLq2QYm2mngWU+WU6IxsxMrCgCfae78 u020LMCUM5Ds/t0eb7IMDS4= =6LfN -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 6 13:42:38 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32A8C16A4CE for ; Thu, 6 Jan 2005 13:42:38 +0000 (GMT) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03ECB43D4C for ; Thu, 6 Jan 2005 13:42:37 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (localhost.cs.ait.ac.th [127.0.0.1]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j06DgZqv057914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Jan 2005 20:42:35 +0700 (ICT) Received: (from on@localhost) by mail.cs.ait.ac.th (8.12.11/8.12.11/Submit) id j06DgZqc057911; Thu, 6 Jan 2005 20:42:35 +0700 (ICT) Date: Thu, 6 Jan 2005 20:42:35 +0700 (ICT) Message-Id: <200501061342.j06DgZqc057911@mail.cs.ait.ac.th> From: Olivier Nicole To: freebsd-net@freebsd.org X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Subject: Packet drop in bridging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 13:42:38 -0000 Hi, I have a firewall in bridging mode, using ipf. I upgraded to 4.10-p5 and now I have a bunch of error message: bdg_forward drop MULTICAST PKT /usr/src/sys/net/if_ethersubr.c line 609 Any clue what I am missing (sysctl or kernel) Thank you, Olivier From owner-freebsd-net@FreeBSD.ORG Thu Jan 6 20:46:45 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1190516A4D1 for ; Thu, 6 Jan 2005 20:46:45 +0000 (GMT) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.FreeBSD.org (Postfix) with SMTP id 63B4A43D1F for ; Thu, 6 Jan 2005 20:46:44 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 40214 invoked from network); 6 Jan 2005 20:46:43 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 6 Jan 2005 20:46:43 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 6 Jan 2005 14:46:42 -0600 (CST) From: Mike Silbersack To: Mark Allman In-Reply-To: <20050105151352.87D2A77B0CC@guns.icir.org> Message-ID: <20050106143727.S18425@odysseus.silby.com> References: <20050105151352.87D2A77B0CC@guns.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: rrs@cisco.com cc: net@freebsd.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 20:46:45 -0000 On Wed, 5 Jan 2005, Mark Allman wrote: > I ran this idea by Randall Stewart who has done a bunch of thinking on > this topic (and, helped produce one of the current internet-drafts on > the topic). He swayed me that my initial hit (above) might not be quite > right. Below is Randall's response to my forward of Mike's note > (forwarded with permission). This is a case that had not occurred to me > and leaves me thinking maybe ignoring SYNs is not quite the right > approach. However, I think there could be times when ignoring SYNs > might be fine. E.g., if the connection is moving right along and there > are other packets being transmitted and ACKed and we see a SYN that it > should be ignored. > > FWIW. > > allman Don convinced me of the same thing, using similar reasoning. I think that you're right that "there could be times when ignoring SYNs might be fine." I think that we track how long a connection has been idle; my plan is to only respond to SYNs if the connection has been idle for more than 30 seconds or more. That should ensure that we handle the client crashing case properly (even if the client reboots instantly, it'll keep retransmitting SYNs for more than 30 sceonds), but also ensure that we do not let a forged SYN flood prod us into sending unnecessary ACKs. I'll try to get this coded up this weekend. (Yes, rate limiting ACKs to these types of SYNs would also help, but it would be nice to not send any unnecessary packets.) Thanks for Randall's response, it provided some useful insight into the situation. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Thu Jan 6 22:06:36 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 490DE16A4CE for ; Thu, 6 Jan 2005 22:06:36 +0000 (GMT) Received: from poczta.o2.pl (mx2.go2.pl [193.17.41.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B7A943D5A for ; Thu, 6 Jan 2005 22:06:35 +0000 (GMT) (envelope-from knockefreebsd@o2.pl) Received: from ALFA (aaf223.warszawa.sdi.tpnet.pl [217.97.85.223]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by poczta.o2.pl (Postfix) with ESMTP id 043B7602B3 for ; Thu, 6 Jan 2005 23:06:34 +0100 (CET) Message-ID: <004a01c4f43c$521af510$df5561d9@ALFA> From: "Heinz Knocke" To: Date: Thu, 6 Jan 2005 23:03:07 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Subject: What will do the TCP stack in the described scenario? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Heinz Knocke List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 22:06:36 -0000 Hi! I'm writing here because I'm solving a strange performance problem ( http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3420+0+current/freebsd-net ) and wonder is this and OS or aplication side's bottleneck. Imagine the situation (S /C - TCP sender / client respectively). S: 0:10 C: ack 10 S: 10:20 (10) S: 20:30 (10) S: 30:40 (10) S: 40:50 (10) C: ack 30 ... S: 40:50 (10) - retransmission. C doesn't send duplicate ACKs to let the S know he don't have everything yet .. because he doesn't know that 40:50 were ever to be sent, am I right? Does it mean that 40:50 was the last from window / allowed by sender's cwnd? If he had, lets say, 30:40, 50:60 than he'd send multiple ack 30 segments and start recovery procedure, right? Is there any way to avoid serious speed drop in this scenario? Can disabling delayed acks / enabling SACKS on client/ server help?? I'll be very grateful for your comments as usual :)) hk From owner-freebsd-net@FreeBSD.ORG Thu Jan 6 23:58:08 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDDF916A4CE for ; Thu, 6 Jan 2005 23:58:08 +0000 (GMT) Received: from electra.nolink.net (electra.nolink.net [195.139.204.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id D092643D31 for ; Thu, 6 Jan 2005 23:58:07 +0000 (GMT) (envelope-from lerik@nolink.net) Received: (qmail 3754 invoked by uid 1000); 6 Jan 2005 23:58:06 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Jan 2005 23:58:06 -0000 Date: Fri, 7 Jan 2005 00:58:06 +0100 (CET) From: Lars Erik Gullerud To: Mike Silbersack In-Reply-To: <20050106143727.S18425@odysseus.silby.com> Message-ID: <20050107004734.O97889@electra.nolink.net> References: <20050105151352.87D2A77B0CC@guns.icir.org> <20050106143727.S18425@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: net@freebsd.org Subject: Re: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2005 23:58:09 -0000 On Thu, 6 Jan 2005, Mike Silbersack wrote: > Don convinced me of the same thing, using similar reasoning. > > I think that you're right that "there could be times when ignoring SYNs might > be fine." I think that we track how long a connection has been idle; my plan > is to only respond to SYNs if the connection has been idle for more than 30 > seconds or more. That should ensure that we handle the client crashing case > properly (even if the client reboots instantly, it'll keep retransmitting > SYNs for more than 30 sceonds), but also ensure that we do not let a forged > SYN flood prod us into sending unnecessary ACKs. I'll try to get this coded > up this weekend. OK, time to chime in here - if you read Don's comments, the particular example he chose to use was BGP, where one end crashes and tries to bring up a new session. BGP stability in particular was also one of the main reasons this particular draft received so much attention recently. Now, I'm a network engineer, not a developer. And if there is one thing I would hate if a BGP process were to crash, it is for the reestablishment of this connection to be delayed for up to 30 seconds because the other end thinks it is a good idea to ignore these SYNs. So please - don't. Why not stick to the procedures outlined in the draft as they are? The acronym "KISS" also comes to mind here, I don't really see that sending a few extra ACKs in this situation is a particularly relevant problem, I have problems seeing how this would realistically be used as a vector for a DoS or other nastiness. /leg From owner-freebsd-net@FreeBSD.ORG Fri Jan 7 06:04:04 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF8EF16A4CE for ; Fri, 7 Jan 2005 06:04:04 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 924A043D4C for ; Fri, 7 Jan 2005 06:04:04 +0000 (GMT) (envelope-from msapariya@gmail.com) Received: by rproxy.gmail.com with SMTP id g11so120960rne for ; Thu, 06 Jan 2005 22:04:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ANsCKLi2co1BCO0V7dWonjuFyYCGHgdt7/mSQopg4ODASF2TWkWfHdEFTw5u9TLl+53VF3yveePheH1aSHJdqsLVj3KnnYGy1CtE2oy4E5+LxdyDfZIq4f9305UeDxGqVLiF6SwvhIAPKYOMoramiM67KX/+1Rr5d5+gFVBo/p4= Received: by 10.38.102.50 with SMTP id z50mr267675rnb; Thu, 06 Jan 2005 22:04:04 -0800 (PST) Received: by 10.38.72.14 with HTTP; Thu, 6 Jan 2005 22:04:03 -0800 (PST) Message-ID: <5abcac5c0501062204120fc24d@mail.gmail.com> Date: Fri, 7 Jan 2005 11:34:03 +0530 From: Manish Sapariya To: freebsd-net@freebsd.org In-Reply-To: <20050105053301.85548.qmail@web8404.mail.in.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050105053301.85548.qmail@web8404.mail.in.yahoo.com> Subject: test suites for testing tcp/ip implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Manish Sapariya List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2005 06:04:05 -0000 Hello, Can anybody suggest me freely available test suite for tcp/ip implementation. Are there any avalilable? Thanks, Manish From owner-freebsd-net@FreeBSD.ORG Fri Jan 7 06:41:16 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E494616A4D0 for ; Fri, 7 Jan 2005 06:41:16 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id C16A143D1F for ; Fri, 7 Jan 2005 06:41:16 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) j076fFwN059164; Thu, 6 Jan 2005 22:41:16 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id j076fCuE079949; Thu, 6 Jan 2005 22:41:13 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Fri, 07 Jan 2005 15:41:08 +0900 Message-ID: From: gnn@freebsd.org To: Manish Sapariya In-Reply-To: <5abcac5c0501062204120fc24d@mail.gmail.com> References: <20050105053301.85548.qmail@web8404.mail.in.yahoo.com> <5abcac5c0501062204120fc24d@mail.gmail.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: test suites for testing tcp/ip implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2005 06:41:17 -0000 At Fri, 7 Jan 2005 11:34:03 +0530, Manish Sapariya wrote: > > Hello, > Can anybody suggest me freely available test suite for tcp/ip implementation. > Are there any avalilable? If you mean something that can veryify an RFC or do packet by packet testing then the answer is, "Not yet." There are other apps that folks use to do testing such as: ANVL (for pay, not very good, IMHO). Last time I used this they had not implemented exhaustive protocol testing for TCP/IP and writing new tests was non-trivial. It used to require specific hardware as well (at the time a Sun with an HME ethernet card). Some folks use these peformance tests to do testing: NetPipe netperf They are both in ports, and there are others as well. Later, George From owner-freebsd-net@FreeBSD.ORG Fri Jan 7 14:54:40 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CB7F16A4CE for ; Fri, 7 Jan 2005 14:54:40 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CBC943D1F for ; Fri, 7 Jan 2005 14:54:39 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1CmvVe-000Noq-1U for freebsd-net@freebsd.org; Fri, 07 Jan 2005 16:54:38 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Jan 2005 16:54:37 +0200 From: Danny Braniss Message-Id: <20050107145439.9CBC943D1F@mx1.FreeBSD.org> Subject: sosend(...) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2005 14:54:40 -0000 I need to send/receive tcp packets in the kernel. At the moment im looking at /sys/kern/uipc_socket:sosend, and was wondering if that is the best way to go. thanks, danny From owner-freebsd-net@FreeBSD.ORG Fri Jan 7 15:35:13 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DFB716A4CE for ; Fri, 7 Jan 2005 15:35:13 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7BF243D45 for ; Fri, 7 Jan 2005 15:35:12 +0000 (GMT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id j07FVEri022250; Fri, 7 Jan 2005 10:31:14 -0500 (EST) (envelope-from arr@watson.org) Received: from localhost (arr@localhost)j07FVE76022247; Fri, 7 Jan 2005 10:31:14 -0500 (EST) (envelope-from arr@watson.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Fri, 7 Jan 2005 10:31:14 -0500 (EST) From: "Andrew R. Reiter" To: Danny Braniss In-Reply-To: <20050107145439.9CBC943D1F@mx1.FreeBSD.org> Message-ID: <20050107103042.D22134@fledge.watson.org> References: <20050107145439.9CBC943D1F@mx1.FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: sosend(...) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2005 15:35:13 -0000 On Fri, 7 Jan 2005, Danny Braniss wrote: :I need to send/receive tcp packets in the kernel. At the moment im :looking at /sys/kern/uipc_socket:sosend, and was wondering if that is the best :way to go. : Check out: src/tools/tools/kttcp Might just be a helpful. Cheers, Andrew -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Fri Jan 7 16:57:13 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAC7C16A4CE for ; Fri, 7 Jan 2005 16:57:12 +0000 (GMT) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2D2A43D49 for ; Fri, 7 Jan 2005 16:57:10 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id A407B1A; Fri, 7 Jan 2005 17:57:04 +0100 (CET) Date: Fri, 7 Jan 2005 17:57:04 +0100 From: Andrea Campi To: freebsd-net@freebsd.org Message-ID: <20050107165703.GC16579@webcom.it> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dTy3Mrz/UPE2dbVg" Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: howl patch for better BSD support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2005 16:57:13 -0000 --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, as promised, I've been working on improving howl. I've been in touch with the authors, so in fact this is also resulting in cross-platform fixes. You can find the results of my work so far either attached to this email (provided they get through mailing list filters) or at this URL: http://www.webcom.it/ports/howl/files/patch-BSD ; you can just drop in the ports/net/howl/files directory. The current status is that autoipd and nifd are working (for people not familiar with howl, these deal with address negotiation and interface status monitoring respectively). I haven't done anything with mDNSResponder apart from checking it still compiles. There's a lot of stuff to cleanup. Style sucks beyond telling, but that's because at this stage I'm striving to keep the sources diffable to their Linux counterpart. This will change at a later stage. Could some kind folk familiar look at the diff and maybe try it? Apart from feedback of the "it works/doesn't" kind, I'm also looking for guidance on the preferred way to do things. On this note: I'm still using SIOCAIFADDR, as mentioned before, to add a new IP address. I'm still not sure on how to do it best. The way things currently work is: - when autoipd starts, it figures out a random IP, using the MAC address as a seed. It starts probing for someone else already using it, and if nobody is, it start announcing it; - autoipd then starts monitoring for conflicts, and when it detects one it either tries to defend or picks a different one; - nifd is charged with monitoring link state changes; if it detects one, or it notices that an interface changed IP address, it signals autoipd to go through all the process again. Now all this all nice, except it doesn't work! If I manually change the interface address, to simulate what for instance dhclient would do, nifd notices and signals autoipd, who then goes, picks a new IP address and sets it! This happens because nothing is checking whether the IP is valid before letting autoipd loose. The problem is that this is too hard to do in the general case; however, I think we can reasonably deal with the common DHCP+zeroconf case by using dhclient-script(8). Basically, I'd start autoipd on EXPIRE or FAIL and kill it on BOUND. I will go this way, at least for a beginning, unless someone with more experience is willing to guide me. I do plan on creating a sample script that could be provided in the port to give a complete solution. Thought? Bye, Andrea -- Intel: where Quality is job number 0.9998782345! --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-BSD Content-Transfer-Encoding: quoted-printable Index: configure =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/CVS/howl/work/howl-0.9.7/configure,v retrieving revision 1.1.1.1 retrieving revision 1.3 diff -u -r1.1.1.1 -r1.3 --- configure 12 Dec 2004 08:24:26 -0000 1.1.1.1 +++ configure 12 Dec 2004 09:16:29 -0000 1.3 @@ -8516,6 +8516,17 @@ PLATFORM_LIBS=3D"-framework CoreFoundation" HOWL_MAN_PAGES=3D ;; + *-*-freebsd*) + SRC_SUBDIRS=3D"lib mDNSResponder autoipd nifd" + LIB_SUBDIRS=3D"howl mDNSResponder" + HOWL_LIB_SUBDIRS=3D"Posix NotOSX" + HOWL_LIB_OBJECTS=3D'posix_salt.lo posix_socket.lo posix_time.lo posix_si= gnal.lo posix_interface.lo notosx_mdns_stub.lo' + MDNSRESPONDER_LIB_SUBDIRS=3D"Posix" + MDNSRESPONDER_LIB_OBJECTS=3D'posix_mdns.lo' + AUTOIPD_EXTRA_OBJECTS=3D'freebsd_autoip.lo posix_main.lo' + PLATFORM_LIBS=3D-lpthread + HOWL_MAN_PAGES=3D'mDNSResponder.8 autoipd.8 nifd.8' + ;; *-*-linux*) SRC_SUBDIRS=3D"lib mDNSResponder autoipd nifd" LIB_SUBDIRS=3D"howl mDNSResponder" @@ -8562,7 +8573,7 @@ =20 =20 =20 - = = = = ac_config_file= s=3D"$ac_config_files Makefile include/Makefile include/salt/Makefile inclu= de/corby/Makefile include/discovery/Makefile include/rendezvous/Makefile sr= c/Makefile src/lib/Makefile src/lib/howl/Makefile src/lib/howl/MacOSX/Makef= ile src/lib/howl/Posix/Makefile src/lib/howl/Win32/Makefile src/lib/howl/No= tOSX/Makefile src/lib/mDNSResponder/Makefile src/lib/mDNSResponder/Posix/Ma= kefile src/lib/mDNSResponder/Win32/Makefile src/mDNSResponder/Makefile src/= mDNSResponder/Posix/Makefile src/mDNSResponder/Win32/Makefile src/autoipd/M= akefile src/autoipd/Posix/Makefile src/autoipd/Linux/Makefile src/nifd/Make= file test/Makefile test/step/Makefile samples/Makefile samples/console/Make= file samples/console/publish/Makefile samples/console/browse/Makefile sampl= es/console/resolve/Makefile samples/console/query/Makefile samples/Win32/Ma= kefile samples/Win32/IEBar/Makefile docs/Makefile etc/Makefile howl.pc" + = = = = ac_config_file= s=3D"$ac_config_files Makefile include/Makefile include/salt/Makefile inclu= de/corby/Makefile include/discovery/Makefile include/rendezvous/Makefile sr= c/Makefile src/lib/Makefile src/lib/howl/Makefile src/lib/howl/MacOSX/Makef= ile src/lib/howl/Posix/Makefile src/lib/howl/Win32/Makefile src/lib/howl/No= tOSX/Makefile src/lib/mDNSResponder/Makefile src/lib/mDNSResponder/Posix/Ma= kefile src/lib/mDNSResponder/Win32/Makefile src/mDNSResponder/Makefile src/= mDNSResponder/Posix/Makefile src/mDNSResponder/Win32/Makefile src/autoipd/M= akefile src/autoipd/Posix/Makefile src/autoipd/BSD/Makefile src/autoipd/Lin= ux/Makefile src/nifd/Makefile test/Makefile test/step/Makefile samples/Make= file samples/console/Makefile samples/console/publish/Makefile samples/cons= ole/browse/Makefile samples/console/resolve/Makefile samples/console/query/= Makefile samples/Win32/Makefile samples/Win32/IEBar/Makefile docs/Makefile = etc/Makefile howl.pc" cat >confcache <<\_ACEOF # This file is a shell script that caches the results of configure # tests run on this system so they can be shared between configure @@ -9125,6 +9136,7 @@ "src/mDNSResponder/Win32/Makefile" ) CONFIG_FILES=3D"$CONFIG_FILES src/m= DNSResponder/Win32/Makefile" ;; "src/autoipd/Makefile" ) CONFIG_FILES=3D"$CONFIG_FILES src/autoipd/Makef= ile" ;; "src/autoipd/Posix/Makefile" ) CONFIG_FILES=3D"$CONFIG_FILES src/autoipd= /Posix/Makefile" ;; + "src/autoipd/BSD/Makefile" ) CONFIG_FILES=3D"$CONFIG_FILES src/autoipd/B= SD/Makefile" ;; "src/autoipd/Linux/Makefile" ) CONFIG_FILES=3D"$CONFIG_FILES src/autoipd= /Linux/Makefile" ;; "src/nifd/Makefile" ) CONFIG_FILES=3D"$CONFIG_FILES src/nifd/Makefile" ;; "test/Makefile" ) CONFIG_FILES=3D"$CONFIG_FILES test/Makefile" ;; Index: src/autoipd/Makefile.in =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/CVS/howl/work/howl-0.9.7/src/autoipd/Makefile.in,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- src/autoipd/Makefile.in 12 Dec 2004 08:24:39 -0000 1.1.1.1 +++ src/autoipd/Makefile.in 12 Dec 2004 09:16:29 -0000 1.2 @@ -96,13 +96,13 @@ am__include =3D @am__include@ am__quote =3D @am__quote@ install_sh =3D @install_sh@ -SUBDIRS =3D Posix Linux +SUBDIRS =3D Posix BSD Linux INCLUDES =3D -I$(top_srcdir)/include/ LDADD =3D $(AUTOIPD_EXTRA_OBJECTS) $(top_srcdir)/src/lib/howl/libhowl.la $= (PLATFORM_LIBS) AM_LDFLAGS =3D -static bin_PROGRAMS =3D autoipd autoipd_SOURCES =3D autoip.c autoip.h -EXTRA_autoipd_SOURCES =3D Linux/linux_autoip.c Posix/posix_main.c +EXTRA_autoipd_SOURCES =3D BSD/freebsd_autoip.c Linux/linux_autoip.c Posix/= posix_main.c autoipd_DEPENDENCIES =3D $(AUTOIPD_EXTRA_OBJECTS) subdir =3D src/autoipd mkinstalldirs =3D $(SHELL) $(top_srcdir)/mkinstalldirs @@ -124,6 +124,7 @@ depcomp =3D $(SHELL) $(top_srcdir)/depcomp am__depfiles_maybe =3D depfiles @AMDEP_TRUE@DEP_FILES =3D ./$(DEPDIR)/autoip.Po \ +@AMDEP_TRUE@ ./$(DEPDIR)/freebsd_autoip.Po \ @AMDEP_TRUE@ ./$(DEPDIR)/linux_autoip.Po \ @AMDEP_TRUE@ ./$(DEPDIR)/posix_main.Po COMPILE =3D $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) \ @@ -182,6 +183,7 @@ echo " rm -f $$p $$f"; \ rm -f $$p $$f ; \ done +freebsd_autoip.$(OBJEXT): BSD/freebsd_autoip.c linux_autoip.$(OBJEXT): Linux/linux_autoip.c posix_main.$(OBJEXT): Posix/posix_main.c autoipd$(EXEEXT): $(autoipd_OBJECTS) $(autoipd_DEPENDENCIES)=20 @@ -195,6 +197,7 @@ -rm -f *.tab.c =20 @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/autoip.Po@am__quote@ +@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/freebsd_autoip.Po@am__quo= te@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/linux_autoip.Po@am__quote@ @AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/posix_main.Po@am__quote@ =20 @@ -219,6 +222,24 @@ @AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ $(LTCOMPILE) -c -o $@ `test -f '$<' || echo '$(srcdir)/'`$< =20 +freebsd_autoip.o: BSD/freebsd_autoip.c +@AMDEP_TRUE@ source=3D'BSD/freebsd_autoip.c' object=3D'freebsd_autoip.o' l= ibtool=3Dno @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile=3D'$(DEPDIR)/freebsd_autoip.Po' tmpdepfile=3D'$(DEPDI= R)/freebsd_autoip.TPo' @AMDEPBACKSLASH@ +@AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) = $(AM_CFLAGS) $(CFLAGS) -c -o freebsd_autoip.o `test -f 'BSD/freebsd_autoip.= c' || echo '$(srcdir)/'`BSD/freebsd_autoip.c + +freebsd_autoip.obj: BSD/freebsd_autoip.c +@AMDEP_TRUE@ source=3D'BSD/freebsd_autoip.c' object=3D'freebsd_autoip.obj'= libtool=3Dno @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile=3D'$(DEPDIR)/freebsd_autoip.Po' tmpdepfile=3D'$(DEPDI= R)/freebsd_autoip.TPo' @AMDEPBACKSLASH@ +@AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ + $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) = $(AM_CFLAGS) $(CFLAGS) -c -o freebsd_autoip.obj `cygpath -w BSD/freebsd_aut= oip.c` + +freebsd_autoip.lo: BSD/freebsd_autoip.c +@AMDEP_TRUE@ source=3D'BSD/freebsd_autoip.c' object=3D'freebsd_autoip.lo' = libtool=3Dyes @AMDEPBACKSLASH@ +@AMDEP_TRUE@ depfile=3D'$(DEPDIR)/freebsd_autoip.Plo' tmpdepfile=3D'$(DEPD= IR)/freebsd_autoip.TPlo' @AMDEPBACKSLASH@ +@AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ + $(LIBTOOL) --mode=3Dcompile $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES)= $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o freebsd_autoip.lo = `test -f 'BSD/freebsd_autoip.c' || echo '$(srcdir)/'`BSD/freebsd_autoip.c + linux_autoip.o: Linux/linux_autoip.c @AMDEP_TRUE@ source=3D'Linux/linux_autoip.c' object=3D'linux_autoip.o' lib= tool=3Dno @AMDEPBACKSLASH@ @AMDEP_TRUE@ depfile=3D'$(DEPDIR)/linux_autoip.Po' tmpdepfile=3D'$(DEPDIR)= /linux_autoip.TPo' @AMDEPBACKSLASH@ Index: src/autoipd/autoip.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/CVS/howl/work/howl-0.9.7/src/autoipd/autoip.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- src/autoipd/autoip.c 12 Dec 2004 08:24:39 -0000 1.1.1.1 +++ src/autoipd/autoip.c 12 Dec 2004 09:09:50 -0000 1.2 @@ -212,6 +212,12 @@ sw_debug(SW_LOG_VERBOSE, "IDLE\n"); =20 /* + * initialize the MAC address + */ + err =3D sw_network_interface_mac_address(self->m_nif, &self->m_mac_addr); + sw_check_okay(err, exit); + + /* * initialize the ip address */ err =3D sw_autoip_network_interface_make_initial_ip_address(self); Index: src/lib/howl/Posix/posix_interface.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/CVS/howl/work/howl-0.9.7/src/lib/howl/Posix/posix_interface= =2Ec,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 posix_interface.c --- src/lib/howl/Posix/posix_interface.c 12 Dec 2004 08:24:31 -0000 1.1.1.1 +++ src/lib/howl/Posix/posix_interface.c 7 Jan 2005 15:39:58 -0000 @@ -45,6 +45,14 @@ # include =20 #endif =20 +#if defined(__FreeBSD__) +#include +#include +#include +#include +#include +#endif + #ifndef SIOCGIFCONF # include #endif @@ -231,13 +240,16 @@ sw_network_interface self,=20 sw_bool * islinked) { -#if defined(__linux__) int fd; - struct ifreq ifr; int r; - struct ethtool_value edata; + struct ifreq ifr; int res; sw_result err =3D SW_OKAY; +#if defined(__linux__) + struct ethtool_value edata; +#elif defined(__FreeBSD__) + struct ifmediareq ifmr; +#endif =20 sw_assert(self !=3D NULL); /* must be initialized */ sw_assert(islinked !=3D NULL); /* must be allocated */ @@ -251,6 +263,19 @@ memset(&ifr, 0, sizeof(ifr)); strncpy(ifr.ifr_name, self->m_name, sizeof(ifr.ifr_name) - 1); =20 + /* get the interface flags */ + res =3D ioctl(fd, SIOCGIFFLAGS, &ifr); + err =3D sw_translate_error(res =3D=3D 0, errno); + sw_check_okay_log(err, exit); + + /* if it's down, we can't have a link */ + if ((ifr.ifr_flags & IFF_UP) !=3D IFF_UP) + { + *islinked =3D SW_FALSE; + goto exit; + } + +#if defined(__linux__) edata.cmd =3D ETHTOOL_GLINK; ifr.ifr_data =3D (caddr_t) &edata; =20 @@ -259,15 +284,25 @@ sw_check_okay_log(err, exit); =20 *islinked =3D edata.data ? SW_TRUE : SW_FALSE; +#elif defined(__FreeBSD__) + memset(&ifmr, 0, sizeof(ifmr)); + strncpy(ifmr.ifm_name, self->m_name, sizeof(ifmr.ifm_name) - 1); + + res =3D ioctl(fd, SIOCGIFMEDIA, (caddr_t)&ifmr); + err =3D sw_translate_error(res =3D=3D 0, errno); + sw_check_okay_log(err, exit); + + if (!ifmr.ifm_status & IFM_AVALID) + goto exit; + + *islinked =3D (ifmr.ifm_status & IFM_ACTIVE)? SW_TRUE : SW_FALSE; +#endif =20 exit: =20 close(fd); =20 return err; -#else - return SW_OKAY; -#endif } =20 =20 @@ -280,6 +315,77 @@ } =20 =20 +#if defined(__FreeBSD__) +static int +get_interface_lladdr_by_index(unsigned int ifindex, sw_mac_address *m_mac_= addr) { + + int mib[6]; + struct if_msghdr *ifm; + struct sockaddr_dl *sdl; + + int needed, count =3D 0; + int res; + sw_result err =3D SW_OKAY; + +retry: + mib[0] =3D CTL_NET; + mib[1] =3D PF_ROUTE; + mib[2] =3D 0; + mib[3] =3D 0; /* address family */ + mib[4] =3D NET_RT_IFLIST; + mib[5] =3D ifindex; /* interface index */ + + /* determine how much memory is needed */ + res =3D sysctl(mib, 6, NULL, &needed, NULL, 0); + err =3D sw_translate_error(res =3D=3D 0, errno); + sw_check_okay_log(err, exit); + + ifm =3D (struct if_msghdr *)malloc(needed); + err =3D sw_translate_error(ifm !=3D NULL, SW_E_MEM); + sw_check_okay_log(err, exit); + + /* retrieve information */ + res =3D sysctl(mib, 6, ifm, &needed, NULL, 0); + if (res < 0) { + if (errno =3D=3D ENOMEM && count++ < 10) { + sw_debug(SW_LOG_WARNING, + "Routing table grew, retrying"); + free(ifm); + sleep(1); + goto retry; + } + + err =3D sw_translate_error(res =3D=3D 0, errno); + sw_check_okay_log(err, exit); + } + + sw_debug(SW_LOG_ERROR, "ifm->ifm_type %d=3D%d\n", + ifm->ifm_type, RTM_IFINFO); + if (ifm->ifm_type !=3D RTM_IFINFO) + return 0; + + if (ifm->ifm_data.ifi_datalen =3D=3D 0) + ifm->ifm_data.ifi_datalen =3D sizeof(struct if_data); + + sdl =3D (struct sockaddr_dl *)((char *)ifm + sizeof(struct if_msghdr) - + sizeof(struct if_data) + ifm->ifm_data.ifi_datalen); + + sw_debug(SW_LOG_ERROR, "sdl->sdl_alen %d\n", sdl->sdl_alen); + if (sdl->sdl_alen > 1) { + if (sdl->sdl_type =3D=3D IFT_ETHER && + sdl->sdl_alen =3D=3D ETHER_ADDR_LEN) { + sw_memcpy(m_mac_addr->m_id, + (struct ether_addr *)LLADDR(sdl), + sizeof(struct ether_addr)); + return 1; + } + } + +exit: + return 0; +} +#endif + static sw_result sw_posix_network_interface_init_from_name( sw_posix_network_interface nif, @@ -332,6 +438,7 @@ sw_debug(SW_LOG_VERBOSE, "got ip address: %s\n", tmpname); =20 /* mac address */ +#if !defined(__FreeBSD__) #if defined(SIOCGIFHWADDR) res =3D ioctl(sock, SIOCGIFHWADDR, &ifr); err =3D sw_translate_error(res =3D=3D 0, errno); @@ -343,10 +450,17 @@ sw_check_okay_log(err, exit); sw_memcpy(nif->m_super.m_mac_address.m_id, (sw_uint8*)(ifr.ifr_ifru.ifru_= enaddr), sizeof(sw_mac_address));=20 #endif +#endif =20 /* index */ nif->m_super.m_index =3D if_nametoindex(ifr.ifr_name); =20 +#if defined(__FreeBSD__) + res =3D get_interface_lladdr_by_index(nif->m_super.m_index, &nif->m_super= =2Em_mac_address); + err =3D sw_translate_error(res =3D=3D 1, SW_E_UNKNOWN); + sw_check_okay_log(err, exit); +#endif + /* initialize link status field */ sw_network_interface_link_status(&nif->m_super, &(nif->m_super.m_linked)); =20 @@ -387,6 +501,12 @@ /* ip address */ sw_ipv4_address_init_from_saddr(&(nif->m_super.m_ipv4_address), ((struct = sockaddr_in *) &ifr->ifr_addr)->sin_addr.s_addr); =20 +#if defined(__FreeBSD__) + res =3D get_interface_lladdr_by_index(nif->m_super.m_index, &nif->m_super= =2Em_mac_address); + sw_debug(SW_LOG_ERROR, "%d %s res %d\n", nif->m_super.m_index, ifr->ifr_n= ame, res); + err =3D sw_translate_error(res =3D=3D 1, SW_E_UNKNOWN); + sw_check_okay_log(err, exit); +#else /* get a socket for ioctling */ err =3D sw_posix_inet_socket(&sock); sw_check_okay(err, exit); @@ -403,6 +523,7 @@ sw_check_okay_log(err, exit); sw_memcpy(nif->m_super.m_mac_address.m_id, (sw_uint8*)(ifr->ifr_ifru.ifru= _enaddr), sizeof(sw_mac_address));=20 #endif +#endif =20 /* initialize link status field */ sw_network_interface_link_status(&nif->m_super, &(nif->m_super.m_linked)); @@ -515,6 +636,7 @@ sw_uint32 * nifc, sw_network_interface ** nifv) { +#if defined(__linux__) FILE * fh; char buf[512]; int procnetdev_vsn; @@ -585,6 +707,132 @@ } =20 return err; +#elif defined(__FreeBSD__) + int mib[6]; + struct if_msghdr *ifm, *nextifm; + struct ifa_msghdr *ifam; + int addrcount; + struct sockaddr_dl *sdl; + char name[IFNAMSIZ]; + sw_posix_network_interface nif; + sw_ipv4_address ipaddr; + + int needed, count =3D 0; + char *buf, *lim, *next; + int res; + sw_result err =3D SW_OKAY; + + /* TODO hard code 10 for now */ + /* allocate nifv */ + *nifv =3D (sw_network_interface*) sw_malloc(10 * sizeof(sw_network_interf= ace)); + err =3D sw_translate_error(*nifv, SW_E_MEM); + sw_check_okay_log(err, exit); +=09 + *nifc =3D 0; + +retry: + mib[0] =3D CTL_NET; + mib[1] =3D PF_ROUTE; + mib[2] =3D 0; + mib[3] =3D 0; + mib[4] =3D NET_RT_IFLIST; + mib[5] =3D 0; + + /* determine how much memory is needed */ + res =3D sysctl(mib, 6, NULL, &needed, NULL, 0); + err =3D sw_translate_error(res =3D=3D 0, errno); + sw_check_okay_log(err, exit); + + buf =3D malloc(needed); + err =3D sw_translate_error(buf !=3D NULL, SW_E_MEM); + sw_check_okay_log(err, exit); + + /* retrieve information */ + res =3D sysctl(mib, 6, buf, &needed, NULL, 0); + if (res < 0) { + if (errno =3D=3D ENOMEM && count++ < 10) { + warnx("Routing table grew, retrying"); + free(ifm); + sleep(1); + goto retry; + } + + err =3D sw_translate_error(res =3D=3D 0, errno); + sw_check_okay_log(err, exit); + } + + lim =3D buf + needed; + next =3D buf; + while (next < lim) { + ifm =3D (struct if_msghdr *)next; + + if (ifm->ifm_type =3D=3D RTM_IFINFO) { + if (ifm->ifm_data.ifi_datalen =3D=3D 0) + ifm->ifm_data.ifi_datalen =3D sizeof(struct if_data); + + sdl =3D (struct sockaddr_dl *)((char *)ifm + + sizeof(struct if_msghdr) - + sizeof(struct if_data) + + ifm->ifm_data.ifi_datalen); + } else { + sw_debug(SW_LOG_ERROR, + "out of sync parsing NET_RT_IFLIST\n"); + err =3D SW_E_INIT; + goto exit; + } + + next +=3D ifm->ifm_msglen; + ifam =3D NULL; + addrcount =3D 0; + while (next < lim) { + nextifm =3D (struct if_msghdr *)next; + if (nextifm->ifm_type !=3D RTM_NEWADDR) + break; + + if (ifam =3D=3D NULL) + ifam =3D (struct ifa_msghdr *)nextifm; + + next +=3D nextifm->ifm_msglen; + } + + memcpy(name, sdl->sdl_data, + sizeof(name) < sdl->sdl_nlen ? + sizeof(name)-1 : sdl->sdl_nlen); + name[sizeof(name) < sdl->sdl_nlen ? + sizeof(name)-1 : sdl->sdl_nlen] =3D '\0'; + + sw_debug(SW_LOG_ERROR, "name=3D%s", name); + + if ((ifm->ifm_flags & IFF_BROADCAST) =3D=3D 0) + { + continue; + } + + /* create a new netif */ + err =3D sw_network_interface_init((sw_network_interface*)&nif);=20 + sw_check_okay(err, exit); + + /* initialize fields */ + err =3D sw_posix_network_interface_init_from_name(nif, name); + sw_check_okay(err, exit); + + err =3D sw_network_interface_ipv4_address((sw_network_interface)nif, &ip= addr); + sw_check_okay(err, exit); + + (*nifv)[(*nifc)++] =3D (sw_network_interface)nif; + } +=09 + err =3D SW_OKAY; + +exit: + + if (err && *nifv) + { + sw_network_interfaces_fina(*nifc, *nifv); + } + + return err; +#endif } =20 sw_result diff -urN empty/Makefile src/autoipd/BSD/Makefile --- src/autoipd/BSD/Makefile Thu Jan 1 01:00:00 1970 +++ src/autoipd/BSD/Makefile Sun Dec 12 10:36:27 2004 @@ -0,0 +1,232 @@ +# Makefile.in generated by automake 1.6.3 from Makefile.am. +# src/autoipd/BSD/Makefile. Generated from Makefile.in by configure. + +# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 +# Free Software Foundation, Inc. +# This Makefile.in is free software; the Free Software Foundation +# gives unlimited permission to copy and/or distribute it, +# with or without modifications, as long as this notice is preserved. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY, to the extent permitted by law; without +# even the implied warranty of MERCHANTABILITY or FITNESS FOR A +# PARTICULAR PURPOSE. + + +SHELL =3D /bin/sh + +srcdir =3D . +top_srcdir =3D ../../.. + +prefix =3D /usr/local +exec_prefix =3D ${prefix} + +bindir =3D ${exec_prefix}/bin +sbindir =3D ${exec_prefix}/sbin +libexecdir =3D ${exec_prefix}/libexec +datadir =3D ${prefix}/share +sysconfdir =3D ${prefix}/etc +sharedstatedir =3D ${prefix}/com +localstatedir =3D ${prefix}/var +libdir =3D ${exec_prefix}/lib +infodir =3D ${prefix}/info +mandir =3D ${prefix}/man +includedir =3D ${prefix}/include +oldincludedir =3D /usr/include +pkgdatadir =3D $(datadir)/howl +pkglibdir =3D $(libdir)/howl +pkgincludedir =3D $(includedir)/howl +top_builddir =3D ../../.. + +ACLOCAL =3D ${SHELL} /usr/ports/net/howl/work/howl-0.9.7/missing --run acl= ocal-1.6 +AUTOCONF =3D ${SHELL} /usr/ports/net/howl/work/howl-0.9.7/missing --run au= toconf +AUTOMAKE =3D ${SHELL} /usr/ports/net/howl/work/howl-0.9.7/missing --run au= tomake-1.6 +AUTOHEADER =3D ${SHELL} /usr/ports/net/howl/work/howl-0.9.7/missing --run = autoheader + +am__cd =3D CDPATH=3D"$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd +INSTALL =3D /usr/bin/install -c=20 +INSTALL_PROGRAM =3D install -s -m 555 +INSTALL_DATA =3D install -m 444 +install_sh_DATA =3D $(install_sh) -c -m 644 +install_sh_PROGRAM =3D $(install_sh) -c +install_sh_SCRIPT =3D $(install_sh) -c +INSTALL_SCRIPT =3D install -m 555 +INSTALL_HEADER =3D $(INSTALL_DATA) +transform =3D s,x,x, +NORMAL_INSTALL =3D : +PRE_INSTALL =3D : +POST_INSTALL =3D : +NORMAL_UNINSTALL =3D : +PRE_UNINSTALL =3D : +POST_UNINSTALL =3D : +host_alias =3D=20 +host_triplet =3D i386-portbld-freebsd5.3 + +EXEEXT =3D=20 +OBJEXT =3D o +PATH_SEPARATOR =3D : +AMTAR =3D ${SHELL} /usr/ports/net/howl/work/howl-0.9.7/missing --run tar +AS =3D @AS@ +AUTOIPD_EXTRA_OBJECTS =3D freebsd_autoip.lo posix_main.lo +AWK =3D nawk +CC =3D cc +CXX =3D c++ +DEPDIR =3D .deps +DLLTOOL =3D @DLLTOOL@ +ECHO =3D echo +HOWL_LIBRARY_VERSION =3D 1:0:0 +HOWL_LIB_OBJECTS =3D posix_salt.lo posix_socket.lo posix_time.lo posix_sig= nal.lo posix_interface.lo notosx_mdns_stub.lo +HOWL_LIB_SUBDIRS =3D Posix NotOSX +HOWL_MAN_PAGES =3D mDNSResponder.8 autoipd.8 nifd.8 +HOWL_RELEASE =3D=20 +INSTALL_STRIP_PROGRAM =3D ${SHELL} $(install_sh) -c -s +LIBTOOL =3D $(SHELL) /usr/local/bin/libtool15 +LIB_SUBDIRS =3D howl mDNSResponder +LN_S =3D ln -s +MDNSRESPONDER_LIBRARY_VERSION =3D 0:0:0 +MDNSRESPONDER_LIB_OBJECTS =3D posix_mdns.lo +MDNSRESPONDER_LIB_SUBDIRS =3D Posix +OBJDUMP =3D @OBJDUMP@ +PACKAGE =3D howl +PLATFORM_LIBS =3D -lpthread +RANLIB =3D ranlib +SRC_SUBDIRS =3D lib mDNSResponder autoipd nifd +STRIP =3D strip +VERSION =3D 0.9.7 +am__include =3D include +am__quote =3D=20 +install_sh =3D /usr/ports/net/howl/work/howl-0.9.7/install-sh +sources_h =3D freebsd_autoip.h +sources_c =3D freebsd_autoip.c +DIST_SOURCES =3D $(sources_h) $(sources_c) Makefile.am +INCLUDES =3D -I$(top_srcdir)/include/ +subdir =3D src/autoipd/BSD +mkinstalldirs =3D $(SHELL) $(top_srcdir)/mkinstalldirs +CONFIG_HEADER =3D $(top_builddir)/include/howl_config.h +CONFIG_CLEAN_FILES =3D +DIST_COMMON =3D Makefile.am Makefile.in +all: all-am + +.SUFFIXES: +$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.ac $(ACLOCAL_= M4) + cd $(top_srcdir) && \ + $(AUTOMAKE) --gnu src/autoipd/BSD/Makefile +Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status + cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfile= s_maybe) + +mostlyclean-libtool: + -rm -f *.lo + +clean-libtool: + -rm -rf .libs _libs + +distclean-libtool: + -rm -f libtool +uninstall-info-am: +tags: TAGS +TAGS: + +DISTFILES =3D $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) + +top_distdir =3D ../../.. +distdir =3D $(top_distdir)/$(PACKAGE)-$(VERSION) + +distdir: $(DISTFILES) + @list=3D'$(DISTFILES)'; for file in $$list; do \ + if test -f $$file || test -d $$file; then d=3D.; else d=3D$(srcdir); fi= ; \ + dir=3D`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \ + if test "$$dir" !=3D "$$file" && test "$$dir" !=3D "."; then \ + dir=3D"/$$dir"; \ + $(mkinstalldirs) "$(distdir)$$dir"; \ + else \ + dir=3D''; \ + fi; \ + if test -d $$d/$$file; then \ + if test -d $(srcdir)/$$file && test $$d !=3D $(srcdir); then \ + cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \ + fi; \ + cp -pR $$d/$$file $(distdir)$$dir || exit 1; \ + else \ + test -f $(distdir)/$$file \ + || cp -p $$d/$$file $(distdir)/$$file \ + || exit 1; \ + fi; \ + done +check-am: all-am +check: check-am +all-am: Makefile + +installdirs: + +install: install-am +install-exec: install-exec-am +install-data: install-data-am +uninstall: uninstall-am + +install-am: all-am + @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am + +installcheck: installcheck-am +install-strip: + $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM=3D"$(INSTALL_STRIP_PROGRAM)" \ + INSTALL_STRIP_FLAG=3D-s \ + `test -z '$(STRIP)' || \ + echo "INSTALL_PROGRAM_ENV=3DSTRIPPROG=3D'$(STRIP)'"` install +mostlyclean-generic: + +clean-generic: + +distclean-generic: + -rm -f Makefile $(CONFIG_CLEAN_FILES) + +maintainer-clean-generic: + @echo "This command is intended for maintainers to use" + @echo "it deletes files that may require special tools to rebuild." +clean: clean-am + +clean-am: clean-generic clean-libtool mostlyclean-am + +distclean: distclean-am + +distclean-am: clean-am distclean-generic distclean-libtool + +dvi: dvi-am + +dvi-am: + +info: info-am + +info-am: + +install-data-am: + +install-exec-am: + +install-info: install-info-am + +install-man: + +installcheck-am: + +maintainer-clean: maintainer-clean-am + +maintainer-clean-am: distclean-am maintainer-clean-generic + +mostlyclean: mostlyclean-am + +mostlyclean-am: mostlyclean-generic mostlyclean-libtool + +uninstall-am: uninstall-info-am + +.PHONY: all all-am check check-am clean clean-generic clean-libtool \ + distclean distclean-generic distclean-libtool distdir dvi \ + dvi-am info info-am install install-am install-data \ + install-data-am install-exec install-exec-am install-info \ + install-info-am install-man install-strip installcheck \ + installcheck-am installdirs maintainer-clean \ + maintainer-clean-generic mostlyclean mostlyclean-generic \ + mostlyclean-libtool uninstall uninstall-am uninstall-info-am + +# Tell versions [3.59,3.63) of GNU make to not export all variables. +# Otherwise a system limit (for SysV at least) may be exceeded. +.NOEXPORT: diff -urN empty/Makefile.in src/autoipd/BSD/Makefile.in --- src/autoipd/BSD/Makefile.in Thu Jan 1 01:00:00 1970 +++ src/autoipd/BSD/Makefile.in Sun Dec 12 10:35:09 2004 @@ -0,0 +1,232 @@ +# Makefile.in generated by automake 1.6.3 from Makefile.am. +# @configure_input@ + +# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 +# Free Software Foundation, Inc. +# This Makefile.in is free software; the Free Software Foundation +# gives unlimited permission to copy and/or distribute it, +# with or without modifications, as long as this notice is preserved. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY, to the extent permitted by law; without +# even the implied warranty of MERCHANTABILITY or FITNESS FOR A +# PARTICULAR PURPOSE. + +@SET_MAKE@ +SHELL =3D @SHELL@ + +srcdir =3D @srcdir@ +top_srcdir =3D @top_srcdir@ +VPATH =3D @srcdir@ +prefix =3D @prefix@ +exec_prefix =3D @exec_prefix@ + +bindir =3D @bindir@ +sbindir =3D @sbindir@ +libexecdir =3D @libexecdir@ +datadir =3D @datadir@ +sysconfdir =3D @sysconfdir@ +sharedstatedir =3D @sharedstatedir@ +localstatedir =3D @localstatedir@ +libdir =3D @libdir@ +infodir =3D @infodir@ +mandir =3D @mandir@ +includedir =3D @includedir@ +oldincludedir =3D /usr/include +pkgdatadir =3D $(datadir)/@PACKAGE@ +pkglibdir =3D $(libdir)/@PACKAGE@ +pkgincludedir =3D $(includedir)/@PACKAGE@ +top_builddir =3D ../../.. + +ACLOCAL =3D @ACLOCAL@ +AUTOCONF =3D @AUTOCONF@ +AUTOMAKE =3D @AUTOMAKE@ +AUTOHEADER =3D @AUTOHEADER@ + +am__cd =3D CDPATH=3D"$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd +INSTALL =3D @INSTALL@ +INSTALL_PROGRAM =3D @INSTALL_PROGRAM@ +INSTALL_DATA =3D @INSTALL_DATA@ +install_sh_DATA =3D $(install_sh) -c -m 644 +install_sh_PROGRAM =3D $(install_sh) -c +install_sh_SCRIPT =3D $(install_sh) -c +INSTALL_SCRIPT =3D @INSTALL_SCRIPT@ +INSTALL_HEADER =3D $(INSTALL_DATA) +transform =3D @program_transform_name@ +NORMAL_INSTALL =3D : +PRE_INSTALL =3D : +POST_INSTALL =3D : +NORMAL_UNINSTALL =3D : +PRE_UNINSTALL =3D : +POST_UNINSTALL =3D : +host_alias =3D @host_alias@ +host_triplet =3D @host@ + +EXEEXT =3D @EXEEXT@ +OBJEXT =3D @OBJEXT@ +PATH_SEPARATOR =3D @PATH_SEPARATOR@ +AMTAR =3D @AMTAR@ +AS =3D @AS@ +AUTOIPD_EXTRA_OBJECTS =3D @AUTOIPD_EXTRA_OBJECTS@ +AWK =3D @AWK@ +CC =3D @CC@ +CXX =3D @CXX@ +DEPDIR =3D @DEPDIR@ +DLLTOOL =3D @DLLTOOL@ +ECHO =3D @ECHO@ +HOWL_LIBRARY_VERSION =3D @HOWL_LIBRARY_VERSION@ +HOWL_LIB_OBJECTS =3D @HOWL_LIB_OBJECTS@ +HOWL_LIB_SUBDIRS =3D @HOWL_LIB_SUBDIRS@ +HOWL_MAN_PAGES =3D @HOWL_MAN_PAGES@ +HOWL_RELEASE =3D @HOWL_RELEASE@ +INSTALL_STRIP_PROGRAM =3D @INSTALL_STRIP_PROGRAM@ +LIBTOOL =3D @LIBTOOL@ +LIB_SUBDIRS =3D @LIB_SUBDIRS@ +LN_S =3D @LN_S@ +MDNSRESPONDER_LIBRARY_VERSION =3D @MDNSRESPONDER_LIBRARY_VERSION@ +MDNSRESPONDER_LIB_OBJECTS =3D @MDNSRESPONDER_LIB_OBJECTS@ +MDNSRESPONDER_LIB_SUBDIRS =3D @MDNSRESPONDER_LIB_SUBDIRS@ +OBJDUMP =3D @OBJDUMP@ +PACKAGE =3D @PACKAGE@ +PLATFORM_LIBS =3D @PLATFORM_LIBS@ +RANLIB =3D @RANLIB@ +SRC_SUBDIRS =3D @SRC_SUBDIRS@ +STRIP =3D @STRIP@ +VERSION =3D @VERSION@ +am__include =3D @am__include@ +am__quote =3D @am__quote@ +install_sh =3D @install_sh@ +sources_h =3D freebsd_autoip.h +sources_c =3D freebsd_autoip.c +DIST_SOURCES =3D $(sources_h) $(sources_c) Makefile.am +INCLUDES =3D -I$(top_srcdir)/include/ +subdir =3D src/autoipd/BSD +mkinstalldirs =3D $(SHELL) $(top_srcdir)/mkinstalldirs +CONFIG_HEADER =3D $(top_builddir)/include/howl_config.h +CONFIG_CLEAN_FILES =3D +DIST_COMMON =3D Makefile.am Makefile.in +all: all-am + +.SUFFIXES: +$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.ac $(ACLOCAL_= M4) + cd $(top_srcdir) && \ + $(AUTOMAKE) --gnu src/autoipd/BSD/Makefile +Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status + cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfile= s_maybe) + +mostlyclean-libtool: + -rm -f *.lo + +clean-libtool: + -rm -rf .libs _libs + +distclean-libtool: + -rm -f libtool +uninstall-info-am: +tags: TAGS +TAGS: + +DISTFILES =3D $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) + +top_distdir =3D ../../.. +distdir =3D $(top_distdir)/$(PACKAGE)-$(VERSION) + +distdir: $(DISTFILES) + @list=3D'$(DISTFILES)'; for file in $$list; do \ + if test -f $$file || test -d $$file; then d=3D.; else d=3D$(srcdir); fi= ; \ + dir=3D`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \ + if test "$$dir" !=3D "$$file" && test "$$dir" !=3D "."; then \ + dir=3D"/$$dir"; \ + $(mkinstalldirs) "$(distdir)$$dir"; \ + else \ + dir=3D''; \ + fi; \ + if test -d $$d/$$file; then \ + if test -d $(srcdir)/$$file && test $$d !=3D $(srcdir); then \ + cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \ + fi; \ + cp -pR $$d/$$file $(distdir)$$dir || exit 1; \ + else \ + test -f $(distdir)/$$file \ + || cp -p $$d/$$file $(distdir)/$$file \ + || exit 1; \ + fi; \ + done +check-am: all-am +check: check-am +all-am: Makefile + +installdirs: + +install: install-am +install-exec: install-exec-am +install-data: install-data-am +uninstall: uninstall-am + +install-am: all-am + @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am + +installcheck: installcheck-am +install-strip: + $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM=3D"$(INSTALL_STRIP_PROGRAM)" \ + INSTALL_STRIP_FLAG=3D-s \ + `test -z '$(STRIP)' || \ + echo "INSTALL_PROGRAM_ENV=3DSTRIPPROG=3D'$(STRIP)'"` install +mostlyclean-generic: + +clean-generic: + +distclean-generic: + -rm -f Makefile $(CONFIG_CLEAN_FILES) + +maintainer-clean-generic: + @echo "This command is intended for maintainers to use" + @echo "it deletes files that may require special tools to rebuild." +clean: clean-am + +clean-am: clean-generic clean-libtool mostlyclean-am + +distclean: distclean-am + +distclean-am: clean-am distclean-generic distclean-libtool + +dvi: dvi-am + +dvi-am: + +info: info-am + +info-am: + +install-data-am: + +install-exec-am: + +install-info: install-info-am + +install-man: + +installcheck-am: + +maintainer-clean: maintainer-clean-am + +maintainer-clean-am: distclean-am maintainer-clean-generic + +mostlyclean: mostlyclean-am + +mostlyclean-am: mostlyclean-generic mostlyclean-libtool + +uninstall-am: uninstall-info-am + +.PHONY: all all-am check check-am clean clean-generic clean-libtool \ + distclean distclean-generic distclean-libtool distdir dvi \ + dvi-am info info-am install install-am install-data \ + install-data-am install-exec install-exec-am install-info \ + install-info-am install-man install-strip installcheck \ + installcheck-am installdirs maintainer-clean \ + maintainer-clean-generic mostlyclean mostlyclean-generic \ + mostlyclean-libtool uninstall uninstall-am uninstall-info-am + +# Tell versions [3.59,3.63) of GNU make to not export all variables. +# Otherwise a system limit (for SysV at least) may be exceeded. +.NOEXPORT: diff -urN empty/freebsd_autoip.c src/autoipd/BSD/freebsd_autoip.c --- src/autoipd/BSD/freebsd_autoip.c Thu Jan 1 01:00:00 1970 +++ src/autoipd/BSD/freebsd_autoip.c Fri Jan 7 16:07:11 2005 @@ -0,0 +1,511 @@ +/* + * Copyright 2003, 2004 Porchdog Software. All rights reserved. + * Copyright 2004, 2005 Andrea Campi + * + * Redistribution and use in source and binary forms, with or without modi= fication, + * are permitted provided that the following conditions are met: + * + * 1. Redistributions of source code must retain the above copyright noti= ce, + * this list of conditions and the following disclaimer. =20 + * 2. Redistributions in binary form must reproduce the above copyright n= otice, + * this list of conditions and the following disclaimer in the documen= tation + * and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY PORCHDOG SOFTWARE ``AS IS'' AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLI= ED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE = DISCLAIMED. + * IN NO EVENT SHALL THE HOWL PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DI= RECT, + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INC= LUDING, + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS O= F USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY T= HEORY + * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING= NEGLIGENCE + * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN = IF ADVISED + * OF THE POSSIBILITY OF SUCH DAMAGE. + * + * The views and conclusions contained in the software and documentation a= re those + * of the authors and should not be interpreted as representing official p= olicies, + * either expressed or implied, of Porchdog Software. + */ + +#include "freebsd_autoip.h" +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + + +static sw_result +sw_freebsd_autoip_network_interface_socket_event_handler( + sw_socket_handler handler, + sw_salt salt, + sw_socket socket, + sw_socket_event events, + sw_opaque extra); + + +static struct bpf_insn arp_bpf_filter [] =3D { + /* Make sure this is an IP packet... */ + BPF_STMT (BPF_LD + BPF_H + BPF_ABS, 12), + BPF_JUMP (BPF_JMP + BPF_JEQ + BPF_K, ETHERTYPE_ARP, 0, 1), + + /* If we passed all the tests, ask for the whole packet. */ + BPF_STMT(BPF_RET+BPF_K, 96), + + /* Otherwise, drop it. */ + BPF_STMT(BPF_RET+BPF_K, 0), +}; + +int arp_bpf_filter_len =3D (sizeof arp_bpf_filter / sizeof (struct bpf_ins= n)); + + +sw_string +sw_platform_autoip_network_interface_default_interface_name() +{ + sw_string ret =3D NULL; + int mib[6]; + struct if_msghdr *ifm, *nextifm; + struct ifa_msghdr *ifam; + struct sockaddr_dl *sdl; + char name[IFNAMSIZ]; + + int needed, count =3D 0; + char *buf, *lim, *next; + int res; + sw_result err =3D SW_OKAY; + +retry: + mib[0] =3D CTL_NET; + mib[1] =3D PF_ROUTE; + mib[2] =3D 0; + mib[3] =3D 0; + mib[4] =3D NET_RT_IFLIST; + mib[5] =3D 0; + + /* determine how much memory is needed */ + res =3D sysctl(mib, 6, NULL, &needed, NULL, 0); + err =3D sw_translate_error(res =3D=3D 0, errno); + sw_check_okay_log(err, exit); + + buf =3D malloc(needed); + err =3D sw_translate_error(buf !=3D NULL, SW_E_MEM); + sw_check_okay_log(err, exit); + + /* retrieve information */ + res =3D sysctl(mib, 6, buf, &needed, NULL, 0); + if (res < 0) { + if (errno =3D=3D ENOMEM && count++ < 10) { + warnx("Routing table grew, retrying"); + free(ifm); + sleep(1); + goto retry; + } + + err =3D sw_translate_error(res =3D=3D 0, errno); + sw_check_okay_log(err, exit); + } + + lim =3D buf + needed; + next =3D buf; + while (next < lim) { + ifm =3D (struct if_msghdr *)next; + + if (ifm->ifm_type =3D=3D RTM_IFINFO) { + if (ifm->ifm_data.ifi_datalen =3D=3D 0) + ifm->ifm_data.ifi_datalen =3D sizeof(struct if_data); + + sdl =3D (struct sockaddr_dl *)((char *)ifm + + sizeof(struct if_msghdr) - + sizeof(struct if_data) + + ifm->ifm_data.ifi_datalen); + } else { + sw_debug(SW_LOG_ERROR, + "out of sync parsing NET_RT_IFLIST\n"); + err =3D SW_E_INIT; + goto exit; + } + + next +=3D ifm->ifm_msglen; + ifam =3D NULL; + while (next < lim) { + nextifm =3D (struct if_msghdr *)next; + if (nextifm->ifm_type !=3D RTM_NEWADDR) + break; + + if (ifam =3D=3D NULL) + ifam =3D (struct ifa_msghdr *)nextifm; + + next +=3D nextifm->ifm_msglen; + } + + if ((ifm->ifm_flags & IFF_BROADCAST) =3D=3D 0) + { + continue; + } + + memcpy(name, sdl->sdl_data, + sizeof(name) < sdl->sdl_nlen ? + sizeof(name)-1 : sdl->sdl_nlen); + name[sizeof(name) < sdl->sdl_nlen ? + sizeof(name)-1 : sdl->sdl_nlen] =3D '\0'; + + ret =3D strdup(name); + break; + } +=09 + err =3D SW_OKAY; + +exit: + + return ret; +} + + +sw_result +sw_platform_autoip_network_interface_new( + sw_autoip_network_interface * anif, + sw_salt salt, + sw_network_interface nif) +{ + sw_freebsd_autoip_network_interface self; + int res; + int macsock; + struct ifreq ifr; + char tname[IFNAMSIZ]; + sw_result err =3D SW_OKAY; + int fd; + char name[IFNAMSIZ]; + struct bpf_version v; + struct bpf_program p; + int flag, n; + + self =3D (sw_freebsd_autoip_network_interface) sw_malloc(sizeof(struct _s= w_freebsd_autoip_network_interface)); + sw_check(self, exit, err =3D SW_E_MEM); + + err =3D sw_autoip_network_interface_init(&self->m_super, salt, nif); + sw_check_okay(err, exit); +=09 + /* + * create out socket + */ + n =3D 0; + do { + sprintf(tname, "/dev/bpf%d", n++); + fd =3D open(tname, O_RDWR); + } while (fd < 0 && errno =3D=3D EBUSY && n < 1000); + err =3D sw_translate_error(fd !=3D -1, errno); + sw_check_okay_log(err, exit); + + self->m_osock =3D fd; + self->m_isock =3D fd; + + /* Make sure the BPF version is in range... */ + res =3D ioctl(fd, BIOCVERSION, &v); + err =3D sw_translate_error(res !=3D -1, errno); + sw_check_okay_log(err, exit); + + if (v.bv_major !=3D BPF_MAJOR_VERSION || v.bv_minor < BPF_MINOR_VERSION) { + fprintf(stderr, "BPF version mismatch\n"); + err =3D sw_translate_error(0, SW_E_UNKNOWN); + sw_check_okay_log(err, exit); + } + + /* + * initialize the device name + */ + sw_memset(&ifr, 0, sizeof(ifr)); + sw_network_interface_name(self->m_super.m_nif, name, IFNAMSIZ); + strncpy(ifr.ifr_name, name, IFNAMSIZ - 1); + + /* + * bind to the interface + */ + res =3D ioctl(fd, BIOCSETIF, &ifr); + err =3D sw_translate_error(res !=3D -1, errno); + sw_check_okay_log(err, exit); + + /* Set immediate mode so that reads return as soon as a packet + * comes in, rather than waiting for the input buffer to fill with + * packets. */ + flag =3D 1; + res =3D ioctl(fd, BIOCIMMEDIATE, &flag); + err =3D sw_translate_error(res !=3D -1, errno); + sw_check_okay_log(err, exit); + + /* */ + flag =3D 0; + res =3D ioctl(fd, BIOCSSEESENT, &flag); + err =3D sw_translate_error(res !=3D -1, errno); + sw_check_okay_log(err, exit); + + /* */ + flag =3D 1; + res =3D ioctl(fd, BIOCSHDRCMPLT, &flag); + err =3D sw_translate_error(res !=3D -1, errno); + sw_check_okay_log(err, exit); + + /* Get the required BPF buffer length from the kernel. */ + res =3D ioctl(fd, BIOCGBLEN, &self->m_blen); + err =3D sw_translate_error(res !=3D -1, errno); + sw_check_okay_log(err, exit); + + self->m_buf =3D malloc(self->m_blen); + err =3D sw_translate_error(self->m_buf !=3D NULL, errno); + sw_check_okay_log(err, exit); + + /* + * set BPF filter + */ + p.bf_len =3D arp_bpf_filter_len; + p.bf_insns =3D arp_bpf_filter; + res =3D ioctl(fd, BIOCSETF, &p); + err =3D sw_translate_error(res !=3D -1, errno); + sw_check_okay_log(err, exit); + + /* + * set non-blocking socket + */ + res =3D fcntl(self->m_isock, F_GETFL); + err =3D sw_translate_error(res !=3D -1, errno); + sw_check_okay_log(err, exit); + + res =3D fcntl(self->m_isock, F_SETFL, res | O_NONBLOCK); + err =3D sw_translate_error(res !=3D -1, errno); + sw_check_okay_log(err, exit); + + err =3D sw_tcp_socket_init_with_desc(&self->m_socket, self->m_isock); + sw_check_okay(err, exit); + + err =3D sw_autoip_network_interface_handle_wakeup(&self->m_super); + sw_check_okay(err, exit); + + *anif =3D &self->m_super; + +exit: + + if (err && self) + { + sw_platform_autoip_network_interface_delete(&self->m_super); + *anif =3D NULL; + } + + return err; +} + + +sw_result +sw_platform_autoip_network_interface_delete( + sw_autoip_network_interface anif) +{ + sw_freebsd_autoip_network_interface self =3D (sw_freebsd_autoip_network_i= nterface) anif; + + sw_autoip_network_interface_fina(&self->m_super); + + sw_platform_autoip_network_interface_stop_monitoring(anif); + + /* + * free + */ + close(self->m_isock); + close(self->m_osock); + + /*=20 + * and we're good + */ + sw_free(self); + + return SW_OKAY; +} + + +sw_result +sw_platform_autoip_network_interface_set_mac_address( + const char * s) +{ + return SW_E_INIT; +} + + +sw_result +sw_platform_autoip_network_interface_start_monitoring( + sw_autoip_network_interface anif) +{ + sw_freebsd_autoip_network_interface self =3D (sw_freebsd_autoip_network_i= nterface) anif; + sw_result err; + + err =3D sw_salt_register_socket(self->m_super.m_salt, self->m_socket, SW_= SOCKET_READ, (sw_socket_handler) self, sw_freebsd_autoip_network_interface_= socket_event_handler, (sw_opaque) NULL); + sw_check_okay(err, exit); + +exit: + + return err; +} + + +sw_result +sw_platform_autoip_network_interface_stop_monitoring( + sw_autoip_network_interface anif) +{ + sw_freebsd_autoip_network_interface self =3D (sw_freebsd_autoip_network_i= nterface) anif; + sw_result err; + + err =3D sw_salt_unregister_socket(self->m_super.m_salt, self->m_socket); + sw_check_okay(err, exit); + +exit: + + return err; +} + + =09 + +sw_result +sw_platform_autoip_network_interface_send_arp_packet( + sw_autoip_network_interface anif,=20 + sw_arp_packet * packet) +{ + sw_freebsd_autoip_network_interface self =3D (sw_freebsd_autoip_network_i= nterface) anif; + struct sockaddr sndarp; + char name[IFNAMSIZ]; + sw_mac_address mymac; + int res; + sw_result err =3D SW_OKAY; + + /* + * get interface name + */ + sw_network_interface_name(self->m_super.m_nif, name, IFNAMSIZ); + strcpy(sndarp.sa_data, name); + + /* + * send packet + */ + res =3D write(self->m_osock, packet, sizeof(struct _sw_arp_packet)); + err =3D sw_translate_error(res >=3D 0, errno); + sw_check_okay_log(err, exit); + +exit: + + return err; +} + + +sw_result +sw_platform_autoip_network_interface_set_ip_address( + sw_autoip_network_interface anif) +{ + sw_freebsd_autoip_network_interface self =3D (sw_freebsd_autoip_network_i= nterface) anif; + int r; + int sock_fd; + struct ifreq ifr; + struct in_addr saddr; + char name[IFNAMSIZ]; + int res; + sw_result err =3D SW_OKAY; + struct ifaliasreq ifra; + struct sockaddr_in addr; + + /* + * socket for ioctl + */ + sock_fd =3D socket(PF_INET, SOCK_DGRAM, IPPROTO_IP); + err =3D sw_translate_error(sock_fd !=3D -1, errno); + sw_check_okay_log(err, exit); + + /* + * initialize the device name + */ + sw_memset(&ifra, 0, sizeof(ifra)); + sw_network_interface_name(self->m_super.m_nif, name, IFNAMSIZ); + strncpy(ifra.ifra_name, name, IFNAMSIZ - 1); + =20 + /* + * initialize the ip address + */ + addr.sin_addr.s_addr =3D sw_ipv4_address_saddr(self->m_super.m_ip_addr); + addr.sin_family =3D AF_INET; + addr.sin_len =3D sizeof(struct sockaddr_in); + memcpy(&ifra.ifra_addr, &addr, sizeof(struct sockaddr_in)); + + addr.sin_addr.s_addr |=3D ntohl(0x0000ffff); + memcpy(&ifra.ifra_broadaddr, &addr, sizeof(struct sockaddr_in)); + + addr.sin_addr.s_addr =3D ntohl(0xffff0000); + memcpy(&ifra.ifra_mask, &addr, sizeof(struct sockaddr_in)); + + res =3D ioctl(sock_fd, SIOCAIFADDR, &ifra); + err =3D sw_translate_error(res =3D=3D 0, errno); + sw_check_okay_log(err, exit); + + err =3D sw_network_interface_set_ipv4_address(self->m_super.m_nif, self->= m_super.m_ip_addr); + sw_check_okay(err, exit); + +exit: + + if (sock_fd !=3D -1) + { + close(sock_fd); + } +} + + +static sw_result +sw_freebsd_autoip_network_interface_socket_event_handler( + sw_socket_handler handler, + sw_salt salt, + sw_socket socket, + sw_socket_event events, + sw_opaque extra) +{ + static sw_mac_address ProbeSenderMAC =3D { 0, 0, 0, 0, 0, 0 }; + + sw_freebsd_autoip_network_interface self =3D (sw_freebsd_autoip_network_i= nterface) handler; + char *ptr, *limit; + struct bpf_hdr *hdr; + sw_arp_packet *packet;=20 + char smyip[18], spacketip[18]; + char smymac[18], spacketmac[18]; + int bytes; + sw_result err =3D SW_OKAY; +=09 + sw_assert(self !=3D NULL); + + /* + * ignore invocations if not our socket + */ + sw_check(self->m_isock =3D=3D sw_socket_desc(socket), exit, err =3D SW_OK= AY); + + bytes =3D read(self->m_isock, self->m_buf, self->m_blen); + err =3D sw_translate_error(bytes >=3D 0, errno); + sw_check_okay_log(err, exit); + + + for (ptr =3D (char *)self->m_buf, limit =3D ptr + bytes; + ptr < limit; + ptr +=3D BPF_WORDALIGN(hdr->bh_hdrlen + hdr->bh_caplen)) { + hdr =3D (struct bpf_hdr *)ptr; + packet =3D (sw_arp_packet *)(ptr + hdr->bh_hdrlen); + + if (hdr->bh_caplen >=3D (sizeof(struct _sw_ethernet_header) + sizeof(str= uct _sw_arp_header))) + { + if (((ntohs(packet->m_arp_header.m_op)) =3D=3D SW_AUTOIP_ARP_REQUEST) || + ((ntohs(packet->m_arp_header.m_op)) =3D=3D SW_AUTOIP_ARP_REPLY)) + { + err =3D sw_autoip_network_interface_read_arp_packet(&self->m_super, pa= cket); + sw_check_okay(err, exit); + } + } + } + +exit: + + return err; +} diff -urN empty/freebsd_autoip.h src/autoipd/BSD/freebsd_autoip.h --- src/autoipd/BSD/freebsd_autoip.h Thu Jan 1 01:00:00 1970 +++ src/autoipd/BSD/freebsd_autoip.h Thu Dec 9 17:49:04 2004 @@ -0,0 +1,67 @@ +/* + * Copyright 2003, 2004 Porchdog Software. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without modi= fication, + * are permitted provided that the following conditions are met: + * + * 1. Redistributions of source code must retain the above copyright noti= ce, + * this list of conditions and the following disclaimer. =20 + * 2. Redistributions in binary form must reproduce the above copyright n= otice, + * this list of conditions and the following disclaimer in the documen= tation + * and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY PORCHDOG SOFTWARE ``AS IS'' AND ANY + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLI= ED + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE = DISCLAIMED. + * IN NO EVENT SHALL THE HOWL PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DI= RECT, + * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INC= LUDING, + * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS O= F USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY T= HEORY + * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING= NEGLIGENCE + * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN = IF ADVISED + * OF THE POSSIBILITY OF SUCH DAMAGE. + * + * The views and conclusions contained in the software and documentation a= re those + * of the authors and should not be interpreted as representing official p= olicies, + * either expressed or implied, of Porchdog Software. + */ + +#ifndef _freebsd_autoip_h +#define _freebsd_autoip_h + + +#include "../autoip.h" +#include +#include +#include =20 +#include + + +#if defined(__cplusplus) +extern "C" +{ +#endif + + +struct _sw_freebsd_autoip_network_interface; +typedef struct _sw_freebsd_autoip_network_interface * sw_freebsd_autoip_ne= twork_interface; + + +struct _sw_freebsd_autoip_network_interface +{ + struct _sw_autoip_network_interface m_super; + sw_socket m_socket; + sw_sockdesc_t m_osock; + sw_sockdesc_t m_isock; + + u_int m_blen; + unsigned char *m_buf; +}; + + +#if defined(__cplusplus) +} +#endif + +=20 +#endif Index: src/autoipd/BSD/Makefile.am =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: src/autoipd/BSD/Makefile.am diff -N src/autoipd/BSD/Makefile.am --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ src/autoipd/BSD/Makefile.am 12 Dec 2004 09:36:10 -0000 1.1 @@ -0,0 +1,4 @@ +sources_h =3D freebsd_autoip.h +sources_c =3D freebsd_autoip.c +DIST_SOURCES =3D $(sources_h) $(sources_c) Makefile.am +INCLUDES =3D -I$(top_srcdir)/include/ --dTy3Mrz/UPE2dbVg-- From owner-freebsd-net@FreeBSD.ORG Fri Jan 7 17:48:45 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EE7B16A4CE for ; Fri, 7 Jan 2005 17:48:45 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80AF143D2F for ; Fri, 7 Jan 2005 17:48:44 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 5083765375; Fri, 7 Jan 2005 17:48:42 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21246-02-7; Fri, 7 Jan 2005 17:48:41 +0000 (GMT) Received: from empiric.dek.spc.org (unknown [213.210.24.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 676526530A; Fri, 7 Jan 2005 17:48:41 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 9321464C3; Fri, 7 Jan 2005 17:49:14 +0000 (GMT) Date: Fri, 7 Jan 2005 17:49:14 +0000 From: Bruce M Simpson To: Andrea Campi Message-ID: <20050107174914.GQ9855@empiric.icir.org> Mail-Followup-To: Andrea Campi , freebsd-net@freebsd.org References: <20050107165703.GC16579@webcom.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z+pzSjdB7cqptWpS" Content-Disposition: inline In-Reply-To: <20050107165703.GC16579@webcom.it> cc: freebsd-net@freebsd.org Subject: Re: howl patch for better BSD support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2005 17:48:45 -0000 --z+pzSjdB7cqptWpS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jan 07, 2005 at 05:57:04PM +0100, Andrea Campi wrote: > as promised, I've been working on improving howl. I've been in touch > with the authors, so in fact this is also resulting in cross-platform > fixes. Excellent work! I just gave this a quick try on my laptop. Whilst I don't have other zeroconf nodes to test with right at this minute this is very promising progress and will greatly help potential future work I'm looking at doing which would be greatly aided by working zeroconf support on *BSD. Thanks muchly! BMS --z+pzSjdB7cqptWpS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQFB3suaueUpAYYNtTsRAlq1AJ906lUKy1VPLpmn0n1/XIOFontNegCfVvpE 7AP4nXeL45gd34dQ132LnTI= =bPm2 -----END PGP SIGNATURE----- --z+pzSjdB7cqptWpS-- From owner-freebsd-net@FreeBSD.ORG Sat Jan 8 02:50:20 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CE7E16A4D0 for ; Sat, 8 Jan 2005 02:50:20 +0000 (GMT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EAE243D58 for ; Sat, 8 Jan 2005 02:50:20 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) j082oIwP086926; Fri, 7 Jan 2005 18:50:19 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (pc1.oakwoodazabu1-unet.ocn.ne.jp [220.110.140.201]) by mail.meer.net (8.12.10/8.12.10/meer) with ESMTP id j082oHeg087470; Fri, 7 Jan 2005 18:50:17 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Sat, 08 Jan 2005 11:50:15 +0900 Message-ID: From: gnn@freebsd.org To: Bruce M Simpson In-Reply-To: <20050107174914.GQ9855@empiric.icir.org> References: <20050107165703.GC16579@webcom.it> <20050107174914.GQ9855@empiric.icir.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.5 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: howl patch for better BSD support X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2005 02:50:20 -0000 At Fri, 7 Jan 2005 17:49:14 +0000, bruce wrote: > > [1 ] > On Fri, Jan 07, 2005 at 05:57:04PM +0100, Andrea Campi wrote: > > as promised, I've been working on improving howl. I've been in touch > > with the authors, so in fact this is also resulting in cross-platform > > fixes. > > Excellent work! I just gave this a quick try on my laptop. Whilst I > don't have other zeroconf nodes to test with right at this minute this > is very promising progress and will greatly help potential future work > I'm looking at doing which would be greatly aided by working zeroconf > support on *BSD. > We should try to drag this into Dingo and get it built. I have two zeroconf nodes at home, if a Mac and a Rendezvous based printer count for that. Later, George From owner-freebsd-net@FreeBSD.ORG Sat Jan 8 11:54:36 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E2A716A4CE for ; Sat, 8 Jan 2005 11:54:36 +0000 (GMT) Received: from poczta.o2.pl (mx2.go2.pl [193.17.41.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40BD143D45 for ; Sat, 8 Jan 2005 11:54:35 +0000 (GMT) (envelope-from knockefreebsd@o2.pl) Received: from ALFA (aaf223.warszawa.sdi.tpnet.pl [217.97.85.223]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by poczta.o2.pl (Postfix) with ESMTP id B31AD60042; Sat, 8 Jan 2005 12:54:33 +0100 (CET) Message-ID: <004c01c4f579$2a0d7730$df5561d9@ALFA> From: "Heinz Knocke" To: "Joshua Blanton" References: <004a01c4f43c$521af510$df5561d9@ALFA> <20050107105735.GC29573@jtb.ipx.ath.cx> Date: Sat, 8 Jan 2005 12:56:54 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: freebsd-net@freebsd.org Subject: Re: What will do the TCP stack in the described scenario? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Heinz Knocke List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2005 11:54:36 -0000 Hi! I see that I didn't explain everything clearly, and made some mistakes so let me get through it again :)) You're right about the segment numers, but I use the same packet numeration as tcpdump, so the last segment of the previous packet and the first segment of the following one have the same number. Actually I DO have such situation that client (or I should rather say - the TCP reciever) doesn't send dupack for the packet loss, so the server (or rather - the TCP sender) doesn't know anything about the packet being lost and waits the whole long RTO for retransmission. I'll give you the exact tcpdump extract to see how it works. The output is alittle processed to make it clear, 1.445 is the TCP sender, 2.49821 the reciever. 2.542532 1.445 > 2.49821: P 3807194718:3807198814(4096) ack 1971888923 win 32768 2.542541 1.445 > 2.49821: P 3807198814:3807202910(4096) ack 1971888923 win 32768 2.542872 2.49821 > 1.445: . ack 3807194718 win 31744 .... 2.635501 2.49821 > 1.445: . ack 3807198814 win 32768 .... .... .... 2.956050 1.445 > 2.49821: P 3807198814:3807202910(4096) ack 1971888923 win 32768 As you can see the reciever doesn't ACK segments 3807198814 to 3807202910 which are the last sent by the sender (not like I previously wrote - packet before the last one). Could you please explain this behaviour? I observe this kind of behaviour on many FreeBSD systems using Samba (newest STABLE and CURRENT sys as well) , performance is very poor probably because of the dropping cwnd caused by RTO. hk From owner-freebsd-net@FreeBSD.ORG Sat Jan 8 11:59:22 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 779D916A4CE for ; Sat, 8 Jan 2005 11:59:22 +0000 (GMT) Received: from poczta.o2.pl (mx2.go2.pl [193.17.41.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94B3743D39 for ; Sat, 8 Jan 2005 11:59:21 +0000 (GMT) (envelope-from knockefreebsd@o2.pl) Received: from ALFA (aaf223.warszawa.sdi.tpnet.pl [217.97.85.223]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by poczta.o2.pl (Postfix) with ESMTP id 460D0600D5; Sat, 8 Jan 2005 12:59:20 +0100 (CET) Message-ID: <005601c4f579$d4e03d50$df5561d9@ALFA> From: "Heinz Knocke" To: "Joshua Blanton" References: <004a01c4f43c$521af510$df5561d9@ALFA><20050107105735.GC29573@jtb.ipx.ath.cx> <004c01c4f579$2a0d7730$df5561d9@ALFA> Date: Sat, 8 Jan 2005 13:01:45 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: freebsd-net@freebsd.org Subject: Re: What will do the TCP stack in the described scenario? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Heinz Knocke List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2005 11:59:22 -0000 ----- Original Message ----- From: "Heinz Knocke" To: "Joshua Blanton" Cc: Sent: Saturday, January 08, 2005 12:56 PM Subject: Re: What will do the TCP stack in the described scenario? > As you can see the reciever doesn't ACK segments 3807198814 to > 3807202910 which are the last sent by the sender (not like I > previously wrote - packet before the last one). Could you please > explain this behaviour? .. I should have also add, that those dupacks, as I can see in the reciever's side packet dump, were not dropped by the congested network, they weren't send at all ... hk