From owner-freebsd-net Sun Feb 10 2:11:31 2002 Delivered-To: freebsd-net@freebsd.org Received: from vampiro.rootshell.ru (rshb.com.ru.rshb.com.ru.rshb.com.ru.rshb.com.ru [195.162.58.50]) by hub.freebsd.org (Postfix) with ESMTP id 4E38D37B419 for ; Sun, 10 Feb 2002 02:11:25 -0800 (PST) Received: by vampiro.rootshell.ru (Sendmail for UK-NC (RT11-SJ), from userid 426) id 84DB957C3; Sun, 10 Feb 2002 16:11:33 +0600 (OMST) Received: from rshb.com.ru (vampiro.rsb.local [192.168.1.111]) by vampiro.rootshell.ru (Sendmail for UK-NC (RT11-SJ)) with ESMTP id 7C18757B2 for ; Sun, 10 Feb 2002 16:11:32 +0600 (OMST) Message-ID: <3C664753.2090209@rshb.com.ru> Date: Sun, 10 Feb 2002 16:11:31 +0600 From: "Evgueni V. Gavrilov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.8) Gecko/20020206 X-Accept-Language: ru, en MIME-Version: 1.0 To: net@freebsd.org Subject: Re: HEADS UP: device polling code merged into -stable References: <20020209170804.C13970@iguana.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo wrote: >I'd be grateful if you could stress-test this code and >report problems (if any) or success. Remember that >only 'dc' 'fxp' and 'sis' drivers are supported at the moment. > looks like your device polling page (http://info.iet.unipi.it/~luigi/polling/) doesn't contain info about minor changes since Dec 2001 -- VAMPIRO-RIPN To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 10 14:46:38 2002 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4C0E737B402 for ; Sun, 10 Feb 2002 14:46:33 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id g1AMkUD48221 for ; Sun, 10 Feb 2002 17:46:31 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 10 Feb 2002 17:46:30 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: net@FreeBSD.org Subject: Problems with dhclient on interfaces before they are ifconfig'd. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Noted a few weeks ago that I had the following problem on -current: On inserting a wavelane card (if_wi), I could not get dhclient to recognize the interface until I had manually ifconfig'd it with an address. After that, dhclient would find it fine after that. I tracked this down at some stage, but don't remember what exactly caused it. Poul-Henning Kamp has reported a similar problem. Was wondering if anyone else had noticed this and/or had a fix. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 10 17:43:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id AC50D37B42C for ; Sun, 10 Feb 2002 17:43:36 -0800 (PST) Received: (qmail 14422 invoked from network); 11 Feb 2002 01:43:36 -0000 Received: from unknown (HELO tenebras.com) (192.168.1.123) by 0 with SMTP; 11 Feb 2002 01:43:36 -0000 Message-ID: <3C6721C6.9080904@tenebras.com> Date: Sun, 10 Feb 2002 17:43:34 -0800 From: Michael Sierchio Reply-To: kudzu@tenebras.com User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Possible bug in ip_fw stateful rule stuff Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Running ipfw w/natd, connections through the gateway are dying. Two dynamic rules get instantiated for each connection through the gateway -- one with NAT'd addresses and one revealing the private addresses $on = external net = X.Y.Z/24 $in = internal net = A.B.C/24 (192.168.1.0/24) the external IP is X.Y.Z.23 the internal IP is A.B.C.1 firewall rules: [some static rules...] $fw add divert natd ip from any to any via $external_interface $fw add check-state $fw add allow tcp from $in to any setup keep-state $fw add allow udp from $in to any keep-state $fw add allow tcp from $on to any setup keep-state $fw add allow udp from $on to any keep-state An ssh connection from A.B.C.4 to X.Y.Z.44 causes the following dynamic rules to appear: 02400 15 3197 (T 16, slot 760) <-> tcp, X.Y.Z.23 1549<-> X.Y.Z.44 22 02200 45 9151 (T 296, slot 913) <-> tcp, A.B.C.4 1549<-> X.Y.Z.44 22 Note 02400 -- this connection timer seems to indicate that it is waiting for a completed 3-way handshake and hasn't seen the other SYN. The connection dies because the time counts down. The timer for 02200 doesn't count down because the keep-alives are resetting it. Any insight as to why this is happening? Seems like a bug in the state machine. I could be convinced otherwise, but it seems that these two rules should see the connection as being in the same state -- they both see the same packets. BTW, I could simplify this by safely allowing $fw add divert natd ip from any to any via $external_interface $fw add check-state $fw add allow ip from $in to any $fw add allow ip from any to $in $fw add allow tcp from $on to any setup keep-state $fw add allow udp from $on to any keep-state But the dynamic rule on the public side still seem to be using net.inet.ip.fw.dyn_syn_lifetime instead of net.inet.ip.fw.dyn_ack_lifetime. Comments? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 10 23:45:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (oe62.pav1.hotmail.com [64.4.30.197]) by hub.freebsd.org (Postfix) with ESMTP id C67FD37B417; Sun, 10 Feb 2002 23:45:47 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 10 Feb 2002 23:45:47 -0800 X-Originating-IP: [66.185.84.77] From: "jack xiao" To: , Subject: MTU problems on PPP interfaces with L2TP Date: Mon, 11 Feb 2002 02:47:07 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0080_01C1B2A6.654328E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 11 Feb 2002 07:45:47.0679 (UTC) FILETIME=[1E71A2F0:01C1B2D0] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0080_01C1B2A6.654328E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0081_01C1B2A6.654328E0" ------=_NextPart_001_0081_01C1B2A6.654328E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQo= ------=_NextPart_001_0081_01C1B2A6.654328E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNjAwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_001_0081_01C1B2A6.654328E0-- ------=_NextPart_000_0080_01C1B2A6.654328E0 Content-Type: text/plain; name="mtu problems on pppd interfaces with l2tp.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="mtu problems on pppd interfaces with l2tp.txt" I set up L2TP tunnels between FreeBSD4.2 and Redback through VLAN = interfaces. Then ADSL clients connect to our FreeBSD server through PPP tunnel = directly.=20 Actually, the PPPd is caused by L2tpd = (http://sourceforge.net/projects/l2tpd/) to=20 genarate a PPP tunnel. Now I met some weird problems about the MTU value on PPP interfaces. Here is the values I set for all the interfaces, Ethernet:1500 Vlan:1496 PPP:1496-16(L2tp header)-20(ip-ip tunnel header)-4(ppp header)=3D1456 So I set mtu 1456 and mru 1456 for ppp interfaces I am not sure it is the right value. Any suggestion? On the PPPoE client the default value is 1492 for mru and 1454 for mtu. During the test, I found I can hit websites but can't download files = from some websites. So I droped the PPP mtu and mru to 1452 and I can download but can't hit = some websites. Does anybody have such experience as above? Any help will be = appreciated. Thanks! Jack ------=_NextPart_000_0080_01C1B2A6.654328E0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sun Feb 10 23:53:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from workhorse.iMach.com (workhorse.iMach.com [206.127.77.89]) by hub.freebsd.org (Postfix) with ESMTP id 107FC37B405; Sun, 10 Feb 2002 23:53:39 -0800 (PST) Received: from localhost (forrestc@localhost) by workhorse.iMach.com (8.9.3/8.9.3) with ESMTP id AAA27856; Mon, 11 Feb 2002 00:53:26 -0700 (MST) Date: Mon, 11 Feb 2002 00:53:26 -0700 (MST) From: "Forrest W. Christian" To: jack xiao Cc: freebsd-isp@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: MTU problems on PPP interfaces with L2TP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 11 Feb 2002, jack xiao wrote: > During the test, I found I can hit websites but can't download files > from some websites. So I droped the PPP mtu and mru to 1452 and I can > download but can't hit some websites. Sounds like a MTU path discovery problem. Are you using RFC1419 (192.168 or 10.x or 172.x) address space anywhere in your network and/or are filtering ICMP anywhere? If not, do you have a sample website which is exibiting breakage? Chances are the ICMP responses to the DF packets which MTU path discovery uses aren't getting back to their origin. The broken web sites might be the ones using MTU path discovery, or there may be a fragmentation issue somewhere end to end. - Forrest W. Christian (forrestc@imach.com) AC7DE ---------------------------------------------------------------------- The Innovation Machine Ltd. P.O. Box 5749 http://www.imach.com/ Helena, MT 59604 Home of PacketFlux Technogies and BackupDNS.com (406)-442-6648 ---------------------------------------------------------------------- Protect your personal freedoms - visit http://www.lp.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 1:34:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 0EDF137B419 for ; Mon, 11 Feb 2002 01:34:52 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020211093446.LBBO1672.rwcrmhc51.attbi.com@blossom.cjclark.org>; Mon, 11 Feb 2002 09:34:46 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g1B9Ykf22491; Mon, 11 Feb 2002 01:34:46 -0800 (PST) (envelope-from cjc) Date: Mon, 11 Feb 2002 01:34:46 -0800 From: "Crist J. Clark" To: Michael Sierchio Cc: freebsd-net@FreeBSD.ORG Subject: Re: Possible bug in ip_fw stateful rule stuff Message-ID: <20020211013445.D20884@blossom.cjclark.org> References: <3C6721C6.9080904@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C6721C6.9080904@tenebras.com>; from kudzu@tenebras.com on Sun, Feb 10, 2002 at 05:43:34PM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Feb 10, 2002 at 05:43:34PM -0800, Michael Sierchio wrote: > Running ipfw w/natd, connections through the gateway are dying. Two dynamic > rules get instantiated for each connection through the gateway -- one > with NAT'd addresses and one revealing the private addresses > > $on = external net = X.Y.Z/24 > $in = internal net = A.B.C/24 (192.168.1.0/24) > > the external IP is X.Y.Z.23 > the internal IP is A.B.C.1 > > firewall rules: > > [some static rules...] > > $fw add divert natd ip from any to any via $external_interface > > $fw add check-state > > $fw add allow tcp from $in to any setup keep-state > $fw add allow udp from $in to any keep-state > > $fw add allow tcp from $on to any setup keep-state > $fw add allow udp from $on to any keep-state > > > An ssh connection from A.B.C.4 to X.Y.Z.44 causes the following dynamic rules > to appear: > > > 02400 15 3197 (T 16, slot 760) <-> tcp, X.Y.Z.23 1549<-> X.Y.Z.44 22 > 02200 45 9151 (T 296, slot 913) <-> tcp, A.B.C.4 1549<-> X.Y.Z.44 22 > > Note 02400 -- this connection timer seems to indicate that it is waiting for > a completed 3-way handshake and hasn't seen the other SYN. The connection dies > because the time counts down. The timer for 02200 doesn't count down because > the keep-alives are resetting it. > > Any insight as to why this is happening? It is pretty simple. 1) Initial SYN leaves A.B.C.4. 2) SYN comes in firewall, goes through rules, and matches 2200. 3) SYN goes out of firewall, goes through rules, matches natd(8) rule, and is translated. 4) SYN continues through firewall, now with X.Y.Z.23 as source, and matches 2400. 5) SYN get to remote machine, remote machine sends SYN-ACK to X.Y.Z.23. 6) SYN-ACK reaches firewall, goes through rules, matches the natd(8) rule, and is translated. 7) SYN-ACK continues through rules, now with destination A.B.C.4, and matches the dynamic rule for _2200._ 8) SYN-ACK goes through rules on way out and again matches 2200. Notice, the returning packets never hit the dynamic rule from 2400. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 3: 3:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from artemis.drwilco.net (diana.drwilco.net [66.48.127.79]) by hub.freebsd.org (Postfix) with ESMTP id 5F5EB37B416; Mon, 11 Feb 2002 03:03:09 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g1BB2uZ99732 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Mon, 11 Feb 2002 06:02:59 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020211121214.01bb03e0@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Feb 2002 12:13:01 +0100 To: Archie Cobbs , Andrew Reilly From: "Rogier R. Mulhuijzen" Subject: Re: mpd-netgraph problem. Cc: Archie Cobbs , freebsd-stable@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <200202070514.g175EDx16223@arch20m.dellroad.org> References: <20020207160415.A479@gurney.lake> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 21:14 6-2-2002 -0800, Archie Cobbs wrote: >Andrew Reilly writes: > > Presumably this is simple pilot-error: I should either have put > > all of the netgraph options into my kernel or none. But perhaps > > this indicates an error with one kldload being taken too strongly, > > and short-circuiting the loading of subsequent modules? > >There are long-standing bugs in the KLD module system that >have yet to be fixed.. I think this is one of them. I can confirm this problem. I had the same thing, and either not having any netgraph options or all fixed it. Doc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 5: 5:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from web20106.mail.yahoo.com (web20106.mail.yahoo.com [216.136.226.43]) by hub.freebsd.org (Postfix) with SMTP id EF44537B400 for ; Mon, 11 Feb 2002 05:05:33 -0800 (PST) Message-ID: <20020211130533.11520.qmail@web20106.mail.yahoo.com> Received: from [212.234.238.114] by web20106.mail.yahoo.com via HTTP; Mon, 11 Feb 2002 05:05:33 PST Date: Mon, 11 Feb 2002 05:05:33 -0800 (PST) From: ome ome Subject: Re: Sangoma WAN card To: julian@elischer.org Cc: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, OK, I've understood Netgraph philosophy and particulary that a hardware driver need to support Netgraph lines disciplines. So, for in order to use Sangoma WAN card S5141 with Netgraph, the driver needs to be modified. But, I'm not enough good in C for doing that. Someone could help me please! Thanks the drivers are located at: ftp://ftp.sangoma.com/FreeBSD/ Julian Elischer wrote : ahhhhh does teh card provide a /dev/tty type interface? if not then you may be out of luck because it doesn't have a netgraph interface. The hardware has to be able to connect with netgraph in some way. I gather the driver is binary? On Mon, 28 Jan 2002, ome ome wrote: > Hi, > > I'm trying to use a Sangoma WAN card in raw mode > to use pppd (from freeBSD 3.5) and not the PPP which > is on the WAN Card. > For this, I tried netgraph, but I don't know which > type of node to use for the wan card. > > Thanks > __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 8:51: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from bob.inty.net (bob.inty.net [213.38.150.165]) by hub.freebsd.org (Postfix) with ESMTP id 42F7E37B400 for ; Mon, 11 Feb 2002 08:51:03 -0800 (PST) Received: from inty.hq.inty.net ([213.38.150.161]) by bob.inty.net (8.11.3/8.11.3) with ESMTP id g1BGosf30038 for ; Mon, 11 Feb 2002 16:50:55 GMT Received: from tariq ([10.0.1.156]) by inty.hq.inty.net (8.12.1/8.12.1) with SMTP id g1BGosYl037165 for ; Mon, 11 Feb 2002 16:50:54 GMT From: "Tariq Rashid" To: Subject: RE: squeeze more performance out of natd? Date: Mon, 11 Feb 2002 16:53:54 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <004701c1b01e$7039d3f0$361c1a09@gsicomp.on.ca> X-Sender-IP: 10.0.1.156 X-INT-DeliveryDone: g1BGosYl037165 X-suppress-rcpt-virus-notify: yes X-Skip-Virus-Check: yes X-Virus-Checked: 29835 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org some tests seems to show that natd's cpu load goes up because we have a large file descriptor set for select() - this is more of a problem than the kernelspace/userland packet traversal. the traffic its handling is something like 1500 low traffic tcp connections to a single server port. from doing some rtfm-ing i see that select() is not very scalable - not good for large fd sets and not good if they are nearly alwats ready for reading. does this sound no too far wrong? (i'm not an expert my any means) possible ideas: * is doing a select on 1000 file descriptors more efficient than having 10 selects on 100 file descriptors? * what about diverting to multiple natd processes? * threading? are there any benefits at all in this scenario? tariq -----Original Message----- From: owner-freebsd-net@FreeBSD.ORG [mailto:owner-freebsd-net@FreeBSD.ORG]On Behalf Of Matthew Emmerton Sent: 07 February 2002 21:29 To: Tariq Rashid; freebsd-net@FreeBSD.ORG Subject: Re: squeeze more performance out of natd? > i've spent a good number of hours RTFMs, trying to make the best of a bad > situtaion: userland natd instead of kernel-space nat. I've been told that if you use ipf and ipnat, then you get the benefit of kernel-space NAT. Have you investigated this to see how it compares to natd/ipfw for your purposes? -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message intY has automatically scanned this email with Sophos Anti-Virus (www.inty.net) intY has automatically scanned this email with Sophos Anti-Virus (www.inty.net) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 10:20:27 2002 Delivered-To: freebsd-net@freebsd.org Received: from web9903.mail.yahoo.com (web9903.mail.yahoo.com [216.136.129.246]) by hub.freebsd.org (Postfix) with SMTP id 5BA1037B402 for ; Mon, 11 Feb 2002 10:20:24 -0800 (PST) Message-ID: <20020211182024.22608.qmail@web9903.mail.yahoo.com> Received: from [216.98.102.241] by web9903.mail.yahoo.com via HTTP; Mon, 11 Feb 2002 10:20:24 PST Date: Mon, 11 Feb 2002 10:20:24 -0800 (PST) From: W Alexander Hagen Subject: Re: How to Update and recompile an device driver To: Doug Ambrisko , Brooks Davis Cc: W Alexander Hagen , Kevin Oberman , net@FreeBSD.ORG In-Reply-To: <200202090323.g193NMa37685@ambrisko.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-250480297-1013451624=:20747" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --0-250480297-1013451624=:20747 Content-Type: text/plain; charset=us-ascii Thanks all for your inputs. I will follow your advice and upgrade to 4.4. My problem is that I am using Portland State Mobile IP which modifies some of the FreeBSD source so I can't upgrade easily. Alexander Hagen Docomo USA Labs Doug Ambrisko wrote: Brooks Davis writes: | On Fri, Feb 08, 2002 at 02:44:31PM -0800, W Alexander Hagen wrote: | > | > Is is possible to cvsup only a device driver. I have tried copying the | > source of the driver and then rebuilding the kernel, but it allways | > seems to invoke dependencies that are assumed to be updated over the | > base 4.3 FreeBSD as well. The latest try I get | > | > if_an.c IFM_IEE80211 undeclared and related messages | | By far, your best bet is to give up now and do an OS upgrade. Updating | drivers independently is a completly unsupported operation for experts | only. The above error means you need to updated your if_media support. | To do that you need to find the commit logs for the upgrades to add | IEEE 802.11 support to if_media and update all the files in question. | There are probalby other things you'd have to update too. ... yep like Linux device private ioctl's and ancontrol changes. You really are better off get the latest -stable and then building everything. Things will work better in the end. Also if you find a problem then getting a fix will be easier as well! Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message --------------------------------- Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! --0-250480297-1013451624=:20747 Content-Type: text/html; charset=us-ascii

Thanks all for your inputs. I will follow your advice and upgrade to 4.4. My problem is that I am using Portland State Mobile IP which modifies some of the FreeBSD source so I can't upgrade easily.

Alexander Hagen

Docomo USA Labs

  Doug Ambrisko <ambrisko@ambrisko.com> wrote:

Brooks Davis writes:
| On Fri, Feb 08, 2002 at 02:44:31PM -0800, W Alexander Hagen wrote:
| >
| > Is is possible to cvsup only a device driver. I have tried copying the
| > source of the driver and then rebuilding the kernel, but it allways
| > seems to invoke dependencies that are assumed to be updated over the
| > base 4.3 FreeBSD as well. The latest try I get
| >
| > if_an.c IFM_IEE80211 undeclared and related messages
|
| By far, your best bet is to give up now and do an OS upgrade. Updating
| drivers independently is a completly unsupported operation for experts
| only. The above error means you need to updated your if_media support.
| To do that you need to find the commit logs for the upgrades to add
| IEEE 802.11 support to if_media and update all the files in question.
| There are probalby other things you'd have to update too.

... yep like Linux device private ioctl's and ancontrol changes.
You really are better off get the latest -stable and then building
everything. Things will work better in the end. Also if you find
a problem then getting a fix will be easier as well!

Doug A.

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


Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings! --0-250480297-1013451624=:20747-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 11: 5:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d188.as6.nwbl0.wi.voyager.net [169.207.130.62]) by hub.freebsd.org (Postfix) with ESMTP id DCE3937B427 for ; Mon, 11 Feb 2002 11:04:36 -0800 (PST) Received: from localhost (silby@localhost) by patrocles.silby.com (8.11.6/8.11.6) with ESMTP id g1BD89385047; Mon, 11 Feb 2002 13:08:20 GMT (envelope-from silby@silby.com) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 11 Feb 2002 13:08:07 +0000 (GMT) From: Mike Silbersack To: Tariq Rashid Cc: freebsd-net@FreeBSD.ORG Subject: RE: squeeze more performance out of natd? In-Reply-To: Message-ID: <20020211130512.S84750-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 11 Feb 2002, Tariq Rashid wrote: > some tests seems to show that natd's cpu load goes up because we have a > large file descriptor set for select() - this is more of a problem than the > kernelspace/userland packet traversal. the traffic its handling is something > like 1500 low traffic tcp connections to a single server port. > > from doing some rtfm-ing i see that select() is not very scalable - not > good for large fd sets and not good if they are nearly alwats ready for > reading. The best way to improve performance would probably be to rewrite natd to use kqueue instead of select. I'm not sure how difficult this would be, you might wish to talk to jlemon if you have any questions on the best way to tackle the project. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 11:20:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 68A3B37B402 for ; Mon, 11 Feb 2002 11:20:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020211192009.VAWH1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Mon, 11 Feb 2002 19:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA17612; Mon, 11 Feb 2002 11:14:55 -0800 (PST) Date: Mon, 11 Feb 2002 11:14:54 -0800 (PST) From: Julian Elischer To: Mike Silbersack Cc: Tariq Rashid , freebsd-net@FreeBSD.ORG Subject: RE: squeeze more performance out of natd? In-Reply-To: <20020211130512.S84750-100000@patrocles.silby.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 11 Feb 2002, Mike Silbersack wrote: > > On Mon, 11 Feb 2002, Tariq Rashid wrote: > > The best way to improve performance would probably be to rewrite natd to > use kqueue instead of select. I'm not sure how difficult this would be, > you might wish to talk to jlemon if you have any questions on the best way > to tackle the project. or just select on a really small array of bits.. > > Mike "Silby" Silbersack > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 11:26:49 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 674F537B402 for ; Mon, 11 Feb 2002 11:26:45 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 2AD3210DDFB; Mon, 11 Feb 2002 11:26:45 -0800 (PST) Date: Mon, 11 Feb 2002 11:26:45 -0800 From: Alfred Perlstein To: Mike Silbersack Cc: Tariq Rashid , freebsd-net@FreeBSD.ORG Subject: Re: squeeze more performance out of natd? Message-ID: <20020211112645.F63886@elvis.mu.org> References: <20020211130512.S84750-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020211130512.S84750-100000@patrocles.silby.com>; from silby@silby.com on Mon, Feb 11, 2002 at 01:08:07PM +0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Mike Silbersack [020211 11:05] wrote: > > On Mon, 11 Feb 2002, Tariq Rashid wrote: > > > some tests seems to show that natd's cpu load goes up because we have a > > large file descriptor set for select() - this is more of a problem than the > > kernelspace/userland packet traversal. the traffic its handling is something > > like 1500 low traffic tcp connections to a single server port. > > > > from doing some rtfm-ing i see that select() is not very scalable - not > > good for large fd sets and not good if they are nearly alwats ready for > > reading. > > The best way to improve performance would probably be to rewrite natd to > use kqueue instead of select. I'm not sure how difficult this would be, > you might wish to talk to jlemon if you have any questions on the best way > to tackle the project. That's what I thought initially, however the problem is that each packet requires at least a select(2) then recvfrom(2) and then possibly a sendto(2). The select(2) loop is particulary niave as the dispatched functions will only pull one packet from the socket instead of looping until the outstanding data is removed. Yes, another way would be to loop doing recvfrom's until EAGAIN is returned, I suspect this may give at least a 2 fold increase in performance and is trivial to accomplish. another would be to figure out a way to pull multiple packets via some recvfrom-like call that can return multiple sockaddrs, this would probably also give a very nice performance improvement. another way to improve it slightly would be to use kevent, failing that, there's always moving it into the kernel where the perf would most likely get better by several orders of magnitude by avoiding copies and userspace/kernel context switching. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 12: 0:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from devonshire.cnchost.com (devonshire.concentric.net [207.155.248.12]) by hub.freebsd.org (Postfix) with ESMTP id F097837B402 for ; Mon, 11 Feb 2002 12:00:22 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by devonshire.cnchost.com id PAA10901; Mon, 11 Feb 2002 15:00:20 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200202112000.PAA10901@devonshire.cnchost.com> To: "Tariq Rashid" Cc: freebsd-net@FreeBSD.ORG Subject: Re: squeeze more performance out of natd? In-reply-to: Your message of "Mon, 11 Feb 2002 16:53:54 GMT." Date: Mon, 11 Feb 2002 12:00:19 -0800 From: Bakul Shah Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > possible ideas: > > * is doing a select on 1000 file descriptors more efficient than having 10 > selects on 100 file descriptors? > > * what about diverting to multiple natd processes? > > * threading? are there any benefits at all in this scenario? Or write a translator from natd rules to ipnat rules. Doing three system calls and a couple of extra context switches costs a bunch. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 12:12:20 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d188.as6.nwbl0.wi.voyager.net [169.207.130.62]) by hub.freebsd.org (Postfix) with ESMTP id E0FB137B405 for ; Mon, 11 Feb 2002 12:12:16 -0800 (PST) Received: from localhost (silby@localhost) by patrocles.silby.com (8.11.6/8.11.6) with ESMTP id g1BEFxq85306; Mon, 11 Feb 2002 14:16:00 GMT (envelope-from silby@silby.com) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Mon, 11 Feb 2002 14:15:59 +0000 (GMT) From: Mike Silbersack To: Alfred Perlstein Cc: Tariq Rashid , Subject: Re: squeeze more performance out of natd? In-Reply-To: <20020211112645.F63886@elvis.mu.org> Message-ID: <20020211140933.Y84750-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 11 Feb 2002, Alfred Perlstein wrote: > * Mike Silbersack [020211 11:05] wrote: > > The best way to improve performance would probably be to rewrite natd to > > use kqueue instead of select. I'm not sure how difficult this would be, > > you might wish to talk to jlemon if you have any questions on the best way > > to tackle the project. > > That's what I thought initially, however the problem is that each > packet requires at least a select(2) then recvfrom(2) and then possibly > a sendto(2). The select(2) loop is particulary niave as the dispatched > functions will only pull one packet from the socket instead of looping > until the outstanding data is removed. > > Yes, > another way would be to loop doing recvfrom's until EAGAIN is returned, > I suspect this may give at least a 2 fold increase in performance and > is trivial to accomplish. Wow. Yeah, it sounds like that change would make more of a difference than moving away from select(). Tell us how it works, Tariq. :) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 17: 8:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 34C8537B404 for ; Mon, 11 Feb 2002 17:08:51 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1C18lD33422; Mon, 11 Feb 2002 17:08:47 -0800 (PST) (envelope-from rizzo) Date: Mon, 11 Feb 2002 17:08:47 -0800 From: Luigi Rizzo To: net@freebsd.org Subject: HEADS UP: upcoming change to net.link.ether.bridge_cfg handling Message-ID: <20020211170846.B32847@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, since i recently had a chance to do some fixes to the bridging code, in the next few days I am about to change the parsing of the sysctl variable net.link.ether.bridge_cfg. The variable was meant to contain the list of interfaces on which bridging was enabled, optionally following each interface with its cluster id. For reasons related to the handling of dynamically created interfaces (e.g. PCMCIA cards), at some point the code was changed so that each interface creation/deletion would rescan the list of interfaces, and overwrite "bridge_cfg" with a default configuration in which all ethernet interfaces become part of the same cluster. Obviously, this automatic override of an existing configuration is less than desirable, was almost surely an undesired side effect, and poses significant security problems which are just not acceptable. So, I am going to change the handling of "bridge_cfg" so that on interface creation/deletion the system will not change its value but just reinitialize bridging on all interfaces specified in that variable *and* still existing. Bridging on dynamically created interfaces (such as PC-CARD devices, or vlan) will be still possible, but you have to configure them explicitly. That also means that at boot time, the list of interfaces will be empty. This can be easily fixed by doing sysctl net.link.ether.bridge_cfg="`ifconfig -l`" in the rc* files, and I will make sure that this is the default in rc* files. Constructive complaints are welcome, but 100% backward compatibility is just not feasible. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 ----------------------------------+----------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 17:50:35 2002 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by hub.freebsd.org (Postfix) with ESMTP id 9CEE337B400 for ; Mon, 11 Feb 2002 17:50:32 -0800 (PST) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id g1C1oDn39260; Mon, 11 Feb 2002 20:50:13 -0500 (EST) (envelope-from barney) Date: Mon, 11 Feb 2002 20:50:13 -0500 From: Barney Wolff To: Luigi Rizzo Cc: net@FreeBSD.ORG Subject: Re: HEADS UP: upcoming change to net.link.ether.bridge_cfg handling Message-ID: <20020211205013.A39212@tp.databus.com> References: <20020211170846.B32847@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020211170846.B32847@iguana.icir.org>; from rizzo@icir.org on Mon, Feb 11, 2002 at 05:08:47PM -0800 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org How about the ability to list i'faces that should NOT bridge, and let all others bridge? Pattened after the traditional allow/deny lists of other things. People could then use whichever polarity made life easiest for their config. Barney Wolff On Mon, Feb 11, 2002 at 05:08:47PM -0800, Luigi Rizzo wrote: > > That also means that at boot time, the list of interfaces will be > empty. This can be easily fixed by doing > > sysctl net.link.ether.bridge_cfg="`ifconfig -l`" > > in the rc* files, and I will make sure that this is the default in > rc* files. > > Constructive complaints are welcome, but 100% backward compatibility > is just not feasible. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 17:58:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 451AA37B416 for ; Mon, 11 Feb 2002 17:58:50 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1C1wge33817; Mon, 11 Feb 2002 17:58:42 -0800 (PST) (envelope-from rizzo) Date: Mon, 11 Feb 2002 17:58:42 -0800 From: Luigi Rizzo To: Barney Wolff Cc: net@FreeBSD.ORG Subject: Re: HEADS UP: upcoming change to net.link.ether.bridge_cfg handling Message-ID: <20020211175842.C32847@iguana.icir.org> References: <20020211170846.B32847@iguana.icir.org> <20020211205013.A39212@tp.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020211205013.A39212@tp.databus.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Feb 11, 2002 at 08:50:13PM -0500, Barney Wolff wrote: > How about the ability to list i'faces that should NOT bridge, and > let all others bridge? Pattened after the traditional allow/deny > lists of other things. People could then use whichever polarity > made life easiest for their config. code please... luigi > Barney Wolff > > On Mon, Feb 11, 2002 at 05:08:47PM -0800, Luigi Rizzo wrote: > > > > That also means that at boot time, the list of interfaces will be > > empty. This can be easily fixed by doing > > > > sysctl net.link.ether.bridge_cfg="`ifconfig -l`" > > > > in the rc* files, and I will make sure that this is the default in > > rc* files. > > > > Constructive complaints are welcome, but 100% backward compatibility > > is just not feasible. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 23:40:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.19]) by hub.freebsd.org (Postfix) with ESMTP id 5DE9D37B404 for ; Mon, 11 Feb 2002 23:40:16 -0800 (PST) Received: from there (coffee.syncrontech.com [62.71.8.37]) by guinness.syncrontech.com (8.11.6/8.11.6) with SMTP id g1C6o7L40811; Tue, 12 Feb 2002 08:50:12 +0200 (EET) (envelope-from ari.suutari@syncrontech.com) Message-Id: <200202120650.g1C6o7L40811@guinness.syncrontech.com> Content-Type: text/plain; charset="iso-8859-1" From: Ari Suutari To: Mike Silbersack , Alfred Perlstein Subject: Re: squeeze more performance out of natd? Date: Tue, 12 Feb 2002 08:50:07 +0200 X-Mailer: KMail [version 1.3.2] Cc: Tariq Rashid , References: <20020211140933.Y84750-100000@patrocles.silby.com> In-Reply-To: <20020211140933.Y84750-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, On Monday 11 February 2002 16:15, Mike Silbersack wrote: > On Mon, 11 Feb 2002, Alfred Perlstein wrote: > > > another way would be to loop doing recvfrom's until EAGAIN is returned, > > I suspect this may give at least a 2 fold increase in performance and > > is trivial to accomplish. > > Wow. Yeah, it sounds like that change would make more of a difference > than moving away from select(). Tell us how it works, Tariq. :) > Natd doesn't use select if you use alias address instead of interface name. In this case there is just simple recvfrom - sendto loop. The select is there currently mostly to get information from routing socket which is needed on DHCP / PPP environments. There was also second purpose - to check space on output socket - but it has been found unnecessary recently and I think it was removed from -current, at least. Ari S. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Mon Feb 11 23:57:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 2773C37B725 for ; Mon, 11 Feb 2002 23:54:30 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 2387110DDF9; Mon, 11 Feb 2002 23:39:39 -0800 (PST) Date: Mon, 11 Feb 2002 23:39:39 -0800 From: Alfred Perlstein To: Ari Suutari Cc: Mike Silbersack , Tariq Rashid , freebsd-net@FreeBSD.ORG Subject: Re: squeeze more performance out of natd? Message-ID: <20020211233939.M63886@elvis.mu.org> References: <20020211140933.Y84750-100000@patrocles.silby.com> <200202120650.g1C6o7L40811@guinness.syncrontech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202120650.g1C6o7L40811@guinness.syncrontech.com>; from ari.suutari@syncrontech.com on Tue, Feb 12, 2002 at 08:50:07AM +0200 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Ari Suutari [020211 22:50] wrote: > Hi, > > > On Monday 11 February 2002 16:15, Mike Silbersack wrote: > > On Mon, 11 Feb 2002, Alfred Perlstein wrote: > > > > > another way would be to loop doing recvfrom's until EAGAIN is returned, > > > I suspect this may give at least a 2 fold increase in performance and > > > is trivial to accomplish. > > > > Wow. Yeah, it sounds like that change would make more of a difference > > than moving away from select(). Tell us how it works, Tariq. :) > > > > Natd doesn't use select if you use alias address instead of interface > name. In this case there is just simple recvfrom - sendto loop. Yes, that looks right, still, that case probably doesn't perform all that well at all and could be improved. > The select is there currently mostly to get information from routing > socket which is needed on DHCP / PPP environments. There > was also second purpose - to check space on output socket - > but it has been found unnecessary recently and I think it > was removed from -current, at least. I guess then it looks like natd really either wants batch-recvfrom/sendto or to be moved into the kernel for higher performance. -- -Alfred Perlstein [alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 12 1: 5:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from hale.inty.net (hale.inty.net [195.92.21.144]) by hub.freebsd.org (Postfix) with ESMTP id 963B937B435 for ; Tue, 12 Feb 2002 01:05:01 -0800 (PST) Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150]) by hale.inty.net (8.11.3/8.11.3) with ESMTP id g1C91cR79814 for ; Tue, 12 Feb 2002 09:01:39 GMT Received: from tariq ([10.0.1.156]) by inty.hq.inty.net (8.12.1/8.12.1) with SMTP id g1C91ZYl037547 for ; Tue, 12 Feb 2002 09:01:36 GMT From: "Tariq Rashid" To: Subject: RE: squeeze more performance out of natd? Date: Tue, 12 Feb 2002 09:04:40 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020211233939.M63886@elvis.mu.org> X-Sender-IP: 10.0.1.156 X-INT-DeliveryDone: g1C91ZYl037547 X-suppress-rcpt-virus-notify: yes X-Skip-Virus-Check: yes X-Virus-Checked: 53454 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org thanks for the suggestions, ideas and info everyone... i'll start by looking more closely at the source code and looking at what kqueue and kevents actually are (!) before i dive in and change natd. (for all those who suggested ipf/ipnat - yes i know, but unfortunately natd if part of a bigger product which would have to be rewritten - i did think that there would'nt be a problem with doing the NATing in ipnat and the firewalling in ipfw but i understand that ipnat is done _before_ ipfw sees that packets (which makes sense) and this is the wrong way around for us) i'll let you all know how i get on - and post any difficult questions again - thanks tariq intY has automatically scanned this email with Sophos Anti-Virus (www.inty.net) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 12 5:52:34 2002 Delivered-To: freebsd-net@freebsd.org Received: from host185.dolanmedia.com (host185.dolanmedia.com [209.98.197.185]) by hub.freebsd.org (Postfix) with SMTP id 867C837B41E for ; Tue, 12 Feb 2002 05:52:30 -0800 (PST) Received: (qmail 47262 invoked by uid 0); 12 Feb 2002 13:43:36 -0000 Received: from greg.panula@dolaninformation.com by proxy with qmail-scanner-0.96 (. Clean. Processed in 0.334861 secs); 12 Feb 2002 13:43:36 -0000 X-Qmail-Scanner-Mail-From: greg.panula@dolaninformation.com via proxy X-Qmail-Scanner-Rcpt-To: rizzo@icir.org,net@freebsd.org X-Qmail-Scanner: 0.96 (No viruses found. Processed in 0.334861 secs) Received: from mail.dolanmedia.com (10.1.1.23) by proxy.dolanmedia.com with SMTP; 12 Feb 2002 13:43:35 -0000 Received: from dolaninformation.com (10.1.1.135) by mail.dolanmedia.com (Worldmail 1.3.167); 12 Feb 2002 07:43:35 -0600 Message-ID: <3C691C07.7A7A0BFE@dolaninformation.com> Date: Tue, 12 Feb 2002 07:43:35 -0600 From: Greg Panula Reply-To: greg.panula@dolaninformation.com Organization: Dolan Information Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: net@freebsd.org Subject: Re: HEADS UP: device polling code merged into -stable References: <20020209170804.C13970@iguana.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo wrote: > > [Bcc to -stable as relevant there] > > I have merged into -stable the device polling code that has > been in -current for the past couple of months, plus a minor > change that addresses the 'device going deaf' problems that > some have reported with early patches of this code. > > I'd be grateful if you could stress-test this code and > report problems (if any) or success. Remember that > only 'dc' 'fxp' and 'sis' drivers are supported at the moment. > > See you at BSDCon for those who will be here. > > cheers > luigi > ----------------------------------+----------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) > http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 > Phone: (510) 666 2927 > ----------------------------------+----------------------------------------- I still get watchdog time-outs with the dc driver when I use a SMP kernel. Hardware platform: Compaq DL360 with dual-cpus NIC: D-Link's DFE570TX (4-port nic, chipset Intel 21143) cvsup'd the src tree this morning(~2am CST), build a fresh world & kernels and installed them. When I use a non-smp kernel the dc driver & nic work fine. Initially reported to freebsd-stable. You can view the original post at: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=252043+0+archive/2002/freebsd-stable/20020210.freebsd-stable I tried using the de driver for the nic(apparently fbsd-3.x uses that driver for those nics) but couldn't get any connectivity with either kernel(smp or non-smp). I'll try to find some time tonight to test the through-put of the D-Link card and let you know if I see any other oddities. Suggestions, comments, or ideas, please let me know. Thanks, Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 12 8:28:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 60F1337B428 for ; Tue, 12 Feb 2002 08:28:49 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1CGNta38701; Tue, 12 Feb 2002 08:23:55 -0800 (PST) (envelope-from rizzo) Date: Tue, 12 Feb 2002 08:23:55 -0800 From: Luigi Rizzo To: Greg Panula Cc: net@FreeBSD.ORG Subject: Re: HEADS UP: device polling code merged into -stable Message-ID: <20020212082355.A38657@iguana.icir.org> References: <20020209170804.C13970@iguana.icir.org> <3C691C07.7A7A0BFE@dolaninformation.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C691C07.7A7A0BFE@dolaninformation.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Feb 12, 2002 at 07:43:35AM -0600, Greg Panula wrote: > I still get watchdog time-outs with the dc driver when I use a SMP kernel. > Hardware platform: Compaq DL360 with dual-cpus > NIC: D-Link's DFE570TX (4-port nic, chipset Intel 21143) > > cvsup'd the src tree this morning(~2am CST), build a fresh world & kernels > and installed them. > > When I use a non-smp kernel the dc driver & nic work fine. certainly this is unrelated to device polling, as it does not even compile with SMP, and the driver is the same for smp and non-smp. It might be something related to the dispatching of interrupts on your box ? cheers luigi > Initially reported to freebsd-stable. You can view the original post at: > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=252043+0+archive/2002/freebsd-stable/20020210.freebsd-stable > > I tried using the de driver for the nic(apparently fbsd-3.x uses that driver > for those nics) but couldn't get any connectivity with either kernel(smp or > non-smp). > > I'll try to find some time tonight to test the through-put of the D-Link > card and let you know if I see any other oddities. > > Suggestions, comments, or ideas, please let me know. > > Thanks, > Greg > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 12 9:34:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from hotmail.com (f158.pav2.hotmail.com [64.4.37.158]) by hub.freebsd.org (Postfix) with ESMTP id 6EC9137B41B for ; Tue, 12 Feb 2002 09:34:21 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 12 Feb 2002 09:30:51 -0800 Received: from 204.178.20.13 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 12 Feb 2002 17:30:51 GMT X-Originating-IP: [204.178.20.13] From: "murthy kn" To: net@freebsd.org Subject: ~40 DupAcks And No Fast Retransmit !! Date: Tue, 12 Feb 2002 23:00:51 +0530 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Feb 2002 17:30:51.0528 (UTC) FILETIME=[0461A880:01C1B3EB] Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello all, I am using 4.3 BSD and from the below capture, I feel that there is some problem with the Fast Retransmit (unless I am missing something). I also recall that there was a short thread about some problems with Fast Retransmit earlier in Nov 2001 - that sender was resorting to the costly Retransmission timeout even after receiving many DupAcks. 1. Currently, I am not very sure if what is seen in the below traces is same as the above thread and I would like to get your opinion on that. 2. If so, is there any patch available for 4.3, or if somebody has already corrected it in 4.3, it will be helpful to give some suggestion on how to correct this. Thanks, Murthy --------------------------------------------- Test Bed and Some Configuration Variables : 1. 3 Isolated 4.3 Machines _______ sender -|_______ |- Router ---------- Receiver (Aggregated Pair of Links) 2.Fast Retransmission Threshold set to 1 (to increase the chances of Fast Retransmission) 3. No Dupacks 4. Send and Receive Windows 65536 -------------------------------------------- Trace at the sender 10:58:28.850500 10.10.10.1.1094 > 10.10.10.2.5001: S 3783794163:3783794163(0) win 65535 (DF) 10:58:28.850922 10.10.10.2.5001 > 10.10.10.1.1094: S 3608498642:3608498642(0) ack 3783794164 win 65535 (DF) 10:58:28.850983 10.10.10.1.1094 > 10.10.10.2.5001: . ack 3608498643 win 33304 (DF) 10:58:28.858138 10.10.10.1.1094 > 10.10.10.2.5001: . 3783794164:3783795612(1448) ack 3608498643 win 33304 (DF) 10:58:28.858944 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783795612 win 32580 (DF) 10:58:28.858997 10.10.10.1.1094 > 10.10.10.2.5001: . 3783795612:3783797060(1448) ack 3608498643 win 33304 (DF) 10:58:28.859016 10.10.10.1.1094 > 10.10.10.2.5001: . 3783797060:3783798508(1448) ack 3608498643 win 33304 (DF) 10:58:28.859814 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783797060 win 32580 (DF) 10:58:28.859863 10.10.10.1.1094 > 10.10.10.2.5001: . 3783798508:3783799956(1448) ack 3608498643 win 33304 (DF) 10:58:28.859885 10.10.10.1.1094 > 10.10.10.2.5001: . 3783799956:3783801404(1448) ack 3608498643 win 33304 (DF) 10:58:28.859941 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783798508 win 32580 (DF) 10:58:28.859980 10.10.10.1.1094 > 10.10.10.2.5001: . 3783801404:3783802852(1448) ack 3608498643 win 33304 (DF) -----> Segment of Interest Transmitted first time 10:58:28.859998 10.10.10.1.1094 > 10.10.10.2.5001: . 3783802852:3783804300(1448) ack 3608498643 win 33304 (DF) 10:58:28.860814 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783799956 win 32580 (DF) 10:58:28.860823 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783801404 win 32580 (DF) 10:58:28.860855 10.10.10.1.1094 > 10.10.10.2.5001: . 3783804300:3783805748(1448) ack 3608498643 win 33304 (DF) 10:58:28.860874 10.10.10.1.1094 > 10.10.10.2.5001: . 3783805748:3783807196(1448) ack 3608498643 win 33304 (DF) 10:58:28.860908 10.10.10.1.1094 > 10.10.10.2.5001: . 3783807196:3783808644(1448) ack 3608498643 win 33304 (DF) 10:58:28.860931 10.10.10.1.1094 > 10.10.10.2.5001: . 3783808644:3783810092(1448) ack 3608498643 win 33304 (DF) 10:58:28.860950 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 32580 (DF) 10:58:28.860992 10.10.10.1.1094 > 10.10.10.2.5001: . 3783810092:3783811540(1448) ack 3608498643 win 33304 (DF) 10:58:28.861007 10.10.10.1.1094 > 10.10.10.2.5001: . 3783811540:3783812988(1448) ack 3608498643 win 33304 (DF) 10:58:28.862060 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) ----------> Start of the DupAcks (Seq 3783802852) Why is the Win advertised the same in all the Dup Acks - AFAIK, Dup Ack is generated for Each Out of order packet received and hence the Win size should decrease - as these packets cannot be delivered to the application till the right packet is received?? 10:58:28.862081 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.862117 10.10.10.1.1094 > 10.10.10.2.5001: . 3783812988:3783814436(1448) ack 3608498643 win 33304 (DF) 10:58:28.862127 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.862156 10.10.10.1.1094 > 10.10.10.2.5001: . 3783814436:3783815884(1448) ack 3608498643 win 33304 (DF) 10:58:28.862907 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.862934 10.10.10.1.1094 > 10.10.10.2.5001: . 3783815884:3783817332(1448) ack 3608498643 win 33304 (DF) 10:58:28.863023 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.863051 10.10.10.1.1094 > 10.10.10.2.5001: . 3783817332:3783818780(1448) ack 3608498643 win 33304 (DF) 10:58:28.863720 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.863746 10.10.10.1.1094 > 10.10.10.2.5001: . 3783818780:3783820228(1448) ack 3608498643 win 33304 (DF) 10:58:28.863840 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.863867 10.10.10.1.1094 > 10.10.10.2.5001: . 3783820228:3783821676(1448) ack 3608498643 win 33304 (DF) 10:58:28.864534 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.864560 10.10.10.1.1094 > 10.10.10.2.5001: . 3783821676:3783823124(1448) ack 3608498643 win 33304 (DF) 10:58:28.864650 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.864678 10.10.10.1.1094 > 10.10.10.2.5001: . 3783823124:3783824572(1448) ack 3608498643 win 33304 (DF) 10:58:28.865347 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.865374 10.10.10.1.1094 > 10.10.10.2.5001: . 3783824572:3783826020(1448) ack 3608498643 win 33304 (DF) 10:58:28.865466 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.865571 10.10.10.1.1094 > 10.10.10.2.5001: . 3783826020:3783827468(1448) ack 3608498643 win 33304 (DF) 10:58:28.866167 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.866195 10.10.10.1.1094 > 10.10.10.2.5001: . 3783827468:3783828916(1448) ack 3608498643 win 33304 (DF) 10:58:28.866349 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.866378 10.10.10.1.1094 > 10.10.10.2.5001: . 3783828916:3783830364(1448) ack 3608498643 win 33304 (DF) 10:58:28.866972 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.867000 10.10.10.1.1094 > 10.10.10.2.5001: . 3783830364:3783831812(1448) ack 3608498643 win 33304 (DF) 10:58:28.867154 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.867183 10.10.10.1.1094 > 10.10.10.2.5001: . 3783831812:3783833260(1448) ack 3608498643 win 33304 (DF) 10:58:28.867778 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.867806 10.10.10.1.1094 > 10.10.10.2.5001: . 3783833260:3783834708(1448) ack 3608498643 win 33304 (DF) 10:58:28.867959 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.867986 10.10.10.1.1094 > 10.10.10.2.5001: . 3783834708:3783836156(1448) ack 3608498643 win 33304 (DF) 10:58:28.868586 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.868613 10.10.10.1.1094 > 10.10.10.2.5001: . 3783836156:3783837604(1448) ack 3608498643 win 33304 (DF) 10:58:28.868765 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.868794 10.10.10.1.1094 > 10.10.10.2.5001: . 3783837604:3783839052(1448) ack 3608498643 win 33304 (DF) 10:58:28.869393 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.869419 10.10.10.1.1094 > 10.10.10.2.5001: . 3783839052:3783840500(1448) ack 3608498643 win 33304 (DF) 10:58:28.869572 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.869600 10.10.10.1.1094 > 10.10.10.2.5001: . 3783840500:3783841948(1448) ack 3608498643 win 33304 (DF) 10:58:28.870197 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.870226 10.10.10.1.1094 > 10.10.10.2.5001: . 3783841948:3783843396(1448) ack 3608498643 win 33304 (DF) 10:58:28.870375 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.870403 10.10.10.1.1094 > 10.10.10.2.5001: . 3783843396:3783844844(1448) ack 3608498643 win 33304 (DF) 10:58:28.871005 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.871033 10.10.10.1.1094 > 10.10.10.2.5001: . 3783844844:3783846292(1448) ack 3608498643 win 33304 (DF) 10:58:28.871179 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.871208 10.10.10.1.1094 > 10.10.10.2.5001: . 3783846292:3783847740(1448) ack 3608498643 win 33304 (DF) 10:58:28.871809 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.871835 10.10.10.1.1094 > 10.10.10.2.5001: . 3783847740:3783849188(1448) ack 3608498643 win 33304 (DF) 10:58:28.871986 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.872015 10.10.10.1.1094 > 10.10.10.2.5001: . 3783849188:3783850636(1448) ack 3608498643 win 33304 (DF) 10:58:28.872611 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.872641 10.10.10.1.1094 > 10.10.10.2.5001: . 3783850636:3783852084(1448) ack 3608498643 win 33304 (DF) 10:58:28.872794 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.872821 10.10.10.1.1094 > 10.10.10.2.5001: . 3783852084:3783853532(1448) ack 3608498643 win 33304 (DF) 10:58:28.873421 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.873449 10.10.10.1.1094 > 10.10.10.2.5001: . 3783853532:3783854980(1448) ack 3608498643 win 33304 (DF) 10:58:28.873598 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.873628 10.10.10.1.1094 > 10.10.10.2.5001: . 3783854980:3783856428(1448) ack 3608498643 win 33304 (DF) 10:58:28.874226 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.874256 10.10.10.1.1094 > 10.10.10.2.5001: . 3783856428:3783857876(1448) ack 3608498643 win 33304 (DF) 10:58:28.874403 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.874432 10.10.10.1.1094 > 10.10.10.2.5001: . 3783857876:3783859324(1448) ack 3608498643 win 33304 (DF) 10:58:28.875044 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.875069 10.10.10.1.1094 > 10.10.10.2.5001: FP 378859324:3783859700(376) ack 3608498643 win 33304 (DF) 10:58:28.875212 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:28.875479 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 10:58:29.855425 10.10.10.1.1094 > 10.10.10.2.5001: . -----------> Segment of interest Retransmitted aftere a "Long" time 3783802852:3783804300(1448) ack 3608498643 win 33304 (DF) -------> ACk updated to reflect the reception of this "long pending" segment !! 10:58:29.856258 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783808644 win 30408 (DF) 10:58:29.856299 10.10.10.1.1094 > 10.10.10.2.5001: . 3783808644:3783810092(1448) ack 3608498643 win 33304 (DF) 10:58:29.856317 10.10.10.1.1094 > 10.10.10.2.5001: . 3783810092:3783811540(1448) ack 3608498643 win 33304 (DF) 10:58:29.856356 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783808644 win 33304 (DF) 10:58:29.857102 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783810092 win 32580 (DF) 10:58:29.857130 10.10.10.1.1094 > 10.10.10.2.5001: . 3783811540:3783812988(1448) ack 3608498643 win 33304 (DF) 10:58:29.857146 10.10.10.1.1094 > 10.10.10.2.5001: . 3783812988:3783814436(1448) ack 3608498643 win 33304 (DF) 10:58:29.857223 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783811540 win 32580 (DF) 10:58:29.857254 10.10.10.1.1094 > 10.10.10.2.5001: . 3783814436:3783815884(1448) ack 3608498643 win 33304 (DF) 10:58:29.857271 10.10.10.1.1094 > 10.10.10.2.5001: . 3783815884:3783817332(1448) ack 3608498643 win 33304 (DF) 10:58:29.858072 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783859701 win 9224 (DF) 10:58:29.858109 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783859701 win 11396 (DF) 10:58:29.858184 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783859701 win 15016 (DF) 10:58:29.858303 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783859701 win 18636 (DF) 10:58:29.858568 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783859701 win 33304 (DF) 10:58:29.859019 10.10.10.2.5001 > 10.10.10.1.1094: F 3608498643:3608498643(0) ack 3783859701 win 33304 (DF) 10:58:29.859051 10.10.10.1.1094 > 10.10.10.2.5001: . ack 3608498644 win 33304 (DF) ---------------------------------------------------- Trace at the receiver 09:40:40.012547 10.10.10.1.1094 > 10.10.10.2.5001: S 3783794163:3783794163(0) win 65535 (DF) 09:40:40.012667 10.10.10.2.5001 > 10.10.10.1.1094: S 3608498642:3608498642(0) ack 3783794164 win 65535 (DF) 09:40:40.012994 10.10.10.1.1094 > 10.10.10.2.5001: . ack 3608498643 win 33304 (DF) 09:40:40.020649 10.10.10.1.1094 > 10.10.10.2.5001: . 3783794164:3783795612(1448) ack 3608498643 win 33304 (DF) 09:40:40.020700 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783795612 win 32580 (DF) 09:40:40.021517 10.10.10.1.1094 > 10.10.10.2.5001: . 3783795612:3783797060(1448) ack 3608498643 win 33304 (DF) 09:40:40.021562 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783797060 win 32580 (DF) 09:40:40.021639 10.10.10.1.1094 > 10.10.10.2.5001: . 3783797060:3783798508(1448) ack 3608498643 win 33304 (DF) 09:40:40.021677 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783798508 win 32580 (DF) 09:40:40.022386 10.10.10.1.1094 > 10.10.10.2.5001: . 3783798508:3783799956(1448) ack 3608498643 win 33304 (DF) 09:40:40.022427 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783799956 win 32580 (DF) 09:40:40.022510 10.10.10.1.1094 > 10.10.10.2.5001: . 3783799956:3783801404(1448) ack 3608498643 win 33304 (DF) 09:40:40.022549 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783801404 win 32580 (DF) 09:40:40.022633 10.10.10.1.1094 > 10.10.10.2.5001: . 3783801404:3783802852(1448) ack 3608498643 win 33304 (DF) 09:40:40.022670 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 32580 (DF) 09:40:40.023379 10.10.10.1.1094 > 10.10.10.2.5001: . 3783804300:3783805748(1448) ack 3608498643 win 33304 (DF) 09:40:40.023418 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) -----------> DupAcks generated by receiver 09:40:40.023502 10.10.10.1.1094 > 10.10.10.2.5001: . 3783805748:3783807196(1448) ack 3608498643 win 33304 (DF) 09:40:40.023535 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.023628 10.10.10.1.1094 > 10.10.10.2.5001: . 3783807196:3783808644(1448) ack 3608498643 win 33304 (DF) 09:40:40.023661 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.024632 10.10.10.1.1094 > 10.10.10.2.5001: . 3783812988:3783814436(1448) ack 3608498643 win 33304 (DF) 09:40:40.024667 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.024753 10.10.10.1.1094 > 10.10.10.2.5001: . 3783814436:3783815884(1448) ack 3608498643 win 33304 (DF) 09:40:40.024785 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.025445 10.10.10.1.1094 > 10.10.10.2.5001: . 3783815884:3783817332(1448) ack 3608498643 win 33304 (DF) 09:40:40.025479 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.025568 10.10.10.1.1094 > 10.10.10.2.5001: . 3783817332:3783818780(1448) ack 3608498643 win 33304 (DF) 09:40:40.025600 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.026259 10.10.10.1.1094 > 10.10.10.2.5001: . 3783818780:3783820228(1448) ack 3608498643 win 33304 (DF) 09:40:40.026294 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.026380 10.10.10.1.1094 > 10.10.10.2.5001: . 3783820228:3783821676(1448) ack 3608498643 win 33304 (DF) 09:40:40.026411 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.027073 10.10.10.1.1094 > 10.10.10.2.5001: . 3783821676:3783823124(1448) ack 3608498643 win 33304 (DF) 09:40:40.027106 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.027194 10.10.10.1.1094 > 10.10.10.2.5001: . 3783823124:3783824572(1448) ack 3608498643 win 33304 (DF) 09:40:40.027226 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.027894 10.10.10.1.1094 > 10.10.10.2.5001: . 3783824572:3783826020(1448) ack 3608498643 win 33304 (DF) 09:40:40.027927 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.028075 10.10.10.1.1094 > 10.10.10.2.5001: . 3783826020:3783827468(1448) ack 3608498643 win 33304 (DF) 09:40:40.028109 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.028700 10.10.10.1.1094 > 10.10.10.2.5001: . 3783827468:3783828916(1448) ack 3608498643 win 33304 (DF) 09:40:40.028732 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.028884 10.10.10.1.1094 > 10.10.10.2.5001: . 3783828916:3783830364(1448) ack 3608498643 win 33304 (DF) 09:40:40.028917 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.029505 10.10.10.1.1094 > 10.10.10.2.5001: . 3783830364:3783831812(1448) ack 3608498643 win 33304 (DF) 09:40:40.029538 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.029687 10.10.10.1.1094 > 10.10.10.2.5001: . 3783831812:3783833260(1448) ack 3608498643 win 33304 (DF) 09:40:40.029719 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.030309 10.10.10.1.1094 > 10.10.10.2.5001: . 3783833260:3783834708(1448) ack 3608498643 win 33304 (DF) 09:40:40.030346 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.030492 10.10.10.1.1094 > 10.10.10.2.5001: . 3783834708:3783836156(1448) ack 3608498643 win 33304 (DF) 09:40:40.030525 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.031118 10.10.10.1.1094 > 10.10.10.2.5001: . 3783836156:3783837604(1448) ack 3608498643 win 33304 (DF) 09:40:40.031153 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.031298 10.10.10.1.1094 > 10.10.10.2.5001: . 3783837604:3783839052(1448) ack 3608498643 win 33304 (DF) 09:40:40.031330 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.031925 10.10.10.1.1094 > 10.10.10.2.5001: . 3783839052:3783840500(1448) ack 3608498643 win 33304 (DF) 09:40:40.031957 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.032103 10.10.10.1.1094 > 10.10.10.2.5001: . 3783840500:3783841948(1448) ack 3608498643 win 33304 (DF) 09:40:40.032137 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.032730 10.10.10.1.1094 > 10.10.10.2.5001: . 3783841948:3783843396(1448) ack 3608498643 win 33304 (DF) 09:40:40.032763 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.032906 10.10.10.1.1094 > 10.10.10.2.5001: . 3783843396:3783844844(1448) ack 3608498643 win 33304 (DF) 09:40:40.032939 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.033535 10.10.10.1.1094 > 10.10.10.2.5001: . 3783844844:3783846292(1448) ack 3608498643 win 33304 (DF) 09:40:40.033570 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.033712 10.10.10.1.1094 > 10.10.10.2.5001: . 3783846292:3783847740(1448) ack 3608498643 win 33304 (DF) 09:40:40.033746 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.034339 10.10.10.1.1094 > 10.10.10.2.5001: . 3783847740:3783849188(1448) ack 3608498643 win 33304 (DF) 09:40:40.034371 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.034521 10.10.10.1.1094 > 10.10.10.2.5001: . 3783849188:3783850636(1448) ack 3608498643 win 33304 (DF) 09:40:40.034553 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.035148 10.10.10.1.1094 > 10.10.10.2.5001: . 3783850636:3783852084(1448) ack 3608498643 win 33304 (DF) 09:40:40.035181 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.035326 10.10.10.1.1094 > 10.10.10.2.5001: . 3783852084:3783853532(1448) ack 3608498643 win 33304 (DF) 09:40:40.035358 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.035953 10.10.10.1.1094 > 10.10.10.2.5001: . 3783853532:3783854980(1448) ack 3608498643 win 33304 (DF) 09:40:40.035987 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.036130 10.10.10.1.1094 > 10.10.10.2.5001: . 3783854980:3783856428(1448) ack 3608498643 win 33304 (DF) 09:40:40.036164 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.036770 10.10.10.1.1094 > 10.10.10.2.5001: . 3783856428:3783857876(1448) ack 3608498643 win 33304 (DF) 09:40:40.036802 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.036936 10.10.10.1.1094 > 10.10.10.2.5001: . 3783857876:3783859324(1448) ack 3608498643 win 33304 (DF) 09:40:40.036969 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:40.037211 10.10.10.1.1094 > 10.10.10.2.5001: FP 3783859324:3783859700(376) ack 3608498643 win 33304 (DF) 09:40:40.037241 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783802852 win 33304 (DF) 09:40:41.017883 10.10.10.1.1094 > 10.10.10.2.5001: . -----------> The packet seems to have "lost" somehow during its first transmission and the receiver is seeing it during only retransmission ! 3783802852:3783804300(1448) ack 3608498643 win 33304 (DF) 09:40:41.017939 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783808644 win 30408 (DF) 09:40:41.018019 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783808644 win 33304 (DF) 09:40:41.018739 10.10.10.1.1094 > 10.10.10.2.5001: . 3783808644:3783810092(1448) ack 3608498643 win 33304 (DF) 09:40:41.018785 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783810092 win 32580 (DF) 09:40:41.018862 10.10.10.1.1094 > 10.10.10.2.5001: . 3783810092:3783811540(1448) ack 3608498643 win 33304 (DF) 09:40:41.018905 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783811540 win 32580 (DF) 09:40:41.019576 10.10.10.1.1094 > 10.10.10.2.5001: . 3783811540:3783812988(1448) ack 3608498643 win 33304 (DF) 09:40:41.019656 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783859701 win 9224 (DF) 09:40:41.019698 10.10.10.1.1094 > 10.10.10.2.5001: . 3783812988:3783814436(1448) ack 3608498643 win 33304 (DF) 09:40:41.019738 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783859701 win 11396 (DF) 09:40:41.019824 10.10.10.1.1094 > 10.10.10.2.5001: . 3783814436:3783815884(1448) ack 3608498643 win 33304 (DF) 09:40:41.019868 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783859701 win 15016 (DF) 09:40:41.019946 10.10.10.1.1094 > 10.10.10.2.5001: . 3783815884:3783817332(1448) ack 3608498643 win 33304 (DF) 09:40:41.019988 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783859701 win 18636 (DF) 09:40:41.020255 10.10.10.2.5001 > 10.10.10.1.1094: . ack 3783859701 win 33304 (DF) 09:40:41.020705 10.10.10.2.5001 > 10.10.10.1.1094: F 3608498643:3608498643(0) ack 3783859701 win 33304 (DF) 09:40:41.020983 10.10.10.1.1094 > 10.10.10.2.5001: . ack 3608498644 win 33304 (DF) ------------------------------------------------------------ _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 12 11:17: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.marketwatchmail.com (mail.marketwatchmail.com [206.146.143.85]) by hub.freebsd.org (Postfix) with SMTP id 9F60837B402 for ; Tue, 12 Feb 2002 11:16:57 -0800 (PST) Received: (qmail 7270 invoked from network); 12 Feb 2002 20:00:52 -0000 Received: from unknown (HELO jaustadw2k) (206.147.106.71) by mail.marketwatchmail.com with SMTP; 12 Feb 2002 20:00:52 -0000 From: "Jay Austad" To: Subject: gif0 tunnel and rip (using zebra) Date: Tue, 12 Feb 2002 13:13:51 -0600 Message-ID: <54180709DD3FE145917BB165AFE7EFA002E0D4A3@mspexch2.office.mktw.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm trying to propagate rip routes using zebra (ripd) across a gif0 tunnel interface to another freebsd box running zebra. I have zebra and ripd running, but they only seem to broadcast routes out the fxp0 interface, and not across the gif0 tunnel. It's quite annoying. A "show ip protocols" in the ripd vty shows that both fxp0 and gif0 are sending and receiving RIP updates. However tcpdump shows otherwise. I really don't need to use zebra, but I'd like to. Otherwise, if someone can help me with a gated config which completely excludes fxp1, does not broadcast a default route, and only broadcasts and accepts routes on the fxp0 and gif0 interfaces, I would gladly use that. The endpoints on the gif0 tunnel are tied down to addresses assigned to the lo1 interface on each side. Should I tie these down to the addresses assigned to fxp0 instead? When I did it this way, traceroute would not work across the tunnel. Also, does FreeBSD 4.5 support GRE tunnels? Thanks. Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 12 12: 5:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from sonic.kks.net (sonic.kks.net [213.161.0.18]) by hub.freebsd.org (Postfix) with ESMTP id 2FAE937B41B for ; Tue, 12 Feb 2002 12:05:54 -0800 (PST) Received: from voyager.kksonline.com (5-51.ro.cable.kks.net [213.161.5.51]) by sonic.kks.net (Postfix) with ESMTP id 584CC1B7 for ; Tue, 12 Feb 2002 20:25:57 +0100 (CET) Message-Id: <5.0.2.1.0.20020212201851.06699610@164.8.8.5> X-Sender: rozmanal@164.8.8.5 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 12 Feb 2002 20:22:18 +0100 To: freebsd-net@freebsd.org From: Aleksander Rozman - Andy Subject: socket options (struct sockopt) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi ! I am working on implementation of AX.25 on fbsd (as you probably already know)... I need to know how to create socket options (for use with xxx_ctlinput, xxx_ctloutput, getsockopt, setsockopt)? In which part of code could I see how socket options are created... Andy ************************************************************************** * Aleksander Rozman - Andy * Fandoms: E2:EA, SAABer, Trekkie, Earthie * * andy@kksonline.com * Sentinel, BH 90210, True's Trooper, * * andy@atechnet.dhs.org * Heller's Angel, Questie, Legacy, PO5, * * Maribor, Slovenia (Europe) * Profiler, Buffy (Slayerete), Pretender * * ICQ-UIC: 4911125 ********************************************* * PGP key available * http://www.atechnet.dhs.org/~andy/ * ************************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Tue Feb 12 17:43:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from overlord.e-gerbil.net (e-gerbil.net [207.91.110.247]) by hub.freebsd.org (Postfix) with ESMTP id 9FC5037B402 for ; Tue, 12 Feb 2002 17:43:26 -0800 (PST) Received: by overlord.e-gerbil.net (Postfix, from userid 1001) id D62F2E5008; Mon, 11 Feb 2002 16:30:15 -0500 (EST) Date: Mon, 11 Feb 2002 16:30:15 -0500 From: Richard A Steenbergen To: Alfred Perlstein Cc: freebsd-net@FreeBSD.ORG Subject: Re: squeeze more performance out of natd? Message-ID: <20020211213015.GO90229@overlord.e-gerbil.net> References: <20020211130512.S84750-100000@patrocles.silby.com> <20020211112645.F63886@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020211112645.F63886@elvis.mu.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Feb 11, 2002 at 11:26:45AM -0800, Alfred Perlstein wrote: > failing that, there's always moving it into the kernel where the perf > would most likely get better by several orders of magnitude by avoiding > copies and userspace/kernel context switching. Of course copying the entire packet in and out for nat is very stupid. But in theory, keeping the decision making in userland would allow for easier implementation of more powerful nat tools (ex: per-flow nat load balancing, etc). Perhaps it would be more useful to retain some userland part, but only pass the layer 3/4 headers around. Or perhaps it should be entirely kernel based for simple NAT, but with a hook for a userland program that could snarf the headers and make decisions if needed/wanted. -- Richard A Steenbergen http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 13 1:14:36 2002 Delivered-To: freebsd-net@freebsd.org Received: from freddy.inty.net (freddy.inty.net [195.224.93.243]) by hub.freebsd.org (Postfix) with ESMTP id 3492B37B402 for ; Wed, 13 Feb 2002 01:14:18 -0800 (PST) Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150]) by freddy.inty.net (8.11.3/8.11.3) with ESMTP id g1D9EE323030 for ; Wed, 13 Feb 2002 09:14:14 GMT Received: from tariq ([10.0.1.156]) by inty.hq.inty.net (8.12.1/8.12.1) with SMTP id g1D9EEYl021757 for ; Wed, 13 Feb 2002 09:14:14 GMT From: "Tariq Rashid" To: Subject: RE: squeeze more performance out of natd? Date: Wed, 13 Feb 2002 09:17:25 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020211213015.GO90229@overlord.e-gerbil.net> X-Sender-IP: 10.0.1.156 X-INT-DeliveryDone: g1D9EEYl021757 X-suppress-rcpt-virus-notify: yes X-Skip-Virus-Check: yes X-Virus-Checked: 53454 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org i tried altering the code to do teh following: 1. when select returns saying the file descriptor is readable: 2. process 2 packets at a time (recvfrom woould just fail if there were none left) 3. try this with 3 and 5 packets at a time Surprisingly (for me) I noticed * the natd CPU load still reaches similar levels before the change * using -a alias_ip instead if -interface and using debugging code to ensure that select was NOT used (as mentioned by ari, earlier) also appears not to significantly reduce CPU (eg peak 23% down to peak 21%) Considering the following facts: * cpu load rises roughly linearly with "number of connections to a single dest port" * cpu load rises more than linearly with "number of dest ports" makes me think that the problem is in libalias... investigations are ongoing - any ideas / advice would be great as i'm not an expert. i'll let you know how it goes tariq intY has automatically scanned this email with Sophos Anti-Virus (www.inty.net) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Wed Feb 13 2: 7:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.nsu.ru (mx.nsu.ru [193.124.215.71]) by hub.freebsd.org (Postfix) with ESMTP id A029137B405 for ; Wed, 13 Feb 2002 02:07:21 -0800 (PST) Received: from iclub.nsu.ru ([193.124.215.97] ident=root) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 16awJl-00082I-00 for freebsd-net@freebsd.org; Wed, 13 Feb 2002 16:07:13 +0600 Received: (from fjoe@localhost) by iclub.nsu.ru (8.11.6/8.11.6) id g1DA7Cs91728 for freebsd-net@freebsd.org; Wed, 13 Feb 2002 16:07:12 +0600 (NS) (envelope-from fjoe) Date: Wed, 13 Feb 2002 16:07:12 +0600 From: Max Khon To: freebsd-net@freebsd.org Subject: soft interrupts Message-ID: <20020213160712.A91628@iclub.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org hi, there! I am writing netwrok device driver and I need to execute some code which is activated by hardware interrupt but with interrupts enabled. Is it ok to use netisr's and schednetisr? What is preferred way to do this? /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 2:17: 1 2002 Delivered-To: freebsd-net@freebsd.org Received: from hale.inty.net (hale.inty.net [195.92.21.144]) by hub.freebsd.org (Postfix) with ESMTP id 408EC37B400 for ; Thu, 14 Feb 2002 02:16:45 -0800 (PST) Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150]) by hale.inty.net (8.11.3/8.11.3) with ESMTP id g1EAGZN51164 for ; Thu, 14 Feb 2002 10:16:35 GMT Received: from tariq ([10.0.1.156]) by inty.hq.inty.net (8.12.1/8.12.1) with SMTP id g1EAGXYl031552 for ; Thu, 14 Feb 2002 10:16:34 GMT From: "Tariq Rashid" To: Subject: RE: squeeze more performance out of natd? - some gprof stats Date: Thu, 14 Feb 2002 10:19:51 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-Sender-IP: 10.0.1.156 X-INT-DeliveryDone: g1EAGXYl031552 X-suppress-rcpt-virus-notify: yes X-Skip-Virus-Check: yes X-Virus-Checked: 11031 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org attached are some gprof stats - it seems that sendto() is taking most of the time... does this mean that nothing can be done about it? what affects the speed of sendto() returning... i have the following boosted kernel params: net.local.stream.sendspace: 8192 net.local.stream.recvspace: 8192 net.local.dgram.recvspace: 4096 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 net.inet.udp.recvspace: 41600 net.inet.raw.recvspace: 8192 and the ulimit -a shows a healthy max proc /fds... the kernel option maxusers is set to 1024. cpu time (seconds) unlimited file size (blocks) unlimited data seg size (kbytes) 524288 stack size (kbytes) 65536 core file size (blocks) unlimited resident set size (kbytes) unlimited locked-in-memory size (kb) unlimited processes 16403 file descriptors 32808 socket buffer size (kb) unlimited i do note that sometimes the SendNeedIcmpFrag is called after sendto() - i guess thats due to the sendto() not happening atomically at that particular time. my earlier thoughts that it migt be select() don't seem to be reflected by the gprof output below? any advice from those with more profiling experience would be gratefully recieved. the top bit of gprof attched... --------------- gprof natd natd.gmon ------------------------------ called/total parents index %time self descendents called+self name index called/total children [1] 99.9 0.23 24.49 main [1] 0.14 23.19 94551/94551 DoAliasing [2] 1.04 0.00 94552/94552 select [7] 0.00 0.08 1/1 ParseArgs [19] 0.04 0.00 189104/189104 bzero [28] 0.00 0.00 1/1 SetAliasAddressFromIfName [67] 0.00 0.00 1/2 PacketAliasSetMode [66] 0.00 0.00 1/1 PacketAliasInit [79] 0.00 0.00 1/1 printf [89] 0.00 0.00 2/4 socket [119] 0.00 0.00 2/3 siginterrupt [126] 0.00 0.00 2/3 signal [128] 0.00 0.00 1/1 openlog [150] 0.00 0.00 1/1 _bind [658] 0.00 0.00 1/1 _shutdown [663] 0.00 0.00 1/27362 __error_unthreaded [639] ----------------------------------------------- 0.14 23.19 94551/94551 main [1] [2] 94.3 0.14 23.19 94551 DoAliasing [2] 0.05 20.19 94551/94551 FlushPacketBuffer [3] 1.16 0.00 94551/94551 recvfrom [5] 0.05 0.91 50094/50094 PacketAliasOut [8] 0.04 0.79 44457/44457 PacketAliasIn [9] ----------------------------------------------- 0.05 20.19 94551/94551 DoAliasing [2] [3] 81.8 0.05 20.19 94551 FlushPacketBuffer [3] 20.19 0.00 94551/94552 _sendto [4] ----------------------------------------------- 0.00 0.00 1/94552 send [70] 20.19 0.00 94551/94552 FlushPacketBuffer [3] [4] 81.6 20.19 0.00 94552 _sendto [4] ----------------------------------------------- 1.16 0.00 94551/94551 DoAliasing [2] [5] 4.7 1.16 0.00 94551 recvfrom [5] ----------------------------------------------- 94551 SendNeedFragIcmp [6] 0.08 0.44 44457/94551 PacketAliasIn [9] 0.09 0.50 50094/94551 PacketAliasOut [8] [6] 4.5 0.17 0.94 94551+94551 SendNeedFragIcmp [6] 0.02 0.36 50094/50094 FindUdpTcpOut [14] 0.02 0.31 44457/44457 FindUdpTcpIn [17] 0.05 0.00 94551/94551 GetAckModified [26] 0.04 0.00 94551/94551 GetAliasAddress [29] 0.02 0.00 50094/50094 ProxyCheck [33] 0.02 0.00 50094/50594 GetAliasPort [32] 0.02 0.00 50094/50094 GetStateOut [34] 0.02 0.00 44457/44957 GetOriginalPort [35] 0.02 0.00 44457/44457 GetProxyAddress [36] 0.01 0.00 44457/44457 GetProxyPort [37] 0.01 0.00 44457/44957 GetOriginalAddress [44] 0.01 0.00 50094/50094 SetStartSeq [45] 0.01 0.00 44457/44457 GetStateIn [49] 0.01 0.00 44457/44457 GetFlags [52] 0.00 0.00 500/500 SetStateOut [61] 0.00 0.00 500/500 SetStateIn [101] 94551 SendNeedFragIcmp [6] ----------------------------------------------- 1.04 0.00 94552/94552 main [1] [7] 4.2 1.04 0.00 94552 select [7] ----------------------------------------------- 0.05 0.91 50094/50094 DoAliasing [2] [8] 3.9 0.05 0.91 50094 PacketAliasOut [8] 0.09 0.50 50094/94551 SendNeedFragIcmp [6] 0.05 0.25 50094/94552 HouseKeeping [12] 0.01 0.00 50094/50094 GetDefaultAliasAddress [39] 0.00 0.00 50094/50094 SetDefaultAliasAddress [53] 0.00 0.00 50094/94551 ClearCheckNewLink [47] ----------------------------------------------- 0.04 0.79 44457/44457 DoAliasing [2] [9] 3.4 0.04 0.79 44457 PacketAliasIn [9] 0.08 0.44 44457/94551 SendNeedFragIcmp [6] 0.05 0.22 44457/94552 HouseKeeping [12] 0.00 0.00 44457/94551 ClearCheckNewLink [47] ----------------------------------------------- [10] 2.7 0.30 0.37 95949+99575 [10] 0.26 0.37 96449+98083 FindNewPortGroup [11] 0.04 0.00 99075 DifferentialChecksum [27] ----------------------------------------------- 98083 FindNewPortGroup [11] 500 DifferentialChecksum [27] 0.00 0.00 1/95949 PacketAliasSetAddress [78] 0.00 0.00 1/95949 PacketAliasUninit [63] 0.00 0.00 8/95949 PacketAliasRedirectPort [72] 0.00 0.00 388/95949 HouseKeeping [12] 0.00 0.00 500/95949 FindAliasAddress [54] 0.14 0.17 44457/95949 FindUdpTcpIn [17] 0.16 0.20 50594/95949 FindUdpTcpOut [14] [11] 2.5 0.26 0.37 96449+98083 FindNewPortGroup [11] 0.00 0.37 1008/1010 PunchFWHole [15] 0.00 0.00 1016/1047 malloc [58] 0.00 0.00 1016/1045 free [59] 99075 DifferentialChecksum [27] 98083 FindNewPortGroup [11] ----------------------------------------------- 0.00 0.00 1/94552 PacketAliasUninit [63] 0.05 0.22 44457/94552 PacketAliasIn [9] 0.05 0.25 50094/94552 PacketAliasOut [8] [12] 2.3 0.10 0.47 94552 HouseKeeping [12] 0.46 0.00 94551/94554 gettimeofday [13] 0.00 0.00 388/95949 FindNewPortGroup [11] ----------------------------------------------- 0.00 0.00 1/94554 PacketAliasInit [79] 0.00 0.00 2/94554 time [77] 0.46 0.00 94551/94554 HouseKeeping [12] [13] 1.9 0.46 0.00 94554 gettimeofday [13] ----------------------------------------------- 0.02 0.36 50094/50094 SendNeedFragIcmp [6] [14] 1.5 0.02 0.36 50094 FindUdpTcpOut [14] 0.16 0.20 50594/95949 FindNewPortGroup [11] 0.00 0.00 500/500 FindAliasAddress [54] ----------------------------------------------- 0.00 0.00 2/1010 PacketAliasCheckNewLink [62] 0.00 0.37 1008/1010 FindNewPortGroup [11] [15] 1.5 0.00 0.37 1010 PunchFWHole [15] 0.37 0.00 28664/28664 _setsockopt [16] 0.00 0.00 500/44957 GetOriginalPort [35] 0.00 0.00 500/50594 GetAliasPort [32] 0.00 0.00 500/44957 GetOriginalAddress [44] 0.00 0.00 500/500 GetDestAddress [100] 0.00 0.00 2/3 memset [123] ----------------------------------------------- 0.37 0.00 28664/28664 PunchFWHole [15] [16] 1.5 0.37 0.00 28664 _setsockopt [16] ----------------------------------------------- 0.02 0.31 44457/44457 SendNeedFragIcmp [6] [17] 1.3 0.02 0.31 44457 FindUdpTcpIn [17] 0.14 0.17 44457/95949 FindNewPortGroup [11] ----------------------------------------------- [18] 0.3 0.00 0.08 4+9 [18] 0.00 0.08 12 ParseOption [20] 0.00 0.00 1 ReadConfigFile [81] ----------------------------------------------- 0.00 0.08 1/1 main [1] [19] 0.3 0.00 0.08 1 ParseArgs [19] 0.00 0.08 4/4 ParseOption [20] 0.00 0.00 4/4 strncat [120] ----------------------------------------------- 8 ReadConfigFile [81] 0.00 0.08 4/4 ParseArgs [19] [20] 0.3 0.00 0.08 12 ParseOption [20] 0.00 0.08 8/8 SetupPortRedirect [21] root@exoserver.tariq11:/# gprof /sbin/natd natd.gmon | less /usr/share/misc/gprof.callg: No such file or directory None granularity: each sample hit covers 4 byte(s) for 0.00% of 24.73 seconds granularity: each sample hit covers 4 byte(s) for 0.00% of 24.73 seconds called/total parents index %time self descendents called+self name index called/total children [1] 99.9 0.23 24.49 main [1] 0.14 23.19 94551/94551 DoAliasing [2] 1.04 0.00 94552/94552 select [7] 0.00 0.08 1/1 ParseArgs [19] 0.04 0.00 189104/189104 bzero [28] 0.00 0.00 1/1 SetAliasAddressFromIfName [67] 0.00 0.00 1/2 PacketAliasSetMode [66] 0.00 0.00 1/1 PacketAliasInit [79] 0.00 0.00 1/1 printf [89] 0.00 0.00 2/4 socket [119] 0.00 0.00 2/3 siginterrupt [126] 0.00 0.00 2/3 signal [128] 0.00 0.00 1/1 openlog [150] 0.00 0.00 1/1 _bind [658] 0.00 0.00 1/1 _shutdown [663] 0.00 0.00 1/27362 __error_unthreaded [639] ----------------------------------------------- 0.14 23.19 94551/94551 main [1] [2] 94.3 0.14 23.19 94551 DoAliasing [2] 0.05 20.19 94551/94551 FlushPacketBuffer [3] 1.16 0.00 94551/94551 recvfrom [5] 0.05 0.91 50094/50094 PacketAliasOut [8] 0.04 0.79 44457/44457 PacketAliasIn [9] ----------------------------------------------- 0.05 20.19 94551/94551 DoAliasing [2] [3] 81.8 0.05 20.19 94551 FlushPacketBuffer [3] 20.19 0.00 94551/94552 _sendto [4] ----------------------------------------------- 0.00 0.00 1/94552 send [70] 20.19 0.00 94551/94552 FlushPacketBuffer [3] [4] 81.6 20.19 0.00 94552 _sendto [4] ----------------------------------------------- 1.16 0.00 94551/94551 DoAliasing [2] [5] 4.7 1.16 0.00 94551 recvfrom [5] ----------------------------------------------- 94551 SendNeedFragIcmp [6] 0.08 0.44 44457/94551 PacketAliasIn [9] 0.09 0.50 50094/94551 PacketAliasOut [8] [6] 4.5 0.17 0.94 94551+94551 SendNeedFragIcmp [6] 0.02 0.36 50094/50094 FindUdpTcpOut [14] 0.02 0.31 44457/44457 FindUdpTcpIn [17] 0.05 0.00 94551/94551 GetAckModified [26] 0.04 0.00 94551/94551 GetAliasAddress [29] 0.02 0.00 50094/50094 ProxyCheck [33] 0.02 0.00 50094/50594 GetAliasPort [32] 0.02 0.00 50094/50094 GetStateOut [34] 0.02 0.00 44457/44957 GetOriginalPort [35] 0.02 0.00 44457/44457 GetProxyAddress [36] 0.01 0.00 44457/44457 GetProxyPort [37] 0.01 0.00 44457/44957 GetOriginalAddress [44] 0.01 0.00 50094/50094 SetStartSeq [45] 0.01 0.00 44457/44457 GetStateIn [49] 0.01 0.00 44457/44457 GetFlags [52] 0.00 0.00 500/500 SetStateOut [61] 0.00 0.00 500/500 SetStateIn [101] 94551 SendNeedFragIcmp [6] ----------------------------------------------- 1.04 0.00 94552/94552 main [1] [7] 4.2 1.04 0.00 94552 select [7] ----------------------------------------------- 0.05 0.91 50094/50094 DoAliasing [2] [8] 3.9 0.05 0.91 50094 PacketAliasOut [8] 0.09 0.50 50094/94551 SendNeedFragIcmp [6] 0.05 0.25 50094/94552 HouseKeeping [12] 0.01 0.00 50094/50094 GetDefaultAliasAddress [39] 0.00 0.00 50094/50094 SetDefaultAliasAddress [53] 0.00 0.00 50094/94551 ClearCheckNewLink [47] ----------------------------------------------- 0.04 0.79 44457/44457 DoAliasing [2] [9] 3.4 0.04 0.79 44457 PacketAliasIn [9] 0.08 0.44 44457/94551 SendNeedFragIcmp [6] 0.05 0.22 44457/94552 HouseKeeping [12] 0.00 0.00 44457/94551 ClearCheckNewLink [47] ----------------------------------------------- intY has automatically scanned this email with Sophos Anti-Virus (www.inty.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 2:44:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from sekunda5.oslo.kvalito.no (sekunda5.oslo.kvalito.no [194.29.201.8]) by hub.freebsd.org (Postfix) with ESMTP id BFE8737B416 for ; Thu, 14 Feb 2002 02:44:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: error writing routing socket, not enough buffer space. content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 14 Feb 2002 11:57:50 +0100 Message-ID: <010B55064719D511AEBD00500488036202298D@sekunda5.oslo.kvalito.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: error writing routing socket, not enough buffer space. Thread-Index: AcG1RPde/J7kHfokTbm7JXN4ve2CAw== From: =?iso-8859-1?Q?Are_=D8hrn?= To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org After spending a few days, trying to find any scrap of information on the web and coming up empty, I make a last try here before nuking my freebsd box. I'm running FreeBSD 4.4 on an Duron 800, 256Mb ram, 3x3com 905c. The box is only running zebrad and bgpd. After booting the box, putting it on the network, and starting the bgpd and zebra, it seems to be working ok. But it does not route correctly, some traffic is working ok, but mostly it's not. I also get an error when trying to add/change a static route : error writing to routing socket : not enough buffer space and sometimes : disk quota exceeded when trying to do the same. Any pointers on where to look to fix this problem?=20 Best regards=20 Are =D8hrn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 8: 5:21 2002 Delivered-To: freebsd-net@freebsd.org Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by hub.freebsd.org (Postfix) with SMTP id B794437B402 for ; Thu, 14 Feb 2002 08:05:10 -0800 (PST) Received: (qmail 7328 invoked from network); 14 Feb 2002 16:04:19 -0000 Received: from dhcp-64-58-3-62.mho.net (HELO jason) (64.58.3.62) by smtp.mho.net with SMTP; 14 Feb 2002 16:04:19 -0000 Message-ID: <001601c1b4a7$da834a60$3e033a40@jason> From: "Jason Hoffman" To: Subject: Netgraph LMC T3 Support? Date: Wed, 13 Feb 2002 09:02:35 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C1B46D.2E0A81C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C1B46D.2E0A81C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does netgraph support the LMC T3 interface? I am having trouble getting netgraph to find the interface. Any reply would be greatly appreciated. Thanks in advance, Jay Hoffman MHO Networks (303) 584-9711 ------=_NextPart_000_0013_01C1B46D.2E0A81C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 Does netgraph support the LMC T3 interface?
 I am = having=20 trouble getting netgraph to find the interface.
 
Any reply would be greatly=20 appreciated.
 
Thanks in advance,
 
Jay Hoffman
MHO Networks
(303) 584-9711
------=_NextPart_000_0013_01C1B46D.2E0A81C0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 8:43: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id A47D337B405 for ; Thu, 14 Feb 2002 08:42:53 -0800 (PST) Received: (qmail 27170 invoked from network); 14 Feb 2002 16:42:53 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 14 Feb 2002 16:42:53 -0000 Message-ID: <3C6BE90D.3020108@tenebras.com> Date: Thu, 14 Feb 2002 08:42:53 -0800 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020131 X-Accept-Language: en-us MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Bug in stateful code? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've sent this to Luigi and a couple of other folks without reply, so here it is. I'm seeing what I believe to be a bug in the stateful filter code for ipfw/ip_fw. Here's my original message: ============================================================================= Running ipfw w/natd, connections through the gateway are dying. Two dynamic rules get instantiated for each connection through the gateway -- one with NAT'd addresses and one revealing the private addresses $on = external net = X.Y.Z/24 $in = internal net = A.B.C/24 (192.168.1.0/24) the external IP is X.Y.Z.23 the internal IP is A.B.C.1 firewall rules: [some static rules...] $fw add divert natd ip from any to any via $external_interface $fw add check-state $fw add allow tcp from $in to any setup keep-state $fw add allow udp from $in to any keep-state $fw add allow tcp from $on to any setup keep-state $fw add allow udp from $on to any keep-state An ssh connection from A.B.C.4 to X.Y.Z.44 causes the following dynamic rules to appear: 02400 15 3197 (T 16, slot 760) <-> tcp, X.Y.Z.23 1549<-> X.Y.Z.44 22 02200 45 9151 (T 296, slot 913) <-> tcp, A.B.C.4 1549<-> X.Y.Z.44 22 Note 02400 -- this connection timer seems to indicate that it is waiting for a completed 3-way handshake and hasn't seen the other SYN. The connection dies because the time counts down. The timer for 02200 doesn't count down because the keep-alives are resetting it. Any insight as to why this is happening? Seems like a bug in the state machine. I could be convinced otherwise, but it seems that these two rules should see the connection as being in the same state -- they both see the same packets. BTW, I could simplify this by safely allowing $fw add divert natd ip from any to any via $external_interface $fw add check-state $fw add allow ip from $in to any $fw add allow ip from any to $in $fw add allow tcp from $on to any setup keep-state $fw add allow udp from $on to any keep-state But the dynamic rule on the public side still seem to be using net.inet.ip.fw.dyn_syn_lifetime instead of net.inet.ip.fw.dyn_ack_lifetime. Comments? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 9:19:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 19A9737B405; Thu, 14 Feb 2002 09:19:32 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g1EHJ6209330; Thu, 14 Feb 2002 19:19:06 +0200 (EET) (envelope-from ru) Date: Thu, 14 Feb 2002 19:19:06 +0200 From: Ruslan Ermilov To: Garrett Wollman Cc: net@FreeBSD.org Subject: Re: rdr 127.0.0.1 and blocking 127/8 in ip_output() Message-ID: <20020214191906.A7309@sunbay.com> References: <20020213110347.C46245@sunbay.com> <200202131550.g1DFoDh41696@khavrinen.lcs.mit.edu> <20020213175851.A22977@sunbay.com> <3C6AFD6D.9ED1190A@mindspring.com> <20020214110941.A30024@sunbay.com> <200202141639.g1EGdbS06007@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200202141639.g1EGdbS06007@khavrinen.lcs.mit.edu> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [Redirected to -net] On Thu, Feb 14, 2002 at 11:39:37AM -0500, Garrett Wollman wrote: > < said: > > > ping -s 127.1 1.2.3.4 > > telnet -S 127.1 1.2.3.4 > > If someone explicitly overrides source-address selection, they are > presumed to know WTF they are doing, and the kernel should not be > trying to second-guess them. > That "someone" could be a bad guy playing dirty games with your box and certainly knowing what he's doing. :-) So far, noone gave me a real example where using of net 127 outside loopback would be useful. If there such an example exists, we should wrap all three checks into a sysctl, including ip_input(), ip_output(), and in_canforward() parts, where ip_input() exists for almost a year, and in_canforward() existed since 1987. -- Ruslan, who just wants a consistency here. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 9:37:17 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id B7FE137B416; Thu, 14 Feb 2002 09:36:50 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1EHalf57727; Thu, 14 Feb 2002 09:36:47 -0800 (PST) (envelope-from rizzo) Date: Thu, 14 Feb 2002 09:36:47 -0800 From: Luigi Rizzo To: Michael Sierchio Cc: freebsd-ipfw@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Bug in stateful code? Message-ID: <20020214093647.A57238@iguana.icir.org> References: <3C6BE90D.3020108@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C6BE90D.3020108@tenebras.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Feb 14, 2002 at 08:42:53AM -0800, Michael Sierchio wrote: > > I've sent this to Luigi and a couple of other folks without reply, > so here it is. the reply was that keep-state and natd are very hard to use together, and besides it is rather useless because natd is stateful by itself. This said, we have only so much time to do things. Sure, i do not exclude a-priori the possibility of a bug, but it sounds more lilely to be a misconfiguration of your ruleset, and since the example you are presenting has no reasonable application (that i can see -- again, i'm happy to be proved wrong), i do not feel like spending an hour or two trying to infer what is on your [some static rules], and i'll happily leave you the job to explain where the bug (which means reconstruct the flow of packets in and out of the ipfw and show which one is dealt in the wrong way). cheers luigi > I'm seeing what I believe to be a bug in the stateful filter code > for ipfw/ip_fw. Here's my original message: > > ============================================================================= > > Running ipfw w/natd, connections through the gateway are dying. Two > dynamic > rules get instantiated for each connection through the gateway -- one > with NAT'd addresses and one revealing the private addresses > > $on = external net = X.Y.Z/24 > $in = internal net = A.B.C/24 (192.168.1.0/24) > > the external IP is X.Y.Z.23 > the internal IP is A.B.C.1 > > firewall rules: > > [some static rules...] > > $fw add divert natd ip from any to any via $external_interface > > $fw add check-state > > $fw add allow tcp from $in to any setup keep-state > $fw add allow udp from $in to any keep-state > > $fw add allow tcp from $on to any setup keep-state > $fw add allow udp from $on to any keep-state > > > An ssh connection from A.B.C.4 to X.Y.Z.44 causes the following dynamic > rules > to appear: > > > 02400 15 3197 (T 16, slot 760) <-> tcp, X.Y.Z.23 1549<-> X.Y.Z.44 22 > 02200 45 9151 (T 296, slot 913) <-> tcp, A.B.C.4 1549<-> X.Y.Z.44 22 > > Note 02400 -- this connection timer seems to indicate that it is waiting for > a completed 3-way handshake and hasn't seen the other SYN. The connection > dies > because the time counts down. The timer for 02200 doesn't count down > because > the keep-alives are resetting it. > > Any insight as to why this is happening? Seems like a bug in the state > machine. > I could be convinced otherwise, but it seems that these two rules should > see the connection as being in the same state -- they both see the same > packets. BTW, I could simplify this by safely allowing > > > $fw add divert natd ip from any to any via $external_interface > > $fw add check-state > > $fw add allow ip from $in to any > $fw add allow ip from any to $in > > $fw add allow tcp from $on to any setup keep-state > $fw add allow udp from $on to any keep-state > > But the dynamic rule on the public side still seem to be using > net.inet.ip.fw.dyn_syn_lifetime instead of net.inet.ip.fw.dyn_ack_lifetime. > > Comments? > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 12:43:51 2002 Delivered-To: freebsd-net@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id 07F6B37B417 for ; Thu, 14 Feb 2002 12:43:46 -0800 (PST) Received: (qmail 771 invoked from network); 14 Feb 2002 20:43:44 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 14 Feb 2002 20:43:44 -0000 Message-ID: <3C6C2180.3020704@tenebras.com> Date: Thu, 14 Feb 2002 12:43:44 -0800 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020131 X-Accept-Language: en-us MIME-Version: 1.0 To: Luigi Rizzo Cc: freebsd-ipfw@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Bug in stateful code? References: <3C6BE90D.3020108@tenebras.com> <20020214093647.A57238@iguana.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Luigi Rizzo wrote: > the reply was that keep-state and natd are very hard to use > together, and besides it is rather useless because natd is stateful > by itself. natd is stateful, but provides no protection for inbound IP traffic that is destined for the filtering host itself. The ruleset *is* particularly useful, since the host in question is both a router for nat'd hosts and a dns and mail server. I'd like to preserve stateful filtering rules for packets that originate at and are destined for the host itself. > ..., i do not feel like spending > an hour or two trying to infer what is on your [some static rules], > and i'll happily leave you the job to explain where the bug (which > means reconstruct the flow of packets in and out of the ipfw and > show which one is dealt in the wrong way). I'd be happy to share the static rules -- and AFAIK I did give a hint as to what the problem is. What kind of evidence do you want, in particular? I have a tcpdump that shows the packet exchange, shows SYN from each host, and demonstrates that the dynamic rule is in the wrong state, using the wrong timer. This could easily have something to do with the interaction of ipfw and natd, but I'm just reporting the observable phenomena. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 12:44:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.marketwatchmail.com (mail.marketwatchmail.com [206.146.143.85]) by hub.freebsd.org (Postfix) with SMTP id 07A4B37B402 for ; Thu, 14 Feb 2002 12:44:51 -0800 (PST) Received: (qmail 26903 invoked from network); 14 Feb 2002 21:31:42 -0000 Received: from unknown (HELO jaustadw2k) (206.147.106.71) by mail.marketwatchmail.com with SMTP; 14 Feb 2002 21:31:42 -0000 From: "Jay Austad" To: Subject: gated config Date: Thu, 14 Feb 2002 14:44:47 -0600 Message-ID: <54180709DD3FE145917BB165AFE7EFA002E0D4DC@mspexch2.office.mktw.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ok, I'm trying to use gated. Here's my setup... I have 2 machines in different offices, each with an internal and external ethernet interface. There is a gif0 tunnel between the external interfaces tied down to a 10.x.x.x address assigned to lo1. I've tried using the following config: bgp off; egp off; ospf off; rip on { broadcast; interface fxp0; interface gif0; interface fxp1 noripin noripout; }; export proto rip interface gif0 { proto direct { 10.20.0.0 mask 255.255.0.0 metric 1; 10.254.254.76 mask 255.255.255.252 metric 1; }; }; export proto rip interface fxp0 { proto direct { 10.20.0.0 mask 255.255.0.0 metric 1; 10.254.254.76 mask 255.255.255.252 metric 1; }; }; import proto rip interface gif0 { all; }; import proto rip interface fxp0 { all; }; However, it doesn't seem to send out any routing updates over the gif0 tunnel. What am I doing wrong? I need to make sure it doesn't accept or broadcast routes out the fxp1 interface also. And it also should *not* broadcast a default route. It needs to send routes acquired from other routers on each network across the tunnel and be broadcast out to the other network. I guess OSPF would work also. Does anyone have a working config for this type of situation that they could post? (either ospf or rip) Or any working config for that matter? Thanks. Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 13:15:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from artemis.drwilco.net (diana.drwilco.net [66.48.127.79]) by hub.freebsd.org (Postfix) with ESMTP id EA1D337B404; Thu, 14 Feb 2002 13:15:08 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g1ELEwZ89266 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Thu, 14 Feb 2002 16:14:59 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020214221354.01c37da0@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Feb 2002 22:25:13 +0100 To: Michael Sierchio , Luigi Rizzo From: "Rogier R. Mulhuijzen" Subject: Re: Bug in stateful code? Cc: freebsd-ipfw@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <3C6C2180.3020704@tenebras.com> References: <3C6BE90D.3020108@tenebras.com> <20020214093647.A57238@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>the reply was that keep-state and natd are very hard to use >>together, and besides it is rather useless because natd is stateful >>by itself. >natd is stateful, but provides no protection for inbound IP traffic >that is destined for the filtering host itself. I have personally looked at natd & stateful ipfw rules, and have concluded that it logically impossible to get it to work. Thus I made a ipfw rulelist that utilizes the statefulness of natd. I hope this helps you in making your own rulelist. tl0 is the interface on internal LAN lnc0 is the interface on external LAN -------------------- #divert all http requests from internal network to quid cache add 00510 fwd 172.30.0.1 tcp from 172.30.0.0/16 to any 80 in via tl0 add 00520 fwd 172.30.0.1 tcp from 172.20.0.0/16 to any 80 in via tl0 add 00530 fwd 172.30.0.1 tcp from 192.168.0.0/24 to any 80 in via tl0 #allow all traffic to/from internal network add 01000 allow all from any to any via tl0 #translate incoming packets (NAT) add 30000 divert natd all from any to in via lnc0 #allow incoming packets for hosts on internal network #(Since we translated them, we're sure they belong to existing #connection) add 30110 allow all from any to 172.20.0.0/16 in via lnc0 add 30111 allow all from any to 172.30.0.0/16 in via lnc0 add 30112 allow all from any to 192.168.0.0/24 in via lnc0 #allow SSH from XXXXXXXX add 30200 allow tcp from to 22 in via lnc0 add 30210 allow tcp from 22 to out via lnc0 #allow DNS queries to UUnet DNS servers add 30300 allow udp from 53 to in via lnc0 add 30310 allow udp from to 53 out via lnc0 add 30320 allow udp from 53 to in via lnc0 add 30330 allow udp from to 53 out via lnc0 #allow outgoing traffic from internal hosts #(use skipto 34000 instead of allow because they still need translation) add 31010 skipto 34000 all from 172.20.0.0/16 to any out via lnc0 add 31020 skipto 34000 all from 172.30.0.0/16 to any out via lnc0 add 31030 skipto 34000 all from 192.168.0.0/24 to any out via lnc0 #allow outgoing connections from local machine (using dynamic rules) add 32000 allow all from to any out via lnc0 keep-state #block and log everything that hasn't been allowed so far add 33000 deny log all from any to any -------------------- Greets, Doc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 13:33:26 2002 Delivered-To: freebsd-net@freebsd.org Received: from artemis.drwilco.net (diana.drwilco.net [66.48.127.79]) by hub.freebsd.org (Postfix) with ESMTP id 26AF037B400; Thu, 14 Feb 2002 13:33:19 -0800 (PST) Received: from ceres.drwilco.net (docwilco.xs4all.nl [213.84.68.230]) by artemis.drwilco.net (8.11.6/8.11.6) with ESMTP id g1ELXFZ89822 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Thu, 14 Feb 2002 16:33:17 -0500 (EST) (envelope-from drwilco@drwilco.net) Message-Id: <5.1.0.14.0.20020214224151.01c350c0@mail.drwilco.net> X-Sender: lists@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Feb 2002 22:43:30 +0100 To: Michael Sierchio , Luigi Rizzo From: "Rogier R. Mulhuijzen" Subject: Re: Bug in stateful code? Cc: freebsd-ipfw@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <5.1.0.14.0.20020214221354.01c37da0@mail.drwilco.net> References: <3C6C2180.3020704@tenebras.com> <3C6BE90D.3020108@tenebras.com> <20020214093647.A57238@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 22:25 14-2-2002 +0100, Rogier R. Mulhuijzen wrote: ----SNIP---- Oops, forgot a few rules at the end (bad copy/paste) So here it is again. tl0 is the interface on internal LAN lnc0 is the interface on external LAN -------------------- #divert all http requests from internal network to quid cache add 00510 fwd 172.30.0.1 tcp from 172.30.0.0/16 to any 80 in via tl0 add 00520 fwd 172.30.0.1 tcp from 172.20.0.0/16 to any 80 in via tl0 add 00530 fwd 172.30.0.1 tcp from 192.168.0.0/24 to any 80 in via tl0 #allow all traffic to/from internal network add 01000 allow all from any to any via tl0 #translate incoming packets (NAT) add 30000 divert natd all from any to in via lnc0 #allow incoming packets for hosts on internal network #(Since we translated them, we're sure they belong to existing #connection) add 30110 allow all from any to 172.20.0.0/16 in via lnc0 add 30111 allow all from any to 172.30.0.0/16 in via lnc0 add 30112 allow all from any to 192.168.0.0/24 in via lnc0 #allow SSH from XXXXXXXX add 30200 allow tcp from to 22 in via lnc0 add 30210 allow tcp from 22 to out via lnc0 #allow DNS queries to UUnet DNS servers add 30300 allow udp from 53 to in via lnc0 add 30310 allow udp from to 53 out via lnc0 add 30320 allow udp from 53 to in via lnc0 add 30330 allow udp from to 53 out via lnc0 #allow outgoing traffic from internal hosts #(use skipto 34000 instead of allow because they still need translation) add 31010 skipto 34000 all from 172.20.0.0/16 to any out via lnc0 add 31020 skipto 34000 all from 172.30.0.0/16 to any out via lnc0 add 31030 skipto 34000 all from 192.168.0.0/24 to any out via lnc0 #allow outgoing connections from local machine (using dynamic rules) add 32000 allow all from to any out via lnc0 keep-state #block and log everything that hasn't been allowed so far add 33000 deny log all from any to any #translate outgoing packets (NAT) add 34000 divert natd all from any to any out via lnc0 #allow translated packets to go out add 34010 allow all from 195.109.218.253 to any out via lnc0 #block and log whatever remains (shouldn't be anything) add 65000 deny log all from any to any -------------------- Greets, Doc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 13:59:44 2002 Delivered-To: freebsd-net@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 75CDD37B416; Thu, 14 Feb 2002 13:59:40 -0800 (PST) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g1ELxao59263; Thu, 14 Feb 2002 13:59:36 -0800 (PST) (envelope-from rizzo) Date: Thu, 14 Feb 2002 13:59:36 -0800 From: Luigi Rizzo To: Michael Sierchio Cc: freebsd-ipfw@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Bug in stateful code? Message-ID: <20020214135936.A59207@iguana.icir.org> References: <3C6BE90D.3020108@tenebras.com> <20020214093647.A57238@iguana.icir.org> <3C6C2180.3020704@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C6C2180.3020704@tenebras.com> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Feb 14, 2002 at 12:43:44PM -0800, Michael Sierchio wrote: > >..., i do not feel like spending > >an hour or two trying to infer what is on your [some static rules], > >and i'll happily leave you the job to explain where the bug (which > >means reconstruct the flow of packets in and out of the ipfw and > >show which one is dealt in the wrong way). > > I'd be happy to share the static rules -- and AFAIK I did give a hint > as to what the problem is. What kind of evidence do you want, in > particular? > I have a tcpdump that shows the packet exchange, shows SYN from each > host, and demonstrates that the dynamic rule is in the wrong state, > using the wrong timer. This could easily have something to do with the only reason why the rule can be "in the wrong state" as you say, is that the packet you are waiting for never reaches the rule. Whihc in turn boils down to a misconfiguration of the ruleset. A tcpdump alone, even taken on both sides, is not enough because the packet goes like this: input interface ip_input() ipfw up to the natd rule natd rest of ipfw ruleset ip_output() (if gateway is enabled) ipfw up to the natd rule natd rest of ipfw ruleset where is it dropped, you ight probably figure out with a bit of experimenting and lookinga at ipfw counters and possibly running natd in verbose mode. luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 14:16:19 2002 Delivered-To: freebsd-net@freebsd.org Received: from web21101.mail.yahoo.com (web21101.mail.yahoo.com [216.136.227.103]) by hub.freebsd.org (Postfix) with SMTP id 3E2B737B400 for ; Thu, 14 Feb 2002 14:16:16 -0800 (PST) Message-ID: <20020214221615.23759.qmail@web21101.mail.yahoo.com> Received: from [152.15.24.198] by web21101.mail.yahoo.com via HTTP; Thu, 14 Feb 2002 14:16:15 PST Date: Thu, 14 Feb 2002 14:16:15 -0800 (PST) From: Vinod Namboodiri Subject: MAC Layer of TCP/IP stack To: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi there.I am about to embark on a research project wherein some changes need to be made in the MAC layer of the TCP/IP stack.We have a wireless testbed running on FreeBSD.I had a few doubts.can i make the changes from the TCP/IP stack source code of FreeBSD?I dont know much about the source code of the stack.or would i need to be modifying the firmware of the wireless network card which probably has the mac layer code? Could use some help. Vinod __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 14:20:53 2002 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id C3B0E37B400 for ; Thu, 14 Feb 2002 14:20:49 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id g1EMKmZ30049; Thu, 14 Feb 2002 17:20:48 -0500 (EST) (envelope-from wollman) Date: Thu, 14 Feb 2002 17:20:48 -0500 (EST) From: Garrett Wollman Message-Id: <200202142220.g1EMKmZ30049@khavrinen.lcs.mit.edu> To: Vinod Namboodiri Cc: freebsd-net@FreeBSD.ORG Subject: MAC Layer of TCP/IP stack In-Reply-To: <20020214221615.23759.qmail@web21101.mail.yahoo.com> References: <20020214221615.23759.qmail@web21101.mail.yahoo.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org < said: > i need to be modifying the firmware of the wireless > network card which probably has the mac layer code? The MAC layer is almost invariably implemented in hardware for modern network interfaces. In the case of wireless networks, that's usually firmware running on a microcontroller inside the card, although controllers differ as to the amount of functionality assumed by the firmware. FreeBSD's network stack implements support for Ethernet-like devices from the LLC sublayer up. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 15:20:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 13A0737B400; Thu, 14 Feb 2002 15:20:53 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020214232052.MZCG2951.rwcrmhc53.attbi.com@blossom.cjclark.org>; Thu, 14 Feb 2002 23:20:52 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g1ENKqO37147; Thu, 14 Feb 2002 15:20:52 -0800 (PST) (envelope-from cjc) Date: Thu, 14 Feb 2002 15:20:52 -0800 From: "Crist J. Clark" To: Michael Sierchio Cc: freebsd-ipfw@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Bug in stateful code? Message-ID: <20020214152052.C36782@blossom.cjclark.org> References: <3C6BE90D.3020108@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C6BE90D.3020108@tenebras.com>; from kudzu@tenebras.com on Thu, Feb 14, 2002 at 08:42:53AM -0800 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Feb 14, 2002 at 08:42:53AM -0800, Michael Sierchio wrote: > > I've sent this to Luigi and a couple of other folks without reply, > so here it is. I _DID_ reply to you and on -net explaining why this does not work. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13412+0+current/freebsd-net -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 18:30:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from topaz.mdcc.cx (topaz.mdcc.cx [212.204.230.141]) by hub.freebsd.org (Postfix) with ESMTP id 9F83A37B400 for ; Thu, 14 Feb 2002 18:30:25 -0800 (PST) Received: from k7.mavetju.org (topaz.mdcc.cx [212.204.230.141]) by topaz.mdcc.cx (Postfix) with ESMTP id 86EE22B696 for ; Fri, 15 Feb 2002 03:30:21 +0100 (CET) Received: by k7.mavetju.org (Postfix, from userid 1001) id 3B1B7828; Fri, 15 Feb 2002 13:30:17 +1100 (EST) Date: Fri, 15 Feb 2002 13:30:17 +1100 From: Edwin Groothuis To: freebsd-net@freebsd.org Subject: IPv6-over-IPv4 problems since the upgrade to 4.5 Message-ID: <20020215133017.C491@k7.mavetju.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Greetings, Since the upgrade from 4.4 to 4.5 I have problems with my IPv6-over-v4-tunnel towards the freenet6-servers. The tunnel-setup goes fine, I can ping everything without a problem. But when I open an interactive session, after a short time weird things happen. The TCP-session itself goes fine, until the moment my machine starts sending out ICMP6 neighbor solicitation requests: TCP-session setup: 19:46:39.452386 mavetju-k7.tsps1.freenet6.net.1761 > ftp6.netbsd.org.ftp: S 1971097502:1971097502(0) win 65535 19:46:40.077770 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: S 4240147676:4240147676(0) ack 1971097503 win 32768 19:46:40.077880 mavetju-k7.tsps1.freenet6.net.1761 > ftp6.netbsd.org.ftp: . ack 1 win 33220 220 ftp6.netbsd.org FTP server (NetBSD-ftpd 20020201) ready. 19:46:40.767713 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 1:63(62) ack 1 win 33120 [flowlabel 0x80114] 19:46:40.867511 mavetju-k7.tsps1.freenet6.net.1761 > ftp6.netbsd.org.ftp: . ack 63 win 33220 The neighbor solicitation packets: 19:46:44.697259 mavetju-k7.tsps1.freenet6.net > ftp6.netbsd.org: icmp6: neighbor sol: who has ftp6.netbsd.org 19:46:45.697183 mavetju-k7.tsps1.freenet6.net > ftp6.netbsd.org: icmp6: neighbor sol: who has ftp6.netbsd.org 19:46:46.697131 mavetju-k7.tsps1.freenet6.net > ftp6.netbsd.org: icmp6: neighbor sol: who has ftp6.netbsd.org user anonymous 19:46:47.201295 mavetju-k7.tsps1.freenet6.net.1761 > ftp6.netbsd.org.ftp: P 1:17(16) ack 63 win 33220 331 Guest login ok, type your name as password. 19:46:47.897276 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 [flowlabel 0x80114] 19:46:50.147087 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 [flowlabel 0x80114] 19:46:55.196847 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 [flowlabel 0x80114] 19:47:05.256189 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 [flowlabel 0x80114] 19:47:25.234907 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 [flowlabel 0x80114] 19:48:05.212334 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 [flowlabel 0x80114] These TCP-packet never gets acknowledged and my packets never get send! I have done several tests, with FTP, SSH and plain telnet, everything goes fine until just after the neighbor solicitation. But ICMP-traffic, even large packets as 4Kb, go without a problem. FreeBSD 4.4 didn't, and still doesn't, have this behaviour. Can somebody please confirm that they have the same, or normal, behaviour under 4.5 when connecting to an IPv6 enabled site? Thanks, Edwin -- Edwin Groothuis | Personal website: http://www.MavEtJu.org edwin@mavetju.org | Interested in MUDs? Visit Fatal Dimensions: ------------------+ http://www.FatalDimensions.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Thu Feb 14 18:52: 4 2002 Delivered-To: freebsd-net@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 150B737B402; Thu, 14 Feb 2002 18:52:00 -0800 (PST) Received: (from jmz@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g1F2q0p80051; Thu, 14 Feb 2002 18:52:00 -0800 (PST) (envelope-from jmz) Date: Thu, 14 Feb 2002 18:52:00 -0800 (PST) Message-Id: <200202150252.g1F2q0p80051@freefall.freebsd.org> From: Jean-Marc Zucconi To: Edwin Groothuis Cc: freebsd-net@freebsd.org Subject: Re: IPv6-over-IPv4 problems since the upgrade to 4.5 In-Reply-To: <20020215133017.C491@k7.mavetju.org> References: <20020215133017.C491@k7.mavetju.org> X-Mailer: Emacs 21.1.1 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>>>> Edwin Groothuis writes: > Greetings, > Since the upgrade from 4.4 to 4.5 I have problems with my > IPv6-over-v4-tunnel towards the freenet6-servers. I don't have this problem (but using ipng.nl as IPv6 tunnel): 4636247 bytes received in 79.96 seconds (56.62 KB/s) ftp> 221- Data traffic for this session was 4636247 bytes in 1 file. Total traffic for this session was 4639803 bytes in 2 transfers. 221 Thank you for using the FTP service on ftp6.netbsd.org. Jean-Marc -- Jean-Marc Zucconi -- PGP Key: finger jmz@FreeBSD.org [KeyID: 400B38E9] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 7:26: 2 2002 Delivered-To: freebsd-net@freebsd.org Received: from freddy.inty.net (freddy.inty.net [195.224.93.243]) by hub.freebsd.org (Postfix) with ESMTP id 8533137B402 for ; Fri, 15 Feb 2002 07:25:54 -0800 (PST) Received: from inty.hq.inty.net (inty.hq.inty.net [213.38.150.150]) by freddy.inty.net (8.11.3/8.11.3) with ESMTP id g1FFPfN93184 for ; Fri, 15 Feb 2002 15:25:44 GMT Received: from tariq ([10.0.1.156]) by inty.hq.inty.net (8.12.1/8.12.1) with SMTP id g1FFPcYl091873 for ; Fri, 15 Feb 2002 15:25:38 GMT From: "Tariq Rashid" To: Subject: kernel source for reading from divert sockets Date: Fri, 15 Feb 2002 15:29:04 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender-IP: 10.0.1.156 X-INT-DeliveryDone: g1FFPcYl091873 X-suppress-rcpt-virus-notify: yes X-Skip-Virus-Check: yes X-Virus-Checked: 29835 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org can anyone point me to the kernel source where packets are taken from the DIVERT socket (natd puts them there) - i'm finding that sendto() is taking most of the CPU - so i want to have a look at maybe taking two or three packets from the DIVERT buffer per kernel loop. (i'm not an expert at this by ny means - so useful help would be great!) tariq intY has automatically scanned this email with Sophos Anti-Virus (www.inty.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 8:21:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id EBFD237B430; Fri, 15 Feb 2002 08:21:01 -0800 (PST) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id KAA02162; Fri, 15 Feb 2002 10:20:39 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Fri, 15 Feb 2002 10:20:39 -0600 (CST) From: Chris Dillon To: "Rogier R. Mulhuijzen" Cc: Michael Sierchio , Luigi Rizzo , , Subject: Re: Bug in stateful code? In-Reply-To: <5.1.0.14.0.20020214221354.01c37da0@mail.drwilco.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 14 Feb 2002, Rogier R. Mulhuijzen wrote: > I have personally looked at natd & stateful ipfw rules, and have > concluded that it logically impossible to get it to work. > > Thus I made a ipfw rulelist that utilizes the statefulness of > natd. I hope this helps you in making your own rulelist. If you have the luxury of having more than one IP address available for the outside interface, you can dedicate one address to natd's use, and the other to the host machine. Use -deny_incoming on natd, and use whatever rules you want, including stateful, on the non-NAT address. This is what I've done and it works fine. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 8:21:39 2002 Delivered-To: freebsd-net@freebsd.org Received: from web21106.mail.yahoo.com (web21106.mail.yahoo.com [216.136.227.108]) by hub.freebsd.org (Postfix) with SMTP id A68CD37B427 for ; Fri, 15 Feb 2002 08:20:57 -0800 (PST) Message-ID: <20020215162056.49296.qmail@web21106.mail.yahoo.com> Received: from [152.15.63.69] by web21106.mail.yahoo.com via HTTP; Fri, 15 Feb 2002 08:20:56 PST Date: Fri, 15 Feb 2002 08:20:56 -0800 (PST) From: Vinod Namboodiri Subject: Re: MAC Layer of TCP/IP stack To: Jason Hunt Cc: freebsd-net@freebsd.org, freebsd-mobile@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Not actually.Its more to run QoS experiments and need to customize some medium access protocols like csma/ca e.t.c.Guess i cant get to the csma protocol from the freebsd tcp/ip stack source code. Vinod --- Jason Hunt wrote: > If you mean that you would like to change the MAC > address that the card > has programmed into it, then yes you can change it, > but not perminatly. > The MAC address is hard-coded into the card, and is > restored on a reboot > if you change it. You can configure the machine to > use a MAC address that > you specify by using the option I've pasted below. > > This is from the ifconfig(8) man page: > > lladdr addr > Set the link-level address on an interface. > This can be used to > e.g. set a new MAC address on an ethernet > interface, though the > mechanism used is not ethernet-specific. The > address addr is > specified as a series of colon-separated hex > digits. If the > interface is already up when this option is > used, it will be > briefly brought down and then brought back > up again in order to > insure that the receive filter in the > underlying ethernet hard- > ware is properly reprogrammed. > > > Hope this helps. > > > On Thu, 14 Feb 2002, Vinod Namboodiri wrote: > > > Hi there.I am about to embark on a research > project > > wherein some changes need to be made in the MAC > layer > > of the TCP/IP stack.We have a wireless testbed > running > > on FreeBSD.I had a few doubts.can i make the > changes > > from the TCP/IP stack source code of FreeBSD?I > dont > > know much about the source code of the stack.or > would > > i need to be modifying the firmware of the > wireless > > network card which probably has the mac layer > code? > > > > Could use some help. > > Vinod > > > > > > __________________________________________________ > > Do You Yahoo!? > > Send FREE Valentine eCards with Yahoo! Greetings! > > http://greetings.yahoo.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-mobile" in the body of > the message > > > > > > __________________________________________________ Do You Yahoo!? Got something to say? Say it better with Yahoo! Video Mail http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 8:59:54 2002 Delivered-To: freebsd-net@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id 353C837B405; Fri, 15 Feb 2002 08:59:50 -0800 (PST) Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Postfix) with ESMTP id E92E05D09; Fri, 15 Feb 2002 08:59:49 -0800 (PST) To: Vinod Namboodiri Cc: Jason Hunt , freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: MAC Layer of TCP/IP stack In-reply-to: Your message of "Fri, 15 Feb 2002 08:20:56 PST." <20020215162056.49296.qmail@web21106.mail.yahoo.com> Date: Fri, 15 Feb 2002 08:59:49 -0800 From: "Kevin Oberman" Message-Id: <20020215165949.E92E05D09@ptavv.es.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Date: Fri, 15 Feb 2002 08:20:56 -0800 (PST) > From: Vinod Namboodiri > Sender: owner-freebsd-net@FreeBSD.ORG > > Not actually.Its more to run QoS experiments and need > to customize some medium access protocols like csma/ca > e.t.c.Guess i cant get to the csma protocol from the > freebsd tcp/ip stack source code. CSMA/CD is ALWAYS implemented on the card in microcode, usually in ROM and is totally untouchable from the standard API, let alone TCP or IP. The closest you can come is a total reload of the code and many cards don't support this. In the world of full-duplex Ethernet, there is no CSMA/CD and virtually no MAC. Only cards running half-duplex still use CSMA/CD. The specifics of CSMA/CD were in the original 802.3 specification and the rules have never changed since then (although they are broken). In wireless (802.11) protocols there is also no CSMA/CD as it is not applicable to wireless although there IS a MAC and it is usually loadable, though documentation and source is proprietary and general hard to get. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 9:18:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from gate.killian.com (gate.killian.com [205.179.65.162]) by hub.freebsd.org (Postfix) with ESMTP id 5ABB237B400; Fri, 15 Feb 2002 09:18:40 -0800 (PST) Received: (from smtp@localhost) by gate.killian.com (8.11.6/8.11.6) id g1FHIbJ37362; Fri, 15 Feb 2002 09:18:37 -0800 (PST) (envelope-from earl@killian.com) Received: from sax.killian.com(199.165.155.18) via SMTP by gate.killian.com, id smtpdXTvTxk; Fri Feb 15 09:18:29 2002 From: "Earl A. Killian" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.17124.999950.13271@sax.killian.com> Date: Fri, 15 Feb 2002 09:18:28 -0800 To: Chris Dillon Cc: "Rogier R. Mulhuijzen" , Michael Sierchio , Luigi Rizzo , , Subject: Re: Bug in stateful code? In-Reply-To: References: <5.1.0.14.0.20020214221354.01c37da0@mail.drwilco.net> X-Mailer: VM 7.00 under 21.4 (patch 5) "Civil Service" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Chris Dillon writes: > Date: Fri, 15 Feb 2002 10:20:39 -0600 (CST) > From: Chris Dillon > > If you have the luxury of having more than one IP address available > for the outside interface, you can dedicate one address to natd's use, > and the other to the host machine. Use -deny_incoming on natd, and > use whatever rules you want, including stateful, on the non-NAT > address. This is what I've done and it works fine. This sounds promising, but I am confused by the man page on -deny_incoming. Perhaps you could clarify? It says, "Do not pass incoming packets that have no entry in the internal translation table." Which internal translation table do they mean? If this is the translation table set up when an internal host packet is forwarded to the internet, I don't see how a connection ever gets established. Does "internal translation table" mean something else? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 9:30: 3 2002 Delivered-To: freebsd-net@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id 7536237B402 for ; Fri, 15 Feb 2002 09:29:55 -0800 (PST) Received: (qmail 3977 invoked from network); 15 Feb 2002 17:29:55 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 15 Feb 2002 17:29:55 -0000 Message-ID: <3C6D4592.8010809@tenebras.com> Date: Fri, 15 Feb 2002 09:29:54 -0800 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020131 X-Accept-Language: en-us MIME-Version: 1.0 To: Kevin Oberman Cc: Vinod Namboodiri , Jason Hunt , freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: MAC Layer of TCP/IP stack References: <20020215165949.E92E05D09@ptavv.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Kevin Oberman wrote: > In wireless (802.11) protocols there is also no CSMA/CD as it is not > applicable to wireless although there IS a MAC and it is usually > loadable, though documentation and source is proprietary and general > hard to get. 802.11 supports CSMA/CA, where the A stands for the avoidance algorithm -- CD is impossible where the transmit and receive antennas are coincident. And I don't know why you declare CSMA/CD rules to be "broken" -- they've worked surprisingly well since Metcalfe and Boggs devised Ethernet. The major problem as I see it is that the wait period is defined by the physical layer constraints (fixed time), whereas increasing bandwidth makes the wait time a higher and higher percentage of the bandwidth. There are certainly wireless cards that permit 802.11 raw frame processing by the host -- this is a great help to those miscreants who engage in the exercise of driving around and snooping on others' 802.11 nets with the excuse that they're "helping" the rest of us. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 9:39:56 2002 Delivered-To: freebsd-net@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id F402337B405 for ; Fri, 15 Feb 2002 09:39:37 -0800 (PST) Received: (qmail 4032 invoked from network); 15 Feb 2002 17:39:37 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 15 Feb 2002 17:39:37 -0000 Message-ID: <3C6D47D9.10003@tenebras.com> Date: Fri, 15 Feb 2002 09:39:37 -0800 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020131 X-Accept-Language: en-us MIME-Version: 1.0 To: "Earl A. Killian" Cc: Chris Dillon , "Rogier R. Mulhuijzen" , Luigi Rizzo , freebsd-ipfw@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Bug in stateful code? References: <5.1.0.14.0.20020214221354.01c37da0@mail.drwilco.net> <15469.17124.999950.13271@sax.killian.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Earl A. Killian wrote: > Chris Dillon writes: > > Date: Fri, 15 Feb 2002 10:20:39 -0600 (CST) > > From: Chris Dillon > > > > If you have the luxury of having more than one IP address available > > for the outside interface, you can dedicate one address to natd's use, > > and the other to the host machine. Use -deny_incoming on natd, and > > use whatever rules you want, including stateful, on the non-NAT > > address. This is what I've done and it works fine. > > This sounds promising, but I am confused by the man page on > -deny_incoming. Perhaps you could clarify? It says, "Do not pass > incoming packets that have no entry in the internal translation > table." Which internal translation table do they mean? If this is > the translation table set up when an internal host packet is forwarded > to the internet, I don't see how a connection ever gets established. > Does "internal translation table" mean something else? It's a 'natd' option, which says not to pass incoming packets (from the nat'd interface, presumably the external interface) which aren't part of established "connections" -- the internal translation table is internal to natd. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 9:49:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by hub.freebsd.org (Postfix) with ESMTP id AF4F037B400; Fri, 15 Feb 2002 09:49:37 -0800 (PST) Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Postfix) with ESMTP id 7A12F5D0C; Fri, 15 Feb 2002 09:49:37 -0800 (PST) To: Michael Sierchio Cc: Vinod Namboodiri , Jason Hunt , freebsd-net@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: MAC Layer of TCP/IP stack In-reply-to: Your message of "Fri, 15 Feb 2002 09:29:54 PST." <3C6D4592.8010809@tenebras.com> Date: Fri, 15 Feb 2002 09:49:37 -0800 From: "Kevin Oberman" Message-Id: <20020215174937.7A12F5D0C@ptavv.es.net> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Date: Fri, 15 Feb 2002 09:29:54 -0800 > From: Michael Sierchio > > Kevin Oberman wrote: > > > > In wireless (802.11) protocols there is also no CSMA/CD as it is not > > applicable to wireless although there IS a MAC and it is usually > > loadable, though documentation and source is proprietary and general > > hard to get. > > > 802.11 supports CSMA/CA, where the A stands for the > avoidance algorithm -- CD is impossible where the transmit and > receive antennas are coincident. > > And I don't know why you declare CSMA/CD rules to be "broken" -- they've > > worked surprisingly well since Metcalfe and Boggs devised Ethernet. > > The major problem as I see it is that the wait period is defined by > the physical layer constraints (fixed time), whereas increasing > bandwidth makes the wait time a higher and higher percentage of > the bandwidth. > > There are certainly wireless cards that permit 802.11 raw frame > processing by the host -- this is a great help to those miscreants > who engage in the exercise of driving around and snooping on > others' 802.11 nets with the excuse that they're "helping" the > rest of us. This is getting a bit off-topic, but the problem with the CSMA/CD algorithm is that it allows a single system to "sync" with the collision back-off and monopolize the link to the exclusion of other systems. This is not intentional hogging but a simple artifact of the mechanism interacting with a system sufficiently fast to always have the next frame ready to transmit immediately after the IFG. Because of the common use of switches which break up the collision domain, this is very seldom a problem and is never more than a minor annoyance unless something else is broken. This is well documented in some IEEE papers from back in the late 80s. The problem is in the collision back-off algorithm. A replacement called BLAM was proposed. It is fully interoperable with the 802.3 mechanism but would place system running it at a disadvantage in gaining access to a busy network. As a result, no vendor wanted to implement it. I don't think the 802.3 committee ever even considered adding it to the spec. I think Jeff Mogel at Digital did the work on this, but it is many years old and I no longer work with Ethernet at this level (and hardly at all except to plug in my computer) and I don't have a ready reference for all of the older stuff. (I do still have my trusty, if outdated copy of 802.3, though.) While many cards (both 802.3 and 802.11) allow the user to generate raw frames, this is not really a MAC adjustment. Things like collision handling, FCS and error generation are beyond what is normally available to the user. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 9:52:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from gate.killian.com (gate.killian.com [205.179.65.162]) by hub.freebsd.org (Postfix) with ESMTP id 53B8137B400; Fri, 15 Feb 2002 09:52:19 -0800 (PST) Received: (from smtp@localhost) by gate.killian.com (8.11.6/8.11.6) id g1FHqJc37544; Fri, 15 Feb 2002 09:52:19 -0800 (PST) (envelope-from earl@killian.com) Received: from sax.killian.com(199.165.155.18) via SMTP by gate.killian.com, id smtpdfIvb0i; Fri Feb 15 09:52:13 2002 From: "Earl A. Killian" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.19149.677645.220962@sax.killian.com> Date: Fri, 15 Feb 2002 09:52:13 -0800 To: "Michael Sierchio" Cc: "Chris Dillon" , "Rogier R. Mulhuijzen" , "Luigi Rizzo" , freebsd-ipfw@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Bug in stateful code? In-Reply-To: <3C6D47D9.10003@tenebras.com> References: <5.1.0.14.0.20020214221354.01c37da0@mail.drwilco.net> <15469.17124.999950.13271@sax.killian.com> <3C6D47D9.10003@tenebras.com> X-Mailer: VM 7.00 under 21.4 (patch 5) "Civil Service" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Michael Sierchio writes: > Date: Fri, 15 Feb 2002 09:39:37 -0800 > From: Michael Sierchio > > It's a 'natd' option, which says not to pass incoming packets (from > the nat'd interface, presumably the external interface) which > aren't part of established "connections" -- the internal translation > table is internal to natd. So then I'm asking how does anything ever get into that table, if incoming packets are all denied? Are SYN packets exempted from -deny_incoming? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 10:14:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id 4476E37B402 for ; Fri, 15 Feb 2002 10:14:39 -0800 (PST) Received: (qmail 4153 invoked from network); 15 Feb 2002 18:14:38 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 15 Feb 2002 18:14:38 -0000 Message-ID: <3C6D500E.50609@tenebras.com> Date: Fri, 15 Feb 2002 10:14:38 -0800 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020131 X-Accept-Language: en-us MIME-Version: 1.0 To: "Earl A. Killian" Cc: Chris Dillon , "Rogier R. Mulhuijzen" , Luigi Rizzo , freebsd-ipfw@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Bug in stateful code? References: <5.1.0.14.0.20020214221354.01c37da0@mail.drwilco.net> <15469.17124.999950.13271@sax.killian.com> <3C6D47D9.10003@tenebras.com> <15469.19149.677645.220962@sax.killian.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Earl A. Killian wrote: > So then I'm asking how does anything ever get into that table, if > incoming packets are all denied? Are SYN packets exempted from > -deny_incoming? No, SYN packets aren't exempted. Incoming packets that are associated with a pre-existing connection (or attempt) originating from the inside are permitted. The other option is to set '-target_address', which would redirect such incoming packets to a particular address. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 10:34:29 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 96C0937B404; Fri, 15 Feb 2002 10:34:08 -0800 (PST) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id MAA05061; Fri, 15 Feb 2002 12:34:00 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Fri, 15 Feb 2002 12:33:58 -0600 (CST) From: Chris Dillon To: "Earl A. Killian" Cc: "Rogier R. Mulhuijzen" , Michael Sierchio , Luigi Rizzo , , Subject: Re: Bug in stateful code? In-Reply-To: <15469.17124.999950.13271@sax.killian.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 15 Feb 2002, Earl A. Killian wrote: > Chris Dillon writes: > > Date: Fri, 15 Feb 2002 10:20:39 -0600 (CST) > > From: Chris Dillon > > > > If you have the luxury of having more than one IP address available > > for the outside interface, you can dedicate one address to natd's use, > > and the other to the host machine. Use -deny_incoming on natd, and > > use whatever rules you want, including stateful, on the non-NAT > > address. This is what I've done and it works fine. > > This sounds promising, but I am confused by the man page on > -deny_incoming. Perhaps you could clarify? It says, "Do not pass > incoming packets that have no entry in the internal translation > table." Which internal translation table do they mean? The translation table in natd. The -deny-incoming option is designed to deny incoming connections to the host, not the internal machines. By design you can't create an incoming connection to internal machines without redirect rules in place anyway. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 14:57: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10]) by hub.freebsd.org (Postfix) with ESMTP id 3EA8737B417 for ; Fri, 15 Feb 2002 14:56:49 -0800 (PST) Received: from there (eq.net [208.186.104.163]) by ns1.infowest.com (Postfix) with SMTP id DBAB521CE8; Fri, 15 Feb 2002 15:56:47 -0700 (MST) Content-Type: text/plain; charset="iso-8859-1" From: "Aaron D. Gifford" To: freebsd-net@freebsd.org Subject: Re: Bug in stateful code? Date: Fri, 15 Feb 2002 15:56:46 -0700 X-Mailer: KMail [version 1.3.2] Cc: kudzu@tenebras.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020215225647.DBAB521CE8@ns1.infowest.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I use stateful rules and natd together without any trouble. You just have to think through VERY carefully exactly what is happening to each and every packet during it's journey and write your rules accordingly. Let's look at your example ruleset, Michael: Michael Sierchio (kudzu@tenebras.com) wrote: >$on = external net = X.Y.Z/24 >$in = internal net = A.B.C/24 (192.168.1.0/24) > >the external IP is X.Y.Z.23 >the internal IP is A.B.C.1 > >firewall rules: > >[some static rules...] > >$fw add divert natd ip from any to any via $external_interface > >$fw add check-state > >$fw add allow tcp from $in to any setup keep-state >$fw add allow udp from $in to any keep-state > >$fw add allow tcp from $on to any setup keep-state >$fw add allow udp from $on to any keep-state > >An ssh connection from A.B.C.4 to X.Y.Z.44 causes the following dynamic rules >to appear: > >02400 15 3197 (T 16, slot 760) <-> tcp, X.Y.Z.23 1549<-> X.Y.Z.44 22 >02200 45 9151 (T 296, slot 913) <-> tcp, A.B.C.4 1549<-> X.Y.Z.44 22 After carefully reading your above rules, I can assure you that you're NOT seeing a bug at all, and what you see is what I expect SHOULD be happening. Let's follow a SYN, SYN-ACK, ACK three-way TCP handshake through your ruleset: Your SYN packet from INSIDE to OUTSIDE first traverses your ruleset IN VIA your internal interface. It MATCHES your rule: "$fw add allow tcp from $in to any setup keep-state" This adds the dynamic rule you see as "A.B.C.4 1549<-> X.Y.Z.44 22". Next, your packet goes through the list again, this time OUT VIA your external interface. It matches your NAT divert rule, the source address of the SYN packet gets changed from A.B.C.4 to A.B.C.1. This now modified packet does NOT MATCH the check-state because the source address differs. So this same SYN packet now matches this rule: "$fw add allow tcp from $on to any setup keep-state" That's the other dynamic rule you see as "X.Y.Z.23 1549<-> X.Y.Z.44 22" Now let's trace the SYN-ACK packet from X.Y.Z.44 port 22 back to your inside machine. It enters IPFW as a packet IN VIA your external interface, so this packet immediately matches your NAT divert rule and is rewritten with a DESTINATION address of "A.B.C.D 1549". This reply packet will NEVER hit your check-state, and that's why the dynamic rule "X.Y.Z.23 1549<-> X.Y.Z.44 22" stays in the SYN state until it times out. Continuing on, the now translated SYN/ACK now hits the check-state and MATCHES the dynamic rule "A.B.C.4 1549<-> X.Y.Z.44 22" and that rule's timeout is updated just fine. Now you your inside source sends an ACK packet back to complete the 3-way handshake. This ACK enters as an IN VIA internal interface packet. It doesn't match the NAT divert, but it DOES match the "A.B.C.4 1549<-> X.Y.Z.44 22" check-state rule, and updates the dynamic rule's timeout. Next it enters your ruleset OUT VIA your external interface, hits the NAT divert, and gets translated. It then continues through the rules. When it hits check-state, while it DOES match the "X.Y.Z.23 1549<-> X.Y.Z.44 22" dynamic rule in principal, it FAILS to match because the dynamic rule is expecting to see a SYN-ACK response from the remote host FIRST (remember, the SYN-ACK never matched this particular dynamic rule). Thus this dynamic rule STILL sits, expecting SYN-ACK. Since no further rules match, if you default to deny, your ACK packet gets dropped/denied. Is this the behavior you are seeing? If anyone is interested, I'd be happy to post my ipfw rules I use at home. I have a single Internet visible IP and a few hosts translated sitting behind it on a broadband connection. Aaron out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 15: 3:22 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10]) by hub.freebsd.org (Postfix) with ESMTP id 2979637B405 for ; Fri, 15 Feb 2002 15:03:17 -0800 (PST) Received: from there (eq.net [208.186.104.163]) by ns1.infowest.com (Postfix) with SMTP id B0CB52159D; Fri, 15 Feb 2002 16:03:16 -0700 (MST) Content-Type: text/plain; charset="iso-8859-1" From: "Aaron D. Gifford" To: freebsd-net@freebsd.org Subject: Re: Bug in stateful code? Date: Fri, 15 Feb 2002 16:03:16 -0700 X-Mailer: KMail [version 1.3.2] Cc: drwilco@drwilco.net MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020215230316.B0CB52159D@ns1.infowest.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Rogier R. Mulhuijzen" (drwilco@drwilco.net) was heard to say: >>>the reply was that keep-state and natd are very hard to use >>>together, and besides it is rather useless because natd is stateful >>>by itself. >>natd is stateful, but provides no protection for inbound IP traffic >>that is destined for the filtering host itself. > >I have personally looked at natd & stateful ipfw rules, and have concluded >that it logically impossible to get it to work. > >Thus I made a ipfw rulelist that utilizes the statefulness of natd. I hope >this helps you in making your own rulelist. > Actually you CAN use both together, but there's really no reason to do so. One would be duplicating things, since NAT is effectively a stateful filter of sorts. One just has to think things through very carefully, following the flow of packets through the ruleset. My own ruleset I use at home shares some similarities with your set, Rogier. For NAT traffic, I don't use stateful rules -- I let NAT track the state, but for traffic to/from my gateway host, I still use stateful rules. But, the way my ruleset is written, I could drop stateful rules in for the NAT traffic without a hitch. But it would be wasted duplication of effort for the most part. Aaron out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 16: 0: 7 2002 Delivered-To: freebsd-net@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id 2741E37B404 for ; Fri, 15 Feb 2002 16:00:02 -0800 (PST) Received: (qmail 4816 invoked from network); 16 Feb 2002 00:00:00 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 16 Feb 2002 00:00:00 -0000 Message-ID: <3C6DA100.3080108@tenebras.com> Date: Fri, 15 Feb 2002 16:00:00 -0800 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020131 X-Accept-Language: en-us MIME-Version: 1.0 To: "Aaron D. Gifford" Cc: freebsd-net@freebsd.org Subject: Re: Bug in stateful code? References: <20020215225647.DBAB521CE8@ns1.infowest.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Aaron D. Gifford wrote: > When it hits check-state, while it DOES match the "X.Y.Z.23 1549<-> X.Y.Z.44 > 22" dynamic rule in principal, it FAILS to match because the dynamic rule is > expecting to see a SYN-ACK response from the remote host FIRST (remember, the > SYN-ACK never matched this particular dynamic rule). Thus this dynamic rule > STILL sits, expecting SYN-ACK. > > Since no further rules match, if you default to deny, your ACK packet gets > dropped/denied. > > Is this the behavior you are seeing? The packet is never dropped, it's just that -- as Crist previously pointed out -- it matches an earlier rule, so it never changes the state of the dynamic rule in question. It's sometimes useful to use 'add count' rules before and after 'divert natd' to see what's happening. > If anyone is interested, I'd be happy to post my ipfw rules I use at home. I > have a single Internet visible IP and a few hosts translated sitting behind > it on a broadband connection. I elected to try Chris Dillon's suggestion, since I have two IPs on my external interface, and can dedicate one to NAT and use stateful rules on the other -- with the minor complication that this host is running both tinydns and dnscache (the latter for my own hosts), and so I still need a few allow rules before 'divert natd' -- all of which seem straightforward now. All of this mess was the result of changing ISPs and having, instead of a nice little /29 subnet, discontiguous addresses on a bridged SDSL connection. Ack. Ppppt. Thanks to Chris, Crist, Aaron and Luigi. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 17:16: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10]) by hub.freebsd.org (Postfix) with ESMTP id 9638C37B400 for ; Fri, 15 Feb 2002 17:15:54 -0800 (PST) Received: from there (eq.net [208.186.104.163]) by ns1.infowest.com (Postfix) with SMTP id 79227214BC; Fri, 15 Feb 2002 18:15:53 -0700 (MST) Content-Type: text/plain; charset="iso-8859-1" From: "Aaron D. Gifford" To: freebsd-net@freebsd.org Subject: Re: Bug in stateful code? Date: Fri, 15 Feb 2002 18:15:52 -0700 X-Mailer: KMail [version 1.3.2] References: <20020215225647.DBAB521CE8@ns1.infowest.com> <3C6DA100.3080108@tenebras.com> In-Reply-To: <3C6DA100.3080108@tenebras.com> Cc: kudzu@tenebras.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020216011553.79227214BC@ns1.infowest.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Friday 15 February 2002 05:00 pm, Michael Sierchio wrote: > Aaron D. Gifford wrote: > > When it hits check-state, while it DOES match the "X.Y.Z.23 1549<-> > > X.Y.Z.44 22" dynamic rule in principal, it FAILS to match because the > > dynamic rule is expecting to see a SYN-ACK response from the remote host > > FIRST (remember, the SYN-ACK never matched this particular dynamic rule). > > Thus this dynamic rule STILL sits, expecting SYN-ACK. > > > > Since no further rules match, if you default to deny, your ACK packet > > gets dropped/denied. > > > > Is this the behavior you are seeing? > > The packet is never dropped, it's just that -- as Crist previously > pointed out -- it matches an earlier rule, so it never changes > the state of the dynamic rule in question. It's sometimes useful to > use 'add count' rules before and after 'divert natd' to see what's > happening. > Okay, I understand now. You're saying that the last packet of the three-way TCP handshake (the SYN+ACK from the INSIDE to the OUTSIDE) is NOT dropped, but passed by the "X.Y.Z.23 1549<-> X.Y.Z.44 22" rule WITHOUT that rule being updated. That indeed is a bug. Reading the code in /usr/src/sys/netinet/ip_fw.c (on my 4.5-STABLE box), I see where the problem is. Around line 780, there is a switch()/case: statement that handles normal TCP states. Because of your ruleset, you have created a dynamic rule that only sees the INSIDE-to-OUTSIDE packets but will NEVER see the reverse packets (the other dynamic rule your original post mentions will behave normally, seeing the packets in BOTH directions). The current ip_fw.c code there, in this case will PASS the matched packet, and update the timeout using dyn_rst_lifetime because it falls through the switch() statement to the default: section. I don't know what the correct "fix" is. My gut instinct is that ifpw's default: seciton (line 798) should just reject/drop the packet (return NULL) instead of what it does today, passing the packet with a very short timeout. If there are valid states that are not yet handled, they should be added and handled. Perhaps a useful solution to the bug that might have helped warn you in your specific situation would be to detect such half-seen behavior in the default case, and log a warning, since this is likely to be a common problem with anyone using ipfw stateful rules and natd. Something like: default: if (q->state == TH_SYN | TH_ACK) /* * Both forward SYN and SYN+ACK packets have been seen, * without a reverse SYN+ACK packet in between, due to a * buggy rule set, or bogus traffic from the originating host. */ if (fw_verbose) { log(LOG_SECURITY | LOG_NOTICE, "ipfw: Invalid stateful TCP rule (from %d): Middle packet " "missing from three-way TCP handshake.", q->parent->fw_number); return NULL; /* Drop the packet as if not matched */ } If you'd seen such a warning right away, without it passing your packets, you would have known it was a ruleset problem, or else asked someone on the list about the error message in the logs. Thoughts? Aaron out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 17:43:43 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10]) by hub.freebsd.org (Postfix) with ESMTP id 1F46F37B402 for ; Fri, 15 Feb 2002 17:43:36 -0800 (PST) Received: from there (eq.net [208.186.104.163]) by ns1.infowest.com (Postfix) with SMTP id AE41B213CA for ; Fri, 15 Feb 2002 18:43:35 -0700 (MST) Content-Type: text/plain; charset="iso-8859-1" From: "Aaron D. Gifford" To: freebsd-net@freebsd.org Subject: Re: Bug in stateful code? Date: Fri, 15 Feb 2002 18:43:35 -0700 X-Mailer: KMail [version 1.3.2] References: <20020215225647.DBAB521CE8@ns1.infowest.com> <3C6DA100.3080108@tenebras.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020216014335.AE41B213CA@ns1.infowest.com> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Friday 15 February 2002 06:15 pm, I was heard to blurt out without thinking: > default: > if (q->state == TH_SYN | TH_ACK) > /* > * Both forward SYN and SYN+ACK packets have been seen, > * without a reverse SYN+ACK packet in between, due to a > * buggy rule set, or bogus traffic from the originating host. > */ > if (fw_verbose) { > log(LOG_SECURITY | LOG_NOTICE, > "ipfw: Invalid stateful TCP rule (from %d): Middle packet " > "missing from three-way TCP handshake.", > q->parent->fw_number); > return NULL; /* Drop the packet as if not matched */ > } Heh, I MEANT to say: default: if (q->state == (TH_SYN | TH_ACK)) { /* * Both forward SYN and ACK packets have been seen, without * a reverse SYN+ACK packet in between, likely due to either * a buggy rule set, or bogus traffic. */ if (fw_verbose) { log(LOG_SECURITY | LOG_NOTICE, "ipfw: Invalid stateful TCP rule (from %d): Middle " "packet missing from three-way TCP handshake.", q->rule->fw_number); return NULL; /* Drop it as if not matched */ } } There. I don't know why I was calling the third packet a SYN+ACK in the comments. The original also was missing some parenthesis, and used an incorrect field name (q->parent->fw_number instead of q-.rule->fw_number). Sorry. Comes from leaping before looking, I supppose. Aaron out. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 18:18:32 2002 Delivered-To: freebsd-net@freebsd.org Received: from patrocles.silby.com (d165.as4.nwbl0.wi.voyager.net [169.207.139.39]) by hub.freebsd.org (Postfix) with ESMTP id DFA9437B402 for ; Fri, 15 Feb 2002 18:18:28 -0800 (PST) Received: from localhost (silby@localhost) by patrocles.silby.com (8.11.6/8.11.6) with ESMTP id g1FKMJA05512; Fri, 15 Feb 2002 20:22:21 GMT (envelope-from silby@silby.com) X-Authentication-Warning: patrocles.silby.com: silby owned process doing -bs Date: Fri, 15 Feb 2002 20:22:18 +0000 (GMT) From: Mike Silbersack To: murthy kn Cc: net@freebsd.org Subject: Re: ~40 DupAcks And No Fast Retransmit !! In-Reply-To: Message-ID: <20020215202131.L3087-100000@patrocles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 12 Feb 2002, murthy kn wrote: > Hello all, > > I am using 4.3 BSD and from the below capture, I feel > that there is some problem with the Fast Retransmit (unless > I am missing something). I also recall that there was > a short thread about some problems with Fast Retransmit > earlier in Nov 2001 - that sender was resorting to > the costly Retransmission timeout even after receiving > many DupAcks. Ok, I'll look at this in depth when I get some time. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Fri Feb 15 19:33:33 2002 Delivered-To: freebsd-net@freebsd.org Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by hub.freebsd.org (Postfix) with SMTP id 62F2437B400 for ; Fri, 15 Feb 2002 19:33:30 -0800 (PST) Received: (qmail 3313 invoked from network); 16 Feb 2002 03:33:29 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (66.92.188.241) by 0 with SMTP; 16 Feb 2002 03:33:29 -0000 Message-ID: <3C6DD308.8030009@tenebras.com> Date: Fri, 15 Feb 2002 19:33:28 -0800 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020131 X-Accept-Language: en-us MIME-Version: 1.0 To: "Aaron D. Gifford" Cc: freebsd-net@freebsd.org Subject: Re: Bug in stateful code? References: <20020215225647.DBAB521CE8@ns1.infowest.com> <3C6DA100.3080108@tenebras.com> <20020216014335.AE41B213CA@ns1.infowest.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org see Crist's response for an accurate description of effect on the stateful rules of natd. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13412+0+current/freebsd-net I revised my ruleset, with a few tricks, to use one IP address for nat and one for the local host's stateful rules. This works, though I had to use a couple of skipto rules (GOTO rules!). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 16 5: 9:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id B2C7D37B402 for ; Sat, 16 Feb 2002 05:09:46 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020216130946.CTIX2951.rwcrmhc53.attbi.com@blossom.cjclark.org>; Sat, 16 Feb 2002 13:09:46 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g1GD9jX48327; Sat, 16 Feb 2002 05:09:45 -0800 (PST) (envelope-from cjc) Date: Sat, 16 Feb 2002 05:09:45 -0800 From: "Crist J. Clark" To: Tariq Rashid Cc: freebsd-net@FreeBSD.ORG Subject: Re: kernel source for reading from divert sockets Message-ID: <20020216050945.H36782@blossom.cjclark.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tariq@inty.net on Fri, Feb 15, 2002 at 03:29:04PM -0000 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Feb 15, 2002 at 03:29:04PM -0000, Tariq Rashid wrote: > > can anyone point me to the kernel source where packets are taken from the > DIVERT socket (natd puts them there) - > > i'm finding that sendto() is taking most of the CPU - so i want to have a > look at maybe taking two or three packets from the DIVERT buffer per kernel > loop. > > (i'm not an expert at this by ny means - so useful help would be great!) Look in sys/netinet. ip_divert.c, ip_input.c, and ip_output.c are good starts. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 16 13:16:48 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns.live.com (ns.live.com [66.80.62.34]) by hub.freebsd.org (Postfix) with ESMTP id D6B4537B416 for ; Sat, 16 Feb 2002 13:16:42 -0800 (PST) Received: (from rsf@localhost) by ns.live.com (8.9.3/8.9.3) id NAA01248; Sat, 16 Feb 2002 13:16:42 -0800 (PST) (envelope-from rsf) Message-Id: <4.3.1.1.20020216130038.00babc30@localhost> X-Sender: rsf@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 16 Feb 2002 13:16:40 -0800 To: freebsd-net@FreeBSD.ORG From: Ross Finlayson Subject: nd6_rtrequest: bad gateway value: stf0 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have tried to configure my system (FreeBSD 4.5-STABLE) for 6to4, using the "stf" interface, but am getting the error message "nd6_rtrequest: bad gateway value: stf0" in my log, whenever I try to 'ping6' a remote IPv6 address. My kernel configuration contains: options INET6 pseudo-device stf My "rc.conf" contains: ifconfig_dc0="inet 66.80.62.34/29" ... ipv6_enable="YES" ipv6_gateway_enable="YES" ipv6_ifconfig_dc0="2002:4250:3e22 prefixlen 45" stf_interface_ipv4addr="66.80.62.34" # Note: 66.80.62.34 == 4250:3e22 ipv6_defaultrouter="2002:c058:6301::" "ifconfig" returns (for stf0): stf0: flags=1 mtu 1280 inet6 2002:4250:3e22::1 prefixlen 16 "netstat -r" returns (for Internet6): Internet6: Destination Gateway Flags Netif Expire :: localhost.live.com UGRSc lo0 => default 2002:c058:6301:: UGSc stf0 localhost.live.com localhost.live.com UH lo0 ::ffff:0.0.0.0 localhost.live.com UGRSc lo0 2002:: localhost.live.com UGRSc lo0 => 2002:: 2002:4250:3e22::1 Uc stf0 2002:4250:3e22::1 link#8 UHL lo0 2002:7f00:: localhost.live.com UGRSc lo0 2002:e000:: localhost.live.com UGRSc lo0 2002:ff00:: localhost.live.com UGRSc lo0 ... Is there anything obvious that I'm doing wrong? Ross. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 16 13:27:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from eagle.sasktel.net (eagle.sasktel.net [142.165.19.3]) by hub.freebsd.org (Postfix) with ESMTP id 0537637B402 for ; Sat, 16 Feb 2002 13:27:21 -0800 (PST) Received: from sk.sympatico.ca (regnsk01d050201233.sk.sympatico.ca [142.165.25.233]) by eagle.sasktel.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GRN000EBA9DRS@eagle.sasktel.net> for freebsd-net@freebsd.org; Sat, 16 Feb 2002 15:27:15 -0600 (CST) Content-return: allowed Date: Sat, 16 Feb 2002 15:27:14 -0600 From: TOPCAT CONSULTING Subject: dual NAT setup; physical layer question To: freebsd-net@freebsd.org Message-id: <3C6ECEB1.2388E8B0@sk.sympatico.ca> MIME-version: 1.0 X-Mailer: Mozilla 4.08 [en] (X11; I; FreeBSD 3.1-RELEASE i386) Content-type: multipart/mixed; boundary="Boundary_(ID_qSQRql1OOFFrPHEv4651NQ)" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --Boundary_(ID_qSQRql1OOFFrPHEv4651NQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I have been assigned two static Class B IP addresses from my ISP, but I only have a single physical cable coming in. I would like to build 2 independent firewalled networks. I'm very inexperienced in NAT and would appreciate comments/suggestions/alternatives on how I have envisioned this to work. Many thanks in advance. --Boundary_(ID_qSQRql1OOFFrPHEv4651NQ) Content-type: text/plain; charset=us-ascii; name=plan.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=plan.txt ISP | | coax_cable | pc1 | | | --| |-- | Cable |------NIC1 | nat | NIC2---------HUB-----pc2 Modem | --| |-- | | | | | | pc3 | | UTP_cable | | | | | | | | | | | HUB----------| FIREWALL (ipfw) | | | | | | | | pc4 | | | --| |-- | |------NIC3 | nat | NIC4--------HUB-----pc5 --| |-- | | pc5 where NIC1 = 142.165.x.x and NIC2 = 10.0.0.x where NIC3 = 142.165.x.x and NIC4 = 192.168.x.x --Boundary_(ID_qSQRql1OOFFrPHEv4651NQ)-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 16 17:25:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from topaz.mdcc.cx (topaz.mdcc.cx [212.204.230.141]) by hub.freebsd.org (Postfix) with ESMTP id DF0CA37B404; Sat, 16 Feb 2002 17:25:27 -0800 (PST) Received: from k7.mavetju.org (topaz.mdcc.cx [212.204.230.141]) by topaz.mdcc.cx (Postfix) with ESMTP id 4E5522B6AF; Sun, 17 Feb 2002 02:25:24 +0100 (CET) Received: by k7.mavetju.org (Postfix, from userid 1001) id DBA0B42B; Sun, 17 Feb 2002 12:25:10 +1100 (EST) Date: Sun, 17 Feb 2002 12:25:10 +1100 From: Edwin Groothuis To: Miguel Mendez Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPv6-over-IPv4 problems since the upgrade to 4.5 Message-ID: <20020217122510.D491@k7.mavetju.org> Mail-Followup-To: Edwin Groothuis , Miguel Mendez , freebsd-hackers@freebsd.org, freebsd-net@freebsd.org References: <0D9185CE635BD511ACA50090277A6FCF1359DB@axcs18.cos.agilent.com> <20020216130842.A19081@energyhq.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020216130842.A19081@energyhq.homeip.net>; from flynn@energyhq.homeip.net on Sat, Feb 16, 2002 at 01:08:42PM +0100 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, Feb 16, 2002 at 01:08:42PM +0100, Miguel Mendez wrote: > On Fri, Feb 15, 2002 at 05:14:31PM -0700, DOROVSKOY,IGOR (A-Portsmouth,ex1) wrote: > I recently installed the freenet6 port to test IPv6 and have been > experiencing similar problems, I can ping6 any host but my ftp > connections stall at some point. > > As an alternative you can use Hurricane Electric's free tunnel. I'm > using it now and it works like a champ. I found what caused this. he.net uses the "route add -inet6 default " statement while freenet6.net uses "route add -inet6 default -interface gif0" statement. I've submitted a patch for this port to keep it working, I don't know what to do with the route-command. I'll write a PR about it. Thanks for your hints! Edwin -- Edwin Groothuis | Personal website: http://www.MavEtJu.org edwin@mavetju.org | Interested in MUDs? Visit Fatal Dimensions: ------------------+ http://www.FatalDimensions.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 16 19:56:30 2002 Delivered-To: freebsd-net@freebsd.org Received: from email.seznam.cz (smtp.seznam.cz [195.119.180.43]) by hub.freebsd.org (Postfix) with SMTP id 1F1DB37B405 for ; Sat, 16 Feb 2002 19:56:25 -0800 (PST) Received: (qmail 10213 invoked from network); 17 Feb 2002 03:56:24 -0000 Received: from linux.sux.cz (HELO notes) (62.24.72.206) by smtp.seznam.cz with SMTP; 17 Feb 2002 03:56:24 -0000 Message-ID: <004101c1b766$cee780b0$0500a8c0@notes> From: "Zviratko" To: Subject: Ethernet bonding/load balancing on fbsd 4-stable Date: Sun, 17 Feb 2002 04:54:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, is there a preferred way to do ethernet load balancing? My situation is - 2 cable modems connected to two ethernet cards on with a machine functioning as a NAT gateway for LAN. I tried netgraph (ng_ether with round robin and ng_fec). With ng_ether, I achieved packets being sent via one interface and received on another one(not what I want), ng_fec didn't work at all (it just silently dropped all outgoing packets). Is there another way? I already did this with linux (by using bond.c similiar to ng_fec) and it worked under the same conditions. Any advice would be appreciated. Zviratko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 16 20:29: 0 2002 Delivered-To: freebsd-net@freebsd.org Received: from alumni.deec.uc.pt (alumni.deec.uc.pt [193.136.238.200]) by hub.freebsd.org (Postfix) with ESMTP id 7F8C137B400 for ; Sat, 16 Feb 2002 20:28:52 -0800 (PST) Received: (from root@localhost) by alumni.deec.uc.pt (8.11.6/8.11.2) id g1H4Skt01583 for freebsd-net@freebsd.org; Sun, 17 Feb 2002 04:28:46 GMT (envelope-from slug@alumni.deec.uc.pt) Received: from localhost (slug@localhost) by alumni.deec.uc.pt (8.11.6/8.11.1av) with ESMTP id g1H4SjV01575 for ; Sun, 17 Feb 2002 04:28:45 GMT (envelope-from slug@alumni.deec.uc.pt) X-Authentication-Warning: alumni.deec.uc.pt: slug owned process doing -bs Date: Sun, 17 Feb 2002 04:28:45 +0000 (WET) From: Nuno Miguel Fernandes Sucena Almeida To: freebsd-net@freebsd.org Subject: getifaddrs usage (bug?) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS perl-10 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, i'm using getifaddrs to get the IP and HW address of an ethernet interface but it seems that the ifap->ifa_next pointer is never NULL so I end up with an infinite loop! If i uncomment the // printf's I get the HW address correctly but after that I get the IP address repeated ad eternum! Any ideas ? ()s Nuno Sucena PS: Please CC to me since i'm not subscribed in this list. i have something like: struct ifaddrs *ifap,*current; /* man getifaddrs */ struct sockaddr_dl *e_tmp; struct sockaddr_in *i_tmp; (...) error = getifaddrs (&ifap); if (error!=0) { perror("getifaddrs()"); return(EXIT_FAILURE); } current = ifap; while (current!=NULL) { if ((strcmp(current->ifa_name,device)==0)&& (((current->ifa_flags)&IFF_UP)==IFF_UP)&& (current->ifa_addr!=NULL)) { /* ethernet physical address - */ e_tmp = (struct sockaddr_dl*)current->ifa_addr; if (e_tmp->sdl_family==AF_LINK) { /* hope that sdl_alen < ETHER_ADDR_LEN ;) */ memcpy(*eth_address,LLADDR(e_tmp),e_tmp->sdl_alen); // printf("ethernet: %s\n",ethernet_print (*eth_address)); got_eth=1; } /* ethernet IP address - */ i_tmp = (struct sockaddr_in*)current->ifa_addr; if (i_tmp->sin_family==AF_INET) { ip_address->s_addr = i_tmp->sin_addr.s_addr; // printf ("%s\n",inet_ntoa(*ip_address)); got_ip=1; } } current = ifap->ifa_next; } freeifaddrs(ifap); (...) -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 16 20:42:24 2002 Delivered-To: freebsd-net@freebsd.org Received: from zephir.primus.ca (mail.tor.primus.ca [216.254.136.21]) by hub.freebsd.org (Postfix) with ESMTP id 6255937B405 for ; Sat, 16 Feb 2002 20:42:21 -0800 (PST) Received: from dialin-140-110.hamilton.primus.ca ([209.90.140.110]) by zephir.primus.ca with esmtp (Exim 3.33 #12) id 16bVSV-0008CL-0A; Thu, 14 Feb 2002 18:38:35 -0500 Date: Thu, 14 Feb 2002 18:38:36 -0500 (EST) From: Jason Hunt X-X-Sender: leth@lethargic.dyndns.org To: freebsd-net@FreeBSD.ORG Cc: Vinod Namboodiri Subject: Re: MAC Layer of TCP/IP stack In-Reply-To: <20020214221615.23759.qmail@web21101.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If you mean that you would like to change the MAC address that the card has programmed into it, then yes you can change it, but not perminatly. The MAC address is hard-coded into the card, and is restored on a reboot if you change it. You can configure the machine to use a MAC address that you specify by using the option I've pasted below. This is from the ifconfig(8) man page: lladdr addr Set the link-level address on an interface. This can be used to e.g. set a new MAC address on an ethernet interface, though the mechanism used is not ethernet-specific. The address addr is specified as a series of colon-separated hex digits. If the interface is already up when this option is used, it will be briefly brought down and then brought back up again in order to insure that the receive filter in the underlying ethernet hard- ware is properly reprogrammed. Hope this helps. On Thu, 14 Feb 2002, Vinod Namboodiri wrote: > Hi there.I am about to embark on a research project > wherein some changes need to be made in the MAC layer > of the TCP/IP stack.We have a wireless testbed running > on FreeBSD.I had a few doubts.can i make the changes > from the TCP/IP stack source code of FreeBSD?I dont > know much about the source code of the stack.or would > i need to be modifying the firmware of the wireless > network card which probably has the mac layer code? > > Could use some help. > Vinod > > > __________________________________________________ > Do You Yahoo!? > Send FREE Valentine eCards with Yahoo! Greetings! > http://greetings.yahoo.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-mobile" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 16 21: 2:25 2002 Delivered-To: freebsd-net@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 4924337B405 for ; Sat, 16 Feb 2002 21:02:23 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 203A8AE4AC; Sat, 16 Feb 2002 21:02:18 -0800 (PST) Date: Sat, 16 Feb 2002 21:02:18 -0800 From: Alfred Perlstein To: Nuno Miguel Fernandes Sucena Almeida Cc: freebsd-net@freebsd.org Subject: Re: getifaddrs usage (bug?) Message-ID: <20020217050218.GE12136@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Nuno Miguel Fernandes Sucena Almeida [020216 20:29] wrote: > Hello, > i'm using getifaddrs to get the IP and HW address of an ethernet > interface but it seems that the ifap->ifa_next pointer is never NULL so I > end up with an infinite loop! If i uncomment the // printf's I get the > HW address correctly but after that I get the IP address repeated ad > eternum! Any ideas ? > current = ifap->ifa_next; should be: current = current->ifa_next; I also do birthdays and Bar Mitvahs, let me know. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message From owner-freebsd-net Sat Feb 16 21:13:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from ns.live.com (ns.live.com [66.80.62.34]) by hub.freebsd.org (Postfix) with ESMTP id B047137B404 for ; Sat, 16 Feb 2002 21:13:57 -0800 (PST) Received: (from rsf@localhost) by ns.live.com (8.9.3/8.9.3) id VAA00286; Sat, 16 Feb 2002 21:13:57 -0800 (PST) (envelope-from rsf) Message-Id: <4.3.1.1.20020216201023.00af8f00@localhost> X-Sender: rsf@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 16 Feb 2002 21:12:58 -0800 To: freebsd-net@FreeBSD.ORG From: Ross Finlayson Subject: Re: nd6_rtrequest: bad gateway value: stf0 In-Reply-To: <4.3.1.1.20020216130038.00babc30@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Following up on my own question... I took at look at the code (/usr/src/sys/netinet6/nd6.c line 1185) where this message is printed. From what I can tell, the message is being printed only because the interface (stf0) is an "AF_INET6" rather than a "AF_LINK". It's not clear to me whether there's even a real error occurring here - and it turns out that I am able to communicate with other IPv6 nodes (both 6to4 and native) just fine. Can anyone who's familiar with this code confirm whether or not this message is just a red herring? Ross. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message