From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 00:34:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E454106566C for ; Sun, 2 Mar 2008 00:34:34 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by mx1.freebsd.org (Postfix) with ESMTP id 4D2298FC16 for ; Sun, 2 Mar 2008 00:34:34 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5E06F5A7461; Sat, 1 Mar 2008 22:34:37 -0200 (ARDT) Received: from notebook.gont.com.ar (201-254-62-65.speedy.com.ar [201.254.62.65] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m220YJ6t018608; Sat, 1 Mar 2008 22:34:19 -0200 Message-Id: <200803020034.m220YJ6t018608@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 01 Mar 2008 22:22:58 -0200 To: "Kevin Oberman" From: Fernando Gont In-Reply-To: <20080301224217.33F0A45047@ptavv.es.net> References: <20080301224217.33F0A45047@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Sat, 01 Mar 2008 22:34:34 -0200 (ARDT) Cc: Rui Paulo , freebsd-net@freebsd.org Subject: Re: Ephemeral port range (patch) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 00:34:34 -0000 At 08:42 p.m. 01/03/2008, Kevin Oberman wrote: > > This patch changes the default ephemeral port range from 49152-65535 > > to 1024-65535. This makes it harder for an attacker to guess the > > ephemeral ports (as the port number space is larger). Also, it makes > > the chances of port number collisions smaller. > > > (http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt) > > > > This patch also includes my previous patch that eliminated duplicated > > code in in_pcb_bind(). > >The idea is good, but 1024 is way too low. Things like rpc and the like >use ports well above 1024. Notably, 6000 and above are used by X. Maybe >10000 would be OK. Maybe not, though. I see that gnuserv and gkrellmd >both use ports about 1000. (gnuserv uses 30871 and gkrellmd uses 19150.) Other UNIX-like systems use that "low" port range. e.g., OpenBSD uses the range 1024-49151. The idea is would be to define a bit string in which you can specify those ports that should not be used as ephemeral ports (I will send this patch soon). (This is described in the IETF internet-draft I referenced, too). I will also start working on the double-hash ephemeral port selection algorithm described in the draft (this is, IMHO, the right approach to ephemeral port randomization) Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 00:39:59 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 068D11065670 for ; Sun, 2 Mar 2008 00:39:59 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 9ABDB8FC19 for ; Sun, 2 Mar 2008 00:39:58 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 20444 invoked by uid 60001); 2 Mar 2008 00:39:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ZW7ErabRrWyZOLHnhkuv7lX07w2sDnRc+6444RsFZErW5JNphXylj8W0LsWJIqMwYk0l3g5SW45/bXug73RENAmOxnT0Ezv7UcKFpgFPy6+wjLIaF//9Jd2JhLEJ/gVyljfMDtRscewb+SZ7igQBZnMW73uWGM7NRV0deAd+JT4=; X-YMail-OSG: 3qla208VM1mvVi.D98xcv3MF6z0tsTOP9FX4r6H.OXUtkYRR240WOVqljHAhcmDvNGFUdWDU6T_CVQ60rbODxY6wefUU4Pi7WHl0pepDwEdq4gaJ5p0P.N3sGtqZvudhtsXrN6kqgjiU2BQ- Received: from [98.203.28.38] by web63906.mail.re1.yahoo.com via HTTP; Sat, 01 Mar 2008 16:39:57 PST Date: Sat, 1 Mar 2008 16:39:57 -0800 (PST) From: Barney Cordoba To: Erik Trulsson In-Reply-To: <20080301225727.GA85851@owl.midgard.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <638970.20021.qm@web63906.mail.re1.yahoo.com> Cc: net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 00:39:59 -0000 --- Erik Trulsson wrote: > On Sat, Mar 01, 2008 at 01:27:46PM -0800, Barney > Cordoba wrote: > > > > --- Ingo Flaschberger wrote: > > > > > Dear Barney, > > > > > > > It seems absolutely ridiculous to buy such > > > hardware > > > > and not install a PCIx or 4x PCIe card for > another > > > > $100. or less. Saying a 1x is "fast enough" is > > > like > > > > saying a Celeron is "fast enough". > > > > > > The box is a small 1HE appliance and can boot > from a > > > CF-Card. > > > I trust them more than a "al cheapo" pc. > > > 1x axiomtek NA-820 > > > 1x P4 3Ghz cpu > > > 1x 1gb ddr2 > > > --- > > > 850eur without taxes. > > > > > > A good chipset, good cpu, good ram, good > harddisk, > > > god powersupply has > > > same price. > > > And don't forget that in exchanges you pay for > each > > > HE. > > > > > > And back to 1x is not fast enough: > > > There are no 1gbit single port network cards > that > > > support more than 1 > > > lane, even if you plug it into a 16 lane slot. > > > (and I'm not talking about 10gbit cards; if you > have > > > 10gbit upstream you > > > have enough $$ to buy good gear) > > > > Ok, well I've never seen a router with 1 port. I > > thought we were talking about building a router? > > He did not say anything about a single port router. > He talked about single port network cards. You can > use more than one of them when building a router. His argument is that there are only 1x PCIe cards that have 1 port. Since he needs 2 ports, and there are 2 port PCIe cards, then his argument makes no sense. But the point is that PCIe NICs are implemented with 1 port per lane in the chip. So a 2 port card will use 2 lanes > > > > > The lack of PCIe cards is a good reason to > consider a > > PCIX machine. > > What lack of PCI-E cards? These days there are > quite a > few to choose between. Yes, but they are all 1x, while there are many 1 and 2 port PCIx cards which are twice as fast. > > > On the systems that we have, the 1x PCIe > > ports are a lot slower than a PCI-X card in the > slot. > > > > You need 4Gb/s of throughput to handle a gigablt > > router. (1 GB/s full duplex times 2). 1x is 4Gb/s > > maximum. In my view, you always need twice the > > bandwidth on the bus to avoid contention issues. > > What contention issues? With PCI-E each device is > essentially on its own > bus and does not need to contend with other devices > for bandwidth on that > bus. > > A PCI-E 1x connection provides more bandwidth than > one gigabit ethernet > connection can use. Does each PCIe slot have its own dedicated memory controller? The concept that there is some sort of mutually exclusive, independent path for each controller is simply not the case in practice. You're accessing the same memory; you're going through shared hubs and bridges. You're doing I/O on the same bus. North bridges typically have a 512 Byte payload maximum, so you can't even burst a full packet. You have transaction overhead for each transfer. There are many factors that will chip away at your realizable bandwidth. Its not like a hose gushing a continuos stream of water. Another factor is that "server" chipsets do PCIe better than "desktop" chipsets. Server chipsets are optimized in the chipset to handle multiple devices more efficiently. So don't expect your "desktop" chipset to be as efficient as a server chipset at the same task. There's a reason that intel has desktop and server chipsets. I've tested dual port cards based on the 82546 and 82571 parts on the same system that has both PCIX and PCIe slots. The parts are essentially the same, and the driver is essentially the same, with the bus being the only real difference. The PCIe card is a 2x card. so its the equivalent of 2 PCIe cards with dedicated 1x lanes. The results are the that PCIx card is simply more efficient, in that is uses less CPU with the same load (an indication of less contention for I/O), and the PCIX card has a higher capacity (that is, the point in which the cpu is saturated is higher by about 10%) In practice your little box is never going to be routing bi-direction, full gigabit traffic, but if you only have "just enough" bandwidth, your CPU is going to get less and less efficient as you get higher and higher usage. You'll need more cpu to do the same task with less bus. I'm not claiming that PCIX is faster than pcie at the same "speed", but that the limitation of 1x per NIC causes PCIX to be a better choice for a 2 port system in most cases. Barney ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 00:51:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F2671065673 for ; Sun, 2 Mar 2008 00:51:42 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id B26398FC19 for ; Sun, 2 Mar 2008 00:51:41 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m21MmpEd028556 for ; Sun, 2 Mar 2008 09:48:51 +1100 Received: from server.vk2pj.dyndns.org (c220-239-20-82.belrs4.nsw.optusnet.com.au [220.239.20.82]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m21Mmmmp027403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Mar 2008 09:48:48 +1100 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.2/8.14.1) with ESMTP id m21MmlvL097850; Sun, 2 Mar 2008 09:48:47 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.2/8.14.2/Submit) id m21MmlgB097849; Sun, 2 Mar 2008 09:48:47 +1100 (EST) (envelope-from peter) Date: Sun, 2 Mar 2008 09:48:47 +1100 From: Peter Jeremy To: Juri Mianovich Message-ID: <20080301224847.GU67687@server.vk2pj.dyndns.org> References: <754299.92112.qm@web45601.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <754299.92112.qm@web45601.mail.sp1.yahoo.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-net@freebsd.org Subject: Re: simple, adaptive bandwidth throttling with ipfw/dummynet ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 00:51:42 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 29, 2008 at 02:28:04PM -0800, Juri Mianovich wrote: >"after 30 minutes of maxed dummynet rule, add X mbps >to the rule for every active TCP session, with a max >ceiling of Y mbps" > >and: > >"after 30 minutes of less than max usage, subtract X >mbps from the rule every Y minutes, with a minimum >floor of Z" > >Make sense ? It doesn't really make sense to me but it's your firewall and you are free to implement whatever rules you like. >If I wanted to do this myself with a shell script, is >there any way to test a particular dummynet rule for >its current "fill rate" - OR - a simple way to test if >a particular dummynet rule is currently in enforcement >? The system doesn't maintain stats on the instantaneous "fill rate" of pipes/queues. All it will report is total counts of traffic through and in the pipe/queue. Since the format wasn't clear to me from a quick read of the man page, the following is a breakdown of the output, with added notes: fwall# ipfw pipe list 00001: 6.400 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte= Drp 0 tcp 192.168.123.200/56599 150.101.135.3/61455 122097 6353558 0 = 0 397 |----- dummynet accumulation bucket details -----|---- Totals ---|Queued= | 'dummynet accumulation bucket details' is the details of the most recent (I think) packet matching the specific bucket mask 'Totals' is total bytes and packets through that particular bucket 'Queued' refer to bytes and packets for that bucket currently queued 'Drp' is the number of packets dropped. You would need to calculate a rate by periodically sampling the counts. You can get a rough idea of if a particular dummynet rule is restricting traffic flow by looking for non-zero queued counts (though keep in mind that it is normal for a packet to occasionally be queued). Assuming you have the TCP sessions spread across distinct buckets (either with multiple pipes/queues or with masks to split them up), my suggestion would be a perl script that regularly does 'ipfw pipe list' or 'ipfw queue list' and use change_in_total_bytes/time to calculate average throughput per session. Then use a leaky bucket on the average throughput to trigger pipe/queue re-configurations as desired. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHyd1P/opHv/APuIcRAgo/AJ43YU/rwrVKEztwoV8tMpMZWLf+9ACggQ/T hY52Y7GYc+KKqsGQVPW9/LU= =N6xf -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 02:12:15 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE20F106566B for ; Sun, 2 Mar 2008 02:12:15 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 136028FC1B for ; Sun, 2 Mar 2008 02:12:15 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-25-183.bredband.comhem.se ([83.253.25.183]:54237 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1JVdgT-0005yd-5T for net@freebsd.org; Sun, 02 Mar 2008 03:12:14 +0100 Received: (qmail 9964 invoked from network); 2 Mar 2008 03:12:08 +0100 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 2 Mar 2008 03:12:08 +0100 Received: (qmail 88429 invoked by uid 1001); 2 Mar 2008 03:12:08 +0100 Date: Sun, 2 Mar 2008 03:12:08 +0100 From: Erik Trulsson To: Barney Cordoba Message-ID: <20080302021208.GA87031@owl.midgard.homeip.net> Mail-Followup-To: Barney Cordoba , net@freebsd.org References: <20080301225727.GA85851@owl.midgard.homeip.net> <638970.20021.qm@web63906.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <638970.20021.qm@web63906.mail.re1.yahoo.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Originating-IP: 83.253.25.183 X-Scan-Result: No virus found in message 1JVdgT-0005yd-5T. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1JVdgT-0005yd-5T 08f83dfc7f00c706f4c28abf13809549 Cc: net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 02:12:15 -0000 On Sat, Mar 01, 2008 at 04:39:57PM -0800, Barney Cordoba wrote: > > --- Erik Trulsson wrote: > > > On Sat, Mar 01, 2008 at 01:27:46PM -0800, Barney > > Cordoba wrote: > > > > > > --- Ingo Flaschberger wrote: > > > > > > > Dear Barney, > > > > > > > > > It seems absolutely ridiculous to buy such > > > > hardware > > > > > and not install a PCIx or 4x PCIe card for > > another > > > > > $100. or less. Saying a 1x is "fast enough" is > > > > like > > > > > saying a Celeron is "fast enough". > > > > > > > > The box is a small 1HE appliance and can boot > > from a > > > > CF-Card. > > > > I trust them more than a "al cheapo" pc. > > > > 1x axiomtek NA-820 > > > > 1x P4 3Ghz cpu > > > > 1x 1gb ddr2 > > > > --- > > > > 850eur without taxes. > > > > > > > > A good chipset, good cpu, good ram, good > > harddisk, > > > > god powersupply has > > > > same price. > > > > And don't forget that in exchanges you pay for > > each > > > > HE. > > > > > > > > And back to 1x is not fast enough: > > > > There are no 1gbit single port network cards > > that > > > > support more than 1 > > > > lane, even if you plug it into a 16 lane slot. > > > > (and I'm not talking about 10gbit cards; if you > > have > > > > 10gbit upstream you > > > > have enough $$ to buy good gear) > > > > > > Ok, well I've never seen a router with 1 port. I > > > thought we were talking about building a router? > > > > He did not say anything about a single port router. > > He talked about single port network cards. You can > > use more than one of them when building a router. > > His argument is that there are only 1x PCIe cards that > have 1 port. Since he needs 2 ports, and there are 2 > port > PCIe cards, then his argument makes no sense. But the > point is that PCIe NICs are implemented with 1 port > per lane in the chip. So a 2 port card will use 2 > lanes No, the argument was that all 1-port PCI-E cards are only x1, ergo a x1 card must be fast enough for 1 port, else there would be 1-port cards manufactured that used more than one lane. > > > > > > > > > The lack of PCIe cards is a good reason to > > consider a > > > PCIX machine. > > > > What lack of PCI-E cards? These days there are > > quite a > > few to choose between. > > Yes, but they are all 1x, while there are many 1 and 2 > port PCIx cards which are twice as fast. There are dual- and quad-port PCI-E cards available too, and they are generally x4 lane models. Today there really is very little reason to use PCI-X instead of PCI-E when one is putting together a brand new system. > > > > > > On the systems that we have, the 1x PCIe > > > ports are a lot slower than a PCI-X card in the > > slot. > > > > > > You need 4Gb/s of throughput to handle a gigablt > > > router. (1 GB/s full duplex times 2). 1x is 4Gb/s > > > maximum. In my view, you always need twice the > > > bandwidth on the bus to avoid contention issues. > > > > What contention issues? With PCI-E each device is > > essentially on its own > > bus and does not need to contend with other devices > > for bandwidth on that > > bus. > > > > A PCI-E 1x connection provides more bandwidth than > > one gigabit ethernet > > connection can use. > > Does each PCIe slot have its own dedicated memory > controller? The concept that there is some sort of > mutually exclusive, independent path for each > controller is simply not the case in practice. You're > accessing the same memory; you're going through > shared hubs and bridges. You're doing I/O on the same > bus. North bridges typically have a 512 Byte payload > maximum, so you can't even burst a full packet. You > have transaction overhead for each transfer. There are > many factors that will chip away at your realizable > bandwidth. Its not like a hose gushing a continuos > stream of water. Sure, but those limitations apply equally regardless of what kind of slots you use. A x8 lane PCI-E card will suffer just as much of contention on the FSB between the CPU and the chipset as a x1 lane card will. Having a wider channel between the NIC and the chipset will not help if the bottleneck is elswehere. > > Another factor is that "server" chipsets do PCIe > better than "desktop" chipsets. Server chipsets are > optimized in the chipset to handle multiple devices > more efficiently. So don't expect your "desktop" > chipset to be as efficient as a server chipset at the > same task. There's a reason that intel has desktop and > server chipsets. Intel uses the same southbridge chips for all their single-CPU chipsets, regardless of whether the nortbridge is labeled as a server or desktop part. Most I/O-devices are normally connected to the southbridge. > > I've tested dual port cards based on the 82546 and > 82571 parts on the same system that has both PCIX and > PCIe slots. The parts are essentially the same, and > the driver is essentially the same, with the bus being > the only real difference. The PCIe card is a 2x card. PCI-E cards and slots only come in 4 physical sizes: x1, x4, x8, and x16. It is not uncommon for a slot to have fewer lanes attached to it than the physical size allows, so there do exist some 'x2' slots. I have however never seen any PCI-E cards being sold as x2, only as one of the standard widths. > so its the equivalent of 2 PCIe cards with dedicated > 1x lanes. The results are the that PCIx card is simply > more efficient, in that is uses less CPU with the same > load (an indication of less contention for I/O), and > the PCIX card has a higher capacity (that is, the > point in which the cpu is saturated is higher by about > 10%) On that particular system, with those particular cards, it might well be the case that the PCI-X card performed better than the PCI-E card. That says essentially nothing about the relative performance of PCI-X vs PCI-E in general, and I doubt that there was any lack of bandwidth between either of the cards and the chipset anyway. How the different buses and chips are connected on the motherboard can cause quite a bit of difference. If, for example, the PCI-X bus was connected to the Northbridge of the chipset, while the PCI-E x1 slots were connected to the Southbridge, and there was a fairly narrow connection (equivalent to a x4 lane PCI-E bus) between the north- and south-bridge, then you could well get the results you saw. On another motherboard, with a different topology, you might get the opposite results from those same cards. > > In practice your little box is never going to be > routing bi-direction, full gigabit traffic, but if you > only have "just enough" bandwidth, your CPU is going > to get less and less efficient as you get higher and > higher usage. You'll need more cpu to do the same task > with less bus. But a x1 lane PCI-E connection does not provide "just enough" bandwidth for a gigabit ethernet connection. It provides "more than enough" bandwidth. (The theoretical bandwidth of such a x1 lane is twice what is needed for the ethernet connection, which is quite enough even taking into account various overheads.) > > I'm not claiming that PCIX is faster than pcie at the > same "speed", but that the limitation of 1x per NIC > causes PCIX to be a better choice for a 2 port system > in most cases. There is no inherent "limitation of 1x per NIC", but even if there was this is not a problem as long as you do not put more than 1 port per NIC. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 02:44:33 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9C84106567C; Sun, 2 Mar 2008 02:44:33 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3958FC13; Sun, 2 Mar 2008 02:44:33 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m222iXet048229; Sun, 2 Mar 2008 02:44:33 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m222iXQL048225; Sun, 2 Mar 2008 02:44:33 GMT (envelope-from linimon) Date: Sun, 2 Mar 2008 02:44:33 GMT Message-Id: <200803020244.m222iXQL048225@freefall.freebsd.org> To: qyang@stbernard.com, linimon@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/95277: [netinet] [patch] IP Encapsulation mask_match() returns wrong results X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 02:44:33 -0000 Synopsis: [netinet] [patch] IP Encapsulation mask_match() returns wrong results State-Changed-From-To: feedback->open State-Changed-By: linimon State-Changed-When: Sun Mar 2 02:44:10 UTC 2008 State-Changed-Why: Note that feedback was received some time ago. http://www.freebsd.org/cgi/query-pr.cgi?pr=95277 From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 02:57:19 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A893D1065681; Sun, 2 Mar 2008 02:57:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7DD998FC27; Sun, 2 Mar 2008 02:57:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m222vJuB049563; Sun, 2 Mar 2008 02:57:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m222vJWH049559; Sun, 2 Mar 2008 02:57:19 GMT (envelope-from linimon) Date: Sun, 2 Mar 2008 02:57:19 GMT Message-Id: <200803020257.m222vJWH049559@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/121274: [panic] Panic in ether_input() with different NIC's. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 02:57:19 -0000 Old Synopsis: Panic in ether_input() with different NIC's. New Synopsis: [panic] Panic in ether_input() with different NIC's. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Mar 2 02:56:55 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121274 From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 06:31:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98F111065670 for ; Sun, 2 Mar 2008 06:31:44 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id D963D8FC1B for ; Sun, 2 Mar 2008 06:31:41 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id RAA12378; Sun, 2 Mar 2008 17:16:48 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 2 Mar 2008 17:16:47 +1100 (EST) From: Ian Smith To: Peter Jeremy In-Reply-To: <20080301224847.GU67687@server.vk2pj.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Juri Mianovich Subject: Re: simple, adaptive bandwidth throttling with ipfw/dummynet ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 06:31:44 -0000 On Sun, 2 Mar 2008, Peter Jeremy wrote: > On Fri, Feb 29, 2008 at 02:28:04PM -0800, Juri Mianovich wrote: > >"after 30 minutes of maxed dummynet rule, add X mbps > >to the rule for every active TCP session, with a max > >ceiling of Y mbps" > > > >and: > > > >"after 30 minutes of less than max usage, subtract X > >mbps from the rule every Y minutes, with a minimum > >floor of Z" > > > >Make sense ? > > It doesn't really make sense to me but it's your firewall and you are > free to implement whatever rules you like. :) > >If I wanted to do this myself with a shell script, is > >there any way to test a particular dummynet rule for > >its current "fill rate" - OR - a simple way to test if > >a particular dummynet rule is currently in enforcement > >? > > The system doesn't maintain stats on the instantaneous "fill rate" > of pipes/queues. All it will report is total counts of traffic > through and in the pipe/queue. Since the format wasn't clear to > me from a quick read of the man page, the following is a breakdown > of the output, with added notes: > fwall# ipfw pipe list > 00001: 6.400 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp > 0 tcp 192.168.123.200/56599 150.101.135.3/61455 122097 6353558 0 0 397 > |----- dummynet accumulation bucket details -----|---- Totals ---|Queued | > 'dummynet accumulation bucket details' is the details of the most recent > (I think) packet matching the specific bucket mask Yes, but I'm not sure if it's the last packet into or out of the queue. > 'Totals' is total bytes and packets through that particular bucket > 'Queued' refer to bytes and packets for that bucket currently queued > 'Drp' is the number of packets dropped. > > You would need to calculate a rate by periodically sampling the > counts. You can get a rough idea of if a particular dummynet rule is > restricting traffic flow by looking for non-zero queued counts (though > keep in mind that it is normal for a packet to occasionally be queued). Also if there's any burstiness in the flow (ie letting the queue fully or partially empty), you could easily misinterpret the overall flow. > Assuming you have the TCP sessions spread across distinct buckets > (either with multiple pipes/queues or with masks to split them up), my I think this would be the way to go. Juri said he only has one pipe defined, and managing multiple sessions through that has to be handled by some tricky out of band means. Personally I've found it easier to monitor recv/sent throughput per host over a period by parsing the output of ipfw show on rules numbered by IP address than trying to parse ipfw pipe show output, using sh rather than perl, but everyone's mileage varies. An extract: subnet="192.168.0" base='27000' # ctc 'preweb' skipto rules if [ $ip -eq 1 ]; then ip="*"; recvrule='26890'; sentrule='26900' else recvrule=$(($base + $ip * 10)); sentrule=$(($recvrule + 5)); fi getbytes() { echo -n `ipfw show $1 2>/dev/null | awk '{print $3}'` } oldrx=`getbytes $recvrule` ; oldtx=`getbytes $sentrule` [..] > suggestion would be a perl script that regularly does 'ipfw pipe list' > or 'ipfw queue list' and use change_in_total_bytes/time to calculate > average throughput per session. Then use a leaky bucket on the > average throughput to trigger pipe/queue re-configurations as desired. Please explain 'leaky bucket'? Someone on questions@ recently mentioned using one pipe with masks to limit traffic per-host, then fed through another pipe limiting overall bandwidth for the lot or for distinct subgroups, but due to a crash I'm several days behind and haven't yet caught up with how that's done, or indeed if that can be done on a filtering bridge using ipfw1 and old bridge(4) on 4.8-RELEASE, which I'm stuck with using for a while yet. cheers, Ian From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 08:41:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB3B31065676 for ; Sun, 2 Mar 2008 08:41:09 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id BBFF38FC1C for ; Sun, 2 Mar 2008 08:41:09 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JVjTL-0000hm-JT for freebsd-net@freebsd.org; Sun, 02 Mar 2008 00:23:03 -0800 Message-ID: <15784710.post@talk.nabble.com> Date: Sun, 2 Mar 2008 00:23:03 -0800 (PST) From: zDen To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: angwyshield-freebsd@yahoo.com Subject: Looking for a guide to extend|adapting the socket framework for NFCIP-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 08:41:10 -0000 Hi, I'm exploring the way to extend or adapt the socket programming framework for NFC devices using C programming. (for future-porting compatible) Using the bluetooth framework as basic reference, I've some questions and need helps regarding the adaption. 1) As the NFC device is attached to the USB or UART port, how and where in the source code can I change the output of the byte-stream packet to the proper physical port? i.e where is the part of the source code that is physical device dependent when doing the I/O calls? 2) As the protocol family (PF_xx) and address family (AF_xx) of NFC is not define in the socket library, how can I define them and let the default socket() call return a socket with the customized structure? I can see that I may need to use SOCK_RAW as the basic socket framework or any others recommendation? Any comments and recommendations for the above issue is gladly appreciated. Thanks for help. -- View this message in context: http://www.nabble.com/Looking-for-a-guide-to-extend%7Cadapting-the-socket-framework-for-NFCIP-1-tp15784710p15784710.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 12:52:52 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3C0A1065677 for ; Sun, 2 Mar 2008 12:52:52 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63910.mail.re1.yahoo.com (web63910.mail.re1.yahoo.com [69.147.97.125]) by mx1.freebsd.org (Postfix) with SMTP id 8E8998FC16 for ; Sun, 2 Mar 2008 12:52:52 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 63963 invoked by uid 60001); 2 Mar 2008 12:52:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=iE2NVZejFcV6iV5Lm2hxZOfUpzhk4T3qXpcAh2iWq/co2yO6N+uNTPignP+G8kPfEWgr9UkwxFjtqJeY9CckUl9iqOFDDHSzS+YfkdgCoryvbzb6GUADkyYR5vSqXS3Wb7xqs3cLIe+Ctg02jmEpVKzl8IiG6Mv0K1Y8ysfxP04=; X-YMail-OSG: 3WD3gNoVM1lYM8tMtQ_TOegfrnlhNCoQAlnWLPRjpj0TMlRSDryGzGGkL61Xc2hVOWDefTpFDDGRrWHVLBvPOue.9m.peryCbx9PLsaU9KpQqpA1jjs8.pLhSUfknaOHqx6jwlDSr4zTnPM- Received: from [98.203.28.38] by web63910.mail.re1.yahoo.com via HTTP; Sun, 02 Mar 2008 04:52:51 PST Date: Sun, 2 Mar 2008 04:52:51 -0800 (PST) From: Barney Cordoba To: Erik Trulsson In-Reply-To: <20080302021208.GA87031@owl.midgard.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <644693.83415.qm@web63910.mail.re1.yahoo.com> Cc: net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 12:52:52 -0000 --- Erik Trulsson wrote: > On Sat, Mar 01, 2008 at 04:39:57PM -0800, Barney > Cordoba wrote: > > > > --- Erik Trulsson wrote: > > > > > On Sat, Mar 01, 2008 at 01:27:46PM -0800, Barney > > > Cordoba wrote: > > > > > > > > --- Ingo Flaschberger wrote: > > > > > > > > > Dear Barney, > > > > > > > > > > > It seems absolutely ridiculous to buy such > > > > > hardware > > > > > > and not install a PCIx or 4x PCIe card for > > > another > > > > > > $100. or less. Saying a 1x is "fast > enough" is > > > > > like > > > > > > saying a Celeron is "fast enough". > > > > > > > > > > The box is a small 1HE appliance and can > boot > > > from a > > > > > CF-Card. > > > > > I trust them more than a "al cheapo" pc. > > > > > 1x axiomtek NA-820 > > > > > 1x P4 3Ghz cpu > > > > > 1x 1gb ddr2 > > > > > --- > > > > > 850eur without taxes. > > > > > > > > > > A good chipset, good cpu, good ram, good > > > harddisk, > > > > > god powersupply has > > > > > same price. > > > > > And don't forget that in exchanges you pay > for > > > each > > > > > HE. > > > > > > > > > > And back to 1x is not fast enough: > > > > > There are no 1gbit single port network cards > > > that > > > > > support more than 1 > > > > > lane, even if you plug it into a 16 lane > slot. > > > > > (and I'm not talking about 10gbit cards; if > you > > > have > > > > > 10gbit upstream you > > > > > have enough $$ to buy good gear) > > > > > > > > Ok, well I've never seen a router with 1 port. > I > > > > thought we were talking about building a > router? > > > > > > He did not say anything about a single port > router. > > > He talked about single port network cards. You > can > > > use more than one of them when building a > router. > > > > His argument is that there are only 1x PCIe cards > that > > have 1 port. Since he needs 2 ports, and there are > 2 > > port > > PCIe cards, then his argument makes no sense. But > the > > point is that PCIe NICs are implemented with 1 > port > > per lane in the chip. So a 2 port card will use 2 > > lanes > > No, the argument was that all 1-port PCI-E cards are > only > x1, ergo a x1 card must be fast enough for 1 port, > else there > would be 1-port cards manufactured that used more > than > one lane. > PCIe cards are 1x because the chips are all wired for 1x. Intel has a marketing plan. Its not to use low-end chips for high-end operations. Intel is just going to cannibalized their own business by putting out higher performance low-end chips. > > > > > > > > > > > > > > > The lack of PCIe cards is a good reason to > > > consider a > > > > PCIX machine. > > > > > > What lack of PCI-E cards? These days there are > > > quite a > > > few to choose between. > > > > Yes, but they are all 1x, while there are many 1 > and 2 > > port PCIx cards which are twice as fast. > > There are dual- and quad-port PCI-E cards available > too, and they are > generally x4 lane models. > > Today there really is very little reason to use > PCI-X instead > of PCI-E when one is putting together a brand new > system. the "reason" is that its faster, but its clear that you have no interest in understanding that, so I'll give up on trying to educated you. The math is clearly over your head. Barney ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 13:43:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3A08106566C for ; Sun, 2 Mar 2008 13:43:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8DC298FC1F for ; Sun, 2 Mar 2008 13:43:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id AADE346BBF; Sun, 2 Mar 2008 08:27:32 -0500 (EST) Date: Sun, 2 Mar 2008 13:27:32 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Silbersack In-Reply-To: <20080301142538.L29763@odysseus.silby.com> Message-ID: <20080302132610.E10502@fledge.watson.org> References: <200803011338.m21DcY9Z026418@venus.xmundo.net> <20080301142538.L29763@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rui Paulo , freebsd-net@freebsd.org Subject: Re: Ephemeral port range (patch) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 13:43:12 -0000 On Sat, 1 Mar 2008, Mike Silbersack wrote: > On Sat, 1 Mar 2008, Fernando Gont wrote: > >> This patch changes the default ephemeral port range from 49152-65535 to >> 1024-65535. This makes it harder for an attacker to guess the ephemeral >> ports (as the port number space is larger). Also, it makes the chances of >> port number collisions smaller. >> (http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt) > > There are a number of commonly used ports above 1000, such as nfs and x11. I > think OpenBSD uses 10000-65535, maybe that's a safer choice to go with. In order to get acceptable open connection counts with 10gbps ethernet, I've needed to run with a significantly lower starting portrange. In practice, the following seems to do the trick for me: sysctl net.inet.ip.portrange.first=10000 Of course, I only run into this if I also increase maxsockets: sysctl kern.ipc.maxsockets=30000 Lowering the lower end of the ephemeral range to 10,000 would do the trick for me, anyway. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 14:00:53 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B77A10656F1 for ; Sun, 2 Mar 2008 14:00:52 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (www.tegenbosch28.nl [217.21.251.97]) by mx1.freebsd.org (Postfix) with ESMTP id F07B48FC1C for ; Sun, 2 Mar 2008 14:00:51 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 9CCC81736C; Sun, 2 Mar 2008 14:37:58 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqpPJuoz2wBK; Sun, 2 Mar 2008 14:37:56 +0100 (CET) Received: from [192.168.2.10] (unknown [192.168.2.10]) by mail.digiware.nl (Postfix) with ESMTP id 7381F1715A; Sun, 2 Mar 2008 14:37:56 +0100 (CET) Message-ID: <47CAADB8.9000202@digiware.nl> Date: Sun, 02 Mar 2008 14:38:00 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Barney Cordoba , Ingo Flaschberger , net@freebsd.org References: <497111.42659.qm@web63905.mail.re1.yahoo.com> <20080301225727.GA85851@owl.midgard.homeip.net> In-Reply-To: <20080301225727.GA85851@owl.midgard.homeip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 14:00:53 -0000 Erik Trulsson wrote: >> Ok, well I've never seen a router with 1 port. I >> thought we were talking about building a router? > > He did not say anything about a single port router. > He talked about single port network cards. You can > use more than one of them when building a router. Well lets nitpick. A router does not have to have 2 ports. 2 examples: - routing between VLANs on the same interface - when doing routing in an overlay network. EG. in a connecting VPN networks I'm looking for a stream exploder.:) 1 2Mbit stream in, and as many as possible out. And 7*1Gb = 14Gbit, so I'd like to be pushing 7000 streams. (One advantage is that they will be UDP streams, so there is a little less bookkeeping in the protocol stack ) >> The lack of PCIe cards is a good reason to consider a >> PCIX machine. > > What lack of PCI-E cards? These days there are quite a > few to choose between. I'm under the impression that PCI-E is the way to go. Especially if I look at what is implemented on the more serious server boards. >> On the systems that we have, the 1x PCIe >> ports are a lot slower than a PCI-X card in the slot. >> >> You need 4Gb/s of throughput to handle a gigablt >> router. (1 GB/s full duplex times 2). 1x is 4Gb/s >> maximum. In my view, you always need twice the >> bandwidth on the bus to avoid contention issues. > > What contention issues? With PCI-E each device is essentially on its own > bus and does not need to contend with other devices for bandwidth on that > bus. Right, in PCI-E the lanes are just a star network into a hub. Now there is always going to be a bottleneck in a network. So here the big chance is that this is between the CPU and the hub. To see that just complete the above math: 7000 stream @ 2mbit/sec =~> 1.25E6 p/s =~> 1,75 Gb/sec Where all datatransport has to go over the processor. Well I have not seen systems with this as Frontside bus, so this is going to require a carefully crafted design. :) --WjW From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 15:04:47 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79F011065672; Sun, 2 Mar 2008 15:04:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4BAA08FC17; Sun, 2 Mar 2008 15:04:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (rwatson@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m22F4l1u018035; Sun, 2 Mar 2008 15:04:47 GMT (envelope-from rwatson@freefall.freebsd.org) Received: (from rwatson@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m22F4lgx018031; Sun, 2 Mar 2008 15:04:47 GMT (envelope-from rwatson) Date: Sun, 2 Mar 2008 15:04:47 GMT Message-Id: <200803021504.m22F4lgx018031@freefall.freebsd.org> To: scf@FreeBSD.org, rwatson@FreeBSD.org, freebsd-net@FreeBSD.org From: rwatson@FreeBSD.org Cc: Subject: Re: kern/121274: [panic] Panic in ether_input() with different NIC's. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 15:04:47 -0000 Synopsis: [panic] Panic in ether_input() with different NIC's. State-Changed-From-To: open->feedback State-Changed-By: rwatson State-Changed-When: Sun Mar 2 15:03:57 UTC 2008 State-Changed-Why: Could you run memtest86 or some other memory testing tool on the box? While this could well be a software bug, it would be nice to give it a whirl and make sure you're not running into, say, a 1-bit memory error that might easily explain the panic across various drivers. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=121274 From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 15:10:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CCD21065673; Sun, 2 Mar 2008 15:10:13 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.freebsd.org (Postfix) with ESMTP id E97BC8FC12; Sun, 2 Mar 2008 15:10:12 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from southcross.wired.org (host-62-10-34-34.cust-adsl.tiscali.it [62.10.34.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id 4C52011AE68; Sun, 2 Mar 2008 16:10:12 +0100 (CET) Received: (from piso@localhost) by southcross.wired.org (8.14.2/8.14.1/Submit) id m22FDBa0023669; Sun, 2 Mar 2008 16:13:11 +0100 (CET) (envelope-from piso) Date: Sun, 2 Mar 2008 16:13:10 +0100 From: Paolo Pisati To: Paolo Pisati Message-ID: <20080302151310.GB23353@tin.it> References: <20080302144939.GA23353@tin.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080302144939.GA23353@tin.it> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: ipfw initialization: SI_ORDER_ANY -> SI_ORDER_MIDDLE? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 15:10:13 -0000 On Sun, Mar 02, 2008 at 03:49:39PM +0100, Paolo Pisati wrote: > Hi, > > i just found out that depending on a KLD doesn't imply any > initialization order, thus depending on a lock initialized in the ipfw > init path is _really_ a bad idea from another KLD init path (see > ip_fw_nat.c::ipfw_nat_init()). > > A fix would be to move ipfw init priority from SI_ORDER_ANY to > SI_ORDER_MIDDLE, but i guess there are side effects that i'm > unaware in this modification... > > On the other hand, if we keep ipfw at SI_ORDER_ANY, i don't know how > to build stuff that relies on it without opening race conditions: > see ip_fw_nat.c::flush_nat_ptrs() called in rule deletion and > rule configuration paths. as the problem arises only during ip_fw_nat initialization, another viable solution would be to fix ipfw_nat_init() this way: static void ipfw_nat_init(void) { - IPFW_WLOCK(&layer3_chain); /* init ipfw hooks */ - ipfw_nat_ptr = ipfw_nat; ipfw_nat_cfg_ptr = ipfw_nat_cfg; ipfw_nat_del_ptr = ipfw_nat_del; ipfw_nat_get_cfg_ptr = ipfw_nat_get_cfg; ipfw_nat_get_log_ptr = ipfw_nat_get_log; - IPFW_WUNLOCK(&layer3_chain); + ipfw_nat_ptr = ipfw_nat; ifaddr_event_tag = EVENTHANDLER_REGISTER(ifaddr_event, ifaddr_change, NULL, EVENTHANDLER_PRI_ANY); } avoid grabbing the lock at all during init, and exploit orders of hooks initialization: as the presence of ipfw_nat in ipfw is checked via ipfw_nat_ptr, i can narrow/close the race window initializing ipfw_nat_ptr at the end of the function, but can i trust the order of variables assignment? i guess no without some sort of memory barriers, and are memory barriers available in all archs? and are memory barriers enough? bye, P. From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 15:11:31 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78DA9106566C for ; Sun, 2 Mar 2008 15:11:31 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id BC3208FC25 for ; Sun, 2 Mar 2008 15:11:30 +0000 (UTC) (envelope-from if@xip.at) Received: (qmail 5657 invoked from network); 2 Mar 2008 16:11:28 +0100 Received: from unknown (HELO filebunker.xip.at) (86.59.10.180) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Mar 2008 16:11:28 +0100 Date: Sun, 2 Mar 2008 16:11:28 +0100 (CET) From: Ingo Flaschberger To: Barney Cordoba In-Reply-To: <497111.42659.qm@web63905.mail.re1.yahoo.com> Message-ID: References: <497111.42659.qm@web63905.mail.re1.yahoo.com> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 15:11:31 -0000 Dear Bareney, >> And back to 1x is not fast enough: >> There are no 1gbit single port network cards that >> support more than 1 >> lane, even if you plug it into a 16 lane slot. >> (and I'm not talking about 10gbit cards; if you have >> 10gbit upstream you >> have enough $$ to buy good gear) > > Ok, well I've never seen a router with 1 port. I > thought we were talking about building a router? Have you ever read the link? Have you noticed that the axiomtek appliance has 7 gigabit ports? Each one connected with 1 lane pci-e? > The lack of PCIe cards is a good reason to consider a > PCIX machine. On the systems that we have, the 1x PCIe > ports are a lot slower than a PCI-X card in the slot. Perhaps, but: pci-x: 4gbit for the whole bus system. pci-e: 2gbit/lane > You need 4Gb/s of throughput to handle a gigablt > router. (1 GB/s full duplex times 2). 1x is 4Gb/s > maximum. In my view, you always need twice the > bandwidth on the bus to avoid contention issues. sample1: 3 pci-cards: card 1: 1x = 2gbit (dedicated) card 2: 1x = 2gbit (dedicated) card 3: 1x = 2gbit (dedicated) -------------------- sum: 6gbit (but the use only 3) sample2: 2 pci-x cards card 1: 4gbit (shared) card 2: 4gbit (shared) card 3: 4gbit (shared) --------------------- sum: 4gbit homework: calculate with 7 ports. Kind regards, Ingo Flaschberger From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 15:13:30 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E92BC1065672 for ; Sun, 2 Mar 2008 15:13:30 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.freebsd.org (Postfix) with ESMTP id A435F8FC27 for ; Sun, 2 Mar 2008 15:13:30 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from southcross.wired.org (host-62-10-30-20.cust-adsl.tiscali.it [62.10.30.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id C5FE811AE94; Sun, 2 Mar 2008 15:46:39 +0100 (CET) Received: (from piso@localhost) by southcross.wired.org (8.14.2/8.14.1/Submit) id m22Enfwo023498; Sun, 2 Mar 2008 15:49:41 +0100 (CET) (envelope-from piso) Date: Sun, 2 Mar 2008 15:49:39 +0100 From: Paolo Pisati To: freebsd-ipfw@FreeBSD.org Message-ID: <20080302144939.GA23353@tin.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: freebsd-net@FreeBSD.org Subject: ipfw initialization: SI_ORDER_ANY -> SI_ORDER_MIDDLE? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 15:13:31 -0000 Hi, i just found out that depending on a KLD doesn't imply any initialization order, thus depending on a lock initialized in the ipfw init path is _really_ a bad idea from another KLD init path (see ip_fw_nat.c::ipfw_nat_init()). A fix would be to move ipfw init priority from SI_ORDER_ANY to SI_ORDER_MIDDLE, but i guess there are side effects that i'm unaware in this modification... On the other hand, if we keep ipfw at SI_ORDER_ANY, i don't know how to build stuff that relies on it without opening race conditions: see ip_fw_nat.c::flush_nat_ptrs() called in rule deletion and rule configuration paths. bye, P. ps yes, next time i'll better read the MODULE_DEPEND man page... From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 15:17:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FD3F1065677; Sun, 2 Mar 2008 15:17:46 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 59DF78FC12; Sun, 2 Mar 2008 15:17:46 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id C54EC73129; Sun, 2 Mar 2008 15:58:50 +0100 (CET) Date: Sun, 2 Mar 2008 15:58:50 +0100 From: Luigi Rizzo To: Paolo Pisati Message-ID: <20080302145850.GA33308@onelab2.iet.unipi.it> References: <20080302144939.GA23353@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080302144939.GA23353@tin.it> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: ipfw initialization: SI_ORDER_ANY -> SI_ORDER_MIDDLE? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 15:17:46 -0000 On Sun, Mar 02, 2008 at 03:49:39PM +0100, Paolo Pisati wrote: > Hi, > > i just found out that depending on a KLD doesn't imply any > initialization order, thus depending on a lock initialized in the ipfw > init path is _really_ a bad idea from another KLD init path (see > ip_fw_nat.c::ipfw_nat_init()). > > A fix would be to move ipfw init priority from SI_ORDER_ANY to > SI_ORDER_MIDDLE, but i guess there are side effects that i'm > unaware in this modification... The SI_ORDER_* definitions in /sys/sys/kernel.h are enumerated on a large range, so if the existing code does not have races, you can safely move the non-leaf modules (such as ipfw,ko in your case) to (SI_ORDER_ANY - some_small_integer) without breaking anything. If this change breaks something, it means that there was already a race condition and you are just pointing it out - so it is a worthwhile change... cheers luigi From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 15:33:54 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72C0C1065670 for ; Sun, 2 Mar 2008 15:33:54 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id E05088FC20 for ; Sun, 2 Mar 2008 15:33:52 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-25-183.bredband.comhem.se ([83.253.25.183]:52230 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1JVqCE-0005mC-5n for net@freebsd.org; Sun, 02 Mar 2008 16:33:51 +0100 Received: (qmail 14926 invoked from network); 2 Mar 2008 16:33:49 +0100 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 2 Mar 2008 16:33:49 +0100 Received: (qmail 7115 invoked by uid 1001); 2 Mar 2008 16:33:49 +0100 Date: Sun, 2 Mar 2008 16:33:49 +0100 From: Erik Trulsson To: Ingo Flaschberger Message-ID: <20080302153348.GA6587@owl.midgard.homeip.net> Mail-Followup-To: Ingo Flaschberger , Barney Cordoba , net@freebsd.org References: <497111.42659.qm@web63905.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Originating-IP: 83.253.25.183 X-Scan-Result: No virus found in message 1JVqCE-0005mC-5n. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1JVqCE-0005mC-5n ea13dc659781907d0a713628af21fb8d Cc: Barney Cordoba , net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 15:33:54 -0000 On Sun, Mar 02, 2008 at 04:11:28PM +0100, Ingo Flaschberger wrote: > Dear Bareney, > >>> And back to 1x is not fast enough: >>> There are no 1gbit single port network cards that >>> support more than 1 >>> lane, even if you plug it into a 16 lane slot. >>> (and I'm not talking about 10gbit cards; if you have >>> 10gbit upstream you >>> have enough $$ to buy good gear) >> >> Ok, well I've never seen a router with 1 port. I >> thought we were talking about building a router? > > Have you ever read the link? > Have you noticed that the axiomtek appliance has 7 gigabit ports? > Each one connected with 1 lane pci-e? > >> The lack of PCIe cards is a good reason to consider a >> PCIX machine. On the systems that we have, the 1x PCIe >> ports are a lot slower than a PCI-X card in the slot. > > Perhaps, but: pci-x: 4gbit for the whole bus system. PCI-X actually has up to twice that: 133 MHz * 64 bits = 8.512 Gbit/s ( = 1.066 GB/s ) That's assuming only a single PCI-X device on the bus. If you have two devices connected to the same PCI-X bus then most motherboards will lower the clock frequency to 100MHz for reliability reasons. If there are 3 or more devices connected to the same PCI-X bus then the clock frequency is usually lowered to 66 MHz. (Yes, the more devices you connect to a PCI-X bus, the less bandwidth you get to share among them.) > pci-e: 2gbit/lane In each direction. The total bandwidth available is 4Gbit/s per lane. (This is similar to Gigabit ethernet which can only send 1Gbit/s in each direction, but can send and receive at the same time, thus using a total bandwidth of up to 2Gbit/s.) > >> You need 4Gb/s of throughput to handle a gigablt >> router. (1 GB/s full duplex times 2). 1x is 4Gb/s >> maximum. In my view, you always need twice the >> bandwidth on the bus to avoid contention issues. > > sample1: > 3 pci-cards: > card 1: 1x = 2gbit (dedicated) > card 2: 1x = 2gbit (dedicated) > card 3: 1x = 2gbit (dedicated) > -------------------- > sum: 6gbit > (but the use only 3) > > sample2: > 2 pci-x cards > card 1: 4gbit (shared) > card 2: 4gbit (shared) > card 3: 4gbit (shared) > --------------------- > sum: 4gbit > > homework: > calculate with 7 ports. > > Kind regards, > Ingo Flaschberger > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 15:49:35 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 205931065673 for ; Sun, 2 Mar 2008 15:49:35 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.176]) by mx1.freebsd.org (Postfix) with ESMTP id C1CA08FC28 for ; Sun, 2 Mar 2008 15:49:34 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by el-out-1112.google.com with SMTP id v27so1250552ele.12 for ; Sun, 02 Mar 2008 07:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=ZJ6MzL366Id/j0bbbY3BbhjB6yeTrDt1r2SDLJ8k2WY=; b=OaWDK7y+PHf+PjiJTQPGDlh4E3rU5qdU+cFtwlnftZuXym1iITkBrUmuIUdvMwCqH6pe0zUBYJZgaXq9zNSlBVkCsL6MEOT13VeZHCKRda5b06JQ4o6GnPvIGqEIYQMH30ChKzvnzvRYQMZzJLluIsw4iHYcdWtOjO97ddX94Ts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ajaowJKjFz19BLRXEjZC1X+Qu2i2l8QmR2o0ooeHWf7bUNmD+icyUu/kwH8VYUIRYYgG9S7zfqssIYJ0pPMSEOpPghEXB8t3fsg1uhEtqyZ5mzOzBqvOu9OWnRjVn5IT/EjiR83ONHQRSxWb82nGlIYwJLdd4X8XtdZ8RDMluiA= Received: by 10.141.115.6 with SMTP id s6mr7455649rvm.47.1204471507168; Sun, 02 Mar 2008 07:25:07 -0800 (PST) Received: by 10.140.207.1 with HTTP; Sun, 2 Mar 2008 07:25:07 -0800 (PST) Message-ID: <2e77fc10803020725p35bec6f6w9316bb38930c2a4f@mail.gmail.com> Date: Sun, 2 Mar 2008 17:25:07 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: "Ingo Flaschberger" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <497111.42659.qm@web63905.mail.re1.yahoo.com> X-Google-Sender-Auth: bd9265a3ad6a9e59 Cc: Barney Cordoba , net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 15:49:35 -0000 On Sun, Mar 2, 2008 at 5:11 PM, Ingo Flaschberger wrote: > Dear Bareney, > > >> And back to 1x is not fast enough: > >> There are no 1gbit single port network cards that > >> support more than 1 > >> lane, even if you plug it into a 16 lane slot. > >> (and I'm not talking about 10gbit cards; if you have > >> 10gbit upstream you > >> have enough $$ to buy good gear) > > > > Ok, well I've never seen a router with 1 port. I > > thought we were talking about building a router? > > Have you ever read the link? > Have you noticed that the axiomtek appliance has 7 gigabit ports? > Each one connected with 1 lane pci-e? > > > The lack of PCIe cards is a good reason to consider a > > PCIX machine. On the systems that we have, the 1x PCIe > > ports are a lot slower than a PCI-X card in the slot. > > Perhaps, but: pci-x: 4gbit for the whole bus system. > pci-e: 2gbit/lane > > > You need 4Gb/s of throughput to handle a gigablt > > router. (1 GB/s full duplex times 2). 1x is 4Gb/s > > maximum. In my view, you always need twice the > > bandwidth on the bus to avoid contention issues. > > sample1: > 3 pci-cards: > card 1: 1x =3D 2gbit (dedicated) > card 2: 1x =3D 2gbit (dedicated) > card 3: 1x =3D 2gbit (dedicated) > -------------------- > sum: 6gbit > (but the use only 3) > > sample2: > 2 pci-x cards > card 1: 4gbit (shared) > card 2: 4gbit (shared) > card 3: 4gbit (shared) > --------------------- > sum: 4gbit > > homework: > calculate with 7 ports. > > Kind regards, > Ingo Flaschberger > > Andr=E9 Oppermann's excellent paper has even more info to why PCIe is better than PCI-X for networking : http://people.freebsd.org/~andre/Optimizing%20the%20FreeBSD%20IP%20and%20TC= P%20Stack.pdf --Niki From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 15:57:38 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F149E1065671 for ; Sun, 2 Mar 2008 15:57:38 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id 39E2A8FC16 for ; Sun, 2 Mar 2008 15:57:37 +0000 (UTC) (envelope-from if@xip.at) Received: (qmail 27872 invoked from network); 2 Mar 2008 16:57:36 +0100 Received: from unknown (HELO filebunker.xip.at) (86.59.10.180) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Mar 2008 16:57:36 +0100 Date: Sun, 2 Mar 2008 16:57:35 +0100 (CET) From: Ingo Flaschberger To: Barney Cordoba In-Reply-To: <644693.83415.qm@web63910.mail.re1.yahoo.com> Message-ID: References: <644693.83415.qm@web63910.mail.re1.yahoo.com> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="657920-542942740-1204473456=:14402" Cc: net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 15:57:39 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --657920-542942740-1204473456=:14402 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Dear Barney, > > PCIe cards are 1x because the chips are all wired for > 1x. Intel has a marketing plan. Its not to use low-end > chips for high-end operations. Intel is just going to > cannibalized their own business by putting out higher > performance low-end chips. really? the 1 port server chip use only 1 lane the 2 port server chip use only Intel® PRO/1000 PF Dual Port Server Adapter: >> Today there really is very little reason to use >> PCI-X instead >> of PCI-E when one is putting together a brand new >> system. > > the "reason" is that its faster, but its clear that > you have no > interest in understanding that, so I'll give up on > trying to educated you. > The math is clearly over your head. I have no problems to saturate 1 gbit desktop pci-e intel card in a 50$ asrock mainboard. Lets show me that at your pci-x board? and please read: http://download.intel.com/design/network/applnots/ap453.pdf Kind regards, Ingo Flaschberger --657920-542942740-1204473456=:14402-- From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 16:23:20 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 088711065672 for ; Sun, 2 Mar 2008 16:23:20 +0000 (UTC) (envelope-from if@xip.at) Received: from chile.gbit.at (ns1.xip.at [193.239.188.99]) by mx1.freebsd.org (Postfix) with ESMTP id 456E18FC1A for ; Sun, 2 Mar 2008 16:23:18 +0000 (UTC) (envelope-from if@xip.at) Received: (qmail 9780 invoked from network); 2 Mar 2008 17:23:17 +0100 Received: from unknown (HELO filebunker.xip.at) (86.59.10.180) by chile.gbit.at with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Mar 2008 17:23:17 +0100 Date: Sun, 2 Mar 2008 17:23:16 +0100 (CET) From: Ingo Flaschberger To: Barney Cordoba In-Reply-To: Message-ID: References: <644693.83415.qm@web63910.mail.re1.yahoo.com> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 16:23:20 -0000 Dear Barney, >> PCIe cards are 1x because the chips are all wired for >> 1x. Intel has a marketing plan. Its not to use low-end >> chips for high-end operations. Intel is just going to >> cannibalized their own business by putting out higher >> performance low-end chips. > > really? > the 1 port server chip use only 1 lane > the 2 port server chip use only sorry, forgotten to finish this part: The 1 and 2 port intel server gbit chipset have a 4x lanes pci-e conection. The 1 port card only use 1x lane. The 2 port card use 4x lanes. The 4 port card use 4x lanes. pci-e bus speeds: http://www.s-t-e.de/index.html?http%3A//www.s-t-e.de/content/Articles/Articles_08b.html (sorry, only in german) http://www.s-t-e.de/content/Articles/images/Articles_08/PCIe_EffVSPay_f24_sml.gif there you see the efficency with different payloads. minimal ethernet packet size of 64 byte has a efficency of 0.4 with small packets you will be able to achieve 800mbits, whats not bad. perhaps with the 2 port-cards it would be better, but I think, the system io of the processor will start limiting. Kind regards, Ingo Flaschberger From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 16:29:15 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09344106566C; Sun, 2 Mar 2008 16:29:15 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (unknown [IPv6:2001:16d8:ffe8:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE318FC14; Sun, 2 Mar 2008 16:29:14 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from [192.168.3.30] (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: brad) by mail.comstyle.com (Postfix) with ESMTPSA id 8517282D2B; Sun, 2 Mar 2008 17:28:56 +0100 (CET) From: Brad To: freebsd-net@freebsd.org Date: Sun, 2 Mar 2008 11:28:54 -0500 User-Agent: KMail/1.9.7 References: <644693.83415.qm@web63910.mail.re1.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803021128.54894.brad@comstyle.com> X-comstyle-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 8517282D2B.28A2A X-comstyle-MailScanner: Found to be clean X-comstyle-MailScanner-From: brad@comstyle.com X-Spam-Status: No Cc: Barney Cordoba , Ingo Flaschberger , net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 16:29:15 -0000 On Sunday 02 March 2008 11:23:16 Ingo Flaschberger wrote: > The 4 port card use 4x lanes. There are also 6 port adapters which use 4x lanes. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 16:29:15 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09344106566C; Sun, 2 Mar 2008 16:29:15 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (unknown [IPv6:2001:16d8:ffe8:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7EE318FC14; Sun, 2 Mar 2008 16:29:14 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from [192.168.3.30] (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: brad) by mail.comstyle.com (Postfix) with ESMTPSA id 8517282D2B; Sun, 2 Mar 2008 17:28:56 +0100 (CET) From: Brad To: freebsd-net@freebsd.org Date: Sun, 2 Mar 2008 11:28:54 -0500 User-Agent: KMail/1.9.7 References: <644693.83415.qm@web63910.mail.re1.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803021128.54894.brad@comstyle.com> X-comstyle-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 8517282D2B.28A2A X-comstyle-MailScanner: Found to be clean X-comstyle-MailScanner-From: brad@comstyle.com X-Spam-Status: No Cc: Barney Cordoba , Ingo Flaschberger , net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 16:29:15 -0000 On Sunday 02 March 2008 11:23:16 Ingo Flaschberger wrote: > The 4 port card use 4x lanes. There are also 6 port adapters which use 4x lanes. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 17:24:24 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C59D106566C; Sun, 2 Mar 2008 17:24:24 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id E1A698FC15; Sun, 2 Mar 2008 17:24:23 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.2/8.14.2) with ESMTP id m22GwJVe003138; Sun, 2 Mar 2008 10:58:19 -0600 (CST) (envelope-from scf@FreeBSD.org) Date: Sun, 2 Mar 2008 10:58:20 -0600 (CST) From: "Sean C. Farley" To: rwatson@FreeBSD.org In-Reply-To: <200803021504.m22F4lgx018031@freefall.freebsd.org> Message-ID: References: <200803021504.m22F4lgx018031@freefall.freebsd.org> User-Agent: Alpine 1.00 (BSF 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on mail.farley.org Cc: freebsd-net@FreeBSD.org Subject: Re: kern/121274: [panic] Panic in ether_input() with different NIC's. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 17:24:24 -0000 On Sun, 2 Mar 2008, rwatson@FreeBSD.org wrote: > Could you run memtest86 or some other memory testing tool on the box? > While this could well be a software bug, it would be nice to give it a > whirl and make sure you're not running into, say, a 1-bit memory error > that might easily explain the panic across various drivers. Thanks! It passed memtest86+ v2.01 scrutiny. Sean -- scf@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 21:50:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 039F31065675 for ; Sun, 2 Mar 2008 21:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B7E758FC1E for ; Sun, 2 Mar 2008 21:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m22Lo3Ba052039 for ; Sun, 2 Mar 2008 21:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m22Lo3wr052033; Sun, 2 Mar 2008 21:50:03 GMT (envelope-from gnats) Date: Sun, 2 Mar 2008 21:50:03 GMT Message-Id: <200803022150.m22Lo3wr052033@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Sean Farley Cc: Subject: Re: kern/121274: [panic] Panic in ether_input() with different NIC's. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sean Farley List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 21:50:04 -0000 The following reply was made to PR kern/121274; it has been noted by GNATS. From: Sean Farley To: bug-followup@FreeBSD.org, scf@FreeBSD.org Cc: Subject: Re: kern/121274: [panic] Panic in ether_input() with different NIC's. Date: Sun, 2 Mar 2008 15:37:24 -0600 (CST) It passed memtest86+ v2.01 scrutiny. From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 23:27:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4B59106566B for ; Sun, 2 Mar 2008 23:27:51 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 01F1B8FC1A for ; Sun, 2 Mar 2008 23:27:50 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 93803 invoked from network); 2 Mar 2008 22:41:54 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Mar 2008 22:41:54 -0000 Message-ID: <47CB37FB.3060009@freebsd.org> Date: Mon, 03 Mar 2008 00:27:55 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Mike Silbersack References: <200803011338.m21DcY9Z026418@venus.xmundo.net> <20080301142538.L29763@odysseus.silby.com> In-Reply-To: <20080301142538.L29763@odysseus.silby.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rui Paulo , freebsd-net@freebsd.org Subject: Re: Ephemeral port range (patch) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 23:27:51 -0000 Mike Silbersack wrote: > > > On Sat, 1 Mar 2008, Fernando Gont wrote: > >> Folks, >> >> This patch changes the default ephemeral port range from 49152-65535 >> to 1024-65535. This makes it harder for an attacker to guess the >> ephemeral ports (as the port number space is larger). Also, it makes >> the chances of port number collisions smaller. >> (http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt) >> > > There are a number of commonly used ports above 1000, such as nfs and > x11. I think OpenBSD uses 10000-65535, maybe that's a safer choice to go > with. Agreed about 10000-65535. -- Andre From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 23:47:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FDFC1065677 for ; Sun, 2 Mar 2008 23:47:09 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id DBF758FC17 for ; Sun, 2 Mar 2008 23:47:08 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 01C0EAC7EB; Sun, 2 Mar 2008 18:47:08 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 02 Mar 2008 18:47:08 -0500 X-Sasl-enc: MIIiAEeF9gEozgmVqGTmP4Ka/SXoqpB8fVP2pwgu3srj 1204501627 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 70A2917E90; Sun, 2 Mar 2008 18:47:07 -0500 (EST) Message-ID: <47CB3C7A.2000809@FreeBSD.org> Date: Sun, 02 Mar 2008 23:47:06 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: zDen References: <15784710.post@talk.nabble.com> In-Reply-To: <15784710.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Looking for a guide to extend|adapting the socket framework for NFCIP-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 23:47:09 -0000 Hi, I had to use a search engine to figure out what the acronym NFC was, and I assume you mean this: http://en.wikipedia.org/wiki/Near_Field_Communication It helps if you give more background information when asking a more general audience for feedback. zDen wrote: > 1) As the NFC device is attached to the USB or UART port, how and where in > the source code can I change the output of the byte-stream packet to the > proper physical port? i.e where is the part of the source code that is > physical device dependent when doing the I/O calls? > You really need to roll your own driver framework for this. Whilst the Bluetooth support sounds like it's the right place to start to look for ideas, you're going to have to write your own layering. I know off the top of my head that the Bluetooth support is able to add its own TTY disciplines to serial devices but I couldn't tell you specifics, as it's not something I meddle with unless I need to. > 2) As the protocol family (PF_xx) and address family (AF_xx) of NFC is not > define in the socket library, how can I define them and let the default > socket() call return a socket with the customized structure? I can see that > I may need to use SOCK_RAW as the basic socket framework or any others > recommendation? > To learn about adding a new socket family to the system, you really need to pick up a copy of TCP/IP Illustrated Volume 2 and read Chapter 15 onwards. It sounds like you have a fairly involved and challenging software project on your hands. I hope you're being funded by someone to do it, it doesn't sound like something a hobbyist would pick up just for the hell of it if it's going to be done properly, i.e. beyond a quick hack for demonstration purposes. cheers BMS From owner-freebsd-net@FreeBSD.ORG Sun Mar 2 23:49:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 396B4106566C for ; Sun, 2 Mar 2008 23:49:04 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id EBEF48FC1A for ; Sun, 2 Mar 2008 23:49:03 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 99A77ACB16; Sun, 2 Mar 2008 18:49:03 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 02 Mar 2008 18:49:03 -0500 X-Sasl-enc: 3ToyC6gNyGjaxzghW8HZ0SbactqOR2JuwGd1cUusQteD 1204501743 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id E7D4C318EB; Sun, 2 Mar 2008 18:49:02 -0500 (EST) Message-ID: <47CB3CED.7070303@FreeBSD.org> Date: Sun, 02 Mar 2008 23:49:01 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: Fernando Gont References: <200803011338.m21DcY9Z026418@venus.xmundo.net> In-Reply-To: <200803011338.m21DcY9Z026418@venus.xmundo.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rui Paulo , freebsd-net@freebsd.org Subject: Re: Ephemeral port range (patch) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2008 23:49:04 -0000 +1 on increasing the threshold, 1024 is way too low. Also consider the folk who depend on the existing behaviour: a predictable ephemeral port range is useful, if for some reason you need to apply a NAT policy to that traffic, with no other knowledge about how the applications you must NAT actually behave. later BMS From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 00:20:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 080331065675 for ; Mon, 3 Mar 2008 00:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BCCBF8FC15 for ; Mon, 3 Mar 2008 00:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m230K20n064195 for ; Mon, 3 Mar 2008 00:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m230K2kT064194; Mon, 3 Mar 2008 00:20:02 GMT (envelope-from gnats) Date: Mon, 3 Mar 2008 00:20:02 GMT Message-Id: <200803030020.m230K2kT064194@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Sean Farley Cc: Subject: Re: kern/121274: [panic] Panic in ether_input() with different NIC's. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sean Farley List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 00:20:03 -0000 The following reply was made to PR kern/121274; it has been noted by GNATS. From: Sean Farley To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/121274: [panic] Panic in ether_input() with different NIC's. Date: Sun, 2 Mar 2008 17:51:35 -0600 (CST) I am currently running a build with INVARIANTS and WITNESS. No panics so far, but I did get a LOR: Mar 2 15:35:22 gw kernel: 1st 0xc39ee8a0 ipf filter load/unload mutex (ipf filter load/unload mutex) @ /usr/FreeBSD/RELENG_7/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/fil.c:2431 Mar 2 15:35:22 gw kernel: 2nd 0xc3a4a404 gif softc (gif softc) @ /usr/FreeBSD/RELENG_7/src/sys/net/if_gif.c:411 From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 03:57:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AFD3106566C for ; Mon, 3 Mar 2008 03:57:28 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 786C08FC13 for ; Mon, 3 Mar 2008 03:57:28 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id 284F63C0482; Sun, 2 Mar 2008 19:57:28 -0800 (PST) Date: Sun, 2 Mar 2008 19:57:28 -0800 From: Christopher Cowart To: Pyun YongHyeon Message-ID: <20080303035728.GD58253@hal.rescomp.berkeley.edu> Mail-Followup-To: Pyun YongHyeon , freebsd-net@freebsd.org References: <20080225091712.GM88015@hal.rescomp.berkeley.edu> <20080226074355.GD47750@cdnetworks.co.kr> <20080228023840.GR58253@hal.rescomp.berkeley.edu> <20080229060353.GC60623@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zsz/KTM5+kqAkz1u" Content-Disposition: inline In-Reply-To: <20080229060353.GC60623@cdnetworks.co.kr> Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org Subject: msk driver issues [was: Re: vlan issues with 7.0-RC3] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 03:57:28 -0000 --zsz/KTM5+kqAkz1u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 29, 2008 at 03:03:53PM +0900, Pyun YongHyeon wrote: > On Wed, Feb 27, 2008 at 06:38:40PM -0800, Christopher Cowart wrote: >>On Tue, Feb 26, 2008 at 04:43:55PM +0900, Pyun YongHyeon wrote: >>>On Mon, Feb 25, 2008 at 01:17:12AM -0800, Christopher Cowart wrote: >>>> I have a mac mini running 7.0-RC3, which I'm trying to turn it into a >>>> router. I have a Linksys SRW2008 "fully managed" (via an IE only web >>>> interface, ick) switch.=20 >>>>=20 >>>> Switch: >>>> Port 1 - Trunk vlans 10,60,98 - FreeBSD Box >>>> Port 7 - Access vlan 98 - Existing LAN (192.168.1.0/24) >>>>=20 >>>> OpenWRT (192.168.1.1): >>>> WRT54G box on the Existing LAN >>>>=20 >>>> FreeBSD Box: >>>> ifconfig msk0 up >>>> ifconfig vlan98 create vlan 98 vlandev msk0 inet 192.168.1.67/24 >>>>=20 >>>> With this configuration, I can ping hosts on the other lan segment (Po= rt >>>> 7). Arp and icmp seem to be quite happy. Unfortunately, I'm not having >>>> any luck with tcp and udp. Any attempt to ssh to OpenWRT or dig >>>> @OpenWRT hangs indefinitely. If I do a tcpdump, I see the SYN or A? >>>> leaving and absolutely no response returning. If I run a tcpdump on >>>> OpenWRT, I see no incoming traffic. >>>>=20 >>>> When I try to connect *to* the FreeBSD box from the other lan segment,= I >>>> continue to have problems. tcpdump shows the SYNs arriving via vlan98 >>>> and the FreeBSD box responding with SYN-ACK. OpenWRT receives the SYNA= CK. >>>>=20 >>>> I disabled ipfw just to be sure (sysctl -w net.inet.ip.fw.enable=3D0),= but >>>> it had no effect on the problem. If I connect the FreeBSD box to a vlan >>>> 98 access port and assign the address to msk0, my connectivity problems >>>> go away. This leads me to believe that the firewall on OpenWRT is not >>>> the problem and the problem is related to vlans. >>>>=20 >>>> Thinking it was a problem with the not-so-cheap Linksys POS (bitterness >>>> about the IE web interface again), I plugged my MacBook (running >>>> Leopard, not FreeBSD) into the trunk port. Running the ifconfig comman= ds >>>> above (s/msk0/en0/), I got up and running without any problems. This >>>> causes me to suspect the FreeBSD box. >>>>=20 >>>> Does anyone have any idea what's going on here? Any suggestions for >>>> further troubleshooting? >>> >>> Try disabling hardware features one by one in msk(4) and see how >>> it goes. >>> o Disable TSO. >>> o Disable Tx checksum offload. >>> o Disable VLAN hardware tagging. >> >>Works great after `sudo ifconfig msk0 -txcsum'.=20 >> >>Is this a known bug, or should I file a PR? Let me know if there are any >>other details I can provide to help somebody squash it. >=20 > Would you capture broken TCP/UDP frames with tcpdump on receiving side > and show it to me? Thanks for your help. I will e-mail you the corresponding tracefile off-list. I wanted to discuss my initial findings here. When the FreeBSD box sends tcp or udp traffic to elsewhere on the network, it is not seen at the receiving side, not even with bad checksums. I tried setting up the Linksys device with a port mirror, but apparently that's only supported on native vlan access ports. Great. So, I decided to cross-connect the FreeBSD box with my MacBook. I set up a vlan interface and was able to reproduce the behavior. I did a traffic dump on the parent interface (not the vlan interface) on the MacBook, and noticed that the ethernet frames originating from the FreeBSD box lacked 802.1q tags. Is it possible that the interface is not performing the hardware tagging when txcsum is enabled?=20 While I have your attention, I am also suffering from a problem that was reported to -questions here[1]. About 3 times a day, I'll see the watchdog timeout (missed Tx interrupts) message get logged, after which point the NIC is useless until I reboot. Any ideas? [1] http://lists.freebsd.org/pipermail/freebsd-questions/2008-February/1696= 33.html --=20 Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley --zsz/KTM5+kqAkz1u Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBR8t3JyPHEDszU3zYAQK3uQ/8DCa74Eh12ZoFxeKobeEswGhZ/8PC+7/F uNnwfI5tFqa/bxZ6kLplS6hjWRMAIZ/0udFFyYVp99QP7+Iv4hLInmL+NlB+tecL 8WZs2z6x1JHIskqFB9tR4fhvolelk1QHj+jbT8oDJXt8N6cSj6GcCeRbyFwyg49N 30tCYNhafevqMCnHnxLJVfr2tSTOzaYh5Ofu7LwOIEmMQaSYMXoIVTxkBClOhEDy d1lGWmPLX/9GwyAjivKPi1Dt7C4wTeN6kBoW3btSUNxW63yx1zxDfB7hARppy9EM icnQyBZUe0sGgqAsFm623z9Bssrm16zAihZNUCk4ENn5mrhEFGc5Mv0oue32w+sk dLSLePlHPEQbhJxA1fqYr1KLU1DrUfyHH7oUMk6gOjrsCSLFuyhhRo7h66zYedZE fGhV/nB9eNl/zd3RhQyEbqLbNxtFKV976MAPHk2kFqNO7vLxqS78fxivl/ey/7/B BKnFIFFAw8aHifWnDM+fNS6aHgHzo/IOYYTsAQw8u5R8nXVjr3dAEKIj7+uQBW7A ad54f/rTvD9w2UR9lkVn330sGfKp7+oNcYfm301fW6UBaStFhMdhjHXiZWAxeEAF kc8zkUGEiNLfp+ySo5zK08/3SPQfkUHZ9qAI53wANcfD7Vcv688MoVR1dNymqo5D CRHORnaVNTU= =rX8s -----END PGP SIGNATURE----- --zsz/KTM5+kqAkz1u-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 04:35:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4CAC106566C for ; Mon, 3 Mar 2008 04:35:30 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by mx1.freebsd.org (Postfix) with ESMTP id DE9ED8FC21 for ; Mon, 3 Mar 2008 04:35:24 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id DA3E25A8612; Mon, 3 Mar 2008 02:35:28 -0200 (ARDT) Received: from notebook.gont.com.ar (201-254-62-65.speedy.com.ar [201.254.62.65] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m234Z7As026508; Mon, 3 Mar 2008 02:35:07 -0200 Message-Id: <200803030435.m234Z7As026508@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Mar 2008 02:33:37 -0200 To: freebsd-net@freebsd.org From: Fernando Gont Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 03 Mar 2008 02:35:28 -0200 (ARDT) Cc: Rui Paulo Subject: Ephemeral ports patch (fixed) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 04:35:30 -0000 Folks, Here's the same patch, but with the first ephemeral port changed from 1024 to 10000. Index: in.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/in.h,v retrieving revision 1.100 diff -u -r1.100 in.h --- in.h 12 Jun 2007 16:24:53 -0000 1.100 +++ in.h 1 Mar 2008 09:00:10 -0000 @@ -293,8 +293,7 @@ * * The value IP_PORTRANGE_HIGH changes the range of candidate port numbers * into the "high" range. These are reserved for client outbound connections - * which do not want to be filtered by any firewalls. Note that by default - * this is the same as IP_PORTRANGE_DEFAULT. + * which do not want to be filtered by any firewalls. * * The value IP_PORTRANGE_LOW changes the range to the "low" are * that is (by convention) restricted to privileged processes. This @@ -331,8 +330,13 @@ #define IPPORT_RESERVED 1024 /* - * Default local port range, used by both IP_PORTRANGE_DEFAULT - * and IP_PORTRANGE_HIGH. + * Default local port range, used by IP_PORTRANGE_DEFAULT + */ +#define IPPORT_EPHEMERALFIRST 10000 +#define IPPORT_EPHEMERALLAST 655535 + +/* + * Dynamic port range, used by IP_PORTRANGE_HIGH. */ #define IPPORT_HIFIRSTAUTO 49152 #define IPPORT_HILASTAUTO 65535 Index: in_pcb.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v retrieving revision 1.198 diff -u -r1.198 in_pcb.c --- in_pcb.c 22 Dec 2007 10:06:11 -0000 1.198 +++ in_pcb.c 1 Mar 2008 09:00:11 -0000 @@ -89,8 +89,8 @@ */ int ipport_lowfirstauto = IPPORT_RESERVED - 1; /* 1023 */ int ipport_lowlastauto = IPPORT_RESERVEDSTART; /* 600 */ -int ipport_firstauto = IPPORT_HIFIRSTAUTO; /* 49152 */ -int ipport_lastauto = IPPORT_HILASTAUTO; /* 65535 */ +int ipport_firstauto = IPPORT_EPHEMERALFIRST; /* 10000 */ +int ipport_lastauto = IPPORT_EPHEMERALLAST; /* 65535 */ int ipport_hifirstauto = IPPORT_HIFIRSTAUTO; /* 49152 */ int ipport_hilastauto = IPPORT_HILASTAUTO; /* 65535 */ @@ -393,7 +393,7 @@ if (*lportp != 0) lport = *lportp; if (lport == 0) { - u_short first, last; + u_short first, last, aux; int count; if (laddr.s_addr != INADDR_ANY) @@ -440,47 +440,28 @@ /* * Simple check to ensure all ports are not used up causing * a deadlock here. - * - * We split the two cases (up and down) so that the direction - * is not being tested on each round of the loop. */ if (first > last) { - /* - * counting down - */ - if (dorandom) - *lastport = first - - (arc4random() % (first - last)); - count = first - last; + aux = first; + first = last; + last = aux; + } - do { - if (count-- < 0) /* completely used? */ - return (EADDRNOTAVAIL); - --*lastport; - if (*lastport > first || *lastport < last) - *lastport = first; - lport = htons(*lastport); - } while (in_pcblookup_local(pcbinfo, laddr, lport, - wild)); - } else { - /* - * counting up - */ - if (dorandom) - *lastport = first + - (arc4random() % (last - first)); - count = last - first; + if (dorandom) + *lastport = first + + (arc4random() % (last - first)); - do { - if (count-- < 0) /* completely used? */ - return (EADDRNOTAVAIL); - ++*lastport; - if (*lastport < first || *lastport > last) - *lastport = first; - lport = htons(*lastport); - } while (in_pcblookup_local(pcbinfo, laddr, lport, - wild)); - } + count = last - first; + + do { + if (count-- < 0) /* completely used? */ + return (EADDRNOTAVAIL); + ++*lastport; + if (*lastport < first || *lastport > last) + *lastport = first; + lport = htons(*lastport); + } while (in_pcblookup_local(pcbinfo, laddr, lport, + wild)); } if (prison_ip(cred, 0, &laddr.s_addr)) return (EINVAL); Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 04:45:09 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3901F106566C for ; Mon, 3 Mar 2008 04:45:09 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by mx1.freebsd.org (Postfix) with ESMTP id D4E228FC1F for ; Mon, 3 Mar 2008 04:45:08 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id B23BB5A7463; Mon, 3 Mar 2008 02:45:13 -0200 (ARDT) Received: from notebook.gont.com.ar (201-254-62-65.speedy.com.ar [201.254.62.65] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m234iqVp004383; Mon, 3 Mar 2008 02:44:52 -0200 Message-Id: <200803030444.m234iqVp004383@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Mar 2008 02:42:58 -0200 To: "Bruce M. Simpson" From: Fernando Gont In-Reply-To: <47CB3CED.7070303@FreeBSD.org> References: <200803011338.m21DcY9Z026418@venus.xmundo.net> <47CB3CED.7070303@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 03 Mar 2008 02:45:13 -0200 (ARDT) Cc: Rui Paulo , freebsd-net@FreeBSD.org Subject: Re: Ephemeral port range (patch) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 04:45:09 -0000 At 09:49 p.m. 02/03/2008, you wrote: >+1 on increasing the threshold, 1024 is way too low. With the current patch, I agree. I'm planning to implement the scheme described in the port randomization internt-draft I referenced, and implement the array-of-bits thing. That way you can exclude whichever ports you want, without "wasting" the 1024-9999 port range. >Also consider the folk who depend on the existing behaviour: a >predictable ephemeral port range is useful, if for some reason you >need to apply a NAT policy to that traffic, with no other >knowledge about how the applications you must NAT actually behave. You can still set porthi or portlow to select whichever port range you want. The patch just changes the default case. As noted in one of the sections of the draft I referenced, turns put that each TCP/IP stack chooses its own range for the ephemeral ports. So unless you're tweaking the configuration of each of the systems you have behind the NAT, I'm afraid you won't be able to implement such a policy. FWIW, Windows used the range 1024-4999 or something... at least W95 and XP. Vista probably still does the same thing. Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 06:06:34 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89104106566C; Mon, 3 Mar 2008 06:06:34 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (pool-72-87-39-191.ptldor.fios.verizon.net [72.87.39.191]) by mx1.freebsd.org (Postfix) with ESMTP id 4EEAA8FC16; Mon, 3 Mar 2008 06:06:34 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from schitzo.solgatos.com (localhost.home.localnet [127.0.0.1]) by schitzo.solgatos.com (8.14.2/8.13.8) with ESMTP id m2366Y46008469; Sun, 2 Mar 2008 22:06:34 -0800 Received: from sopwith.solgatos.com (uucp@localhost) by schitzo.solgatos.com (8.14.2/8.14.1/Submit) with UUCP id m2366XDI008465; Sun, 2 Mar 2008 22:06:34 -0800 Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id GAA01816; Mon, 3 Mar 2008 06:01:35 GMT Message-Id: <200803030601.GAA01816@sopwith.solgatos.com> To: freebsd-net@freebsd.org, freebsd-performance@freebsd.org In-reply-to: Your message of "Sat, 01 Mar 2008 12:31:23 +0100." <47C93E8B.3010609@digiware.nl> Date: Sun, 02 Mar 2008 22:01:35 +0000 From: Dieter Cc: Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 06:06:34 -0000 > > Hopefully there will be direct memory bus connected nic's in future. > > (HyperTransport connected nic's) > > Well that is going to be an AMD only solution, and I'm not even shure > that AMD would like to have other things than CPU's on that bus. There are FPGAs that plug into a CPU socket (for mainboards with multiple CPU sockets). There will be GPUs on the HyperTransport bus. Putting a network controller there seems a tad extreme. From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 06:11:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FB68106566B for ; Mon, 3 Mar 2008 06:11:27 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id F1CFE8FC1C for ; Mon, 3 Mar 2008 06:11:26 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 15909 invoked from network); 3 Mar 2008 06:11:25 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 3 Mar 2008 06:11:25 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 3 Mar 2008 00:11:24 -0600 (CST) From: Mike Silbersack To: Fernando Gont In-Reply-To: <200803030435.m234Z7As026508@venus.xmundo.net> Message-ID: <20080303001004.R37933@odysseus.silby.com> References: <200803030435.m234Z7As026508@venus.xmundo.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rui Paulo , freebsd-net@freebsd.org Subject: Re: Ephemeral ports patch (fixed) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 06:11:27 -0000 On Mon, 3 Mar 2008, Fernando Gont wrote: > Folks, > > Here's the same patch, but with the first ephemeral port changed from 1024 to > 10000. Now that I've actually gone to try to apply the patch (so I can view the two codepaths side by side, rather than in diff form), I'm finding that I can't apply it. I think all the whitespace got stomped, either by your mail program or my mail program. Can you please resent this as an attachment? -Mike From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 06:43:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3ED6106566B for ; Mon, 3 Mar 2008 06:43:10 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id 416EA8FC19 for ; Mon, 3 Mar 2008 06:43:09 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 62488 invoked from network); 3 Mar 2008 06:43:08 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 3 Mar 2008 06:43:08 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 3 Mar 2008 00:43:07 -0600 (CST) From: Mike Silbersack To: Fernando Gont In-Reply-To: <200803020034.m220YJ6t018608@venus.xmundo.net> Message-ID: <20080303002815.U37933@odysseus.silby.com> References: <20080301224217.33F0A45047@ptavv.es.net> <200803020034.m220YJ6t018608@venus.xmundo.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rui Paulo , freebsd-net@freebsd.org, Kevin Oberman Subject: Re: Ephemeral port range (patch) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 06:43:10 -0000 On Sat, 1 Mar 2008, Fernando Gont wrote: > I will also start working on the double-hash ephemeral port selection > algorithm described in the draft (this is, IMHO, the right approach to > ephemeral port randomization) > > Kind regards, > > -- > Fernando Gont Earlier in the week, I had commented (via private e-mail?) that I thought that Amit Klein's algorithm which I recently implemented in ip_id.c might be adapted to serve as an ephemeral port allocator. Now that I've thought more about it, I'm not as certain that it would fit well. I'll try to sketch out my ideas and see if I can figure out how it could fit. The double-hash concept sounds pretty good, but there's a major problem with it. If an application does a bind() to get a local port before doing a connect(), you don't know the remote IP or the remote port. There's a related "feature" in the BSD TCP stack that all local ports are considered equal; even for applications that do a connect() call and specify a remote IP/port, we do not let them use the same local port to two different remote IPs at the same time. This puts a limit on the total number of outgoing connections that one machine can have. -Mike From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 09:20:52 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D0F31065670 for ; Mon, 3 Mar 2008 09:20:52 +0000 (UTC) (envelope-from lukasz@bromirski.net) Received: from r2d2.bromirski.net (r2d2.bromirski.net [217.153.57.194]) by mx1.freebsd.org (Postfix) with ESMTP id E259B8FC16 for ; Mon, 3 Mar 2008 09:20:51 +0000 (UTC) (envelope-from lukasz@bromirski.net) Received: by r2d2.bromirski.net (Postfix, from userid 1008) id 0C198108A78; Mon, 3 Mar 2008 10:02:51 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on r2d2.bromirski.net X-Spam-Level: *** X-Spam-Status: No, score=3.1 required=5.0 tests=DATE_IN_FUTURE_06_12 autolearn=no version=3.2.4 Received: from [127.0.0.1] (r2d2.bromirski.net [217.153.57.194]) by r2d2.bromirski.net (Postfix) with ESMTP id 20D1A108980; Mon, 3 Mar 2008 10:02:50 +0100 (CET) Message-ID: <47CC304F.6040006@bromirski.net> Date: Mon, 03 Mar 2008 18:07:27 +0100 From: =?ISO-8859-2?Q?=A3ukasz_Bromirski?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Willem Jan Withagen References: <497111.42659.qm@web63905.mail.re1.yahoo.com> <20080301225727.GA85851@owl.midgard.homeip.net> <47CAADB8.9000202@digiware.nl> In-Reply-To: <47CAADB8.9000202@digiware.nl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: Barney Cordoba , Ingo Flaschberger , net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 09:20:52 -0000 Willem Jan Withagen wrote: > I'm looking for a stream exploder.:) > 1 2Mbit stream in, and as many as possible out. > And 7*1Gb = 14Gbit, so I'd like to be pushing 7000 streams. > (One advantage is that they will be UDP streams, so there is > a little less bookkeeping in the protocol stack ) Wouldn't it be a case for use of multicast vs unicast? Hardware is always better anyway, so why not invest in some switch that can do unicast/multicast in hardware? -- "Don't expect me to cry for all the | £ukasz Bromirski reasons you had to die" -- Kurt Cobain | http://lukasz.bromirski.net From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 10:14:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DD12106566B; Mon, 3 Mar 2008 10:14:21 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.freebsd.org (Postfix) with ESMTP id 1EA918FC1D; Mon, 3 Mar 2008 10:14:20 +0000 (UTC) (envelope-from piso@southcross.wired.org) Received: from southcross.wired.org (host-84-221-78-158.cust-adsl.tiscali.it [84.221.78.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id CAD5811AE75; Mon, 3 Mar 2008 11:14:14 +0100 (CET) Received: (from piso@localhost) by southcross.wired.org (8.14.2/8.14.1/Submit) id m23AHKDK034084; Mon, 3 Mar 2008 11:17:20 +0100 (CET) (envelope-from piso) Date: Mon, 3 Mar 2008 11:17:19 +0100 From: Paolo Pisati To: Luigi Rizzo Message-ID: <20080303101718.GA34056@tin.it> References: <20080302144939.GA23353@tin.it> <20080302145850.GA33308@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080302145850.GA33308@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: freebsd-ipfw@freebsd.org, Paolo Pisati , freebsd-net@freebsd.org Subject: Re: ipfw initialization: SI_ORDER_ANY -> SI_ORDER_MIDDLE? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 10:14:21 -0000 On Sun, Mar 02, 2008 at 03:58:50PM +0100, Luigi Rizzo wrote: > > The SI_ORDER_* definitions in /sys/sys/kernel.h are enumerated on a > large range, so if the existing code does not have races, > you can safely move the non-leaf modules > (such as ipfw,ko in your case) to (SI_ORDER_ANY - some_small_integer) > without breaking anything. fine, i did this. is it MFCable? bye, P. From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 11:07:13 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F3231065671 for ; Mon, 3 Mar 2008 11:07:13 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0B1538FC15 for ; Mon, 3 Mar 2008 11:07:13 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m23B7C94022128 for ; Mon, 3 Mar 2008 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m23B7CTr022124 for freebsd-net@FreeBSD.org; Mon, 3 Mar 2008 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Mar 2008 11:07:12 GMT Message-Id: <200803031107.m23B7CTr022124@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 11:07:13 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast f kern/116172 net [tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash (regression) o kern/118880 net [ipv6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card (regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time f kern/120725 net [bce] On board second lan port 'bce1' with Broadcom Ne f kern/120966 net [rum]: kernel panic with if_rum and WPA encryption 35 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [ng] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118975 net [bge] [patch] Broadcom 5906 not handled by FreeBSD o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120493 net [wpi] if_wpi.ko fails to load on a Toshiba Satellite P o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120958 net no response to ICMP traffic on interface configured wi o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic f kern/121274 net [panic] Panic in ether_input() with different NIC's. 29 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 11:47:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC32C1065673; Mon, 3 Mar 2008 11:47:11 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 98CB28FC18; Mon, 3 Mar 2008 11:47:10 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6C57373129; Mon, 3 Mar 2008 12:48:04 +0100 (CET) Date: Mon, 3 Mar 2008 12:48:04 +0100 From: Luigi Rizzo To: Paolo Pisati Message-ID: <20080303114804.GA46175@onelab2.iet.unipi.it> References: <20080302144939.GA23353@tin.it> <20080302145850.GA33308@onelab2.iet.unipi.it> <20080303101718.GA34056@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080303101718.GA34056@tin.it> User-Agent: Mutt/1.4.2.3i Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: ipfw initialization: SI_ORDER_ANY -> SI_ORDER_MIDDLE? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 11:47:12 -0000 On Mon, Mar 03, 2008 at 11:17:19AM +0100, Paolo Pisati wrote: > On Sun, Mar 02, 2008 at 03:58:50PM +0100, Luigi Rizzo wrote: > > > > The SI_ORDER_* definitions in /sys/sys/kernel.h are enumerated on a > > large range, so if the existing code does not have races, > > you can safely move the non-leaf modules > > (such as ipfw,ko in your case) to (SI_ORDER_ANY - some_small_integer) > > without breaking anything. > > fine, i did this. > > is it MFCable? i think so, the SI_ORDER_* definitions are the same at least down to RELENG_6, which is the lowest release we probably care about. cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 12:38:58 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97202106566C for ; Mon, 3 Mar 2008 12:38:58 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (www.tegenbosch28.nl [217.21.251.97]) by mx1.freebsd.org (Postfix) with ESMTP id 55DC68FC2C for ; Mon, 3 Mar 2008 12:38:58 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 5282D173A3; Mon, 3 Mar 2008 13:38:57 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDU3IB2LEH7a; Mon, 3 Mar 2008 13:38:55 +0100 (CET) Received: from [212.61.27.67] (opteron.digiware.nl [212.61.27.67]) by mail.digiware.nl (Postfix) with ESMTP id 528C81734E; Mon, 3 Mar 2008 13:38:55 +0100 (CET) Message-ID: <47CBF16C.6020704@digiware.nl> Date: Mon, 03 Mar 2008 13:39:08 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: =?ISO-8859-2?Q?=A3ukasz_Bromirski?= References: <497111.42659.qm@web63905.mail.re1.yahoo.com> <20080301225727.GA85851@owl.midgard.homeip.net> <47CAADB8.9000202@digiware.nl> <47CC304F.6040006@bromirski.net> In-Reply-To: <47CC304F.6040006@bromirski.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: Barney Cordoba , Ingo Flaschberger , net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 12:38:58 -0000 £ukasz Bromirski wrote: > Willem Jan Withagen wrote: > >> I'm looking for a stream exploder.:) >> 1 2Mbit stream in, and as many as possible out. >> And 7*1Gb = 14Gbit, so I'd like to be pushing 7000 streams. >> (One advantage is that they will be UDP streams, so there is >> a little less bookkeeping in the protocol stack ) > > Wouldn't it be a case for use of multicast vs unicast? Hardware > is always better anyway, so why not invest in some switch that > can do unicast/multicast in hardware? Usefull suggestion, only this is going to be in an overlay cloud where we do not have control over all the endpoint networks. let alone that we can get them to use multicast. And even those that use multicast in their last-mule equipment, don't always have correct setups. My experience is that Multicast in nice in theory and experiment, but when push comes to shove it does not completely deliver. --WjW From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 12:52:58 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A81E1065699 for ; Mon, 3 Mar 2008 12:52:58 +0000 (UTC) (envelope-from lukasz@bromirski.net) Received: from r2d2.bromirski.net (r2d2.bromirski.net [217.153.57.194]) by mx1.freebsd.org (Postfix) with ESMTP id 203968FC51 for ; Mon, 3 Mar 2008 12:52:58 +0000 (UTC) (envelope-from lukasz@bromirski.net) Received: by r2d2.bromirski.net (Postfix, from userid 1008) id 128F2108A78; Mon, 3 Mar 2008 13:52:57 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on r2d2.bromirski.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.2.4 Received: from [127.0.0.1] (r2d2.bromirski.net [217.153.57.194]) by r2d2.bromirski.net (Postfix) with ESMTP id 33E45108993; Mon, 3 Mar 2008 13:52:56 +0100 (CET) Message-ID: <47CBF503.9060208@bromirski.net> Date: Mon, 03 Mar 2008 13:54:27 +0100 From: =?ISO-8859-2?Q?=A3ukasz_Bromirski?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Willem Jan Withagen References: <497111.42659.qm@web63905.mail.re1.yahoo.com> <20080301225727.GA85851@owl.midgard.homeip.net> <47CAADB8.9000202@digiware.nl> <47CC304F.6040006@bromirski.net> <47CBF16C.6020704@digiware.nl> In-Reply-To: <47CBF16C.6020704@digiware.nl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: Barney Cordoba , Ingo Flaschberger , net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 12:52:58 -0000 Willem Jan Withagen wrote: > £ukasz Bromirski wrote: >> Willem Jan Withagen wrote: >> >>> I'm looking for a stream exploder.:) >>> 1 2Mbit stream in, and as many as possible out. >>> And 7*1Gb = 14Gbit, so I'd like to be pushing 7000 streams. >>> (One advantage is that they will be UDP streams, so there is >>> a little less bookkeeping in the protocol stack ) >> >> Wouldn't it be a case for use of multicast vs unicast? Hardware >> is always better anyway, so why not invest in some switch that >> can do unicast/multicast in hardware? > > Usefull suggestion, only this is going to be in an overlay cloud where > we do not have control over all the endpoint networks. let alone that we > can get them to use multicast. And even those that use multicast in their > last-mule equipment, don't always have correct setups. > > My experience is that Multicast in nice in theory and experiment, but when > push comes to shove it does not completely deliver. I don't know exact requirements and application used, but given IP TV deployments relying heavily on multicast, and all other "VoD" technologies also using multicast...I find Your comments disturbing :) However, if you don't control the network over which it will be transported, you need to replicate each stream...and so either you'll find bandwidth to do it (or pay for it) or be forced to switch to other design. -- "Don't expect me to cry for all the | £ukasz Bromirski reasons you had to die" -- Kurt Cobain | http://lukasz.bromirski.net From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 12:58:48 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B883106566C for ; Mon, 3 Mar 2008 12:58:48 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (www.tegenbosch28.nl [217.21.251.97]) by mx1.freebsd.org (Postfix) with ESMTP id 388878FC2E for ; Mon, 3 Mar 2008 12:58:47 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 0F1EB17392; Mon, 3 Mar 2008 13:58:47 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJbkutIzQpz9; Mon, 3 Mar 2008 13:58:41 +0100 (CET) Received: from [212.61.27.67] (opteron.digiware.nl [212.61.27.67]) by mail.digiware.nl (Postfix) with ESMTP id 9011D173A4; Mon, 3 Mar 2008 13:58:41 +0100 (CET) Message-ID: <47CBF60E.2060704@digiware.nl> Date: Mon, 03 Mar 2008 13:58:54 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: =?ISO-8859-2?Q?=A3ukasz_Bromirski?= References: <497111.42659.qm@web63905.mail.re1.yahoo.com> <20080301225727.GA85851@owl.midgard.homeip.net> <47CAADB8.9000202@digiware.nl> <47CC304F.6040006@bromirski.net> <47CBF16C.6020704@digiware.nl> <47CBF503.9060208@bromirski.net> In-Reply-To: <47CBF503.9060208@bromirski.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: Barney Cordoba , Ingo Flaschberger , net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 12:58:48 -0000 £ukasz Bromirski wrote: >> My experience is that Multicast in nice in theory and experiment, but >> when >> push comes to shove it does not completely deliver. > > I don't know exact requirements and application used, but given IP TV > deployments relying heavily on multicast, and all other "VoD" > technologies also using multicast...I find Your comments disturbing :) Where do you think I'm getting my experience from. ;) Even network owners and techies will admit to this when squeezed. > However, if you don't control the network over which it will be > transported, you need to replicate each stream...and so either > you'll find bandwidth to do it (or pay for it) or be forced to switch > to other design. There can only be one...... And IP TV over closed networks are not going to make it. That is not what the customer really wants. But this is my last remark to this aspect in this list, since it takes us very OT. --WjW From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 13:06:57 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC0651065670 for ; Mon, 3 Mar 2008 13:06:57 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id AD55A8FC12 for ; Mon, 3 Mar 2008 13:06:57 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 07251AC61F; Mon, 3 Mar 2008 07:47:42 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 03 Mar 2008 07:47:42 -0500 X-Sasl-enc: qqFc1K6f+6jM9gLE9YKSwP+lg8JpQtlw+S7GyRpT7Dd3 1204548461 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 138402C6C0; Mon, 3 Mar 2008 07:47:40 -0500 (EST) Message-ID: <47CBF36C.9000702@FreeBSD.org> Date: Mon, 03 Mar 2008 12:47:40 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: Willem Jan Withagen References: <497111.42659.qm@web63905.mail.re1.yahoo.com> <20080301225727.GA85851@owl.midgard.homeip.net> <47CAADB8.9000202@digiware.nl> <47CC304F.6040006@bromirski.net> <47CBF16C.6020704@digiware.nl> In-Reply-To: <47CBF16C.6020704@digiware.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?=3Fukasz_Bromirski?= , net@freebsd.org, Ingo Flaschberger , Barney Cordoba Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 13:06:57 -0000 Willem Jan Withagen wrote: > =A3ukasz Bromirski wrote: >> Wouldn't it be a case for use of multicast vs unicast? Hardware >> is always better anyway, so why not invest in some switch that >> can do unicast/multicast in hardware? > > Usefull suggestion, only this is going to be in an overlay cloud where > we do not have control over all the endpoint networks. let alone that w= e > can get them to use multicast. And even those that use multicast in the= ir > last-mule equipment, don't always have correct setups. > > My experience is that Multicast in nice in theory and experiment, but=20 > when > push comes to shove it does not completely deliver. I have to agree wholeheartedly, for more detail than you can shake a=20 stick at, look here: http://www.cs.ucr.edu/~michalis/COURSES/204-02b/papers/ramalho.html If you're running over MPLS all bets are off. MPLS is like ATM in the=20 sense that it ain't got no multicast grok, as far as I can fathom,=20 anyway. Label switching is label switching. I never saw any support for=20 the notion of 1:M in the LSPs. Multicast is more likely to succeed at the moment when you have complete = knowledge of the network topology, and IP layer visibility. There are=20 ongoing efforts to address these limitations. later BMS From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 13:33:02 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17AC61065670; Mon, 3 Mar 2008 13:33:02 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F051A8FC2D; Mon, 3 Mar 2008 13:33:01 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m23DX16M039220; Mon, 3 Mar 2008 13:33:01 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m23DX08O039214; Mon, 3 Mar 2008 13:33:00 GMT (envelope-from gavin) Date: Mon, 3 Mar 2008 13:33:00 GMT Message-Id: <200803031333.m23DX08O039214@freefall.freebsd.org> To: weijinhong@cjis.cn, gavin@FreeBSD.org, gavin@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/92090: [bge] bge0: watchdog timeout -- resetting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 13:33:02 -0000 Synopsis: [bge] bge0: watchdog timeout -- resetting State-Changed-From-To: feedback->open State-Changed-By: gavin State-Changed-When: Mon Mar 3 13:32:16 UTC 2008 State-Changed-Why: Feedback was received - this is still an issue Responsible-Changed-From-To: gavin->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Mon Mar 3 13:32:16 UTC 2008 Responsible-Changed-Why: Over to freebsd-net http://www.freebsd.org/cgi/query-pr.cgi?pr=92090 From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 14:12:15 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CE7A1065672 for ; Mon, 3 Mar 2008 14:12:15 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by mx1.freebsd.org (Postfix) with ESMTP id 647E18FC12 for ; Mon, 3 Mar 2008 14:12:14 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AF3505A8A77; Mon, 3 Mar 2008 12:12:14 -0200 (ARDT) Received: from notebook.gont.com.ar (201-254-62-65.speedy.com.ar [201.254.62.65] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m23EC4WB031100; Mon, 3 Mar 2008 12:12:06 -0200 Message-Id: <200803031412.m23EC4WB031100@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Mar 2008 12:06:38 -0200 To: Mike Silbersack From: Fernando Gont In-Reply-To: <20080303001004.R37933@odysseus.silby.com> References: <200803030435.m234Z7As026508@venus.xmundo.net> <20080303001004.R37933@odysseus.silby.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1673812953==_" X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 03 Mar 2008 12:12:14 -0200 (ARDT) Cc: Rui Paulo , freebsd-net@freebsd.org Subject: Re: Ephemeral ports patch (fixed) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 14:12:15 -0000 --=====================_1673812953==_ Content-Type: text/plain; charset="us-ascii"; format=flowed At 04:11 a.m. 03/03/2008, Mike Silbersack wrote: >>Here's the same patch, but with the first ephemeral port changed >>from 1024 to 10000. > >Now that I've actually gone to try to apply the patch (so I can view >the two codepaths side by side, rather than in diff form), I'm >finding that I can't apply it. I think all the whitespace got >stomped, either by your mail program or my mail program. Can you >please resent this as an attachment? Sure. Please let me know if this one is okay. Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 --=====================_1673812953==_ Content-Type: text/plain; name="patch-port-range.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-port-range.txt" SW5kZXg6IGluLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL25ldGlu ZXQvaW4uaCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMDAKZGlmZiAtdSAtcjEuMTAwIGluLmgK LS0tIGluLmgJMTIgSnVuIDIwMDcgMTY6MjQ6NTMgLTAwMDAJMS4xMDAKKysrIGluLmgJMSBNYXIg MjAwOCAwOTowMDoxMCAtMDAwMApAQCAtMjkzLDggKzI5Myw3IEBACiAgKgogICogVGhlIHZhbHVl IElQX1BPUlRSQU5HRV9ISUdIIGNoYW5nZXMgdGhlIHJhbmdlIG9mIGNhbmRpZGF0ZSBwb3J0IG51 bWJlcnMKICAqIGludG8gdGhlICJoaWdoIiByYW5nZS4gIFRoZXNlIGFyZSByZXNlcnZlZCBmb3Ig Y2xpZW50IG91dGJvdW5kIGNvbm5lY3Rpb25zCi0gKiB3aGljaCBkbyBub3Qgd2FudCB0byBiZSBm aWx0ZXJlZCBieSBhbnkgZmlyZXdhbGxzLiAgTm90ZSB0aGF0IGJ5IGRlZmF1bHQKLSAqIHRoaXMg aXMgdGhlIHNhbWUgYXMgSVBfUE9SVFJBTkdFX0RFRkFVTFQuCisgKiB3aGljaCBkbyBub3Qgd2Fu dCB0byBiZSBmaWx0ZXJlZCBieSBhbnkgZmlyZXdhbGxzLgogICoKICAqIFRoZSB2YWx1ZSBJUF9Q T1JUUkFOR0VfTE9XIGNoYW5nZXMgdGhlIHJhbmdlIHRvIHRoZSAibG93IiBhcmUKICAqIHRoYXQg aXMgKGJ5IGNvbnZlbnRpb24pIHJlc3RyaWN0ZWQgdG8gcHJpdmlsZWdlZCBwcm9jZXNzZXMuICBU aGlzCkBAIC0zMzEsOCArMzMwLDEzIEBACiAjZGVmaW5lCUlQUE9SVF9SRVNFUlZFRAkJMTAyNAog CiAvKgotICogRGVmYXVsdCBsb2NhbCBwb3J0IHJhbmdlLCB1c2VkIGJ5IGJvdGggSVBfUE9SVFJB TkdFX0RFRkFVTFQKLSAqIGFuZCBJUF9QT1JUUkFOR0VfSElHSC4KKyAqIERlZmF1bHQgbG9jYWwg cG9ydCByYW5nZSwgdXNlZCBieSBJUF9QT1JUUkFOR0VfREVGQVVMVAorICovCisjZGVmaW5lIElQ UE9SVF9FUEhFTUVSQUxGSVJTVAkxMDAwMAorI2RlZmluZSBJUFBPUlRfRVBIRU1FUkFMTEFTVAk2 NTU1MzUgCisgCisvKgorICogRHluYW1pYyBwb3J0IHJhbmdlLCB1c2VkIGJ5IElQX1BPUlRSQU5H RV9ISUdILgogICovCiAjZGVmaW5lCUlQUE9SVF9ISUZJUlNUQVVUTwk0OTE1MgogI2RlZmluZQlJ UFBPUlRfSElMQVNUQVVUTwk2NTUzNQpJbmRleDogaW5fcGNiLmMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmls ZTogL2hvbWUvbmN2cy9zcmMvc3lzL25ldGluZXQvaW5fcGNiLmMsdgpyZXRyaWV2aW5nIHJldmlz aW9uIDEuMTk4CmRpZmYgLXUgLXIxLjE5OCBpbl9wY2IuYwotLS0gaW5fcGNiLmMJMjIgRGVjIDIw MDcgMTA6MDY6MTEgLTAwMDAJMS4xOTgKKysrIGluX3BjYi5jCTEgTWFyIDIwMDggMDk6MDA6MTEg LTAwMDAKQEAgLTg5LDggKzg5LDggQEAKICAqLwogaW50CWlwcG9ydF9sb3dmaXJzdGF1dG8gID0g SVBQT1JUX1JFU0VSVkVEIC0gMTsJLyogMTAyMyAqLwogaW50CWlwcG9ydF9sb3dsYXN0YXV0byA9 IElQUE9SVF9SRVNFUlZFRFNUQVJUOwkvKiA2MDAgKi8KLWludAlpcHBvcnRfZmlyc3RhdXRvID0g SVBQT1JUX0hJRklSU1RBVVRPOwkJLyogNDkxNTIgKi8KLWludAlpcHBvcnRfbGFzdGF1dG8gID0g SVBQT1JUX0hJTEFTVEFVVE87CQkvKiA2NTUzNSAqLworaW50CWlwcG9ydF9maXJzdGF1dG8gPSBJ UFBPUlRfRVBIRU1FUkFMRklSU1Q7CS8qIDEwMDAwICovCitpbnQJaXBwb3J0X2xhc3RhdXRvICA9 IElQUE9SVF9FUEhFTUVSQUxMQVNUOwkvKiA2NTUzNSAqLwogaW50CWlwcG9ydF9oaWZpcnN0YXV0 byA9IElQUE9SVF9ISUZJUlNUQVVUTzsJLyogNDkxNTIgKi8KIGludAlpcHBvcnRfaGlsYXN0YXV0 byAgPSBJUFBPUlRfSElMQVNUQVVUTzsJCS8qIDY1NTM1ICovCiAKQEAgLTM5Myw3ICszOTMsNyBA QAogCWlmICgqbHBvcnRwICE9IDApCiAJCWxwb3J0ID0gKmxwb3J0cDsKIAlpZiAobHBvcnQgPT0g MCkgewotCQl1X3Nob3J0IGZpcnN0LCBsYXN0OworCQl1X3Nob3J0IGZpcnN0LCBsYXN0LCBhdXg7 CiAJCWludCBjb3VudDsKIAogCQlpZiAobGFkZHIuc19hZGRyICE9IElOQUREUl9BTlkpCkBAIC00 NDAsNDcgKzQ0MCwyOCBAQAogCQkvKgogCQkgKiBTaW1wbGUgY2hlY2sgdG8gZW5zdXJlIGFsbCBw b3J0cyBhcmUgbm90IHVzZWQgdXAgY2F1c2luZwogCQkgKiBhIGRlYWRsb2NrIGhlcmUuCi0JCSAq Ci0JCSAqIFdlIHNwbGl0IHRoZSB0d28gY2FzZXMgKHVwIGFuZCBkb3duKSBzbyB0aGF0IHRoZSBk aXJlY3Rpb24KLQkJICogaXMgbm90IGJlaW5nIHRlc3RlZCBvbiBlYWNoIHJvdW5kIG9mIHRoZSBs b29wLgogCQkgKi8KIAkJaWYgKGZpcnN0ID4gbGFzdCkgewotCQkJLyoKLQkJCSAqIGNvdW50aW5n IGRvd24KLQkJCSAqLwotCQkJaWYgKGRvcmFuZG9tKQotCQkJCSpsYXN0cG9ydCA9IGZpcnN0IC0K LQkJCQkJICAgIChhcmM0cmFuZG9tKCkgJSAoZmlyc3QgLSBsYXN0KSk7Ci0JCQljb3VudCA9IGZp cnN0IC0gbGFzdDsKKwkJCWF1eCA9IGZpcnN0OworCQkJZmlyc3QgPSBsYXN0OworCQkJbGFzdCA9 IGF1eDsKKwkJfQogCi0JCQlkbyB7Ci0JCQkJaWYgKGNvdW50LS0gPCAwKQkvKiBjb21wbGV0ZWx5 IHVzZWQ/ICovCi0JCQkJCXJldHVybiAoRUFERFJOT1RBVkFJTCk7Ci0JCQkJLS0qbGFzdHBvcnQ7 Ci0JCQkJaWYgKCpsYXN0cG9ydCA+IGZpcnN0IHx8ICpsYXN0cG9ydCA8IGxhc3QpCi0JCQkJCSps YXN0cG9ydCA9IGZpcnN0OwotCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKLQkJCX0gd2hp bGUgKGluX3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRkciwgbHBvcnQsCi0JCQkgICAgd2ls ZCkpOwotCQl9IGVsc2UgewotCQkJLyoKLQkJCSAqIGNvdW50aW5nIHVwCi0JCQkgKi8KLQkJCWlm IChkb3JhbmRvbSkKLQkJCQkqbGFzdHBvcnQgPSBmaXJzdCArCi0JCQkJCSAgICAoYXJjNHJhbmRv bSgpICUgKGxhc3QgLSBmaXJzdCkpOwotCQkJY291bnQgPSBsYXN0IC0gZmlyc3Q7CisJCWlmIChk b3JhbmRvbSkKKwkJCSpsYXN0cG9ydCA9IGZpcnN0ICsKKwkJCQkgICAgKGFyYzRyYW5kb20oKSAl IChsYXN0IC0gZmlyc3QpKTsKIAotCQkJZG8gewotCQkJCWlmIChjb3VudC0tIDwgMCkJLyogY29t cGxldGVseSB1c2VkPyAqLwotCQkJCQlyZXR1cm4gKEVBRERSTk9UQVZBSUwpOwotCQkJCSsrKmxh c3Rwb3J0OwotCQkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAqbGFzdHBvcnQgPiBsYXN0KQot CQkJCQkqbGFzdHBvcnQgPSBmaXJzdDsKLQkJCQlscG9ydCA9IGh0b25zKCpsYXN0cG9ydCk7Ci0J CQl9IHdoaWxlIChpbl9wY2Jsb29rdXBfbG9jYWwocGNiaW5mbywgbGFkZHIsIGxwb3J0LAotCQkJ ICAgIHdpbGQpKTsKLQkJfQorCQljb3VudCA9IGxhc3QgLSBmaXJzdDsKKworCQlkbyB7CisJCQlp ZiAoY291bnQtLSA8IDApCS8qIGNvbXBsZXRlbHkgdXNlZD8gKi8KKwkJCQlyZXR1cm4gKEVBRERS Tk9UQVZBSUwpOworCQkJKysqbGFzdHBvcnQ7CisJCQlpZiAoKmxhc3Rwb3J0IDwgZmlyc3QgfHwg Kmxhc3Rwb3J0ID4gbGFzdCkKKwkJCQkqbGFzdHBvcnQgPSBmaXJzdDsKKwkJCWxwb3J0ID0gaHRv bnMoKmxhc3Rwb3J0KTsKKwkJfSB3aGlsZSAoaW5fcGNibG9va3VwX2xvY2FsKHBjYmluZm8sIGxh ZGRyLCBscG9ydCwKKwkJICAgIHdpbGQpKTsKIAl9CiAJaWYgKHByaXNvbl9pcChjcmVkLCAwLCAm bGFkZHIuc19hZGRyKSkKIAkJcmV0dXJuIChFSU5WQUwpOwo= --=====================_1673812953==_-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 14:21:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 144891065674 for ; Mon, 3 Mar 2008 14:21:05 +0000 (UTC) (envelope-from jym@ldh.org) Received: from mx0.kewego.com (mx0.kewego.net [194.62.234.66]) by mx1.freebsd.org (Postfix) with ESMTP id E22B88FC12 for ; Mon, 3 Mar 2008 14:21:04 +0000 (UTC) (envelope-from jym@ldh.org) Received: from pifpaf.cardinet.kewego.int (unknown [10.2.2.20]) by mx0.kewego.com (Postfix) with ESMTP id 1792233C66 for ; Mon, 3 Mar 2008 15:03:41 +0100 (CET) Message-ID: <47CC053B.5090307@ldh.org> Date: Mon, 03 Mar 2008 15:03:39 +0100 From: Jean-Yves Moulin User-Agent: Thunderbird 2.0.0.12 (X11/20080229) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: drlb: a direct routing loadbalancer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 14:21:05 -0000 Hi everybody, I'have made a simple software load-balancer for FreeBSD. It work only in direct-routing mode. This is a kernel module that works for freebsd 6.2, 6.3 and 7.0 (tested) (and netbsd soon). It use pfil in order to watch incoming packet and redirect to real-server. You can define multiple virtual-ip for a same pool of real-server. You can use fourth scheduler: round-robin, least-connections, round-robin with weight and least-connections with weight. You can specify some timeout (before closing or dropping connections), persistence (for TLS) and the size of the connections hash table. When you inhibit real-server, only new connections are not redirected to it. The load-balancer keep open-connections (that's why I made it. IPVS does'nt do this job right). It come with two tools: drlbctl for configuring it. And lbdyn, who will check your real-server (ala keepalived). It's a very simple tool and I need some times to add useful features (like sharing of connections table..) but I use in in a production environment. IPv6 will be tested soon. You can find it here: http://jym.free.fr (under construction :-) and source here: http://jym.free.fr/files/drlb-0.7.tar.gz I will make a ports soon. Comments are welcome. Greetings from Paris! jym From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 14:34:43 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B34C41065674 for ; Mon, 3 Mar 2008 14:34:43 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.freebsd.org (Postfix) with ESMTP id CD5758FC15 for ; Mon, 3 Mar 2008 14:34:42 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by ug-out-1314.google.com with SMTP id y2so2123322uge.37 for ; Mon, 03 Mar 2008 06:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; bh=/FnWiNI18s+OXjAqHcwVJEQYARxHRJ8drYnPvekUMsY=; b=L+YZ+mhu1HYPkM/ISjnIHh6kKvw/4K5FzZ1RmhKKlb51y36lPkn/b+AOXF1GZPpGJnmavfVmBKcHWqYQ4Mx9jys8BVsM6IBjmMc8iO6mC0/qjs8sSq+omJlehMLsT7/A6HzUyuOnH1Up11fhKqKefcQxEmh4On+GwW0ZqaFCTko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer; b=HgfumiafQ8HFoyOwHgzhZ60L8wpIsWIw0xdRpW0myhal/TQ2qz7F4Z9zy8nzfUVkZS+OsVldh1wEJinEFBef23l9bYwkR1gI0/ryiLtFYVRYiSUiKB5Nh5BveJlo7jg5myvxx5fNEHtbXiUlI7BVNVIFWoUZZ++qWpPStv+z71M= Received: by 10.78.159.7 with SMTP id h7mr19025859hue.66.1204553177197; Mon, 03 Mar 2008 06:06:17 -0800 (PST) Received: from ?127.0.0.1? ( [217.206.187.79]) by mx.google.com with ESMTPS id b30sm89215ika.11.2008.03.03.06.06.15 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Mar 2008 06:06:16 -0800 (PST) From: Tom Evans To: =?iso-8859-2?Q?=A3ukasz?= Bromirski In-Reply-To: <47CBF503.9060208@bromirski.net> References: <497111.42659.qm@web63905.mail.re1.yahoo.com> <20080301225727.GA85851@owl.midgard.homeip.net> <47CAADB8.9000202@digiware.nl> <47CC304F.6040006@bromirski.net> <47CBF16C.6020704@digiware.nl> <47CBF503.9060208@bromirski.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-eMDZ/4GtxHQsf8TH8AHn" Date: Mon, 03 Mar 2008 14:06:14 +0000 Message-Id: <1204553174.2126.170.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Cc: net@freebsd.org Subject: Re: FBSD 1GBit router? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 14:34:43 -0000 --=-eMDZ/4GtxHQsf8TH8AHn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 2008-03-03 at 13:54 +0100, =C5=81ukasz Bromirski wrote: > I don't know exact requirements and application used, but given IP TV > deployments relying heavily on multicast, and all other "VoD" > technologies also using multicast...I find Your comments disturbing :) >=20 > However, if you don't control the network over which it will be > transported, you need to replicate each stream...and so either > you'll find bandwidth to do it (or pay for it) or be forced to switch > to other design. >=20 The 4 most used 'IPTV' (in that they deliver TV, over IP) in the UK (BBC iPlayer, 4OD, Sky by Broadband, and itv.com) do not use multicast at all. Some multicast streams are available from the BBC, but they are notorious for not working with various different providers. Clearly, whilst multicast may be the future, for now it is not. Tom --=-eMDZ/4GtxHQsf8TH8AHn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQBHzAXRlcRvFfyds/cRArMaAJsE0x7iW9PdjdVe5RfC/QrDt7BgiACeIWMr X2pK5AkxFTsI7L5amc9lH3A= =BNRd -----END PGP SIGNATURE----- --=-eMDZ/4GtxHQsf8TH8AHn-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 14:54:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4E251065678 for ; Mon, 3 Mar 2008 14:54:42 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by mx1.freebsd.org (Postfix) with ESMTP id 717138FC27 for ; Mon, 3 Mar 2008 14:54:42 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 19D3A5A8A8B; Mon, 3 Mar 2008 12:54:43 -0200 (ARDT) Received: from notebook.gont.com.ar (201-254-62-65.speedy.com.ar [201.254.62.65] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m23EsVeZ006812; Mon, 3 Mar 2008 12:54:31 -0200 Message-Id: <200803031454.m23EsVeZ006812@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Mar 2008 12:45:17 -0200 To: Mike Silbersack From: Fernando Gont In-Reply-To: <20080303002815.U37933@odysseus.silby.com> References: <20080301224217.33F0A45047@ptavv.es.net> <200803020034.m220YJ6t018608@venus.xmundo.net> <20080303002815.U37933@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 03 Mar 2008 12:54:40 -0200 (ARDT) Cc: Rui Paulo , freebsd-net@freebsd.org, Kevin Oberman Subject: Re: Ephemeral port range (patch) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 14:54:43 -0000 At 04:43 a.m. 03/03/2008, Mike Silbersack wrote: >Earlier in the week, I had commented (via private e-mail?) that I >thought that Amit Klein's algorithm which I recently implemented in >ip_id.c might be adapted to serve as an ephemeral port >allocator. Now that I've thought more about it, I'm not as certain >that it would fit well. I'll try to sketch out my ideas and see if >I can figure out how it could fit. (Shame on me... somehow you mail got stuck in my queue, and I didn't respond to it). While I haven't look match at the scheme proposed by Amit, I think there's a "flaw" with the algorithm: IP IDs need to be unique for {source IP, des IP, Protocol}. And the algorithm still keeps a *global* IP ID. That means you'll cycle through the whole IP ID space when you probably didn't need to. Here, two, a double-hash based scheme (a la RFC1948) will do. It would basically separate the IP ID space for every {source IP, dest IP, Protocol} tuple, and thus you'll cycle through the IP ID space only as fast as needed. What's interesting is that when it comes to port randomization, IP ID randomization, and even timestamp randomization, the double-hash scheme seems to be the right solution. That said, at least theoretically speaking, one could argue that there shouldn't be a problem with simply randomizing the IP ID number. For connection-oriented protocols, you should be doing PMTUD, and thus will not care about the IP ID. If your packets are doing fragmentation, then on links will large bandwidth-delay products you're already in trouble. For connection-less transport protocols (e.g., UDP), while they usually do not implement PMTUD, they also do not implement flow-control or congestion control. So you are either sending data to a local system (e.g., in a LAN), or you probably shouldn't be sending data that fast (and then you shouldn't have problems with trivially randomizing the IP ID). >The double-hash concept sounds pretty good, but there's a major >problem with it. If an application does a bind() to get a local >port before doing a connect(), you don't know the remote IP or the remote port. Yes, this is described in Section 3.5 of our id (http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt). Our take is that in that scenario you could simply randomize the local port. (i.e., implement the double-hash scheme, and fall-back to trivial randomization when you face this scenario). >There's a related "feature" in the BSD TCP stack that all local >ports are considered equal; even for applications that do a >connect() call and specify a remote IP/port, we do not let them use >the same local port to two different remote IPs at the same >time. This puts a limit on the total number of outgoing connections >that one machine can have. mmm... I see. So this could limit the number of outgoing connections to about (ephemeral_ports/TIME_WAIT). Any objections against changing this? At least for outgoing connections (i.e., non-listening sockets), this shouldn't be the case. I'd be interested in working on this issue... Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 18:59:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 780EC1065692 for ; Mon, 3 Mar 2008 18:59:11 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 4F5678FC14 for ; Mon, 3 Mar 2008 18:59:11 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JWFsU-00032b-I5 for freebsd-net@freebsd.org; Mon, 03 Mar 2008 10:59:10 -0800 Message-ID: <15811094.post@talk.nabble.com> Date: Mon, 3 Mar 2008 10:59:10 -0800 (PST) From: Oznon To: freebsd-net@freebsd.org In-Reply-To: <4793072F.9030909@modulus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Nabble-From: the_oznon@yahoo.com References: <4793072F.9030909@modulus.org> Subject: Re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 18:59:11 -0000 Hi all, I am currently experiencing the same issue as well except this time around with a Supermicro X7DBU motherboard (Intel=C2=AE 5000P (Blackford) Chipset)= . The identical occurence is happening to me as well so we were wondering if anyone had a resolution? Possibly an updated driver for the Intel NIC card?= =20 Anywho, here is a snippet of the a particular error we receive before the interface disappears: em0: port 0x2000-0x201f mem 0xd8920000-0xd893ffff,0xd8900000-0xd891ffff irq 18 at device 0.0 on pci5 em0: Using MSI interrupt em0: Ethernet address: 00:30:48:7f:be:38 em0: [FILTER] em1: port 0x2020-0x203f mem 0xd8960000-0xd897ffff,0xd8940000-0xd895ffff irq 19 at device 0.1 on pci5 em1: Using MSI interrupt em1: Setup of Shared code failed Thanks all, Guy Andrew Snow-2 wrote: >=20 >=20 > Hi, >=20 > I have a recent Supermicro board (Super X7DWT > Intel 5400 chipset) with two onboard NICs - Intel (ESB2/Gilgal) 82563EB= =20 > Dual-Port Gigabit Ethernet Controller >=20 >=20 >=20 > Usually boot up looks like this: >=20 > em0: port=20 > 0x3000-0x301f mem 0xda020000-0xda03ffff,0xda000000-0xda01ffff irq 44 at= =20 > device 0.0 on pci5 > em0: Using MSI interrupt > em0: Ethernet address: 00:30:48:7e:20:e0 > em0: [FILTER] > em1: port=20 > 0x3020-0x303f mem 0xda060000-0xda07ffff,0xda040000-0xda05ffff irq 40 at= =20 > device 0.1 on pci5 > em1: Using MSI interrupt > em1: Ethernet address: 00:30:48:7e:20:e1 > em1: [FILTER] >=20 > Sometimes when I reboot this happens: >=20 > em0: port=20 > 0x3000-0x301f mem 0xda020000-0xda03ffff,0xda000000-0xda01ffff irq 44 at= =20 > device 0.0 on pci5 > em0: Using MSI interrupt > em0: Ethernet address: 00:30:48:7e:20:e0 > em0: [FILTER] > em1: port=20 > 0x3020-0x303f mem 0xda060000-0xda07ffff,0xda040000-0xda05ffff irq 40 at= =20 > device 0.1 on pci5 > em1: Using MSI interrupt > em1: Setup of Shared code failed > device_attach: em1 attach returned 6 >=20 > And em1 does not exist after that. Power cycling the machine seems to=20 > fix it for the next boot. >=20 >=20 > Any suggestions? >=20 >=20 > Regards, >=20 > - Andrew > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 --=20 View this message in context: http://www.nabble.com/7.0-RC1-onboard-em1-int= el-pro1000-vanishing-occasionally-tp14979560p15811094.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 19:00:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74CF3106566C for ; Mon, 3 Mar 2008 19:00:20 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 5F9E18FC30 for ; Mon, 3 Mar 2008 19:00:20 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JWFtb-00034s-M6 for freebsd-net@freebsd.org; Mon, 03 Mar 2008 11:00:19 -0800 Message-ID: <15811130.post@talk.nabble.com> Date: Mon, 3 Mar 2008 11:00:19 -0800 (PST) From: Oznon To: freebsd-net@freebsd.org In-Reply-To: <479492B6.3080400@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: the_oznon@yahoo.com References: <4793072F.9030909@modulus.org> <2a41acea0801201226t3f7eb2d0qfd12102d1d480529@mail.gmail.com> <47947AD3.2040708@yandex-team.ru> <4794895F.7060402@modulus.org> <479492B6.3080400@yandex-team.ru> Subject: Re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 19:00:20 -0000 I am experiencing the exact same issue as well except this time around I do not have an IPMI card and I am using the X7DBU motherboard by Supermicro. Any luck? Thanks, Guy Vladimir Ivanov wrote: > > Andrew Snow wrote: >> Vladimir Ivanov wrote: >>> We've same issue w/Supermicro boards if IPMI daughterboard installed. >>> A problem looks as PHY reg reads/writes fails. >> >> Ahh, that explains it, thanks. >> >> The management cards seem to cause multiple problems with the FreeBSD em >> driver over time. I don't want to give up the IPMI cards so I'll just >> keep using system reset to get em1 working, it usually only takes 1 or >> 2 resets. >> >> My IPMI card has an option for external/dedicated LAN port so I might >> try that also. > We keep trying same way. It is the only way to disable virtual lan > channel I seem :-| > But Jack gave me another hope. > > WBR > > -- > Vladimir Ivanov > Network Operations Center > OOO "Yandex" > t: +7 495 739-7000 > f: +7 495 739-7070 > @: noc@yandex.net (corporate) > wawa@yandex-team.ru (personal) > www: www.yandex.ru > -- > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- View this message in context: http://www.nabble.com/7.0-RC1-onboard-em1-intel-pro1000-vanishing-occasionally-tp14979560p15811130.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 21:11:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 530F11065677 for ; Mon, 3 Mar 2008 21:11:02 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id 46EBA8FC18 for ; Mon, 3 Mar 2008 21:11:02 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.mx.meer.net (8.12.10/8.12.6) with ESMTP id m23LAhj3073511; Mon, 3 Mar 2008 13:10:59 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m23LAfvB016870; Mon, 3 Mar 2008 13:10:41 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from gnnbsd.hudson-trading.com.neville-neil.com (hudson-trading.com [66.150.84.160] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m23LAerM086578; Mon, 3 Mar 2008 13:10:41 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Mon, 03 Mar 2008 16:10:40 -0500 Message-ID: <7iwsojo6nj.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: Kevin Day In-Reply-To: <40D39AA0-3A15-4183-A52F-2880769CFE6D@dragondata.com> References: <40D39AA0-3A15-4183-A52F-2880769CFE6D@dragondata.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/21.3 (amd64--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: LOR icmp6_input/nd6_lookup X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 21:11:02 -0000 At Fri, 29 Feb 2008 13:44:27 -0600, Kevin Day wrote: > > This is from 7.0-RELEASE: > > lock order reversal: > 1st 0xc3bde2b8 rtentry (rtentry) @ netinet6/nd6.c:1930 > 2nd 0xc3af367c radix node head (radix node head) @ net/route.c:147 > KDB: stack backtrace: > db_trace_self_wrapper > (c08af130,e11b8600,c0662bbe,c08b1592,c3af367c,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c08b1592,c3af367c,c08b15f3,c08b15f3,c08b9ce7,...) at > kdb_backtrace+0x29 > witness_checkorder(c3af367c,9,c08b9cde,93,e11b8624,...) at > witness_checkorder+0x6de > _mtx_lock_flags(c3af367c,0,c08b9cde,93,c066160b,...) at _mtx_lock_flags > +0xbc > rtalloc1(e11b86e0,0,0,0,c3c9d01c,...) at rtalloc1+0x63 > nd6_lookup(c3c9d024,0,c39fd800,c3bde258,c3bde258,...) at nd6_lookup+0x55 > nd6_is_addr_neighbor(c3c9d01c,c39fd800,c08c1d75,78a,c09a5ed8,...) at > nd6_is_addr_neighbor+0x3b > nd6_output(c39fd800,c39fd800,c3cf9b00,c3c9d01c,c3bde258,...) at > nd6_output+0x10f > ip6_output(c3cf9b00,0,e11b88e0,0,0,...) at ip6_output+0x1081 > icmp6_reflect(c3cf9b00,28,8,1,c08c96d0,...) at icmp6_reflect+0x42f > icmp6_input(e11b8c88,e11b8c70,3a,1d5,0,...) at icmp6_input+0x6dc > ip6_input(c3be2900,0,c08b9887,8c,c09a1e24,...) at ip6_input+0xe36 > netisr_processqueue(c0955e30,0,c08b9887,f6,c3865a40,...) at > netisr_processqueue+0x8b > swi_net(0,0,c08a938d,471,c3870364,...) at swi_net+0x9b > ithread_loop(c383ac90,e11b8d38,c08a9115,305,c3873000,...) at > ithread_loop+0x1b5 > fork_exit(c060fbe0,c383ac90,e11b8d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe11b8d70, ebp = 0 --- > > Are LOR's still PR-worthy? Yes, can you file one? Best, George From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 22:10:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D4031065670 for ; Mon, 3 Mar 2008 22:10:35 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.183]) by mx1.freebsd.org (Postfix) with ESMTP id D40E38FC21 for ; Mon, 3 Mar 2008 22:10:34 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by el-out-1112.google.com with SMTP id v27so333983ele.12 for ; Mon, 03 Mar 2008 14:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=aoQsYagYzGqZX5FtS1w2x949MqPOUTPck2WBWfvoPrU=; b=q9iHGXlieRJqTKYVwDjFNNtKUgZd2xKDQhCv00Ct+CxWSG03wepoK9gNo18r34iYFFR6DC0RzgAuhexXqtoFN8+c4TBBi1EdxY81yyytXt2hEuJqJjrI6M4v9rW9witu5QTunVXmXbFhpS2n2qSqEnft1Jce6fPW+SBCAuUerVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=e5f7e7CqajpBcb+KuyHz5epaLO7veOVLQ9BIyrcqL27q5lonVf+1YOzUrjW2bdfyBGUB9qNk07+BXeC2kubzo525ubO94zuv3Jg+i8mfaWVvODFzFH/18pcOT6vy7/+XAQVhKavcv4QzCJRbt5OTz6WT6Nf0Nxd//qx2/pqwW6I= Received: by 10.114.107.19 with SMTP id f19mr789961wac.113.1204580625355; Mon, 03 Mar 2008 13:43:45 -0800 (PST) Received: by 10.114.177.4 with HTTP; Mon, 3 Mar 2008 13:43:45 -0800 (PST) Message-ID: <2a41acea0803031343s6627bebaid8b82353e2619dbf@mail.gmail.com> Date: Mon, 3 Mar 2008 13:43:45 -0800 From: "Jack Vogel" To: Oznon In-Reply-To: <15811130.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4793072F.9030909@modulus.org> <2a41acea0801201226t3f7eb2d0qfd12102d1d480529@mail.gmail.com> <47947AD3.2040708@yandex-team.ru> <4794895F.7060402@modulus.org> <479492B6.3080400@yandex-team.ru> <15811130.post@talk.nabble.com> Cc: freebsd-net@freebsd.org Subject: Re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 22:10:35 -0000 The fix to this problem is in the new shared code that got checked into CURRENT on Friday. I will be MFCing the changes eventually but if you want to test now you'll need to go with CURRENT. On Mon, Mar 3, 2008 at 11:00 AM, Oznon wrote: > > I am experiencing the exact same issue as well except this time around I do > not have an IPMI card and I am using the X7DBU motherboard by Supermicro. > > Any luck? > > Thanks, > > Guy > > > > > Vladimir Ivanov wrote: > > > > Andrew Snow wrote: > >> Vladimir Ivanov wrote: > >>> We've same issue w/Supermicro boards if IPMI daughterboard installed. > >>> A problem looks as PHY reg reads/writes fails. > >> > >> Ahh, that explains it, thanks. > >> > >> The management cards seem to cause multiple problems with the FreeBSD em > >> driver over time. I don't want to give up the IPMI cards so I'll just > >> keep using system reset to get em1 working, it usually only takes 1 or > >> 2 resets. > >> > >> My IPMI card has an option for external/dedicated LAN port so I might > >> try that also. > > We keep trying same way. It is the only way to disable virtual lan > > channel I seem :-| > > But Jack gave me another hope. > > > > WBR > > > > -- > > Vladimir Ivanov > > Network Operations Center > > OOO "Yandex" > > t: +7 495 739-7000 > > f: +7 495 739-7070 > > @: noc@yandex.net (corporate) > > wawa@yandex-team.ru (personal) > > www: www.yandex.ru > > -- > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > -- > View this message in context: http://www.nabble.com/7.0-RC1-onboard-em1-intel-pro1000-vanishing-occasionally-tp14979560p15811130.html > > Sent from the freebsd-net mailing list archive at Nabble.com. > > _______________________________________________ > > > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Mar 3 22:48:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D87201065674 for ; Mon, 3 Mar 2008 22:48:07 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id AC3A78FC37 for ; Mon, 3 Mar 2008 22:48:07 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JWJS2-0005X7-Ts for freebsd-net@freebsd.org; Mon, 03 Mar 2008 14:48:06 -0800 Message-ID: <15816039.post@talk.nabble.com> Date: Mon, 3 Mar 2008 14:48:06 -0800 (PST) From: Oznon To: freebsd-net@freebsd.org In-Reply-To: <2a41acea0803031343s6627bebaid8b82353e2619dbf@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: the_oznon@yahoo.com References: <4793072F.9030909@modulus.org> <2a41acea0801201226t3f7eb2d0qfd12102d1d480529@mail.gmail.com> <47947AD3.2040708@yandex-team.ru> <4794895F.7060402@modulus.org> <479492B6.3080400@yandex-team.ru> <15811130.post@talk.nabble.com> <2a41acea0803031343s6627bebaid8b82353e2619dbf@mail.gmail.com> Subject: Re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 22:48:08 -0000 Thanks for getting back to me so quickly Jack. Your response is very much appreciated for it appears we will be testing with CURRENT for the time being. Cheers, Guy Jack Vogel wrote: > > The fix to this problem is in the new shared code that got checked into > CURRENT on Friday. I will be MFCing the changes eventually but > if you want to test now you'll need to go with CURRENT. > > On Mon, Mar 3, 2008 at 11:00 AM, Oznon wrote: >> >> I am experiencing the exact same issue as well except this time around I >> do >> not have an IPMI card and I am using the X7DBU motherboard by >> Supermicro. >> >> Any luck? >> >> Thanks, >> >> Guy >> >> >> >> >> Vladimir Ivanov wrote: >> > >> > Andrew Snow wrote: >> >> Vladimir Ivanov wrote: >> >>> We've same issue w/Supermicro boards if IPMI daughterboard >> installed. >> >>> A problem looks as PHY reg reads/writes fails. >> >> >> >> Ahh, that explains it, thanks. >> >> >> >> The management cards seem to cause multiple problems with the FreeBSD >> em >> >> driver over time. I don't want to give up the IPMI cards so I'll >> just >> >> keep using system reset to get em1 working, it usually only takes 1 >> or >> >> 2 resets. >> >> >> >> My IPMI card has an option for external/dedicated LAN port so I might >> >> try that also. >> > We keep trying same way. It is the only way to disable virtual lan >> > channel I seem :-| >> > But Jack gave me another hope. >> > >> > WBR >> > >> > -- >> > Vladimir Ivanov >> > Network Operations Center >> > OOO "Yandex" >> > t: +7 495 739-7000 >> > f: +7 495 739-7070 >> > @: noc@yandex.net (corporate) >> > wawa@yandex-team.ru (personal) >> > www: www.yandex.ru >> > -- >> > >> > _______________________________________________ >> > freebsd-net@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-net >> > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > >> >> -- >> View this message in context: >> http://www.nabble.com/7.0-RC1-onboard-em1-intel-pro1000-vanishing-occasionally-tp14979560p15811130.html >> >> Sent from the freebsd-net mailing list archive at Nabble.com. >> >> _______________________________________________ >> >> >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- View this message in context: http://www.nabble.com/7.0-RC1-onboard-em1-intel-pro1000-vanishing-occasionally-tp14979560p15816039.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 05:23:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBC731065670 for ; Tue, 4 Mar 2008 05:23:18 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id 80B928FC19 for ; Tue, 4 Mar 2008 05:23:18 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 83297 invoked from network); 4 Mar 2008 05:23:16 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 4 Mar 2008 05:23:16 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 3 Mar 2008 23:23:16 -0600 (CST) From: Mike Silbersack To: Fernando Gont In-Reply-To: <200803031412.m23EC4WB031100@venus.xmundo.net> Message-ID: <20080303231459.X43305@odysseus.silby.com> References: <200803030435.m234Z7As026508@venus.xmundo.net> <20080303001004.R37933@odysseus.silby.com> <200803031412.m23EC4WB031100@venus.xmundo.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rui Paulo , freebsd-net@freebsd.org Subject: Re: Ephemeral ports patch (fixed) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 05:23:19 -0000 On Mon, 3 Mar 2008, Fernando Gont wrote: > At 04:11 a.m. 03/03/2008, Mike Silbersack wrote: > >>> Here's the same patch, but with the first ephemeral port changed from 1024 >>> to 10000. >> >> Now that I've actually gone to try to apply the patch (so I can view the >> two codepaths side by side, rather than in diff form), I'm finding that I >> can't apply it. I think all the whitespace got stomped, either by your >> mail program or my mail program. Can you please resent this as an >> attachment? > > Sure. Please let me know if this one is okay. > > Kind regards, > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 Too optimistic: ! #define IPPORT_EPHEMERALLAST 655535 Otherwise the patch looks good to me. It looked a bit strange in unified diff format, I needed to look at it in context format. (Strange, since I usually prefer unified.) Rui, were you going to get this committed? -Mike From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 05:37:24 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A6301065677 for ; Tue, 4 Mar 2008 05:37:24 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id DEB008FC34 for ; Tue, 4 Mar 2008 05:37:23 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 68249 invoked from network); 4 Mar 2008 05:37:22 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 4 Mar 2008 05:37:22 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 3 Mar 2008 23:37:19 -0600 (CST) From: Mike Silbersack To: Fernando Gont In-Reply-To: <200803031454.m23EsVeZ006812@venus.xmundo.net> Message-ID: <20080303232430.Q43305@odysseus.silby.com> References: <20080301224217.33F0A45047@ptavv.es.net> <200803020034.m220YJ6t018608@venus.xmundo.net> <20080303002815.U37933@odysseus.silby.com> <200803031454.m23EsVeZ006812@venus.xmundo.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Rui Paulo , freebsd-net@freebsd.org, Kevin Oberman Subject: Re: Ephemeral port range (patch) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 05:37:24 -0000 On Mon, 3 Mar 2008, Fernando Gont wrote: > (Shame on me... somehow you mail got stuck in my queue, and I didn't respond > to it). No sweat, I've taken far longer to reply to your e-mails! > While I haven't look match at the scheme proposed by Amit, I think there's a > "flaw" with the algorithm: IP IDs need to be unique for {source IP, des IP, > Protocol}. And the algorithm still keeps a *global* IP ID. That means you'll > cycle through the whole IP ID space when you probably didn't need to. That is true. I think we have a time/space tradeoff here, with Amit's algorithm taking more memory and less time than a hash-based algorithm. But I haven't benchmarked one against the other, so it is possible that a double-hash might win in both categories. I think Robert Watson said something about investigating the issue of IP IDs more in the near future. What I'd like to see (if possible) is that we use Amit's algorithm until we've established a connection with a host, then switch to per-IP state and just use linear IP IDs. That would seem to provide the least overhead for high speed connections. > That said, at least theoretically speaking, one could argue that there > shouldn't be a problem with simply randomizing the IP ID number. For > connection-oriented protocols, you should be doing PMTUD, and thus will not > care about the IP ID. If your packets are doing fragmentation, then on links > will large bandwidth-delay products you're already in trouble. For > connection-less transport protocols (e.g., UDP), while they usually do not > implement PMTUD, they also do not implement flow-control or congestion > control. So you are either sending data to a local system (e.g., in a LAN), > or you probably shouldn't be sending data that fast (and then you shouldn't > have problems with trivially randomizing the IP ID). I have attempted to make that argument before, and it did not go over well with most people. :) I think the counter-argument was primarily centered around UDP NFS, which, as you pointed out, is almost always a losing case. >> The double-hash concept sounds pretty good, but there's a major problem >> with it. If an application does a bind() to get a local port before doing >> a connect(), you don't know the remote IP or the remote port. > > Yes, this is described in Section 3.5 of our id > (http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt). > Our take is that in that scenario you could simply randomize the local port. > (i.e., implement the double-hash scheme, and fall-back to trivial > randomization when you face this scenario). Doh, I will try to read the ENTIRE paper next time before commenting. >> There's a related "feature" in the BSD TCP stack that all local ports are >> considered equal; even for applications that do a connect() call and >> specify a remote IP/port, we do not let them use the same local port to two >> different remote IPs at the same time. This puts a limit on the total >> number of outgoing connections that one machine can have. > > mmm... I see. So this could limit the number of outgoing connections to about > (ephemeral_ports/TIME_WAIT). Any objections against changing this? At least > for outgoing connections (i.e., non-listening sockets), this shouldn't be the > case. I'd be interested in working on this issue... I don't think anyone is actively working on that problem, so you won't be stepping on anyone's toes by looking into it. Bring on the patches! There's a piece of low hanging fruit also in that area - we add incoming connections to the local port hash table, even though it seems unlikely that you are going to receive a connection from 1.1.1.1:50000->1.1.1.2:80 and then connect from 1.1.1.2:80->1.1.1.1:50000. Those unnecessary additions to the local port hash time would be nice to remove if you're investigating the related issues. One thing you may or may not have noticed is that FreeBSD keeps TIME_WAIT sockets in a seperate zone which has a limit size, so you will not have to worry too much about them clogging up all ephemeral ports. -Mike From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 05:44:18 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 804281065677 for ; Tue, 4 Mar 2008 05:44:18 +0000 (UTC) (envelope-from SRS0=d9a57d0a808c6d6a6c313b965e79263ca070b142=629=es.net=oberman@es.net) Received: from postal1.es.net (postal4.es.net [IPv6:2001:400:6000:1::66]) by mx1.freebsd.org (Postfix) with ESMTP id B610A8FC25 for ; Tue, 4 Mar 2008 05:44:17 +0000 (UTC) (envelope-from SRS0=d9a57d0a808c6d6a6c313b965e79263ca070b142=629=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id KIW72115 for ; Mon, 03 Mar 2008 21:44:15 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 0BB5F45045 for ; Mon, 3 Mar 2008 21:44:13 -0800 (PST) To: net@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1204609453_79349P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 03 Mar 2008 21:44:13 -0800 From: "Kevin Oberman" Message-Id: <20080304054413.0BB5F45045@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; X-Sender: X-To_Name: X-To_Domain: freebsd.org X-To: net@freebsd.org X-To_Email: net@freebsd.org X-To_Alias: net Cc: Subject: IPv6 addresses not released when routes change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 05:44:18 -0000 --==_Exmh_1204609453_79349P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline At a recent networking conference an IPv6 hour took place where IPv6 only was available. It was an interesting experience. On the whole, things worked well, but I hit one problem. When I brought up my system, I associated with the main conference SSID and received an IPv6 address prior to the IPv6 hour. Everything was working fine. At the appointed time, all of the SSIDs for IPv4/IPv6 were disabled. (No, I was not expecting that) and I re-associated with the IPv6 only SSID, the interface retained the old address in a different /64. It added the new address in a different /64, but did not remove the old address, even though there was no router to it. Worse, it continued to originate connections with the old address as the source. I had to manually delete the old address before I could open a connection. I've been thinking about what software should handle this. It needs to be some software that is aware that the router that assigned the the prefix is no longer available. There is nothing wrong with an IPv6 interfaces having several active addresses, so you can't delete one just because another is assigned. -- 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 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1204609453_79349P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFHzOGtkn3rs5h7N1ERAmZtAJ4/6KkyMwDYv7aZ8DdcX46oVzmEyQCgl8v8 EKv5p84uppGroMraCWQ+4L4= =afaV -----END PGP SIGNATURE----- --==_Exmh_1204609453_79349P-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 07:14:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01F831065671 for ; Tue, 4 Mar 2008 07:14:58 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by mx1.freebsd.org (Postfix) with ESMTP id 6337E8FC1D for ; Tue, 4 Mar 2008 07:14:57 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 3BB1B5A745F; Tue, 4 Mar 2008 05:14:55 -0200 (ARDT) Received: from notebook.gont.com.ar (201-254-62-65.speedy.com.ar [201.254.62.65] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m247EcWT008194; Tue, 4 Mar 2008 05:14:38 -0200 Message-Id: <200803040714.m247EcWT008194@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Mar 2008 05:09:14 -0200 To: Mike Silbersack From: Fernando Gont In-Reply-To: <20080303231459.X43305@odysseus.silby.com> References: <200803030435.m234Z7As026508@venus.xmundo.net> <20080303001004.R37933@odysseus.silby.com> <200803031412.m23EC4WB031100@venus.xmundo.net> <20080303231459.X43305@odysseus.silby.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1735174625==_" X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 04 Mar 2008 05:14:54 -0200 (ARDT) Cc: Rui Paulo , freebsd-net@freebsd.org Subject: Re: Ephemeral ports patch (fixed) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 07:14:58 -0000 --=====================_1735174625==_ Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:23 a.m. 04/03/2008, Mike Silbersack wrote: >Too optimistic: > >! #define IPPORT_EPHEMERALLAST 655535 > >Otherwise the patch looks good to me. It looked a bit strange in >unified diff format, I needed to look at it in context >format. (Strange, since I usually prefer unified.) Doh! I had fixed this in the patch itself, but then undid that change when I changed the first ephemeral port from 1024 to 10000. This one should be fine. :-) Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 --=====================_1735174625==_ Content-Type: text/plain; name="patch-port-range.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-port-range.txt" SW5kZXg6IGluLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL25ldGlu ZXQvaW4uaCx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMDAKZGlmZiAtdSAtcjEuMTAwIGluLmgK LS0tIGluLmgJMTIgSnVuIDIwMDcgMTY6MjQ6NTMgLTAwMDAJMS4xMDAKKysrIGluLmgJMSBNYXIg MjAwOCAwOTowMDoxMCAtMDAwMApAQCAtMjkzLDggKzI5Myw3IEBACiAgKgogICogVGhlIHZhbHVl IElQX1BPUlRSQU5HRV9ISUdIIGNoYW5nZXMgdGhlIHJhbmdlIG9mIGNhbmRpZGF0ZSBwb3J0IG51 bWJlcnMKICAqIGludG8gdGhlICJoaWdoIiByYW5nZS4gIFRoZXNlIGFyZSByZXNlcnZlZCBmb3Ig Y2xpZW50IG91dGJvdW5kIGNvbm5lY3Rpb25zCi0gKiB3aGljaCBkbyBub3Qgd2FudCB0byBiZSBm aWx0ZXJlZCBieSBhbnkgZmlyZXdhbGxzLiAgTm90ZSB0aGF0IGJ5IGRlZmF1bHQKLSAqIHRoaXMg aXMgdGhlIHNhbWUgYXMgSVBfUE9SVFJBTkdFX0RFRkFVTFQuCisgKiB3aGljaCBkbyBub3Qgd2Fu dCB0byBiZSBmaWx0ZXJlZCBieSBhbnkgZmlyZXdhbGxzLgogICoKICAqIFRoZSB2YWx1ZSBJUF9Q T1JUUkFOR0VfTE9XIGNoYW5nZXMgdGhlIHJhbmdlIHRvIHRoZSAibG93IiBhcmUKICAqIHRoYXQg aXMgKGJ5IGNvbnZlbnRpb24pIHJlc3RyaWN0ZWQgdG8gcHJpdmlsZWdlZCBwcm9jZXNzZXMuICBU aGlzCkBAIC0zMzEsOCArMzMwLDEzIEBACiAjZGVmaW5lCUlQUE9SVF9SRVNFUlZFRAkJMTAyNAog CiAvKgotICogRGVmYXVsdCBsb2NhbCBwb3J0IHJhbmdlLCB1c2VkIGJ5IGJvdGggSVBfUE9SVFJB TkdFX0RFRkFVTFQKLSAqIGFuZCBJUF9QT1JUUkFOR0VfSElHSC4KKyAqIERlZmF1bHQgbG9jYWwg cG9ydCByYW5nZSwgdXNlZCBieSBJUF9QT1JUUkFOR0VfREVGQVVMVAorICovCisjZGVmaW5lIElQ UE9SVF9FUEhFTUVSQUxGSVJTVAkxMDAwMAorI2RlZmluZSBJUFBPUlRfRVBIRU1FUkFMTEFTVAk2 NTUzNSAKKyAKKy8qCisgKiBEeW5hbWljIHBvcnQgcmFuZ2UsIHVzZWQgYnkgSVBfUE9SVFJBTkdF X0hJR0guCiAgKi8KICNkZWZpbmUJSVBQT1JUX0hJRklSU1RBVVRPCTQ5MTUyCiAjZGVmaW5lCUlQ UE9SVF9ISUxBU1RBVVRPCTY1NTM1CkluZGV4OiBpbl9wY2IuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxl OiAvaG9tZS9uY3ZzL3NyYy9zeXMvbmV0aW5ldC9pbl9wY2IuYyx2CnJldHJpZXZpbmcgcmV2aXNp b24gMS4xOTgKZGlmZiAtdSAtcjEuMTk4IGluX3BjYi5jCi0tLSBpbl9wY2IuYwkyMiBEZWMgMjAw NyAxMDowNjoxMSAtMDAwMAkxLjE5OAorKysgaW5fcGNiLmMJMSBNYXIgMjAwOCAwOTowMDoxMSAt MDAwMApAQCAtODksOCArODksOCBAQAogICovCiBpbnQJaXBwb3J0X2xvd2ZpcnN0YXV0byAgPSBJ UFBPUlRfUkVTRVJWRUQgLSAxOwkvKiAxMDIzICovCiBpbnQJaXBwb3J0X2xvd2xhc3RhdXRvID0g SVBQT1JUX1JFU0VSVkVEU1RBUlQ7CS8qIDYwMCAqLwotaW50CWlwcG9ydF9maXJzdGF1dG8gPSBJ UFBPUlRfSElGSVJTVEFVVE87CQkvKiA0OTE1MiAqLwotaW50CWlwcG9ydF9sYXN0YXV0byAgPSBJ UFBPUlRfSElMQVNUQVVUTzsJCS8qIDY1NTM1ICovCitpbnQJaXBwb3J0X2ZpcnN0YXV0byA9IElQ UE9SVF9FUEhFTUVSQUxGSVJTVDsJLyogMTAwMDAgKi8KK2ludAlpcHBvcnRfbGFzdGF1dG8gID0g SVBQT1JUX0VQSEVNRVJBTExBU1Q7CS8qIDY1NTM1ICovCiBpbnQJaXBwb3J0X2hpZmlyc3RhdXRv ID0gSVBQT1JUX0hJRklSU1RBVVRPOwkvKiA0OTE1MiAqLwogaW50CWlwcG9ydF9oaWxhc3RhdXRv ICA9IElQUE9SVF9ISUxBU1RBVVRPOwkJLyogNjU1MzUgKi8KIApAQCAtMzkzLDcgKzM5Myw3IEBA CiAJaWYgKCpscG9ydHAgIT0gMCkKIAkJbHBvcnQgPSAqbHBvcnRwOwogCWlmIChscG9ydCA9PSAw KSB7Ci0JCXVfc2hvcnQgZmlyc3QsIGxhc3Q7CisJCXVfc2hvcnQgZmlyc3QsIGxhc3QsIGF1eDsK IAkJaW50IGNvdW50OwogCiAJCWlmIChsYWRkci5zX2FkZHIgIT0gSU5BRERSX0FOWSkKQEAgLTQ0 MCw0NyArNDQwLDI4IEBACiAJCS8qCiAJCSAqIFNpbXBsZSBjaGVjayB0byBlbnN1cmUgYWxsIHBv cnRzIGFyZSBub3QgdXNlZCB1cCBjYXVzaW5nCiAJCSAqIGEgZGVhZGxvY2sgaGVyZS4KLQkJICoK LQkJICogV2Ugc3BsaXQgdGhlIHR3byBjYXNlcyAodXAgYW5kIGRvd24pIHNvIHRoYXQgdGhlIGRp cmVjdGlvbgotCQkgKiBpcyBub3QgYmVpbmcgdGVzdGVkIG9uIGVhY2ggcm91bmQgb2YgdGhlIGxv b3AuCiAJCSAqLwogCQlpZiAoZmlyc3QgPiBsYXN0KSB7Ci0JCQkvKgotCQkJICogY291bnRpbmcg ZG93bgotCQkJICovCi0JCQlpZiAoZG9yYW5kb20pCi0JCQkJKmxhc3Rwb3J0ID0gZmlyc3QgLQot CQkJCQkgICAgKGFyYzRyYW5kb20oKSAlIChmaXJzdCAtIGxhc3QpKTsKLQkJCWNvdW50ID0gZmly c3QgLSBsYXN0OworCQkJYXV4ID0gZmlyc3Q7CisJCQlmaXJzdCA9IGxhc3Q7CisJCQlsYXN0ID0g YXV4OworCQl9CiAKLQkJCWRvIHsKLQkJCQlpZiAoY291bnQtLSA8IDApCS8qIGNvbXBsZXRlbHkg dXNlZD8gKi8KLQkJCQkJcmV0dXJuIChFQUREUk5PVEFWQUlMKTsKLQkJCQktLSpsYXN0cG9ydDsK LQkJCQlpZiAoKmxhc3Rwb3J0ID4gZmlyc3QgfHwgKmxhc3Rwb3J0IDwgbGFzdCkKLQkJCQkJKmxh c3Rwb3J0ID0gZmlyc3Q7Ci0JCQkJbHBvcnQgPSBodG9ucygqbGFzdHBvcnQpOwotCQkJfSB3aGls ZSAoaW5fcGNibG9va3VwX2xvY2FsKHBjYmluZm8sIGxhZGRyLCBscG9ydCwKLQkJCSAgICB3aWxk KSk7Ci0JCX0gZWxzZSB7Ci0JCQkvKgotCQkJICogY291bnRpbmcgdXAKLQkJCSAqLwotCQkJaWYg KGRvcmFuZG9tKQotCQkJCSpsYXN0cG9ydCA9IGZpcnN0ICsKLQkJCQkJICAgIChhcmM0cmFuZG9t KCkgJSAobGFzdCAtIGZpcnN0KSk7Ci0JCQljb3VudCA9IGxhc3QgLSBmaXJzdDsKKwkJaWYgKGRv cmFuZG9tKQorCQkJKmxhc3Rwb3J0ID0gZmlyc3QgKworCQkJCSAgICAoYXJjNHJhbmRvbSgpICUg KGxhc3QgLSBmaXJzdCkpOwogCi0JCQlkbyB7Ci0JCQkJaWYgKGNvdW50LS0gPCAwKQkvKiBjb21w bGV0ZWx5IHVzZWQ/ICovCi0JCQkJCXJldHVybiAoRUFERFJOT1RBVkFJTCk7Ci0JCQkJKysqbGFz dHBvcnQ7Ci0JCQkJaWYgKCpsYXN0cG9ydCA8IGZpcnN0IHx8ICpsYXN0cG9ydCA+IGxhc3QpCi0J CQkJCSpsYXN0cG9ydCA9IGZpcnN0OwotCQkJCWxwb3J0ID0gaHRvbnMoKmxhc3Rwb3J0KTsKLQkJ CX0gd2hpbGUgKGluX3BjYmxvb2t1cF9sb2NhbChwY2JpbmZvLCBsYWRkciwgbHBvcnQsCi0JCQkg ICAgd2lsZCkpOwotCQl9CisJCWNvdW50ID0gbGFzdCAtIGZpcnN0OworCisJCWRvIHsKKwkJCWlm IChjb3VudC0tIDwgMCkJLyogY29tcGxldGVseSB1c2VkPyAqLworCQkJCXJldHVybiAoRUFERFJO T1RBVkFJTCk7CisJCQkrKypsYXN0cG9ydDsKKwkJCWlmICgqbGFzdHBvcnQgPCBmaXJzdCB8fCAq bGFzdHBvcnQgPiBsYXN0KQorCQkJCSpsYXN0cG9ydCA9IGZpcnN0OworCQkJbHBvcnQgPSBodG9u cygqbGFzdHBvcnQpOworCQl9IHdoaWxlIChpbl9wY2Jsb29rdXBfbG9jYWwocGNiaW5mbywgbGFk ZHIsIGxwb3J0LAorCQkgICAgd2lsZCkpOwogCX0KIAlpZiAocHJpc29uX2lwKGNyZWQsIDAsICZs YWRkci5zX2FkZHIpKQogCQlyZXR1cm4gKEVJTlZBTCk7Cg== --=====================_1735174625==_-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 07:44:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E7AC1065673 for ; Tue, 4 Mar 2008 07:44:55 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by mx1.freebsd.org (Postfix) with ESMTP id 27FBD8FC17 for ; Tue, 4 Mar 2008 07:44:54 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id AD5565A745F; Tue, 4 Mar 2008 05:44:52 -0200 (ARDT) Received: from notebook.gont.com.ar (201-254-62-65.speedy.com.ar [201.254.62.65] (may be forged)) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id m247iYsY011163; Tue, 4 Mar 2008 05:44:35 -0200 Message-Id: <200803040744.m247iYsY011163@venus.xmundo.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Mar 2008 05:36:02 -0200 To: Mike Silbersack From: Fernando Gont In-Reply-To: <20080303232430.Q43305@odysseus.silby.com> References: <20080301224217.33F0A45047@ptavv.es.net> <200803020034.m220YJ6t018608@venus.xmundo.net> <20080303002815.U37933@odysseus.silby.com> <200803031454.m23EsVeZ006812@venus.xmundo.net> <20080303232430.Q43305@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 04 Mar 2008 05:44:51 -0200 (ARDT) Cc: Rui Paulo , freebsd-net@freebsd.org, Kevin Oberman Subject: Re: Ephemeral port range (patch) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 07:44:55 -0000 At 03:37 a.m. 04/03/2008, Mike Silbersack wrote: >>While I haven't look match at the scheme proposed by Amit, I think >>there's a "flaw" with the algorithm: IP IDs need to be unique for >>{source IP, des IP, Protocol}. And the algorithm still keeps a >>*global* IP ID. That means you'll cycle through the whole IP ID >>space when you probably didn't need to. > >That is true. I think we have a time/space tradeoff here, with >Amit's algorithm taking more memory and less time than a hash-based >algorithm. But I haven't benchmarked one against the other, so it is >possible that a double-hash might win in both categories. (Thinking out loud) Note that in the case of implementing the double-hash scheme for connection-oriented protocols, once you compute the hash for the first IP ID to be used for a connection, you could store the result of the hash in the TCB, and thus you wouldn't need to recompute this "expensive" hash every time you send a packet. >I think Robert Watson said something about investigating the issue >of IP IDs more in the near future. What I'd like to see (if >possible) is that we use Amit's algorithm until we've established a >connection with a host, then switch to per-IP state and just use >linear IP IDs. That would seem to provide the least overhead for >high speed connections. I haven't yet looked that much at Amit's approach but, from what I have seen, your suggestion makes sense. >>That said, at least theoretically speaking, one could argue that >>there shouldn't be a problem with simply randomizing the IP ID >>number. For connection-oriented protocols, you should be doing >>PMTUD, and thus will not care about the IP ID. If your packets are >>doing fragmentation, then on links will large bandwidth-delay >>products you're already in trouble. For connection-less transport >>protocols (e.g., UDP), while they usually do not implement PMTUD, >>they also do not implement flow-control or congestion control. So >>you are either sending data to a local system (e.g., in a LAN), or >>you probably shouldn't be sending data that fast (and then you >>shouldn't have problems with trivially randomizing the IP ID). > >I have attempted to make that argument before, and it did not go >over well with most people. :) > >I think the counter-argument was primarily centered around UDP NFS, >which, as you pointed out, is almost always a losing case. Relying on IP fragmentation for anything that is supposed to be reliable and that should work at high speed is...mmm... probably not the best idea. ;-) Other than the classic "fragmentation considered harmful", there's a more recent id (RFC?) entitled "fragmentation considered very harmful" which shows the problems that may arise due to fragmentation. So the thing here is that people want to do the wrong thing, and then blame the IP ID generator. ;-) >>>The double-hash concept sounds pretty good, but there's a major >>>problem with it. If an application does a bind() to get a local >>>port before doing a connect(), you don't know the remote IP or the remote port. >> >>Yes, this is described in Section 3.5 of our id >>(http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-port-randomization-01.txt). >>Our take is that in that scenario you could simply randomize the >>local port. (i.e., implement the double-hash scheme, and fall-back >>to trivial randomization when you face this scenario). > >Doh, I will try to read the ENTIRE paper next time before commenting. No worries. >>>There's a related "feature" in the BSD TCP stack that all local >>>ports are considered equal; even for applications that do a >>>connect() call and specify a remote IP/port, we do not let them >>>use the same local port to two different remote IPs at the same >>>time. This puts a limit on the total number of outgoing >>>connections that one machine can have. >> >>mmm... I see. So this could limit the number of outgoing >>connections to about (ephemeral_ports/TIME_WAIT). Any objections >>against changing this? At least for outgoing connections (i.e., >>non-listening sockets), this shouldn't be the case. I'd be >>interested in working on this issue... > >I don't think anyone is actively working on that problem, so you >won't be stepping on anyone's toes by looking into it. Bring on the patches! Great! Will do. >There's a piece of low hanging fruit also in that area - we add >incoming connections to the local port hash table, even though it >seems unlikely that you are going to receive a connection from >1.1.1.1:50000->1.1.1.2:80 and then connect from >1.1.1.2:80->1.1.1.1:50000. Those unnecessary additions to the local >port hash time would be nice to remove if you're investigating the >related issues. Ok. >One thing you may or may not have noticed is that FreeBSD keeps >TIME_WAIT sockets in a seperate zone which has a limit size, so you >will not have to worry too much about them clogging up all ephemeral ports. I had not... but will have a look at it. Thanks! -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 10:05:46 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C604106567A for ; Tue, 4 Mar 2008 10:05:46 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8E33D8FC2E for ; Tue, 4 Mar 2008 10:05:45 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JWTEk-0001YY-5H for freebsd-net@freebsd.org; Tue, 04 Mar 2008 09:15:02 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Mar 2008 09:15:02 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 04 Mar 2008 09:15:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Vadim Goncharov Date: Mon, 3 Mar 2008 11:40:32 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 12 Message-ID: References: <200802291635.38308.gizmen@blurp.pl> <55614.192.168.4.151.1204302487.squirrel@router.laiers.local> <200802291814.34559.gizmen@blurp.pl> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Bartosz Giza User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: redirecting connections based on probability X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 10:05:46 -0000 Hi Bartosz Giza! On Fri, 29 Feb 2008 18:14:34 +0100; Bartosz Giza wrote about 'Re: redirecting connections based on probability': > rdr on $int_if inet proto tcp from someip to any port 80 probability 0.1 -> > mywebserver What is exactly your task / other rules? Possibly ipfw could this for you. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 12:07:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FB2810656BE for ; Tue, 4 Mar 2008 12:07:35 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by mx1.freebsd.org (Postfix) with ESMTP id E7F278FC1D for ; Tue, 4 Mar 2008 12:07:34 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so544087nfb.33 for ; Tue, 04 Mar 2008 04:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; bh=oLp4LnJKhqEft6JqLo+QlA+BQ47ZcAzb1thvSqUH6S0=; b=XxjAxFOkuF1LfPLMvbpFeL/2KwA/LLMVYZG+UI9RBygAiJuKNNkWl43TbCMwfl0hMySVM/r4mn+dyc0RDee6qu7xWiUEwefZ4scqxxP21kQ/0lLabbUSuI1xy+aXKb5UGQ3R3qGuAbxFKuKRNVQMo2PRZ5ckLQG3wE+14NTgbA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; b=G1Z9CsZShPOAYvERPlb91CapEkChDYNQYUZEtvh9tp5baLMvLmsoLPRF3tGUV2+R98HAXR1BJoV1AoRcks/DSlapaaWXe+ZFZoFIJaX+E3eij/D15oAWg0KfrAbdbv10WoggVog7GQgsaUe536OS3rar5jF0ofIqEmsDTaUNgJs= Received: by 10.82.165.13 with SMTP id n13mr4441235bue.16.1204632452991; Tue, 04 Mar 2008 04:07:32 -0800 (PST) Received: from fnop.net ( [89.214.156.200]) by mx.google.com with ESMTPS id p10sm1857877gvf.8.2008.03.04.04.07.30 (version=SSLv3 cipher=OTHER); Tue, 04 Mar 2008 04:07:32 -0800 (PST) Date: Tue, 4 Mar 2008 01:36:58 +0000 From: Rui Paulo To: Mike Silbersack Message-ID: <20080304013658.GC1015@fnop.net> References: <200803030435.m234Z7As026508@venus.xmundo.net> <20080303001004.R37933@odysseus.silby.com> <200803031412.m23EC4WB031100@venus.xmundo.net> <20080303231459.X43305@odysseus.silby.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080303231459.X43305@odysseus.silby.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: Rui Paulo Cc: freebsd-net@freebsd.org Subject: Re: Ephemeral ports patch (fixed) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 12:07:35 -0000 On Mon, Mar 03, 2008 at 11:23:16PM -0600, Mike Silbersack wrote: > > > On Mon, 3 Mar 2008, Fernando Gont wrote: > >> At 04:11 a.m. 03/03/2008, Mike Silbersack wrote: >> >>>> Here's the same patch, but with the first ephemeral port changed from >>>> 1024 to 10000. >>> >>> Now that I've actually gone to try to apply the patch (so I can view the >>> two codepaths side by side, rather than in diff form), I'm finding that I >>> can't apply it. I think all the whitespace got stomped, either by your >>> mail program or my mail program. Can you please resent this as an >>> attachment? >> >> Sure. Please let me know if this one is okay. >> >> Kind regards, >> >> -- >> Fernando Gont >> e-mail: fernando@gont.com.ar || fgont@acm.org >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > Too optimistic: > > ! #define IPPORT_EPHEMERALLAST 655535 > > Otherwise the patch looks good to me. It looked a bit strange in unified > diff format, I needed to look at it in context format. (Strange, since I > usually prefer unified.) > > Rui, were you going to get this committed? Yup, I will. Regards. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 12:20:16 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45A5A106567F for ; Tue, 4 Mar 2008 12:20:16 +0000 (UTC) (envelope-from SRS0=Pa+e=TW=tm.uka.de=max.laier@srs.kundenserver.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id D81078FC19 for ; Tue, 4 Mar 2008 12:20:15 +0000 (UTC) (envelope-from SRS0=Pa+e=TW=tm.uka.de=max.laier@srs.kundenserver.de) Received: from vampire.homelinux.org (dslb-088-064-183-181.pools.arcor-ip.net [88.64.183.181]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1JWVvm41kG-0001yy; Tue, 04 Mar 2008 13:07:40 +0100 Received: (qmail 84185 invoked by uid 80); 4 Mar 2008 12:07:09 -0000 Received: from 192.168.4.151 (SquirrelMail authenticated user mlaier) by router.laiers.local with HTTP; Tue, 4 Mar 2008 13:07:09 +0100 (CET) Message-ID: <60524.192.168.4.151.1204632429.squirrel@router.laiers.local> In-Reply-To: <20080304054413.0BB5F45045@ptavv.es.net> References: <20080304054413.0BB5F45045@ptavv.es.net> Date: Tue, 4 Mar 2008 13:07:09 +0100 (CET) From: "Max Laier" To: "Kevin Oberman" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Provags-ID: V01U2FsdGVkX1/xd1UKMh1Ko5q5L1dSpHQJFg1mIgjoirvCv/r 6C2m0TG6ba3rvoX9sXLMxxv0Wutwg2rTI/2l/7HkYQHeKP/i2X Rw/CD9+SfI6eciW6rzV9w== Cc: net@freebsd.org Subject: Re: IPv6 addresses not released when routes change X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 12:20:16 -0000 Am Di, 4.03.2008, 06:44, schrieb Kevin Oberman: > At a recent networking conference an IPv6 hour took place where IPv6 > only was available. It was an interesting experience. On the whole, > things worked well, but I hit one problem. > > When I brought up my system, I associated with the main conference SSID > and received an IPv6 address prior to the IPv6 hour. Everything was > working fine. At the appointed time, all of the SSIDs for IPv4/IPv6 were > disabled. (No, I was not expecting that) and I re-associated with the > IPv6 only SSID, the interface retained the old address in a different > /64. It added the new address in a different /64, but did not remove the > old address, even though there was no router to it. > > Worse, it continued to originate connections with the old address as the > source. I had to manually delete the old address before I could open a > connection. > > I've been thinking about what software should handle this. It needs to > be some software that is aware that the router that assigned the the > prefix is no longer available. There is nothing wrong with an IPv6 > interfaces having several active addresses, so you can't delete one > just because another is assigned. sys/netinet6/nd6_rtr.c::pfxlist_onlink_check() should take care of that. ndp(8) can be used to view the in-kernel state of things. The prefix- (ndp -p) and "default router"-lists (ndp -r) are esp. interesting. Bad parameters in the RA can slow down the process, but eventually the kernel should figure out that the router is no longer reachable and mark the prefixes as such. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 15:16:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 224F61065674 for ; Tue, 4 Mar 2008 15:16:27 +0000 (UTC) (envelope-from crahman@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by mx1.freebsd.org (Postfix) with ESMTP id E9A8D8FC18 for ; Tue, 4 Mar 2008 15:16:26 +0000 (UTC) (envelope-from crahman@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so895081waf.3 for ; Tue, 04 Mar 2008 07:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=MPWWZY7aBBQz3GyhsqE8y3G4grePB0u1oOPnLQV83rk=; b=E3SUYOBgf8UxuCxaL9dbwPVdmh8XfxES6v82Cpvif3iByFlwypAadgyuMINONNIIy+9Vv6VXjF5ns6mfJvPmY/k5sW6oZNicgZFrFnLdDjr4Im1slsDjjRckqWm0DVFjDFqfCOuv09KC9/qy04sIlKZHJ1+Zn+hTwuP65t8fU+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=lq4T1KuaNXtrakipfyJz9apPz+Jw6jaFJKztLbkmGzCySXBD7OTdHgFfUORaJ+UQVu8s/GN279WbclR+9TLGtOjS4bTr2MC/h9V/MTzGYzOSFZu7dcEtUWmjzKhbugGgvquHc7gCaZ0erdsb3UqRF6LPUpm7bDDnWWw+pYQTz9A= Received: by 10.114.146.1 with SMTP id t1mr2241596wad.20.1204642142969; Tue, 04 Mar 2008 06:49:02 -0800 (PST) Received: by 10.115.14.11 with HTTP; Tue, 4 Mar 2008 06:49:02 -0800 (PST) Message-ID: <9e77bdb50803040649u1876d8d4l9f2b7a4cef5c4b5@mail.gmail.com> Date: Tue, 4 Mar 2008 07:49:02 -0700 From: "Cyrus Rahman" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ipv6 + ah + esp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 15:16:27 -0000 Is there a known problem running ah+esp on ip6? I can set up an association and run ah+esp just fine on ip4, and ah or esp work well by themselves in ip6, but I've had no luck with combining them on ip6. I know that ipcomp is documented to be broken but I haven't seen anything about this problem. This is on 7.0-RELEASE. For example this: spdadd hostA hostB any -P out ipsec esp/transport//require ah/transport//require; spdadd hostB hostA any -P in ipsec esp/transport//require ah/transport//require; results in no exchange but the following messages in syslog: snowfall kernel: ip6_output (ipsec): error code 22 Taking either ah or esp out of the policy works just fine. From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 15:30:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6834D106566B for ; Tue, 4 Mar 2008 15:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 253718FC22 for ; Tue, 4 Mar 2008 15:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 7D5CD41C795; Tue, 4 Mar 2008 16:30:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 5D5Z-4j6BaMA; Tue, 4 Mar 2008 16:30:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 2C48C41C75E; Tue, 4 Mar 2008 16:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id CEE484448DD; Tue, 4 Mar 2008 15:25:16 +0000 (UTC) Date: Tue, 4 Mar 2008 15:25:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Cyrus Rahman In-Reply-To: <9e77bdb50803040649u1876d8d4l9f2b7a4cef5c4b5@mail.gmail.com> Message-ID: <20080304152255.M50685@maildrop.int.zabbadoz.net> References: <9e77bdb50803040649u1876d8d4l9f2b7a4cef5c4b5@mail.gmail.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: ipv6 + ah + esp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 15:30:07 -0000 On Tue, 4 Mar 2008, Cyrus Rahman wrote: Hi, > Is there a known problem running ah+esp on ip6? I can set up an > association and run ah+esp just fine on ip4, > and ah or esp work well by themselves in ip6, but I've had no luck > with combining them on ip6. > > I know that ipcomp is documented to be broken but I haven't seen > anything about this problem. This is on 7.0-RELEASE. > > For example this: > > spdadd hostA hostB any -P out ipsec > esp/transport//require ah/transport//require; > spdadd hostB hostA any -P in ipsec > esp/transport//require ah/transport//require; > > results in no exchange but the following messages in syslog: > > snowfall kernel: ip6_output (ipsec): error code 22 > > Taking either ah or esp out of the policy works just fine. 22 is EINVAL. The same error message is there twice in sys/netinet6/ip6_output.c (search for "(ipsec)" w/o the ""). Could you alter them so we can tell them apart, recompile the kernel and file a PR with this information and whether it is the printf after ipsec6_output_trans or after ipsec6_output_tunnel. /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 19:20:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1917D106566B for ; Tue, 4 Mar 2008 19:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0A98FC26 for ; Tue, 4 Mar 2008 19:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m24JK2Z5081311 for ; Tue, 4 Mar 2008 19:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m24JK236081310; Tue, 4 Mar 2008 19:20:02 GMT (envelope-from gnats) Date: Tue, 4 Mar 2008 19:20:02 GMT Message-Id: <200803041920.m24JK236081310@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Sean C. Farley" Cc: Subject: Re: kern/121274: [panic] Panic in ether_input() with different NIC's. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Sean C. Farley" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 19:20:03 -0000 The following reply was made to PR kern/121274; it has been noted by GNATS. From: "Sean C. Farley" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/121274: [panic] Panic in ether_input() with different NIC's. Date: Tue, 4 Mar 2008 13:15:49 -0600 (CST) Two additional items of interest, but I do not know for certain if this is related to the panic I am seeing: 1. I have recently found that running "ipnat -s" will cause a panic regardless of how long the system has been running. 2. Here is the LOR along with a backtrace from running "ipnat -s". More information can be found here: http://www.farley.org/freebsd/tmp/panic/dmesg.boot IP Filter: v4.1.28 initialized. Default = pass all, Logging = enabled Kernel page fault with the following non-sleepable locks held: shared rw ipf filter load/unload mutex r = 0 (0xc52088a0) locked @ /usr/FreeBSD/RELENG_7/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil_freebsd.c:350 KDB: enter: witness_warn Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x28202000 fault code = supervisor write, page not present instruction pointer = 0x20:0xc0777556 stack pointer = 0x28:0xdf59cde4 frame pointer = 0x28:0xdf59dbb4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 62 (ipnat) lock order reversal: (sleepable after non-sleepable) 1st 0xc52088a0 ipf filter load/unload mutex (ipf filter load/unload mutex) @ /usr/FreeBSD/RELENG_7/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil_freebsd.c:350 2nd 0xc4f0b12c user map (user map) @ /usr/FreeBSD/RELENG_7/src/sys/vm/vm_map.c:3111 KDB: stack backtrace: db_trace_self_wrapper(c07ba661,df59cb00,c059895e,c07bcc04,c4f0b12c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07bcc04,c4f0b12c,c07d5a0c,c07d5a0c,c07d5990,...) at kdb_backtrace+0x29 witness_checkorder(c4f0b12c,9,c07d5990,c27,c0461b23,...) at witness_checkorder+0x6de _sx_xlock(c4f0b12c,0,c07d5990,c27,df59cb68,...) at _sx_xlock+0x7d _vm_map_lock_read(c4f0b0e8,c07d5990,c27,0,0,...) at _vm_map_lock_read+0x50 vm_map_lookup(df59cc60,28202000,2,df59cc64,df59cc54,...) at vm_map_lookup+0x38 vm_fault(c4f0b0e8,28202000,2,8,28202000,...) at vm_fault+0x83 trap_pfault(5,0,c07df7db,0,c,...) at trap_pfault+0xf9 trap(df59cda4) at trap+0x3f2 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0777556, esp = 0xdf59cde4, ebp = 0xdf59dbb4 --- generic_copyout(c51a1480,c034725d,1,0,c5020880,...) at generic_copyout+0x36 iplioctl(c5191a00,c034725d,c51a1480,1,c5020880,...) at iplioctl+0xca devfs_ioctl_f(c51b0120,c034725d,c51a1480,c524f000,c5020880,...) at devfs_ioctl_f+0xc9 kern_ioctl(c5020880,3,c034725d,c51a1480,1000000,...) at kern_ioctl+0x243 ioctl(c5020880,df59dcfc,c,c07b487b,c07f8bb0,...) at ioctl+0x134 syscall(df59dd38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x28166363, esp = 0xbfbfeccc, ebp = 0xbfbfed38 --- KDB: enter: witness_checkorder Kernel page fault with the following non-sleepable locks held: shared rw ipf filter load/unload mutex r = 0 (0xc52088a0) locked @ /usr/FreeBSD/RELENG_7/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_fil_freebsd.c:350 KDB: enter: witness_warn Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x28203000 fault code = supervisor write, page not present instruction pointer = 0x20:0xc0777556 stack pointer = 0x28:0xdf59cde4 frame pointer = 0x28:0xdf59dbb4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 62 (ipnat) From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 19:48:43 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 174261065670; Tue, 4 Mar 2008 19:48:43 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E567C8FC1B; Tue, 4 Mar 2008 19:48:42 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m24JmgrN083865; Tue, 4 Mar 2008 19:48:42 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m24Jmgjb083861; Tue, 4 Mar 2008 19:48:42 GMT (envelope-from vwe) Date: Tue, 4 Mar 2008 19:48:42 GMT Message-Id: <200803041948.m24Jmgjb083861@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/76710: [mii] [patch] rgephy does not deal with status properly, if BMCR_ISO is set. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 19:48:43 -0000 Synopsis: [mii] [patch] rgephy does not deal with status properly,if BMCR_ISO is set. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Tue Mar 4 19:48:05 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=76710 From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 20:27:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC94E1065670 for ; Tue, 4 Mar 2008 20:27:07 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5A90D8FC1B for ; Tue, 4 Mar 2008 20:27:07 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so771667nfb.33 for ; Tue, 04 Mar 2008 12:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; bh=RtDhCX2zIqQv1DeQ3X6WbUPuK7LxgUwGRhTmDF9fswg=; b=WHHYZtRuyNus7knjV4bBSnZ3zAhBAjJSbkf+b99mwAQARLAXeL3nU/il4MkYISg07U8eRrJd3bsbt+2I7p3H7RYzV93gjqu7QVipezjQckSNDFZi94THg+RnZFKMaNN62kZKeinqYi2Y4050a/UaxgdKrKmmB1RH0to5LeqXR/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; b=Hq90TQuNhwuUI2cn/0QTBX/Rl+ieCrgK3FI8dEiHtSGKmoEQiXVBAORQu0aNe19lN3U1+fjuc/NNstxvP0Ks0SwTjAaouFAy9f74vQ7PGLPfN+1EFQaCxpwFjJluqshHDOL4N6Qmg4ZSsYZSuvnJ91WIHx7mgZSIg5FcDVtWMkQ= Received: by 10.78.129.16 with SMTP id b16mr4351142hud.34.1204662425557; Tue, 04 Mar 2008 12:27:05 -0800 (PST) Received: from fnop.net ( [89.214.171.92]) by mx.google.com with ESMTPS id q9sm165892gve.10.2008.03.04.12.27.03 (version=SSLv3 cipher=OTHER); Tue, 04 Mar 2008 12:27:04 -0800 (PST) Date: Tue, 4 Mar 2008 17:31:19 +0000 From: Rui Paulo To: Fernando Gont Message-ID: <20080304173119.GB1008@fnop.net> References: <200803030435.m234Z7As026508@venus.xmundo.net> <20080303001004.R37933@odysseus.silby.com> <200803031412.m23EC4WB031100@venus.xmundo.net> <20080303231459.X43305@odysseus.silby.com> <200803040714.m247EcWT008194@venus.xmundo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803040714.m247EcWT008194@venus.xmundo.net> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: Rui Paulo Cc: freebsd-net@freebsd.org Subject: Re: Ephemeral ports patch (fixed) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 20:27:07 -0000 On Tue, Mar 04, 2008 at 05:09:14AM -0200, Fernando Gont wrote: > At 03:23 a.m. 04/03/2008, Mike Silbersack wrote: > >> Too optimistic: >> >> ! #define IPPORT_EPHEMERALLAST 655535 >> >> Otherwise the patch looks good to me. It looked a bit strange in unified >> diff format, I needed to look at it in context format. (Strange, since I >> usually prefer unified.) > > Doh! I had fixed this in the patch itself, but then undid that change when > I changed the first ephemeral port from 1024 to 10000. > > This one should be fine. :-) Committed. Thank you! Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 22:04:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77A8A1065671 for ; Tue, 4 Mar 2008 22:04:30 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id 543AE8FC2F for ; Tue, 4 Mar 2008 22:04:30 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 810E01A000B18 for ; Tue, 4 Mar 2008 13:51:58 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CtEY-FZbHHPS for ; Tue, 4 Mar 2008 13:51:47 -0800 (PST) Received: from coal.local (s10.sbo [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 07CEA1A000B0F for ; Tue, 4 Mar 2008 13:51:47 -0800 (PST) From: Freddie Cash Organization: School District 73 To: freebsd-net@freebsd.org Date: Tue, 4 Mar 2008 13:51:45 -0800 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803041351.46053.fjwcash@gmail.com> Subject: Understanding the interplay of ipfw, vlan, and carp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 22:04:30 -0000 I'm trying to understand how ipfw, vlan, and carp play together. I've figured out how ipfw and vlan work together and have my rules written using the vlan(4) interfaces (in recv vlan100; out xmit vlan100; etc). I've figured out how ipfw and carp work together and have my rules allowing carp protocol traffic over the physical interfaces (ie allow carp from any to any via fxp0). What I'm wondering, though, is how vlan and carp work together. I have a router running FreeBSD 6.3 with three interfaces: fxp0 is connected to the Internet bge1 is connected to a server DMZ bge0 is connected to our WAN bge0 is the physical interface for our vlan setup, and there are 8 vlan interfaces created. bge0 does not have an IP, and each of the vlan interfaces is on its own subnet. I want to use carp to setup a duplicate, fail-over router. I've got carp0 configured with the public IP and it manages the connection over fxp0. fxp0 has a unique IP on each server, separate from the carp IP. I've got carp1 configured with the server DMZ IP and it manages the connection over bge1. bge1 has a unique IP on each server, separate from the carp IP. But I'm not sure how to do carp2 to manage the vlan IPs: - do I create separate carpX interface, one for each vlan? - do I create a single carpX interface and alias all the vlan IPs to it? - do I configure a single carpX interface with a separate management IP? The lack of a "carpdev" option to directly link a carp device to an interface (similar to "vlandev" for vlan(4)) is what's really tripping me up. It appears the carp(4) driver looks at all the interfaces in the box to find one with an IP in the same subnet as the carp IP and then uses that as the physical device. So it seems I'd have to use two IPs for each vlan interface: one shared IP for the carp device, one management IP for the vlan device. Which seems really complicated and not-quite-right. Maybe I'm just over-thinking things. Any pointers greatly appreciated. Thanks. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 22:21:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC3C81065703 for ; Tue, 4 Mar 2008 22:21:02 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.179]) by mx1.freebsd.org (Postfix) with ESMTP id D8B818FC1C for ; Tue, 4 Mar 2008 22:21:01 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-064-183-181.pools.arcor-ip.net [88.64.183.181]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1JWfVH42xD-0007Cj; Tue, 04 Mar 2008 23:21:00 +0100 Received: (qmail 84323 invoked by uid 80); 4 Mar 2008 22:20:26 -0000 Received: from 192.168.4.151 (SquirrelMail authenticated user mlaier) by router with HTTP; Tue, 4 Mar 2008 23:20:26 +0100 (CET) Message-ID: <36735.192.168.4.151.1204669226.squirrel@router> In-Reply-To: <200803041351.46053.fjwcash@gmail.com> References: <200803041351.46053.fjwcash@gmail.com> Date: Tue, 4 Mar 2008 23:20:26 +0100 (CET) From: "Max Laier" To: "Freddie Cash" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20080304232025_19620" X-Priority: 3 (Normal) Importance: Normal X-Provags-ID: V01U2FsdGVkX195+KO213hX/vveB4Sd7c9bjOGn1pdOrgc0Omd tTQqIub7lBCBy8zdiKzRPitt8oTv83XW2HlxIwgs/dzU3aVRKA AqAV3j8DesvyYhJVbuQmg== Cc: freebsd-net@freebsd.org Subject: Re: Understanding the interplay of ipfw, vlan, and carp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 22:21:03 -0000 ------=_20080304232025_19620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Am Di, 4.03.2008, 22:51, schrieb Freddie Cash: ... > The lack of a "carpdev" option to directly link a carp device to an > interface (similar to "vlandev" for vlan(4)) is what's really tripping me > up. It appears the carp(4) driver looks at all the interfaces in the box > to find one with an IP in the same subnet as the carp IP and then uses > that as the physical device. You could try the attached patch. It adds carpdev support. You'll have to recompile ifconfig to make use of it. This patch has some shortcomings that I wanted to address for a long time now, but never found the time to do so. Mostly that IPv6 over CARP is broken with this patch. Everything else is supposed to work and I'd like to hear if you experience otherwise (success stories welcome, too). This is from back in early January, but should apply to RELENG_7 and HEAD w/o too much trouble. Any feedback appreciated! -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News ------=_20080304232025_19620 Content-Type: text/x-diff; name="carpdev.BETA2.diff" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="carpdev.BETA2.diff" diff --git a/sbin/ifconfig/ifcarp.c b/sbin/ifconfig/ifcarp.c index 9c961b7..82dbd50 100644 --- a/sbin/ifconfig/ifcarp.c +++ b/sbin/ifconfig/ifcarp.c @@ -52,13 +52,7 @@ static const char *carp_states[] = { CARP_STATES }; -void carp_status(int s); -void setcarp_advbase(const char *,int, int, const struct afswtch *rafp); -void setcarp_advskew(const char *, int, int, const struct afswtch *rafp); -void setcarp_passwd(const char *, int, int, const struct afswtch *rafp); -void setcarp_vhid(const char *, int, int, const struct afswtch *rafp); - -void +static void carp_status(int s) { const char *state; @@ -76,17 +70,17 @@ carp_status(int s) else state = carp_states[carpr.carpr_state]; - printf("\tcarp: %s vhid %d advbase %d advskew %d\n", - state, carpr.carpr_vhid, carpr.carpr_advbase, - carpr.carpr_advskew); + printf("\tcarp: %s carpdev %s vhid %d advbase %d advskew %d\n", + state, carpr.carpr_carpdev, carpr.carpr_vhid, + carpr.carpr_advbase, carpr.carpr_advskew); } return; } -void -setcarp_passwd(const char *val, int d, int s, const struct afswtch *afp) +static +DECL_CMD_FUNC(setcarp_passwd, val, d) { struct carpreq carpr; @@ -105,8 +99,8 @@ setcarp_passwd(const char *val, int d, int s, const struct afswtch *afp) return; } -void -setcarp_vhid(const char *val, int d, int s, const struct afswtch *afp) +static +DECL_CMD_FUNC(setcarp_vhid, val, d) { int vhid; struct carpreq carpr; @@ -130,8 +124,8 @@ setcarp_vhid(const char *val, int d, int s, const struct afswtch *afp) return; } -void -setcarp_advskew(const char *val, int d, int s, const struct afswtch *afp) +static +DECL_CMD_FUNC(setcarp_advskew, val, d) { int advskew; struct carpreq carpr; @@ -152,8 +146,8 @@ setcarp_advskew(const char *val, int d, int s, const struct afswtch *afp) return; } -void -setcarp_advbase(const char *val, int d, int s, const struct afswtch *afp) +static +DECL_CMD_FUNC(setcarp_advbase, val, d) { int advbase; struct carpreq carpr; @@ -174,11 +168,51 @@ setcarp_advbase(const char *val, int d, int s, const struct afswtch *afp) return; } +static +DECL_CMD_FUNC(setcarp_carpdev, val, d) +{ + struct carpreq carpr; + + memset((char *)&carpr, 0, sizeof(struct carpreq)); + ifr.ifr_data = (caddr_t)&carpr; + + if (ioctl(s, SIOCGVH, (caddr_t)&ifr) == -1) + err(1, "SIOCGVH"); + + strlcpy(carpr.carpr_carpdev, val, sizeof(carpr.carpr_carpdev)); + + if (ioctl(s, SIOCSVH, (caddr_t)&ifr) == -1) + err(1, "SIOCSVH"); + + return; +} + +static +DECL_CMD_FUNC(setcarp_unsetcarpdev, val, d) +{ + struct carpreq carpr; + + memset((char *)&carpr, 0, sizeof(struct carpreq)); + ifr.ifr_data = (caddr_t)&carpr; + + if (ioctl(s, SIOCGVH, (caddr_t)&ifr) == -1) + err(1, "SIOCGVH"); + + memset(carpr.carpr_carpdev, 0, sizeof(carpr.carpr_carpdev)); + + if (ioctl(s, SIOCSVH, (caddr_t)&ifr) == -1) + err(1, "SIOCSVH"); + + return; +} + static struct cmd carp_cmds[] = { DEF_CMD_ARG("advbase", setcarp_advbase), DEF_CMD_ARG("advskew", setcarp_advskew), DEF_CMD_ARG("pass", setcarp_passwd), DEF_CMD_ARG("vhid", setcarp_vhid), + DEF_CMD_ARG("carpdev", setcarp_carpdev), + DEF_CMD_OPTARG("-carpdev", setcarp_unsetcarpdev), }; static struct afswtch af_carp = { .af_name = "af_carp", diff --git a/sys/amd64/conf/CARP b/sys/amd64/conf/CARP new file mode 100644 index 0000000..710a970 --- /dev/null +++ b/sys/amd64/conf/CARP @@ -0,0 +1,4 @@ +include GENERIC +ident CARP + +device carp diff --git a/sys/net/ethernet.h b/sys/net/ethernet.h index 7d45ce3..e7a3450 100644 --- a/sys/net/ethernet.h +++ b/sys/net/ethernet.h @@ -380,6 +380,7 @@ extern void ether_demux(struct ifnet *, struct mbuf *); extern void ether_ifattach(struct ifnet *, const u_int8_t *); extern void ether_ifdetach(struct ifnet *); extern int ether_ioctl(struct ifnet *, u_long, caddr_t); +extern void ether_input(struct ifnet *, struct mbuf *); extern int ether_output(struct ifnet *, struct mbuf *, struct sockaddr *, struct rtentry *); extern int ether_output_frame(struct ifnet *, struct mbuf *); diff --git a/sys/net/if.c b/sys/net/if.c index 9db8935..9178a3d 100644 --- a/sys/net/if.c +++ b/sys/net/if.c @@ -1309,8 +1309,7 @@ if_unroute(struct ifnet *ifp, int flag, int fam) pfctlinput(PRC_IFDOWN, ifa->ifa_addr); if_qflush(&ifp->if_snd); #ifdef DEV_CARP - if (ifp->if_carp) - carp_carpdev_state(ifp->if_carp); + carp_carpdev_state(ifp); #endif rt_ifmsg(ifp); } @@ -1333,8 +1332,7 @@ if_route(struct ifnet *ifp, int flag, int fam) if (fam == PF_UNSPEC || (fam == ifa->ifa_addr->sa_family)) pfctlinput(PRC_IFUP, ifa->ifa_addr); #ifdef DEV_CARP - if (ifp->if_carp) - carp_carpdev_state(ifp->if_carp); + carp_carpdev_state(ifp); #endif rt_ifmsg(ifp); #ifdef INET6 @@ -1386,8 +1384,7 @@ do_link_state_change(void *arg, int pending) IFP2AC(ifp)->ac_netgraph != NULL) (*ng_ether_link_state_p)(ifp, link_state); #ifdef DEV_CARP - if (ifp->if_carp) - carp_carpdev_state(ifp->if_carp); + carp_carpdev_state(ifp); #endif if (ifp->if_bridge) { KASSERT(bstp_linkstate_p != NULL,("if_bridge bstp not loaded!")); diff --git a/sys/net/if_ethersubr.c b/sys/net/if_ethersubr.c index 7023e9c..170bcc7 100644 --- a/sys/net/if_ethersubr.c +++ b/sys/net/if_ethersubr.c @@ -153,6 +153,9 @@ ether_output(struct ifnet *ifp, struct mbuf *m, u_char esrc[ETHER_ADDR_LEN], edst[ETHER_ADDR_LEN]; struct ether_header *eh; struct pf_mtag *t; +#ifdef DEV_CARP + struct ifnet *ifp0 = ifp; +#endif int loop_copy = 1; int hlen; /* link layer header length */ @@ -162,6 +165,19 @@ ether_output(struct ifnet *ifp, struct mbuf *m, senderr(error); #endif +#ifdef DEV_CARP + if (ifp->if_type == IFT_CARP) { + struct ifaddr *ifa; + + if (dst != NULL && ifp->if_link_state == LINK_STATE_UP && + (ifa = ifa_ifwithaddr(dst)) != NULL && + ifa->ifa_ifp == ifp) + return (looutput(ifp, m, dst, rt0)); + + ifp = ifp->if_carpdev; + } +#endif + if (ifp->if_flags & IFF_MONITOR) senderr(ENETDOWN); if (!((ifp->if_flags & IFF_UP) && @@ -172,7 +188,11 @@ ether_output(struct ifnet *ifp, struct mbuf *m, switch (dst->sa_family) { #ifdef INET case AF_INET: +#ifdef DEV_CARP + error = arpresolve(ifp0, rt0, m, dst, edst); +#else error = arpresolve(ifp, rt0, m, dst, edst); +#endif if (error) return (error == EWOULDBLOCK ? 0 : error); type = htons(ETHERTYPE_IP); @@ -293,6 +313,14 @@ ether_output(struct ifnet *ifp, struct mbuf *m, (void)memcpy(eh->ether_shost, IF_LLADDR(ifp), sizeof(eh->ether_shost)); +#ifdef DEV_CARP + if (ifp0 != ifp && ifp0->if_type == IFT_CARP) { + /* XXX: LINK1 */ + (void)memcpy(eh->ether_shost, IF_LLADDR(ifp0), + sizeof(eh->ether_shost)); + } +#endif + /* * If a simplex interface, and the packet is being sent to our * Ethernet address or a broadcast address, loopback a copy. @@ -351,12 +379,6 @@ ether_output(struct ifnet *ifp, struct mbuf *m, return (error); } -#ifdef DEV_CARP - if (ifp->if_carp && - (error = carp_output(ifp, m, dst, NULL))) - goto bad; -#endif - /* Handle ng_ether(4) processing, if any */ if (IFP2AC(ifp)->ac_netgraph != NULL) { KASSERT(ng_ether_output_p != NULL, @@ -506,7 +528,7 @@ ether_ipfw_chk(struct mbuf **m0, struct ifnet *dst, * Process a received Ethernet packet; the packet is in the * mbuf chain m with the ethernet header at the front. */ -static void +void ether_input(struct ifnet *ifp, struct mbuf *m) { struct ether_header *eh; @@ -658,19 +680,15 @@ ether_input(struct ifnet *ifp, struct mbuf *m) } #ifdef DEV_CARP - /* - * Clear M_PROMISC on frame so that carp(4) will see it when the - * mbuf flows up to Layer 3. - * FreeBSD's implementation of carp(4) uses the inprotosw - * to dispatch IPPROTO_CARP. carp(4) also allocates its own - * Ethernet addresses of the form 00:00:5e:00:01:xx, which - * is outside the scope of the M_PROMISC test below. - * TODO: Maintain a hash table of ethernet addresses other than - * ether_dhost which may be active on this ifp. - */ - if (ifp->if_carp && carp_forus(ifp->if_carp, eh->ether_dhost)) { - m->m_flags &= ~M_PROMISC; - } else + if (ifp->if_carp) { + if (ifp->if_type != IFT_CARP && (carp_input(m) == 0)) + return; + else if (ifp->if_type == IFT_CARP && + /* XXX: LINK2 */ + m->m_flags & (M_BCAST | M_MCAST) && + !bcmp(IFP2AC(ifp), eh->ether_dhost, ETHER_ADDR_LEN)) + m->m_flags &= ~(M_BCAST | M_MCAST); + } #endif { /* diff --git a/sys/net/if_loop.c b/sys/net/if_loop.c index bd15bdf..1706f58 100644 --- a/sys/net/if_loop.c +++ b/sys/net/if_loop.c @@ -98,8 +98,6 @@ struct lo_softc { int loioctl(struct ifnet *, u_long, caddr_t); static void lortrequest(int, struct rtentry *, struct rt_addrinfo *); -int looutput(struct ifnet *ifp, struct mbuf *m, - struct sockaddr *dst, struct rtentry *rt); static int lo_clone_create(struct if_clone *, int, caddr_t); static void lo_clone_destroy(struct ifnet *); diff --git a/sys/net/if_var.h b/sys/net/if_var.h index 44a297e..b0da599 100644 --- a/sys/net/if_var.h +++ b/sys/net/if_var.h @@ -131,7 +131,12 @@ struct ifnet { */ struct knlist if_klist; /* events attached to this if */ int if_pcount; /* number of promiscuous listeners */ - struct carp_if *if_carp; /* carp interface structure */ + union { + struct carp_if *carp_s; + struct ifnet *carp_d; + } if_carp_ptr; +#define if_carp if_carp_ptr.carp_s +#define if_carpdev if_carp_ptr.carp_d struct bpf_if *if_bpf; /* packet filter structure */ u_short if_index; /* numeric abbreviation for this if */ short if_timer; /* time 'til if_watchdog called */ @@ -692,6 +697,8 @@ struct ifaddr *ifa_ifwithroute(int, struct sockaddr *, struct sockaddr *); struct ifaddr *ifaof_ifpforaddr(struct sockaddr *, struct ifnet *); int if_simloop(struct ifnet *ifp, struct mbuf *m, int af, int hlen); +int looutput(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, + struct rtentry *rt); typedef void *if_com_alloc_t(u_char type, struct ifnet *ifp); typedef void if_com_free_t(void *com, u_char type); diff --git a/sys/netinet/if_ether.c b/sys/netinet/if_ether.c index 13f2c06..b4f667d 100644 --- a/sys/netinet/if_ether.c +++ b/sys/netinet/if_ether.c @@ -110,7 +110,6 @@ SYSCTL_INT(_net_link_ether_inet, OID_AUTO, proxyall, CTLFLAG_RW, &arp_proxyall, 0, "Enable proxy ARP for all suitable requests"); static void arp_init(void); -static void arp_rtrequest(int, struct rtentry *, struct rt_addrinfo *); static void arprequest(struct ifnet *, struct in_addr *, struct in_addr *, u_char *); static void arpintr(struct mbuf *); @@ -144,7 +143,7 @@ arptimer(void *arg) /* * Parallel to llc_rtrequest. */ -static void +void arp_rtrequest(int req, struct rtentry *rt, struct rt_addrinfo *info) { struct sockaddr *gate; @@ -575,9 +574,6 @@ in_arpinput(struct mbuf *m) int op, rif_len; int req_len; int bridged = 0; -#ifdef DEV_CARP - int carp_match = 0; -#endif if (ifp->if_bridge) bridged = 1; @@ -608,12 +604,11 @@ in_arpinput(struct mbuf *m) itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) goto match; #ifdef DEV_CARP - if (ifp->if_carp != NULL && + if (ifp->if_type != IFT_CARP && ifp->if_carp != NULL && + ia->ia_ifp->if_type == IFT_CARP && carp_iamatch(ifp->if_carp, ia, &isaddr, &enaddr) && - itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) { - carp_match = 1; + itaddr.s_addr == ia->ia_addr.sin_addr.s_addr) goto match; - } #endif } LIST_FOREACH(ia, INADDR_HASH(isaddr.s_addr), ia_hash) @@ -676,7 +671,9 @@ match: /* The following is not an error when doing bridging. */ if (!bridged && rt->rt_ifp != ifp #ifdef DEV_CARP - && (ifp->if_type != IFT_CARP || !carp_match) + && !(rt->rt_ifp->if_type == IFT_CARP && + rt->rt_ifp->if_carpdev == ifp) && + !(ifp->if_type == IFT_CARP && ifp->if_carpdev == rt->rt_ifp) #endif ) { if (log_arp_wrong_iface) diff --git a/sys/netinet/if_ether.h b/sys/netinet/if_ether.h index 9bc6b7b..8c36e02 100644 --- a/sys/netinet/if_ether.h +++ b/sys/netinet/if_ether.h @@ -113,6 +113,7 @@ int arpresolve(struct ifnet *ifp, struct rtentry *rt, struct mbuf *m, struct sockaddr *dst, u_char *desten); void arp_ifinit(struct ifnet *, struct ifaddr *); void arp_ifinit2(struct ifnet *, struct ifaddr *, u_char *); +void arp_rtrequest(int, struct rtentry *, struct rt_addrinfo *); #endif #endif diff --git a/sys/netinet/in_proto.c b/sys/netinet/in_proto.c index 5239805..f642bb9 100644 --- a/sys/netinet/in_proto.c +++ b/sys/netinet/in_proto.c @@ -318,7 +318,7 @@ struct protosw inetsw[] = { .pr_domain = &inetdomain, .pr_protocol = IPPROTO_CARP, .pr_flags = PR_ATOMIC|PR_ADDR, - .pr_input = carp_input, + .pr_input = carp_proto_input, .pr_output = (pr_output_t*)rip_output, .pr_ctloutput = rip_ctloutput, .pr_usrreqs = &rip_usrreqs diff --git a/sys/netinet/ip_carp.c b/sys/netinet/ip_carp.c index c08d39f..aea3518 100644 --- a/sys/netinet/ip_carp.c +++ b/sys/netinet/ip_carp.c @@ -92,11 +92,9 @@ SYSCTL_DECL(_net_inet_carp); struct carp_softc { struct ifnet *sc_ifp; /* Interface clue */ - struct ifnet *sc_carpdev; /* Pointer to parent interface */ - struct in_ifaddr *sc_ia; /* primary iface address */ +#define sc_carpdev sc_ifp->if_carpdev struct ip_moptions sc_imo; #ifdef INET6 - struct in6_ifaddr *sc_ia6; /* primary iface address v6 */ struct ip6_moptions sc_im6o; #endif /* INET6 */ TAILQ_ENTRY(carp_softc) sc_list; @@ -159,7 +157,7 @@ struct carp_if { struct mtx vhif_mtx; }; -/* Get carp_if from softc. Valid after carp_set_addr{,6}. */ +/* Get carp_if from softc. Valid after carp_set_{addr[6],ifp}. */ #define SC2CIF(sc) ((struct carp_if *)(sc)->sc_carpdev->if_carp) /* lock per carp_if queue */ @@ -190,7 +188,7 @@ static void carp_hmac_generate(struct carp_softc *, u_int32_t *, static int carp_hmac_verify(struct carp_softc *, u_int32_t *, unsigned char *); static void carp_setroute(struct carp_softc *, int); -static void carp_input_c(struct mbuf *, struct carp_header *, sa_family_t); +static void carp_proto_input_c(struct mbuf *, struct carp_header *, sa_family_t); static int carp_clone_create(struct if_clone *, int, caddr_t); static void carp_clone_destroy(struct ifnet *); static void carpdetach(struct carp_softc *, int); @@ -203,7 +201,7 @@ static void carp_send_arp(struct carp_softc *); static void carp_master_down(void *); static void carp_master_down_locked(struct carp_softc *); static int carp_ioctl(struct ifnet *, u_long, caddr_t); -static int carp_looutput(struct ifnet *, struct mbuf *, struct sockaddr *, +static int carp_output(struct ifnet *, struct mbuf *, struct sockaddr *, struct rtentry *); static void carp_start(struct ifnet *); static void carp_setrun(struct carp_softc *, sa_family_t); @@ -212,13 +210,16 @@ static int carp_addrcount(struct carp_if *, struct in_ifaddr *, int); enum { CARP_COUNT_MASTER, CARP_COUNT_RUNNING }; static void carp_multicast_cleanup(struct carp_softc *); +static int carp_set_ifp(struct carp_softc *, struct ifnet *); static int carp_set_addr(struct carp_softc *, struct sockaddr_in *); +static int carp_join_multicast(struct carp_softc *); static int carp_del_addr(struct carp_softc *, struct sockaddr_in *); static void carp_carpdev_state_locked(struct carp_if *); static void carp_sc_state_locked(struct carp_softc *); #ifdef INET6 static void carp_send_na(struct carp_softc *); static int carp_set_addr6(struct carp_softc *, struct sockaddr_in6 *); +static int carp_join_multicast6(struct carp_softc *); static int carp_del_addr6(struct carp_softc *, struct sockaddr_in6 *); static void carp_multicast6_cleanup(struct carp_softc *); #endif @@ -247,9 +248,9 @@ carp_hmac_prepare(struct carp_softc *sc) #endif if (sc->sc_carpdev) - CARP_SCLOCK(sc); + CARP_SCLOCK_ASSERT(sc); - /* XXX: possible race here */ + /* XXX: possible race here - really? */ /* compute ipad from key */ bzero(sc->sc_pad, sizeof(sc->sc_pad)); @@ -285,8 +286,6 @@ carp_hmac_prepare(struct carp_softc *sc) for (i = 0; i < sizeof(sc->sc_pad); i++) sc->sc_pad[i] ^= 0x36 ^ 0x5c; - if (sc->sc_carpdev) - CARP_SCUNLOCK(sc); } static void @@ -334,13 +333,106 @@ carp_setroute(struct carp_softc *sc, int cmd) TAILQ_FOREACH(ifa, &SC2IFP(sc)->if_addrlist, ifa_list) { if (ifa->ifa_addr->sa_family == AF_INET && sc->sc_carpdev != NULL) { - int count = carp_addrcount( - (struct carp_if *)sc->sc_carpdev->if_carp, - ifatoia(ifa), CARP_COUNT_MASTER); + int count = 0, error; + struct sockaddr sa; + struct rtentry *rt; + struct radix_node_head *rnh; + struct radix_node *rn; + struct rt_addrinfo info; + int hr_otherif, nr_ourif; + + /* + * Avoid screwing with the routes if there are other + * carp interfaces which are master and have the same + * address. + */ + if (sc->sc_carpdev != NULL && + sc->sc_carpdev->if_carp != NULL) { + count = carp_addrcount( + (struct carp_if *)sc->sc_carpdev->if_carp, + ifatoia(ifa), CARP_COUNT_MASTER); + if ((cmd == RTM_ADD && count != 1) || + (cmd == RTM_DELETE && count != 0)) + continue; + } - if ((cmd == RTM_ADD && count == 1) || - (cmd == RTM_DELETE && count == 0)) - rtinit(ifa, cmd, RTF_UP | RTF_HOST); + /* Remove the existing host route, if any */ + bzero(&info, sizeof(info)); + info.rti_info[RTAX_DST] = ifa->ifa_addr; + info.rti_flags = RTF_HOST; + error = rtrequest1(RTM_DELETE, &info, NULL); + rt_missmsg(RTM_DELETE, &info, info.rti_flags, error); + + /* Check for our address on another interface */ + /* XXX cries for proper API */ + rnh = rt_tables[ifa->ifa_addr->sa_family]; + RADIX_NODE_HEAD_LOCK(rnh); + rn = rnh->rnh_matchaddr(ifa->ifa_addr, rnh); + rt = (struct rtentry *)rn; + hr_otherif = (rt && rt->rt_ifp != sc->sc_ifp && + rt->rt_flags & (RTF_CLONING|RTF_WASCLONED)); + + /* Check for a network route on our interface */ + bcopy(ifa->ifa_addr, &sa, sizeof(sa)); + satosin(&sa)->sin_addr.s_addr = satosin(ifa->ifa_netmask + )->sin_addr.s_addr & satosin(&sa)->sin_addr.s_addr; + rn = rnh->rnh_lookup(&sa, ifa->ifa_netmask, rnh); + rt = (struct rtentry *)rn; + nr_ourif = (rt && rt->rt_ifp == sc->sc_ifp); + RADIX_NODE_HEAD_UNLOCK(rnh); + + switch (cmd) { + case RTM_ADD: + if (hr_otherif) { + ifa->ifa_rtrequest = NULL; + ifa->ifa_flags &= ~RTF_CLONING; + bzero(&info, sizeof(info)); + info.rti_info[RTAX_DST] = + ifa->ifa_addr; + info.rti_info[RTAX_GATEWAY] = + ifa->ifa_addr; + info.rti_flags = RTF_UP | RTF_HOST; + error = rtrequest1(RTM_ADD, &info, + NULL); + rt_missmsg(RTM_ADD, &info, + info.rti_flags, error); + } + if (!hr_otherif || nr_ourif || !rt) { + if (nr_ourif && !(rt->rt_flags & + RTF_CLONING)) { + bzero(&info, sizeof(info)); + info.rti_info[RTAX_DST] = &sa; + info.rti_info[RTAX_NETMASK] = + ifa->ifa_netmask; + error = rtrequest1(RTM_DELETE, + &info, NULL); + rt_missmsg(RTM_DELETE, &info, + info.rti_flags, error); + } + + ifa->ifa_rtrequest = arp_rtrequest; + ifa->ifa_flags |= RTF_CLONING; + + bzero(&info, sizeof(info)); + info.rti_info[RTAX_DST] = &sa; + info.rti_info[RTAX_GATEWAY] = + ifa->ifa_addr; + info.rti_info[RTAX_NETMASK] = + ifa->ifa_netmask; + error = rtrequest1(RTM_ADD, &info, + NULL); + if (error == 0) + ifa->ifa_flags |= IFA_ROUTE; + rt_missmsg(RTM_ADD, &info, + info.rti_flags, error); + } + break; + case RTM_DELETE: + break; + default: + break; + } + break; } #ifdef INET6 if (ifa->ifa_addr->sa_family == AF_INET6) { @@ -360,6 +452,7 @@ carp_clone_create(struct if_clone *ifc, int unit, caddr_t params) struct carp_softc *sc; struct ifnet *ifp; + static const u_char eaddr[ETHER_ADDR_LEN]; /* 00:00:00:00:00:00 */ MALLOC(sc, struct carp_softc *, sizeof(*sc), M_CARP, M_WAITOK|M_ZERO); ifp = SC2IFP(sc) = if_alloc(IFT_ETHER); @@ -391,16 +484,13 @@ carp_clone_create(struct if_clone *ifc, int unit, caddr_t params) ifp->if_softc = sc; if_initname(ifp, CARP_IFNAME, unit); - ifp->if_mtu = ETHERMTU; - ifp->if_flags = IFF_LOOPBACK; + ether_ifattach(ifp, eaddr); + ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; ifp->if_ioctl = carp_ioctl; - ifp->if_output = carp_looutput; + ifp->if_output = carp_output; ifp->if_start = carp_start; ifp->if_type = IFT_CARP; ifp->if_snd.ifq_maxlen = ifqmaxlen; - ifp->if_hdrlen = 0; - if_attach(ifp); - bpfattach(SC2IFP(sc), DLT_NULL, sizeof(u_int32_t)); mtx_lock(&carp_mtx); LIST_INSERT_HEAD(&carpif_list, sc, sc_next); mtx_unlock(&carp_mtx); @@ -503,7 +593,7 @@ carp_ifdetach(void *arg __unused, struct ifnet *ifp) * but it seems more efficient this way or not possible otherwise. */ void -carp_input(struct mbuf *m, int hlen) +carp_proto_input(struct mbuf *m, int hlen) { struct ip *ip = mtod(m, struct ip *); struct carp_header *ch; @@ -517,9 +607,9 @@ carp_input(struct mbuf *m, int hlen) } /* check if received on a valid carp interface */ - if (m->m_pkthdr.rcvif->if_carp == NULL) { + if (m->m_pkthdr.rcvif->if_type != IFT_CARP) { carpstats.carps_badif++; - CARP_LOG("carp_input: packet received on non-carp " + CARP_LOG("carp_proto_input: packet received on non-carp " "interface: %s\n", m->m_pkthdr.rcvif->if_xname); m_freem(m); @@ -529,7 +619,7 @@ carp_input(struct mbuf *m, int hlen) /* verify that the IP TTL is 255. */ if (ip->ip_ttl != CARP_DFLTTL) { carpstats.carps_badttl++; - CARP_LOG("carp_input: received ttl %d != 255i on %s\n", + CARP_LOG("carp_proto_input: received ttl %d != 255i on %s\n", ip->ip_ttl, m->m_pkthdr.rcvif->if_xname); m_freem(m); @@ -540,7 +630,7 @@ carp_input(struct mbuf *m, int hlen) if (m->m_pkthdr.len < iplen + sizeof(*ch)) { carpstats.carps_badlen++; - CARP_LOG("carp_input: received len %zd < " + CARP_LOG("carp_proto_input: received len %zd < " "sizeof(struct carp_header)\n", m->m_len - sizeof(struct ip)); m_freem(m); @@ -550,7 +640,7 @@ carp_input(struct mbuf *m, int hlen) if (iplen + sizeof(*ch) < m->m_len) { if ((m = m_pullup(m, iplen + sizeof(*ch))) == NULL) { carpstats.carps_hdrops++; - CARP_LOG("carp_input: pullup failed\n"); + CARP_LOG("carp_proto_input: pullup failed\n"); return; } ip = mtod(m, struct ip *); @@ -564,7 +654,7 @@ carp_input(struct mbuf *m, int hlen) len = iplen + sizeof(*ch); if (len > m->m_pkthdr.len) { carpstats.carps_badlen++; - CARP_LOG("carp_input: packet too short %d on %s\n", + CARP_LOG("carp_proto_input: packet too short %d on %s\n", m->m_pkthdr.len, m->m_pkthdr.rcvif->if_xname); m_freem(m); @@ -582,19 +672,19 @@ carp_input(struct mbuf *m, int hlen) m->m_data += iplen; if (carp_cksum(m, len - iplen)) { carpstats.carps_badsum++; - CARP_LOG("carp_input: checksum failed on %s\n", + CARP_LOG("carp_proto_input: checksum failed on %s\n", m->m_pkthdr.rcvif->if_xname); m_freem(m); return; } m->m_data -= iplen; - carp_input_c(m, ch, AF_INET); + carp_proto_input_c(m, ch, AF_INET); } #ifdef INET6 int -carp6_input(struct mbuf **mp, int *offp, int proto) +carp6_proto_input(struct mbuf **mp, int *offp, int proto) { struct mbuf *m = *mp; struct ip6_hdr *ip6 = mtod(m, struct ip6_hdr *); @@ -609,9 +699,9 @@ carp6_input(struct mbuf **mp, int *offp, int proto) } /* check if received on a valid carp interface */ - if (m->m_pkthdr.rcvif->if_carp == NULL) { + if (m->m_pkthdr.rcvif->if_type != IFT_CARP) { carpstats.carps_badif++; - CARP_LOG("carp6_input: packet received on non-carp " + CARP_LOG("carp6_proto_input: packet received on non-carp " "interface: %s\n", m->m_pkthdr.rcvif->if_xname); m_freem(m); @@ -621,7 +711,7 @@ carp6_input(struct mbuf **mp, int *offp, int proto) /* verify that the IP TTL is 255 */ if (ip6->ip6_hlim != CARP_DFLTTL) { carpstats.carps_badttl++; - CARP_LOG("carp6_input: received ttl %d != 255 on %s\n", + CARP_LOG("carp6_proto_input: received ttl %d != 255 on %s\n", ip6->ip6_hlim, m->m_pkthdr.rcvif->if_xname); m_freem(m); @@ -633,7 +723,7 @@ carp6_input(struct mbuf **mp, int *offp, int proto) IP6_EXTHDR_GET(ch, struct carp_header *, m, *offp, sizeof(*ch)); if (ch == NULL) { carpstats.carps_badlen++; - CARP_LOG("carp6_input: packet size %u too small\n", len); + CARP_LOG("carp6_proto_input: packet size %u too small\n", len); return (IPPROTO_DONE); } @@ -642,22 +732,22 @@ carp6_input(struct mbuf **mp, int *offp, int proto) m->m_data += *offp; if (carp_cksum(m, sizeof(*ch))) { carpstats.carps_badsum++; - CARP_LOG("carp6_input: checksum failed, on %s\n", + CARP_LOG("carp6_proto_input: checksum failed, on %s\n", m->m_pkthdr.rcvif->if_xname); m_freem(m); return (IPPROTO_DONE); } m->m_data -= *offp; - carp_input_c(m, ch, AF_INET6); + carp_proto_input_c(m, ch, AF_INET6); return (IPPROTO_DONE); } #endif /* INET6 */ static void -carp_input_c(struct mbuf *m, struct carp_header *ch, sa_family_t af) +carp_proto_input_c(struct mbuf *m, struct carp_header *ch, sa_family_t af) { - struct ifnet *ifp = m->m_pkthdr.rcvif; + struct ifnet *ifp = m->m_pkthdr.rcvif->if_carpdev; struct carp_softc *sc; u_int64_t tmp_counter; struct timeval sc_tv, ch_tv; @@ -793,9 +883,6 @@ carp_input_c(struct mbuf *m, struct carp_header *ch, sa_family_t af) static int carp_prepare_ad(struct mbuf *m, struct carp_softc *sc, struct carp_header *ch) { - struct m_tag *mtag; - struct ifnet *ifp = SC2IFP(sc); - if (sc->sc_init_counter) { /* this could also be seconds since unix epoch */ sc->sc_counter = arc4random(); @@ -809,16 +896,6 @@ carp_prepare_ad(struct mbuf *m, struct carp_softc *sc, struct carp_header *ch) carp_hmac_generate(sc, ch->carp_counter, ch->carp_md); - /* Tag packet for carp_output */ - mtag = m_tag_get(PACKET_TAG_CARP, sizeof(struct ifnet *), M_NOWAIT); - if (mtag == NULL) { - m_freem(m); - SC2IFP(sc)->if_oerrors++; - return (ENOMEM); - } - bcopy(&ifp, (caddr_t)(mtag + 1), sizeof(struct ifnet *)); - m_tag_prepend(m, mtag); - return (0); } @@ -859,6 +936,8 @@ carp_send_ad_locked(struct carp_softc *sc) struct carp_header *ch_ptr; struct mbuf *m; int len, advbase, advskew; + struct ifaddr *ifa; + struct sockaddr sa; CARP_SCLOCK_ASSERT(sc); @@ -887,7 +966,7 @@ carp_send_ad_locked(struct carp_softc *sc) ch.carp_cksum = 0; #ifdef INET - if (sc->sc_ia) { + if (sc->sc_naddrs) { struct ip *ip; MGETHDR(m, M_DONTWAIT, MT_HEADER); @@ -916,7 +995,15 @@ carp_send_ad_locked(struct carp_softc *sc) ip->ip_ttl = CARP_DFLTTL; ip->ip_p = IPPROTO_CARP; ip->ip_sum = 0; - ip->ip_src.s_addr = sc->sc_ia->ia_addr.sin_addr.s_addr; + + bzero(&sa, sizeof(sa)); + sa.sa_family = AF_INET; + ifa = ifaof_ifpforaddr(&sa, SC2IFP(sc)); + if (ifa == NULL) + ip->ip_src.s_addr = 0; + else + ip->ip_src.s_addr = + ifatoia(ifa)->ia_addr.sin_addr.s_addr; ip->ip_dst.s_addr = htonl(INADDR_CARP_GROUP); ch_ptr = (struct carp_header *)(&ip[1]); @@ -959,7 +1046,7 @@ carp_send_ad_locked(struct carp_softc *sc) } #endif /* INET */ #ifdef INET6 - if (sc->sc_ia6) { + if (sc->sc_naddrs6) { struct ip6_hdr *ip6; MGETHDR(m, M_DONTWAIT, MT_HEADER); @@ -983,8 +1070,15 @@ carp_send_ad_locked(struct carp_softc *sc) ip6->ip6_vfc |= IPV6_VERSION; ip6->ip6_hlim = CARP_DFLTTL; ip6->ip6_nxt = IPPROTO_CARP; - bcopy(&sc->sc_ia6->ia_addr.sin6_addr, &ip6->ip6_src, - sizeof(struct in6_addr)); + + bzero(&sa, sizeof(sa)); + sa.sa_family = AF_INET6; + ifa = ifaof_ifpforaddr(&sa, SC2IFP(sc)); + if (ifa == NULL) + bzero(&ip6->ip6_src, sizeof(struct in6_addr)); + else + bcopy(ifatoia6(ifa)->ia_addr.sin6_addr.s6_addr, + &ip6->ip6_src, sizeof(struct in6_addr)); /* set the multicast destination */ ip6->ip6_dst.s6_addr16[0] = htons(0xff02); @@ -1058,7 +1152,7 @@ carp_send_arp(struct carp_softc *sc) continue; /* arprequest(sc->sc_carpdev, &in, &in, IF_LLADDR(sc->sc_ifp)); */ - arp_ifinit2(sc->sc_carpdev, ifa, IF_LLADDR(sc->sc_ifp)); + arp_ifinit2(SC2IFP(sc), ifa, IF_LLADDR(sc->sc_ifp)); DELAY(1000); /* XXX */ } @@ -1211,7 +1305,6 @@ carp_iamatch6(void *v, struct in6_addr *taddr) void * carp_macmatch6(void *v, struct mbuf *m, const struct in6_addr *taddr) { - struct m_tag *mtag; struct carp_if *cif = v; struct carp_softc *sc; struct ifaddr *ifa; @@ -1223,18 +1316,6 @@ carp_macmatch6(void *v, struct mbuf *m, const struct in6_addr *taddr) &ifatoia6(ifa)->ia_addr.sin6_addr) && (SC2IFP(sc)->if_flags & IFF_UP) && (SC2IFP(sc)->if_drv_flags & IFF_DRV_RUNNING)) { - struct ifnet *ifp = SC2IFP(sc); - mtag = m_tag_get(PACKET_TAG_CARP, - sizeof(struct ifnet *), M_NOWAIT); - if (mtag == NULL) { - /* better a bit than nothing */ - CARP_UNLOCK(cif); - return (IF_LLADDR(sc->sc_ifp)); - } - bcopy(&ifp, (caddr_t)(mtag + 1), - sizeof(struct ifnet *)); - m_tag_prepend(m, mtag); - CARP_UNLOCK(cif); return (IF_LLADDR(sc->sc_ifp)); } @@ -1423,15 +1504,116 @@ carp_multicast6_cleanup(struct carp_softc *sc) #endif static int +carp_set_ifp(struct carp_softc *sc, struct ifnet *ifp) +{ + struct carp_if *cif = NULL, *ncif = NULL; + struct carp_softc *vr, *after = NULL; + int myself = 0, error = 0; + + if (ifp == sc->sc_carpdev) + return (0); + + if (ifp != NULL) { + if ((ifp->if_flags & IFF_MULTICAST) == 0) + return (ENODEV); + if (ifp->if_type == IFT_CARP) + return (EINVAL); + + if (ifp->if_carp == NULL) { + MALLOC(ncif, struct carp_if *, sizeof(*ncif), M_CARP, + M_WAITOK|M_ZERO); + if (!ncif) + return (ENOBUFS); + if ((error = ifpromisc(ifp, 1))) { + FREE(ncif, M_CARP); + return (error); + } + } else { + cif = (struct carp_if *)ifp->if_carp; + CARP_LOCK(cif); + TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) + if (vr != sc && vr->sc_vhid == sc->sc_vhid) { + CARP_UNLOCK(cif); + return (EINVAL); + } + } + + /* detach from old interface */ + if (sc->sc_carpdev != NULL) { + CARP_SCLOCK(sc); + carpdetach(sc, 1); + } + + if (sc->sc_naddrs != 0 && + (error = carp_join_multicast(sc)) != 0) + goto cleanup; +#ifdef INET6 + if (sc->sc_naddrs6 != 0 && + (error = carp_join_multicast6(sc)) != 0) { + carp_multicast_cleanup(sc); + goto cleanup; + } +#endif + + /* attach carp glue to physical interface */ + if (ncif != NULL) { + CARP_LOCK_INIT(ncif); + CARP_LOCK(ncif); + ncif->vhif_ifp = ifp; + TAILQ_INIT(&ncif->vhif_vrs); + TAILQ_INSERT_HEAD(&ncif->vhif_vrs, sc, sc_list); + ncif->vhif_nvrs++; + ifp->if_carp = ncif; + CARP_UNLOCK(ncif); + } else { + cif = (struct carp_if *)ifp->if_carp; + TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) { + if (vr == sc) + myself = 1; + if (vr->sc_vhid < sc->sc_vhid) + after = vr; + } + if (!myself) { + if (after == NULL) { + TAILQ_INSERT_TAIL(&cif->vhif_vrs, sc, + sc_list); + } else { + TAILQ_INSERT_AFTER(&cif->vhif_vrs, + after, sc, sc_list); + } + cif->vhif_nvrs++; + } + CARP_UNLOCK(cif); + } + + sc->sc_carpdev = ifp; + if (sc->sc_naddrs || sc->sc_naddrs6) + sc->sc_ifp->if_flags |= IFF_UP; + carp_carpdev_state(ifp); + } else { + CARP_SCLOCK(sc); + carpdetach(sc, 1); + SC2IFP(sc)->if_flags &= ~IFF_UP; + SC2IFP(sc)->if_drv_flags &= ~IFF_DRV_RUNNING; + } + + return (0); +cleanup: + if (ncif) + FREE(ncif, M_CARP); + else + CARP_UNLOCK(cif); + + return (error); +} + +static int carp_set_addr(struct carp_softc *sc, struct sockaddr_in *sin) { - struct ifnet *ifp; - struct carp_if *cif; + struct ifnet *ifp = sc->sc_carpdev; struct in_ifaddr *ia, *ia_if; - struct ip_moptions *imo = &sc->sc_imo; - struct in_addr addr; u_long iaddr = htonl(sin->sin_addr.s_addr); - int own, error; + int error; if (sin->sin_addr.s_addr == 0) { if (!(SC2IFP(sc)->if_flags & IFF_UP)) @@ -1443,7 +1625,7 @@ carp_set_addr(struct carp_softc *sc, struct sockaddr_in *sin) } /* we have to do it by hands to check we won't match on us */ - ia_if = NULL; own = 0; + ia_if = NULL; TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) { /* and, yeah, we need a multicast-capable iface too */ if (ia->ia_ifp != SC2IFP(sc) && @@ -1451,106 +1633,65 @@ carp_set_addr(struct carp_softc *sc, struct sockaddr_in *sin) (iaddr & ia->ia_subnetmask) == ia->ia_subnet) { if (!ia_if) ia_if = ia; - if (sin->sin_addr.s_addr == - ia->ia_addr.sin_addr.s_addr) - own++; } } - if (!ia_if) - return (EADDRNOTAVAIL); - - ia = ia_if; - ifp = ia->ia_ifp; - - if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0 || - (imo->imo_multicast_ifp && imo->imo_multicast_ifp != ifp)) - return (EADDRNOTAVAIL); - - if (imo->imo_num_memberships == 0) { - addr.s_addr = htonl(INADDR_CARP_GROUP); - if ((imo->imo_membership[0] = in_addmulti(&addr, ifp)) == NULL) - return (ENOBUFS); - imo->imo_num_memberships++; - imo->imo_multicast_ifp = ifp; - imo->imo_multicast_ttl = CARP_DFLTTL; - imo->imo_multicast_loop = 0; - } - - if (!ifp->if_carp) { - - MALLOC(cif, struct carp_if *, sizeof(*cif), M_CARP, - M_WAITOK|M_ZERO); - if (!cif) { - error = ENOBUFS; - goto cleanup; - } - if ((error = ifpromisc(ifp, 1))) { - FREE(cif, M_CARP); - goto cleanup; + if (ia_if) { + ia = ia_if; + if (ifp) { + if (ifp != ia->ia_ifp) + return (EADDRNOTAVAIL); + } else { + ifp = ia->ia_ifp; } - - CARP_LOCK_INIT(cif); - CARP_LOCK(cif); - cif->vhif_ifp = ifp; - TAILQ_INIT(&cif->vhif_vrs); - ifp->if_carp = cif; - - } else { - struct carp_softc *vr; - - cif = (struct carp_if *)ifp->if_carp; - CARP_LOCK(cif); - TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) - if (vr != sc && vr->sc_vhid == sc->sc_vhid) { - CARP_UNLOCK(cif); - error = EINVAL; - goto cleanup; - } } - sc->sc_ia = ia; - sc->sc_carpdev = ifp; - { /* XXX prevent endless loop if already in queue */ - struct carp_softc *vr, *after = NULL; - int myself = 0; - cif = (struct carp_if *)ifp->if_carp; + if ((error = carp_set_ifp(sc, ifp))) + return (error); - /* XXX: cif should not change, right? So we still hold the lock */ - CARP_LOCK_ASSERT(cif); - - TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) { - if (vr == sc) - myself = 1; - if (vr->sc_vhid < sc->sc_vhid) - after = vr; - } + if (sc->sc_carpdev == NULL) + return (EADDRNOTAVAIL); - if (!myself) { - /* We're trying to keep things in order */ - if (after == NULL) { - TAILQ_INSERT_TAIL(&cif->vhif_vrs, sc, sc_list); - } else { - TAILQ_INSERT_AFTER(&cif->vhif_vrs, after, sc, sc_list); - } - cif->vhif_nvrs++; - } + CARP_SCLOCK(sc); + if (sc->sc_naddrs == 0 && (error = carp_join_multicast(sc)) != 0) { + CARP_SCUNLOCK(sc); + return (error); } sc->sc_naddrs++; SC2IFP(sc)->if_flags |= IFF_UP; - if (own) - sc->sc_advskew = 0; carp_sc_state_locked(sc); carp_setrun(sc, 0); - - CARP_UNLOCK(cif); + CARP_SCUNLOCK(sc); return (0); -cleanup: - in_delmulti(imo->imo_membership[--imo->imo_num_memberships]); - return (error); +/* + * XXX: cleanup multi? + * cleanup: + * return (error); + */ +} + +static int +carp_join_multicast(struct carp_softc *sc) +{ + struct ip_moptions *imo = &sc->sc_imo; + struct in_addr addr; + + KASSERT(imo->imo_num_memberships == 0, + ("carp_join_multicast: leftover multicast memberships")); + + addr.s_addr = htonl(INADDR_CARP_GROUP); + if ((imo->imo_membership[0] = + in_addmulti(&addr, SC2IFP(sc))) == NULL) + return (ENOBUFS); + imo->imo_num_memberships++; + imo->imo_multicast_ifp = SC2IFP(sc); + imo->imo_multicast_ttl = CARP_DFLTTL; + imo->imo_multicast_loop = 0; + + return (0); } static int @@ -1587,12 +1728,8 @@ static int carp_set_addr6(struct carp_softc *sc, struct sockaddr_in6 *sin6) { struct ifnet *ifp; - struct carp_if *cif; struct in6_ifaddr *ia, *ia_if; - struct ip6_moptions *im6o = &sc->sc_im6o; - struct in6_multi_mship *imm; - struct in6_addr in6; - int own, error; + int own; if (IN6_IS_ADDR_UNSPECIFIED(&sin6->sin6_addr)) { if (!(SC2IFP(sc)->if_flags & IFF_UP)) @@ -1633,93 +1770,12 @@ carp_set_addr6(struct carp_softc *sc, struct sockaddr_in6 *sin6) ifp = ia->ia_ifp; if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0 || - (im6o->im6o_multicast_ifp && im6o->im6o_multicast_ifp != ifp)) + (sc->sc_im6o.im6o_multicast_ifp && + sc->sc_im6o.im6o_multicast_ifp != ifp)) return (EADDRNOTAVAIL); - if (!sc->sc_naddrs6) { - im6o->im6o_multicast_ifp = ifp; - - /* join CARP multicast address */ - bzero(&in6, sizeof(in6)); - in6.s6_addr16[0] = htons(0xff02); - in6.s6_addr8[15] = 0x12; - if (in6_setscope(&in6, ifp, NULL) != 0) - goto cleanup; - if ((imm = in6_joingroup(ifp, &in6, &error, 0)) == NULL) - goto cleanup; - LIST_INSERT_HEAD(&im6o->im6o_memberships, imm, i6mm_chain); - - /* join solicited multicast address */ - bzero(&in6, sizeof(in6)); - in6.s6_addr16[0] = htons(0xff02); - in6.s6_addr32[1] = 0; - in6.s6_addr32[2] = htonl(1); - in6.s6_addr32[3] = sin6->sin6_addr.s6_addr32[3]; - in6.s6_addr8[12] = 0xff; - if (in6_setscope(&in6, ifp, NULL) != 0) - goto cleanup; - if ((imm = in6_joingroup(ifp, &in6, &error, 0)) == NULL) - goto cleanup; - LIST_INSERT_HEAD(&im6o->im6o_memberships, imm, i6mm_chain); - } - - if (!ifp->if_carp) { - MALLOC(cif, struct carp_if *, sizeof(*cif), M_CARP, - M_WAITOK|M_ZERO); - if (!cif) { - error = ENOBUFS; - goto cleanup; - } - if ((error = ifpromisc(ifp, 1))) { - FREE(cif, M_CARP); - goto cleanup; - } - - CARP_LOCK_INIT(cif); - CARP_LOCK(cif); - cif->vhif_ifp = ifp; - TAILQ_INIT(&cif->vhif_vrs); - ifp->if_carp = cif; - - } else { - struct carp_softc *vr; - - cif = (struct carp_if *)ifp->if_carp; - CARP_LOCK(cif); - TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) - if (vr != sc && vr->sc_vhid == sc->sc_vhid) { - CARP_UNLOCK(cif); - error = EINVAL; - goto cleanup; - } - } - sc->sc_ia6 = ia; sc->sc_carpdev = ifp; - { /* XXX prevent endless loop if already in queue */ - struct carp_softc *vr, *after = NULL; - int myself = 0; - cif = (struct carp_if *)ifp->if_carp; - CARP_LOCK_ASSERT(cif); - - TAILQ_FOREACH(vr, &cif->vhif_vrs, sc_list) { - if (vr == sc) - myself = 1; - if (vr->sc_vhid < sc->sc_vhid) - after = vr; - } - - if (!myself) { - /* We're trying to keep things in order */ - if (after == NULL) { - TAILQ_INSERT_TAIL(&cif->vhif_vrs, sc, sc_list); - } else { - TAILQ_INSERT_AFTER(&cif->vhif_vrs, after, sc, sc_list); - } - cif->vhif_nvrs++; - } - } - sc->sc_naddrs6++; SC2IFP(sc)->if_flags |= IFF_UP; if (own) @@ -1727,20 +1783,61 @@ carp_set_addr6(struct carp_softc *sc, struct sockaddr_in6 *sin6) carp_sc_state_locked(sc); carp_setrun(sc, 0); - CARP_UNLOCK(cif); - return (0); -cleanup: - /* clean up multicast memberships */ - if (!sc->sc_naddrs6) { - while (!LIST_EMPTY(&im6o->im6o_memberships)) { - imm = LIST_FIRST(&im6o->im6o_memberships); - LIST_REMOVE(imm, i6mm_chain); - in6_leavegroup(imm); - } +/* XXX: + * cleanup: + * * clean up multicast memberships * + * if (!sc->sc_naddrs6) { + * while (!LIST_EMPTY(&im6o->im6o_memberships)) { + * imm = LIST_FIRST(&im6o->im6o_memberships); + * LIST_REMOVE(imm, i6mm_chain); + * in6_leavegroup(imm); + * } + * } + * return (error); + */ +} + +static int +carp_join_multicast6(struct carp_softc *sc) +{ + struct ip6_moptions *im6o = &sc->sc_im6o; + struct in6_multi_mship *imm, *imm2; + struct in6_addr in6; + int error = 0; + + /* join CARP multicast address */ + bzero(&in6, sizeof(in6)); + in6.s6_addr16[0] = htons(0xff02); + in6.s6_addr8[15] = 0x12; + if ((error = in6_setscope(&in6, sc->sc_carpdev, NULL)) != 0) + return (error); + if ((imm = in6_joingroup(sc->sc_carpdev, &in6, &error, 0)) == NULL) + return (error); + + /* join solicited multicast address */ + bzero(&in6, sizeof(in6)); + in6.s6_addr16[0] = htons(0xff02); + in6.s6_addr32[1] = 0; + in6.s6_addr32[2] = htonl(1); + in6.s6_addr32[3] = 0; /* XXX: sin6->sin6_addr.s6_addr32[3]; */ + in6.s6_addr8[12] = 0xff; + if ((error = in6_setscope(&in6, sc->sc_carpdev, NULL)) != 0) { + in6_leavegroup(imm); + return (error); } - return (error); + if ((imm2 = in6_joingroup(sc->sc_carpdev, &in6, &error, 0)) == NULL) { + in6_leavegroup(imm); + return (error); + } + + im6o->im6o_multicast_ifp = sc->sc_carpdev; + + LIST_INSERT_HEAD(&im6o->im6o_memberships, imm, i6mm_chain); + LIST_INSERT_HEAD(&im6o->im6o_memberships, imm2, i6mm_chain); + + return (0); } static int @@ -1786,7 +1883,8 @@ carp_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr) struct ifaddr *ifa; struct ifreq *ifr; struct ifaliasreq *ifra; - int locked = 0, error = 0; + struct ifnet *cdev = NULL; + int locked = 0, error = 0, changed = 0; ifa = (struct ifaddr *)addr; ifra = (struct ifaliasreq *)addr; @@ -1794,12 +1892,12 @@ carp_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr) switch (cmd) { case SIOCSIFADDR: + case SIOCAIFADDR: + changed++; switch (ifa->ifa_addr->sa_family) { #ifdef INET case AF_INET: SC2IFP(sc)->if_flags |= IFF_UP; - bcopy(ifa->ifa_addr, ifa->ifa_dstaddr, - sizeof(struct sockaddr)); error = carp_set_addr(sc, satosin(ifa->ifa_addr)); break; #endif /* INET */ @@ -1815,29 +1913,8 @@ carp_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr) } break; - case SIOCAIFADDR: - switch (ifa->ifa_addr->sa_family) { -#ifdef INET - case AF_INET: - SC2IFP(sc)->if_flags |= IFF_UP; - bcopy(ifa->ifa_addr, ifa->ifa_dstaddr, - sizeof(struct sockaddr)); - error = carp_set_addr(sc, satosin(&ifra->ifra_addr)); - break; -#endif /* INET */ -#ifdef INET6 - case AF_INET6: - SC2IFP(sc)->if_flags |= IFF_UP; - error = carp_set_addr6(sc, satosin6(&ifra->ifra_addr)); - break; -#endif /* INET6 */ - default: - error = EAFNOSUPPORT; - break; - } - break; - case SIOCDIFADDR: + changed++; switch (ifa->ifa_addr->sa_family) { #ifdef INET case AF_INET: @@ -1881,6 +1958,14 @@ carp_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr) if ((error = copyin(ifr->ifr_data, &carpr, sizeof carpr))) break; error = 1; + changed++; + if (carpr.carpr_carpdev[0] != '\0' && + (cdev = ifunit(carpr.carpr_carpdev)) == NULL) { + error = EINVAL; + break; + } + if ((error = carp_set_ifp(sc, cdev))) + break; if (sc->sc_carpdev) { locked = 1; CARP_SCLOCK(sc); @@ -1959,64 +2044,37 @@ carp_ioctl(struct ifnet *ifp, u_long cmd, caddr_t addr) if (error == 0) bcopy(sc->sc_key, carpr.carpr_key, sizeof(carpr.carpr_key)); + if (sc->sc_carpdev != NULL) + strlcpy(carpr.carpr_carpdev, sc->sc_carpdev->if_xname, + CARPDEVNAMSIZ); error = copyout(&carpr, ifr->ifr_data, sizeof(carpr)); break; + case SIOCADDMULTI: + case SIOCDELMULTI: + /* TODO: tell carpdev */ + break; + default: error = EINVAL; } + if (changed) { + if (!locked && sc->sc_carpdev) { + /* XXX: This really shouldn't happen */ + CARP_SCLOCK(sc); + locked = 1; + } + carp_hmac_prepare(sc); + } + if (locked) CARP_SCUNLOCK(sc); - carp_hmac_prepare(sc); - return (error); } /* - * XXX: this is looutput. We should eventually use it from there. - */ -static int -carp_looutput(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, - struct rtentry *rt) -{ - u_int32_t af; - - M_ASSERTPKTHDR(m); /* check if we have the packet header */ - - if (rt && rt->rt_flags & (RTF_REJECT|RTF_BLACKHOLE)) { - m_freem(m); - return (rt->rt_flags & RTF_BLACKHOLE ? 0 : - rt->rt_flags & RTF_HOST ? EHOSTUNREACH : ENETUNREACH); - } - - ifp->if_opackets++; - ifp->if_obytes += m->m_pkthdr.len; - - /* BPF writes need to be handled specially. */ - if (dst->sa_family == AF_UNSPEC) { - bcopy(dst->sa_data, &af, sizeof(af)); - dst->sa_family = af; - } - -#if 1 /* XXX */ - switch (dst->sa_family) { - case AF_INET: - case AF_INET6: - case AF_IPX: - case AF_APPLETALK: - break; - default: - printf("carp_looutput: af=%d unexpected\n", dst->sa_family); - m_freem(m); - return (EAFNOSUPPORT); - } -#endif - return(if_simloop(ifp, m, dst->sa_family, 0)); -} - -/* * Start output on carp interface. This function should never be called. */ static void @@ -2027,81 +2085,84 @@ carp_start(struct ifnet *ifp) #endif } -int +static int carp_output(struct ifnet *ifp, struct mbuf *m, struct sockaddr *sa, struct rtentry *rt) { - struct m_tag *mtag; - struct carp_softc *sc; - struct ifnet *carp_ifp; + struct carp_softc *sc = ifp->if_softc; - if (!sa) - return (0); + if (sc->sc_carpdev != NULL && sc->sc_state == MASTER) + return (sc->sc_carpdev->if_output(ifp, m, sa, rt)); + else { + m_freem(m); + return (ENETUNREACH); + } +} - switch (sa->sa_family) { -#ifdef INET - case AF_INET: - break; -#endif /* INET */ -#ifdef INET6 - case AF_INET6: - break; -#endif /* INET6 */ - default: - return (0); +struct ifnet * +carp_ourether(void *v, struct ether_header *eh, u_char iftype, int src) +{ + struct carp_if *cif = (struct carp_if *)v; + struct carp_softc *vh; + u_int8_t *ena; + + if (src) + ena = (u_int8_t *)&eh->ether_shost; + else + ena = (u_int8_t *)&eh->ether_dhost; + + TAILQ_FOREACH(vh, &cif->vhif_vrs, sc_list) { + if ((vh->sc_ifp->if_flags & (IFF_UP)) != (IFF_UP)) + continue; + if ((vh->sc_state == MASTER /* || vh->sc_ifp->if_flags & IFF_LINK0 */) + && !bcmp(ena, IF_LLADDR(vh->sc_ifp), ETHER_ADDR_LEN)) + return (vh->sc_ifp); } + return (NULL); +} - mtag = m_tag_find(m, PACKET_TAG_CARP, NULL); - if (mtag == NULL) - return (0); +int +carp_input(struct mbuf *m) +{ + struct ether_header *eh; + struct carp_if *cif = (struct carp_if *)m->m_pkthdr.rcvif->if_carp; + struct ifnet *ifp; - bcopy(mtag + 1, &carp_ifp, sizeof(struct ifnet *)); - sc = carp_ifp->if_softc; - - /* Set the source MAC address to Virtual Router MAC Address */ - switch (ifp->if_type) { - case IFT_ETHER: - case IFT_L2VLAN: { - struct ether_header *eh; - - eh = mtod(m, struct ether_header *); - eh->ether_shost[0] = 0; - eh->ether_shost[1] = 0; - eh->ether_shost[2] = 0x5e; - eh->ether_shost[3] = 0; - eh->ether_shost[4] = 1; - eh->ether_shost[5] = sc->sc_vhid; - } - break; - case IFT_FDDI: { - struct fddi_header *fh; - - fh = mtod(m, struct fddi_header *); - fh->fddi_shost[0] = 0; - fh->fddi_shost[1] = 0; - fh->fddi_shost[2] = 0x5e; - fh->fddi_shost[3] = 0; - fh->fddi_shost[4] = 1; - fh->fddi_shost[5] = sc->sc_vhid; - } - break; - case IFT_ISO88025: { - struct iso88025_header *th; - th = mtod(m, struct iso88025_header *); - th->iso88025_shost[0] = 3; - th->iso88025_shost[1] = 0; - th->iso88025_shost[2] = 0x40 >> (sc->sc_vhid - 1); - th->iso88025_shost[3] = 0x40000 >> (sc->sc_vhid - 1); - th->iso88025_shost[4] = 0; - th->iso88025_shost[5] = 0; + eh = mtod(m, struct ether_header *); + + if ((ifp = carp_ourether(cif, eh, m->m_pkthdr.rcvif->if_type, 0))) + ; + else if (m->m_flags & (M_BCAST|M_MCAST)) { + struct carp_softc *vh; + struct mbuf *m0; + + /* + * XXX Should really check the list of multicast addresses + * for each CARP interface _before_ copying. + */ + TAILQ_FOREACH(vh, &cif->vhif_vrs, sc_list) { + m0 = m_dup(m, M_DONTWAIT); + if (m0 == NULL) + continue; + m0->m_pkthdr.rcvif = vh->sc_ifp; + ether_input(vh->sc_ifp, m0); } - break; - default: - printf("%s: carp is not supported for this interface type\n", - ifp->if_xname); - return (EOPNOTSUPP); + return (1); } + if (ifp == NULL) + return (1); + + m->m_pkthdr.rcvif = ifp; + +#if 0 /* XXX: BPF */ + if (ifp->if_bpf) + bpf_mtap_hdr(ifp->if_bpf, (char *)&eh, ETHER_HDR_LEN, m, + BPF_DIRECTION_IN); +#endif + ifp->if_ipackets++; + ether_input(ifp, m); + return (0); } @@ -2131,9 +2192,14 @@ carp_set_state(struct carp_softc *sc, int state) } void -carp_carpdev_state(void *v) +carp_carpdev_state(struct ifnet *ifp) { - struct carp_if *cif = v; + struct carp_if *cif; + + if (ifp->if_type == IFT_CARP || ifp->if_carp == NULL) + return; + + cif = ifp->if_carp; CARP_LOCK(cif); carp_carpdev_state_locked(cif); diff --git a/sys/netinet/ip_carp.h b/sys/netinet/ip_carp.h index 1688b01..3525ab9 100644 --- a/sys/netinet/ip_carp.h +++ b/sys/netinet/ip_carp.h @@ -117,6 +117,13 @@ struct carpstats { uint64_t carps_preempt; /* if enabled, preemptions */ }; +#define CARPDEVNAMSIZ 16 +#ifdef IFNAMSIZ +#if CARPDEVNAMSIZ != IFNAMSIZ +#error +#endif +#endif + /* * Configuration structure for SIOCSVH SIOCGVH */ @@ -128,6 +135,7 @@ struct carpreq { int carpr_advskew; int carpr_advbase; unsigned char carpr_key[CARP_KEY_LEN]; + char carpr_carpdev[CARPDEVNAMSIZ]; }; #define SIOCSVH _IOWR('i', 245, struct ifreq) #define SIOCGVH _IOWR('i', 246, struct ifreq) @@ -152,15 +160,15 @@ struct carpreq { } #ifdef _KERNEL -void carp_carpdev_state(void *); -void carp_input (struct mbuf *, int); -int carp6_input (struct mbuf **, int *, int); -int carp_output (struct ifnet *, struct mbuf *, struct sockaddr *, - struct rtentry *); -int carp_iamatch (void *, struct in_ifaddr *, struct in_addr *, +void carp_carpdev_state(struct ifnet *); +void carp_proto_input(struct mbuf *, int); +int carp6_proto_input(struct mbuf **, int *, int); +int carp_iamatch(void *, struct in_ifaddr *, struct in_addr *, u_int8_t **); struct ifaddr *carp_iamatch6(void *, struct in6_addr *); void *carp_macmatch6(void *, struct mbuf *, const struct in6_addr *); -struct ifnet *carp_forus (void *, void *); +struct ifnet *carp_forus(void *, void *); +struct ifnet *carp_ourether(void *, struct ether_header *, u_char, int); +int carp_input(struct mbuf *); #endif #endif /* _IP_CARP_H */ diff --git a/sys/netinet6/in6_proto.c b/sys/netinet6/in6_proto.c index 2230741..fbd022d 100644 --- a/sys/netinet6/in6_proto.c +++ b/sys/netinet6/in6_proto.c @@ -319,7 +319,7 @@ struct ip6protosw inet6sw[] = { .pr_domain = &inet6domain, .pr_protocol = IPPROTO_CARP, .pr_flags = PR_ATOMIC|PR_ADDR, - .pr_input = carp6_input, + .pr_input = carp6_proto_input, .pr_output = rip6_output, .pr_ctloutput = rip6_ctloutput, .pr_usrreqs = &rip6_usrreqs ------=_20080304232025_19620-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 4 23:25:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ACC5106566C for ; Tue, 4 Mar 2008 23:25:51 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0DB2D8FC17 for ; Tue, 4 Mar 2008 23:25:51 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 8BA5D1A000B17; Tue, 4 Mar 2008 15:25:50 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 049V5Hc8O0Tx; Tue, 4 Mar 2008 15:25:43 -0800 (PST) Received: from coal.local (s10.sbo [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 21F111A000B06; Tue, 4 Mar 2008 15:25:43 -0800 (PST) From: Freddie Cash Organization: School District 73 To: "Max Laier" Date: Tue, 4 Mar 2008 15:25:41 -0800 User-Agent: KMail/1.9.7 References: <200803041351.46053.fjwcash@gmail.com> <36735.192.168.4.151.1204669226.squirrel@router> In-Reply-To: <36735.192.168.4.151.1204669226.squirrel@router> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803041525.42330.fjwcash@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Understanding the interplay of ipfw, vlan, and carp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2008 23:25:51 -0000 On March 4, 2008 02:20 pm Max Laier wrote: > Am Di, 4.03.2008, 22:51, schrieb Freddie Cash: > ... > > > The lack of a "carpdev" option to directly link a carp device to an > > interface (similar to "vlandev" for vlan(4)) is what's really > > tripping me up. It appears the carp(4) driver looks at all the > > interfaces in the box to find one with an IP in the same subnet as > > the carp IP and then uses that as the physical device. > > You could try the attached patch. It adds carpdev support. You'll > have to recompile ifconfig to make use of it. > > This patch has some shortcomings that I wanted to address for a long > time now, but never found the time to do so. Mostly that IPv6 over > CARP is broken with this patch. Everything else is supposed to work > and I'd like to hear if you experience otherwise (success stories > welcome, too). This is from back in early January, but should apply to > RELENG_7 and HEAD w/o too much trouble. > > Any feedback appreciated! I'm in the process of upgrading a test box to RELENG_7_0. I'll see if I can get this patch to apply to that. The lack of IPv6 support won't affect us. Just to make sure I understand how it'll work: - bring up the physical device (ifconfig em1 up) - create the vlan device (ifconfig vlan100 create; ifconfig vlan100 ...) - create the carp device (ifconfig carp2 carpdev vlan100 ...) The physical device and the vlan device won't need IPs, just the carp device? Or will I still need to configure an IP/subnet on the vlan interface? Thanks for this, I'll let you know how it works out. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 00:01:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 242321065678 for ; Wed, 5 Mar 2008 00:01:27 +0000 (UTC) (envelope-from crahman@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.191]) by mx1.freebsd.org (Postfix) with ESMTP id 9EF398FC14 for ; Wed, 5 Mar 2008 00:01:26 +0000 (UTC) (envelope-from crahman@gmail.com) Received: by gv-out-0910.google.com with SMTP id n40so1238268gve.39 for ; Tue, 04 Mar 2008 16:01:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+i/nULbpNZ/RPRdqN7uo7g6WovJ88pubzk0heEpJAqQ=; b=skfBc02JfnPWHzi20ouK8AbfWdf7gpc1xJxUTmCBRZ8PD5Yj/Ruxuc6Pxf4hQ+Cnmj6wuRGpHSbcSQGeXrffusNnac7KecxCZUwXzu4Hk12V4oke6BVF3hdrPL4wgOyC1A65ObevLhKWh3aw5EAwx/yimM5mMa457V/oCEHfnvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KTuekWU9M7KXxY02UgfpvB3av9QrbelGyLTcInnVtDxvsfPRKoiBiXYWU4gQcz8jEmfu/9LNh7AznU5ABf0c5h7al+pNbDGRwlzJthHEtW34HvaqECwKcoUDDuSIrcdc4aXNiPU3d37/JPCW19Kag+O0FhFIjgA2ahBilpCyMjI= Received: by 10.114.95.1 with SMTP id s1mr773795wab.99.1204675282415; Tue, 04 Mar 2008 16:01:22 -0800 (PST) Received: by 10.115.14.11 with HTTP; Tue, 4 Mar 2008 16:01:22 -0800 (PST) Message-ID: <9e77bdb50803041601r9f687bfpe164f1b7b7d02719@mail.gmail.com> Date: Tue, 4 Mar 2008 17:01:22 -0700 From: "Cyrus Rahman" To: "Bjoern A. Zeeb" In-Reply-To: <20080304152255.M50685@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9e77bdb50803040649u1876d8d4l9f2b7a4cef5c4b5@mail.gmail.com> <20080304152255.M50685@maildrop.int.zabbadoz.net> Cc: freebsd-net@freebsd.org Subject: Re: ipv6 + ah + esp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 00:01:27 -0000 > > Is there a known problem running ah+esp on ip6? I can set up an > > association and run ah+esp just fine on ip4, > > and ah or esp work well by themselves in ip6, but I've had no luck > > with combining them on ip6. > > 22 is EINVAL. > > The same error message is there twice in sys/netinet6/ip6_output.c > (search for "(ipsec)" w/o the ""). > > Could you alter them so we can tell them apart, recompile the kernel > and file a PR with this information and whether it is the printf after > ipsec6_output_trans or after ipsec6_output_tunnel. In this case, because I'm using transport mode, it's in ipsec6_output_trans, but the problem would occur in either case. Looking in in ipsec_output.c, ipsec_process_done(), the problem is this dodgy bit of code: /* * If there's another (bundled) SA to apply, do so. * Note that this puts a burden on the kernel stack size. * If this is a problem we'll need to introduce a queue * to set the packet on so we can unwind the stack before * doing further processing. */ if (isr->next) { ipsec4stat.ips_out_bundlesa++; return ipsec4_process_packet(m, isr->next, 0, 0); } which works great for ipv4 but not so well in the other case. Actually, there's another problem in the new ipsec, which is that the refcnt for security associations gets incremented each time a packet traverses the code. So when you tear an association down you have to wait hours for it to be deleted, since it only decrements once each second. This only happens in ipv6 too, ipv4 works fine. I'll file a pr. Thanks! Cyrus From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 00:26:31 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 163711065676; Wed, 5 Mar 2008 00:26:31 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E0C6E8FC24; Wed, 5 Mar 2008 00:26:30 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m250QU6i007099; Wed, 5 Mar 2008 00:26:30 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m250QU0q007095; Wed, 5 Mar 2008 00:26:30 GMT (envelope-from linimon) Date: Wed, 5 Mar 2008 00:26:30 GMT Message-Id: <200803050026.m250QU0q007095@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/121373: [ipsec] New IPSEC & IPV6 & AH+ESP Broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 00:26:31 -0000 Old Synopsis: New IPSEC & IPV6 & AH+ESP Broken New Synopsis: [ipsec] New IPSEC & IPV6 & AH+ESP Broken Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 5 00:26:16 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121373 From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 01:07:32 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 706671065671; Wed, 5 Mar 2008 01:07:32 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 453888FC15; Wed, 5 Mar 2008 01:07:32 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (yongari@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2517W3R010188; Wed, 5 Mar 2008 01:07:32 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2517WdX010184; Wed, 5 Mar 2008 01:07:32 GMT (envelope-from yongari) Date: Wed, 5 Mar 2008 01:07:32 GMT Message-Id: <200803050107.m2517WdX010184@freefall.freebsd.org> To: yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/76710: [mii] [patch] rgephy does not deal with status properly, if BMCR_ISO is set. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 01:07:32 -0000 Synopsis: [mii] [patch] rgephy does not deal with status properly,if BMCR_ISO is set. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Mar 5 01:06:35 UTC 2008 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=76710 From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 02:57:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3E481065673 for ; Wed, 5 Mar 2008 02:57:55 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by mx1.freebsd.org (Postfix) with ESMTP id 82EC08FC18 for ; Wed, 5 Mar 2008 02:57:55 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by wr-out-0506.google.com with SMTP id c49so1357394wra.19 for ; Tue, 04 Mar 2008 18:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=u2GTC0OKnxt2tSsVcrNKsRBZrgNdFuEpsnCs+7lEPFk=; b=bEzZRF6gknr1IYG6XZZ6odItD7GFR3g/iOPI4efvPHAySi5lZ77JTeVXgzNpy4KApbrSN4l+sDa2oXGqWz+mCWpZqYlzw0fJAVDMFHF8u03jNzXwAiaVRuGXRkOyxEX3I193fwya4oA/REwlBvkuaagSKBEHX9PijqnugcMHr8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=auSplaRbFTCUxS3i+If0k+AS5Zv0ex/tVQtf9Ekx9NRaMAa2Zx0yzUMOrou913ueUiv9q2b6V7rAhw/Wjvc8JxIMKKMF7si+0PfL5l1jMRNL+xkCGpGv2OmitN9uS5MwvKnFsZkJU0GzFknozxTii+5q+Efbp78tI6Qz0/YqGkA= Received: by 10.65.211.16 with SMTP id n16mr4601296qbq.50.1204685874183; Tue, 04 Mar 2008 18:57:54 -0800 (PST) Received: by 10.64.184.9 with HTTP; Tue, 4 Mar 2008 18:57:54 -0800 (PST) Message-ID: <8e10486b0803041857v6d20e3f0x115c6842ec7d899b@mail.gmail.com> Date: Tue, 4 Mar 2008 23:57:54 -0300 From: "Alexandre Biancalana" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: ALTQ Vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 02:57:55 -0000 Hi list, Is there any patches or plans to support altq on vlan interfaces ?? Regards, From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 03:38:06 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28361106566B; Wed, 5 Mar 2008 03:38:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EDA3E8FC14; Wed, 5 Mar 2008 03:38:05 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m253c5cC022272; Wed, 5 Mar 2008 03:38:05 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m253c5FM022268; Wed, 5 Mar 2008 03:38:05 GMT (envelope-from linimon) Date: Wed, 5 Mar 2008 03:38:05 GMT Message-Id: <200803050338.m253c5FM022268@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/77913: [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 03:38:06 -0000 Synopsis: [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 5 03:37:41 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=77913 From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 03:39:55 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E503E1065672; Wed, 5 Mar 2008 03:39:55 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B714B8FC1F; Wed, 5 Mar 2008 03:39:55 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m253dtfd022499; Wed, 5 Mar 2008 03:39:55 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m253dtu0022495; Wed, 5 Mar 2008 03:39:55 GMT (envelope-from linimon) Date: Wed, 5 Mar 2008 03:39:55 GMT Message-Id: <200803050339.m253dtu0022495@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/78072: [lge] [patch] Potential memory leak in lge(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 03:39:56 -0000 Synopsis: [lge] [patch] Potential memory leak in lge(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 5 03:39:40 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=78072 From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 04:04:15 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDA8F1065675; Wed, 5 Mar 2008 04:04:15 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8F3DD8FC15; Wed, 5 Mar 2008 04:04:15 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (yongari@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2544Fso024437; Wed, 5 Mar 2008 04:04:15 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2544F8B024433; Wed, 5 Mar 2008 04:04:15 GMT (envelope-from yongari) Date: Wed, 5 Mar 2008 04:04:15 GMT Message-Id: <200803050404.m2544F8B024433@freefall.freebsd.org> To: yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/78072: [lge] [patch] Potential memory leak in lge(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 04:04:15 -0000 Synopsis: [lge] [patch] Potential memory leak in lge(4) Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Wed Mar 5 04:03:50 UTC 2008 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=78072 From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 05:16:48 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 654921065670; Wed, 5 Mar 2008 05:16:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 396178FC2C; Wed, 5 Mar 2008 05:16:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m255GmSC031616; Wed, 5 Mar 2008 05:16:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m255GmQ4031612; Wed, 5 Mar 2008 05:16:48 GMT (envelope-from linimon) Date: Wed, 5 Mar 2008 05:16:48 GMT Message-Id: <200803050516.m255GmQ4031612@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/121374: [ipsec] SP refcnt increases with each packet in ipv6 with new IPSEC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 05:16:48 -0000 Synopsis: [ipsec] SP refcnt increases with each packet in ipv6 with new IPSEC Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 5 05:16:41 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121374 From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 10:11:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 700CF1065670 for ; Wed, 5 Mar 2008 10:11:08 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id E853E8FC1D for ; Wed, 5 Mar 2008 10:11:07 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JWqaV-0003EU-QZ for freebsd-net@freebsd.org; Wed, 05 Mar 2008 10:11:03 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Mar 2008 10:11:03 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Mar 2008 10:11:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Vadim Goncharov Date: Wed, 5 Mar 2008 10:10:55 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 57 Message-ID: X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: All User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: SCTP using questions (API etc.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 10:11:08 -0000 Hi! I've seen that FreeBSD 7.0 is a reference implementation for SCTP, which is a great protocol, good work! But as I was looking through man pages for new API, I couldn't understand some issues with high-load servers. Currently, I am developing client-server application for my needs, and I want to adjust protocol right now to ease possible transition to SCTP later when it becomes wider available. Protocol uses TCP, it breaks stream to variable-sized records (length in header up to 64K) and multiplexes several "substreams". SCTP can do it for me, it's wonderful, but in practice there are some questions. How long can be one particular SCTP message? Can I rely on the fact that it can be unbounded, e.g. I want to emulate a stream with transfer of 6 Gig-sized file? Can I use 32-bit PPID field for my own headers/arbitrary values or I must register that numbers somewhere before using? Can a message be of zero-length data (only headers) ? What is the relation between SCTP streams in both directions? Can streams be opened and closed on-demand, like SSH port forwarding (yet again multiplexing example) or they are preallocated at connection setup all together? What is the minimum number of streams application can rely upon (or it just one stream 0 in general case) ? Another important questions are related with blocking and non-blocking I/O. With TCP servers I have two models: in one a thread/process per client (usually blocking), in other - a single-threaded FSM (Finite-State Machine) serving all clients using select()/poll()/kqueue()/etc. Both rely on the usual UNIX way of creading new file descriptor on accept(). My server currently uses FSM model, but question is interesting for both. I didn't find any words about descriptor duplication or non-blocking I/O in SCTP man pages. How can I put request to kernel for a connect, for example, and then sleep until connect will complete or event in some another descriptor will occur? How can I put each client to it's fd and then do a kqueue()/kevent() on a set of those fd's (and other items) ? It is very handy to have this architecture as kevent() allows to store an arbitrary void* in it's structure which I can later use to quickly dispatch events. And, of course, all this usual C10K-problem-solving-TCP-server tricks I want with basic SCTP SEQPACKET benefits: multiple streams and message record separation (I don't need other SCTP features currently). Where can I find answers to these questions, like it was with W.R.Stevens books for TCP ?.. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 10:59:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12BD71065670 for ; Wed, 5 Mar 2008 10:59:21 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 24A9D8FC1A for ; Wed, 5 Mar 2008 10:59:20 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [192.168.0.103] (unknown [81.253.15.182]) by mail-n.franken.de (Postfix) with ESMTP id 16FC81C0B462A; Wed, 5 Mar 2008 11:59:16 +0100 (CET) Message-Id: <58141B67-8B7F-49FE-BC20-2A0B94A589A0@lurchi.franken.de> From: Michael Tuexen To: vadim_nuclight@mail.ru In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 5 Mar 2008 11:59:14 +0100 References: X-Mailer: Apple Mail (2.919.2) Cc: freebsd-net@freebsd.org Subject: Re: SCTP using questions (API etc.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 10:59:21 -0000 Hi Vadim, comments in-line. Best regards Michael On Mar 5, 2008, at 11:10 AM, Vadim Goncharov wrote: > Hi! > > I've seen that FreeBSD 7.0 is a reference implementation for SCTP, > which is > a great protocol, good work! > > But as I was looking through man pages for new API, I couldn't > understand > some issues with high-load servers. > > Currently, I am developing client-server application for my needs, > and I want > to adjust protocol right now to ease possible transition to SCTP > later when > it becomes wider available. Protocol uses TCP, it breaks stream to > variable-sized records (length in header up to 64K) and multiplexes > several > "substreams". SCTP can do it for me, it's wonderful, but in practice > there > are some questions. > > How long can be one particular SCTP message? Can I rely on the fact > that it > can be unbounded, e.g. I want to emulate a stream with transfer of > 6 Gig-sized file? Protocol wise there is no limitation of the message size. API wise, for this size of a message you need to use the explicit EOR mode to be able to pass this large message using multiple sequential send() calls. > > > Can I use 32-bit PPID field for my own headers/arbitrary values or I > must > register that numbers somewhere before using? Protocolwise: Yes you can do that. However, I would not encourage you to do that. Protocol analyzers (like Wireshark) use this field to determine the upper layer protocol based on the registration found at the corresponding IANA assignment. > > > Can a message be of zero-length data (only headers) ? Empty user messages, i.e. a DATA chunk without payload is not allowed. An empty SCTP message, i.e. only the common header without any chunks is allowed and processed by FreeBSD when received, but ever send (well, I do not know a way to force the FreeBSD implementation to send it). > > > What is the relation between SCTP streams in both directions? Can > streams > be opened and closed on-demand, like SSH port forwarding (yet again > multiplexing example) or they are preallocated at connection setup all > together? What is the minimum number of streams application can rely > upon > (or it just one stream 0 in general case) ? If you restrict to protocols being in RFC status, there is no way of modifying the number of streams during the lifetime of an association. The number of streams in each direction is negotiated during the association setup. The streams in bother directions are completely independent. There is always at least one stream in each direction, which is stream 0. However, there is an extension (currently specified in an Internet Draft) which allows the addition of streams during the lifetime of an association. The ID is at least partially supported by the FreeBSD implementation. https://datatracker.ietf.org/drafts/draft-stewart-sctpstrrst/ > > > Another important questions are related with blocking and non- > blocking I/O. > > With TCP servers I have two models: in one a thread/process per client > (usually blocking), in other - a single-threaded FSM (Finite-State > Machine) > serving all clients using select()/poll()/kqueue()/etc. Both rely on > the > usual UNIX way of creading new file descriptor on accept(). > > My server currently uses FSM model, but question is interesting for > both. > I didn't find any words about descriptor duplication or non-blocking > I/O > in SCTP man pages Have you looked at http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-16.txt > > > How can I put request to kernel for a connect, for example, and then > sleep > until connect will complete or event in some another descriptor will > occur? If you use the 1-to-1 style API, it should be similar to using TCP. Put the socket in non-blocking mode, enable notifications, call connect() and wait until the fd becomes readable. You should get an indication that that association has been established or could not start. > > > How can I put each client to it's fd and then do a kqueue()/kevent() > on a > set of those fd's (and other items) ? It is very handy to have this > architecture as kevent() allows to store an arbitrary void* in it's > structure which I can later use to quickly dispatch events. > > And, of course, all this usual C10K-problem-solving-TCP-server > tricks I want > with basic SCTP SEQPACKET benefits: multiple streams and message > record > separation (I don't need other SCTP features currently). Where can I > find > answers to these questions, like it was with W.R.Stevens books for > TCP ?.. Have you looked at the third edition of 'Unix Network Programming'? Randall Stewart wrote a couple of sections covering SCTP... > > > -- > WBR, Vadim Goncharov. ICQ#166852181 > mailto:vadim_nuclight@mail.ru > [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/ > nuclight] > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 11:16:32 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CED9106566B; Wed, 5 Mar 2008 11:16:32 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D009F8FC1B; Wed, 5 Mar 2008 11:16:31 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (bz@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m25BGV60059705; Wed, 5 Mar 2008 11:16:31 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m25BGVCR059701; Wed, 5 Mar 2008 11:16:31 GMT (envelope-from bz) Date: Wed, 5 Mar 2008 11:16:31 GMT Message-Id: <200803051116.m25BGVCR059701@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/121384: New IPSEC fails to obey policy levels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 11:16:32 -0000 Synopsis: New IPSEC fails to obey policy levels Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: bz Responsible-Changed-When: Wed Mar 5 11:16:13 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121384 From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 13:24:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1187C106566B for ; Wed, 5 Mar 2008 13:24:55 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id BD9428FC24 for ; Wed, 5 Mar 2008 13:24:54 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from dhcp250-210.yandex.ru ([87.250.250.210]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1JWtgO-0006BW-UN; Wed, 05 Mar 2008 16:29:21 +0300 Message-ID: <47CE9F22.4010107@FreeBSD.org> Date: Wed, 05 Mar 2008 16:24:50 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Alexandre Biancalana References: <8e10486b0803041857v6d20e3f0x115c6842ec7d899b@mail.gmail.com> In-Reply-To: <8e10486b0803041857v6d20e3f0x115c6842ec7d899b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ALTQ Vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 13:24:55 -0000 Alexandre Biancalana wrote: > Hi list, > > Is there any patches or plans to support altq on vlan interfaces ?? > The patch is quite trivial: http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch But may be a better way to shape traffic on parent interface for you? I did the patch because I couldn't do shaping on a parent interface for some reason. -- Dixi. Sem. From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 15:41:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E4301065671 for ; Wed, 5 Mar 2008 15:41:02 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.229]) by mx1.freebsd.org (Postfix) with ESMTP id 403668FC30 for ; Wed, 5 Mar 2008 15:41:01 +0000 (UTC) (envelope-from biancalana@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so1956694wxd.7 for ; Wed, 05 Mar 2008 07:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=WdQ7orX8F87yGOhu8WtFtWClbMP0b4pea8xnd3wmxng=; b=PJKRYfQM+b7x8ih5lrIyhdOyh4ZYs0Pwh78l2vLOWY9HXQT7RCYt/TI6sfbTTbksZGZgkZps75RwBjl1hHzeUfFSWs/3BBSEoYkp37vUpquUTBDkhrVrJe9WDVbG+15Xkc4Ky8tJ31+qvx6W25kqgcvr0EorU+IduR4rYQhKURE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CN6kEIMoHghYLwEKBeZHeKcOoVvO3Fs5cqI85rHPe26UUusgf/VPlukOG4I4cNZiV8lJ92P9IYNZf3T88C4diFy/8rC/uHDWTU12YLmWmxvBDdPLYYOKpsMriszIxIP5hcDvijBBwcWe2z+Cg3/SsdLSMMdlYfr01DxRiLIR70A= Received: by 10.64.53.7 with SMTP id b7mr6569550qba.68.1204731657300; Wed, 05 Mar 2008 07:40:57 -0800 (PST) Received: by 10.64.184.9 with HTTP; Wed, 5 Mar 2008 07:40:57 -0800 (PST) Message-ID: <8e10486b0803050740u7d36c784pd0b9d0d1b3e29c95@mail.gmail.com> Date: Wed, 5 Mar 2008 12:40:57 -0300 From: "Alexandre Biancalana" To: "Sergey Matveychuk" In-Reply-To: <47CE9F22.4010107@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8e10486b0803041857v6d20e3f0x115c6842ec7d899b@mail.gmail.com> <47CE9F22.4010107@FreeBSD.org> Cc: freebsd-net@freebsd.org Subject: Re: ALTQ Vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 15:41:02 -0000 On 3/5/08, Sergey Matveychuk wrote: > Alexandre Biancalana wrote: > > Hi list, > > > > Is there any patches or plans to support altq on vlan interfaces ?? > > > > > The patch is quite trivial: > http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch Is this working on 7 ? with pf ? > > But may be a better way to shape traffic on parent interface for you? > I did the patch because I couldn't do shaping on a parent interface for > some reason. My problem is that I've only one physical interface on the server and this interface provide vlans for local network and remote links (which I want to shape the traffic) then I had problems because I want to limit the speed only on remote links. Thank you Sem ! From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 16:22:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A80371065671 for ; Wed, 5 Mar 2008 16:22:21 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (ns.ciam.ru [213.247.195.75]) by mx1.freebsd.org (Postfix) with ESMTP id 5F8A58FC12 for ; Wed, 5 Mar 2008 16:22:21 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from dhcp250-210.yandex.ru ([87.250.250.210]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1JWwS7-000C4K-Tl; Wed, 05 Mar 2008 19:26:47 +0300 Message-ID: <47CEC8B9.3070604@FreeBSD.org> Date: Wed, 05 Mar 2008 19:22:17 +0300 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Alexandre Biancalana References: <8e10486b0803041857v6d20e3f0x115c6842ec7d899b@mail.gmail.com> <47CE9F22.4010107@FreeBSD.org> <8e10486b0803050740u7d36c784pd0b9d0d1b3e29c95@mail.gmail.com> In-Reply-To: <8e10486b0803050740u7d36c784pd0b9d0d1b3e29c95@mail.gmail.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ALTQ Vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 16:22:21 -0000 Alexandre Biancalana wrote: >> The patch is quite trivial: >> http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch > > Is this working on 7 ? with pf ? > I've test it only on 6.x with pf. But I think there should be no problem and with 7.0. -- Dixi. Sem. From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 19:08:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1E1A1065675 for ; Wed, 5 Mar 2008 19:08:07 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 596388FC2C for ; Wed, 5 Mar 2008 19:08:07 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JWyyB-00089E-N0 for freebsd-net@freebsd.org; Wed, 05 Mar 2008 19:08:03 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Mar 2008 19:08:03 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Mar 2008 19:08:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Vadim Goncharov Date: Wed, 5 Mar 2008 19:07:48 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 129 Message-ID: References: <58141B67-8B7F-49FE-BC20-2A0B94A589A0@lurchi.franken.de> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Michael Tuexen User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: SCTP using questions (API etc.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 19:08:08 -0000 Hi Michael Tuexen! On Wed, 5 Mar 2008 11:59:14 +0100; Michael Tuexen wrote about 'Re: SCTP using questions (API etc.)': >> "substreams". SCTP can do it for me, it's wonderful, but in practice >> there >> are some questions. >> >> How long can be one particular SCTP message? Can I rely on the fact >> that it >> can be unbounded, e.g. I want to emulate a stream with transfer of >> 6 Gig-sized file? > Protocol wise there is no limitation of the message size. API wise, for > this size of a message you need to use the explicit EOR mode to be able > to pass this large message using multiple sequential send() calls. And how should I determine from my/remote stack an optimal size for message parts when entire message is guaranteed to not fit into buffers/windows of both peers? >> Can a message be of zero-length data (only headers) ? > Empty user messages, i.e. a DATA chunk without payload is not allowed. > An empty SCTP message, i.e. only the common header without any chunks > is allowed and processed by FreeBSD when received, but ever send (well, > I do not know a way to force the FreeBSD implementation to send it). OK, understood. So I should include at least 1 byte of my own headers into data and do receive into *iov with at least to parts to ensure good align for non-header part? >> What is the relation between SCTP streams in both directions? Can >> streams >> be opened and closed on-demand, like SSH port forwarding (yet again >> multiplexing example) or they are preallocated at connection setup all >> together? What is the minimum number of streams application can rely >> upon >> (or it just one stream 0 in general case) ? > If you restrict to protocols being in RFC status, there is no way of > modifying the number of streams during the lifetime of an association. > The number of streams in each direction is negotiated during the > association setup. The streams in bother directions are completely > independent. There is always at least one stream in each direction, > which > is stream 0. > However, there is an extension (currently specified in an Internet > Draft) > which allows the addition of streams during the lifetime of an > association. > The ID is at least partially supported by the FreeBSD implementation. > https://datatracker.ietf.org/drafts/draft-stewart-sctpstrrst/ OK. Are there recommended defaults for various stacks about how many streams they are creating by default / what maximum of them application can ever request? >> Another important questions are related with blocking and non- >> blocking I/O. >> >> With TCP servers I have two models: in one a thread/process per client >> (usually blocking), in other - a single-threaded FSM (Finite-State >> Machine) >> serving all clients using select()/poll()/kqueue()/etc. Both rely on >> the >> usual UNIX way of creading new file descriptor on accept(). >> >> My server currently uses FSM model, but question is interesting for >> both. >> I didn't find any words about descriptor duplication or non-blocking >> I/O >> in SCTP man pages > Have you looked at > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-16.txt Yes, I've looked to it briefly before writing my previous letter and have re-read it after your pointing. I've found answers for some of my question, but that's overall is too complex for me for the first time, so I'll ask some another questions below :) >> How can I put request to kernel for a connect, for example, and then >> sleep >> until connect will complete or event in some another descriptor will >> occur? > If you use the 1-to-1 style API, it should be similar to using TCP. > Put the socket in non-blocking mode, enable notifications, > call connect() and wait until the fd becomes readable. You should get an > indication that that association has been established or could not > start. Yes, that's possible, as I see after reading draft-ietf-tsvwg-sctpsocket. But several more questions arise. What notifications do I really need on 1-to-1 non-blocking socket API mode? What use is 'context' in this 1-to-1 context and why after a failed send I must receive entire failed sent message (which can be very long) instead of just an error code? In usual FSM I can use kqueue()/kevent() with arbitrary void* to my data, also telling me how many bytes I can read from or write to the socket (RCVLOWAT etc.), as well as indicating error/EOF conditions so I don't need to do additional syscalls. Is this working with SCTP? If I can't write to TCP socket (due to window shortage from peer), I leave data in my own application buffers, but SCTP tells something about unsent messages delivered later, looks somewhat weird, do I really need this? Also, all that msg*/cmsg* staff is too complex, and I see there are simplier sctp_send()/sctp_sendx() interfaces, will they be enough and really simplier for me?.. >> How can I put each client to it's fd and then do a kqueue()/kevent() >> on a >> set of those fd's (and other items) ? It is very handy to have this >> architecture as kevent() allows to store an arbitrary void* in it's >> structure which I can later use to quickly dispatch events. >> >> And, of course, all this usual C10K-problem-solving-TCP-server >> tricks I want >> with basic SCTP SEQPACKET benefits: multiple streams and message >> record >> separation (I don't need other SCTP features currently). Where can I >> find >> answers to these questions, like it was with W.R.Stevens books for >> TCP ?.. > Have you looked at the third edition of 'Unix Network Programming'? > Randall Stewart wrote a couple of sections covering SCTP... Unfortunately, I have only 2nd edition currently available here, though heard about 3rd, yes. May be several months later... -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 19:39:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AE221065671 for ; Wed, 5 Mar 2008 19:39:14 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1483A8FC18 for ; Wed, 5 Mar 2008 19:39:14 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 59A2A1A000B18; Wed, 5 Mar 2008 11:39:13 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aQTKrz7tXzEM; Wed, 5 Mar 2008 11:39:02 -0800 (PST) Received: from coal.local (s10.sbo [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 74BBE1A000B20; Wed, 5 Mar 2008 11:39:02 -0800 (PST) From: Freddie Cash Organization: School District 73 To: "Max Laier" Date: Wed, 5 Mar 2008 11:39:01 -0800 User-Agent: KMail/1.9.7 References: <200803041351.46053.fjwcash@gmail.com> <36735.192.168.4.151.1204669226.squirrel@router> <200803041525.42330.fjwcash@gmail.com> In-Reply-To: <200803041525.42330.fjwcash@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803051139.01547.fjwcash@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Understanding the interplay of ipfw, vlan, and carp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 19:39:14 -0000 On March 4, 2008 03:25 pm Freddie Cash wrote: > On March 4, 2008 02:20 pm Max Laier wrote: > > Am Di, 4.03.2008, 22:51, schrieb Freddie Cash: > > ... > > > > > The lack of a "carpdev" option to directly link a carp device to an > > > interface (similar to "vlandev" for vlan(4)) is what's really > > > tripping me up. It appears the carp(4) driver looks at all the > > > interfaces in the box to find one with an IP in the same subnet as > > > the carp IP and then uses that as the physical device. > > > > You could try the attached patch. It adds carpdev support. You'll > > have to recompile ifconfig to make use of it. > > > > This patch has some shortcomings that I wanted to address for a long > > time now, but never found the time to do so. Mostly that IPv6 over > > CARP is broken with this patch. Everything else is supposed to work > > and I'd like to hear if you experience otherwise (success stories > > welcome, too). This is from back in early January, but should apply > > to RELENG_7 and HEAD w/o too much trouble. Patch applied cleanly to RELENG_7.0. However, there are a few strange things happening now. If there are IPs on the physical devices (em0|em1) things only seem to work if my ipfw rules allow traffic over em0|em1. If there are no IPs on em0|em1, then the ipfw rules work fine using carp0|carp1. But it's not consistent. Sometimes the counters for the em rules increment and sometimes the counters for the carp rules increment. If there are no IPs on the physical devices, and I configure rc.conf to put two IPs onto carp0 (one with /24, one with /32) it loses the route for the /24, can't find the default router, and traffic doesn't go through. Manually adding the route via "route add -net 192.168.0.0/24 -iface carp0" allows traffic to flow again. The rc.conf entries are: cloned_interfaces="carp0 carp2" ifconfig_em0="up" ifconfig_em2="up" ifconfig_carp0="carpdev em0 vhid 100 pass whatever 192.168.0.11/24" ifconfig_carp0_alias0="192.168.0.10/32" ifconfig_carp2="carpdev em2 vhid 102 pass whatever2 172.20.0/1/24" I only upgraded one of my test boxes to RELENG_7_0. The other is still RELENG_6_3. They no longer stay in sync. Even though net.inet.carp.preempt=1 is set on both boxes, only the interface that I pull the plug on or manually down will fail-over to the other box. The ifconfig ouput on the 6.3 box will show (unplug em2 on the 6.3 box): carp0: flags=49 mtu 1500 inet 192.168.0.11 netmask 0xffffff00 inet 192.168.0.10 netmask 0xffffffff carp: MASTER vhid 100 advbase 1 advskew 150 carp2: flags=49 mtu 1500 inet 172.20.0.1 netmask 0xffffff00 carp: BACKUP vhid 102 advbase 1 advskew 150 And the ifconfig output on the 7.0 box will show: carp0: flags=8843 metric 0 mtu 1500 ether 00:00:5e:00:01:64 inet 192.168.0.10 netmask 0xffffffff inet 192.168.0.11 netmask 0xffffff00 carp: MASTER carpdev em0 vhid 100 advbase 1 advskew 0 carp2: flags=8843 metric 0 mtu 1500 ether 00:00:5e:00:01:66 inet 172.20.0.1 netmask 0xffffff00 carp: MASTER carpdev em2 vhid 102 advbase 1 advskew 0 And, finally, if I try to create two carp devices using the same physical device, with IPs in the same subnet, the box crashes. The first time, it locked up with the kernel panic. Every other time it just locks the box. The commands to do this are reproducable: ifconfig em0 up ifconfig carp0 create ifconfig carp0 carpdev em0 vhid 1 192.168.0.1/24 ifconfig carp1 create ifconfig carp1 carpdev em0 vhid 2 192.168.0.2/24 It will complain once that it can't assign the requested address. If you try the ifconfig command again, the box locks up. Might take two or three tries if you're lucky. :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 20:10:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A53F1065675 for ; Wed, 5 Mar 2008 20:10:00 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 95D698FC1D for ; Wed, 5 Mar 2008 20:09:59 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-052-136.pools.arcor-ip.net [88.66.52.136]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1JWzw62R9X-0001fG; Wed, 05 Mar 2008 21:09:58 +0100 Received: (qmail 99172 invoked by uid 80); 5 Mar 2008 20:09:27 -0000 Received: from 192.168.4.151 (SquirrelMail authenticated user mlaier) by router with HTTP; Wed, 5 Mar 2008 21:09:27 +0100 (CET) Message-ID: <41303.192.168.4.151.1204747767.squirrel@router> In-Reply-To: <200803051139.01547.fjwcash@gmail.com> References: <200803041351.46053.fjwcash@gmail.com> <36735.192.168.4.151.1204669226.squirrel@router> <200803041525.42330.fjwcash@gmail.com> <200803051139.01547.fjwcash@gmail.com> Date: Wed, 5 Mar 2008 21:09:27 +0100 (CET) From: "Max Laier" To: "Freddie Cash" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Provags-ID: V01U2FsdGVkX19koy7EkMn3qzkvBTfcs+NYQoaVt9sT8MZoAzS Fps6QpmE8OKulMw0hPPnmBp9d5w+iIkrYCUg62rObNiUCxhqvO OB69P3LuXqClPe23XZKLw== Cc: freebsd-net@freebsd.org Subject: Re: Understanding the interplay of ipfw, vlan, and carp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 20:10:00 -0000 Am Mi, 5.03.2008, 20:39, schrieb Freddie Cash: > On March 4, 2008 03:25 pm Freddie Cash wrote: >> On March 4, 2008 02:20 pm Max Laier wrote: >> > Am Di, 4.03.2008, 22:51, schrieb Freddie Cash: >> > ... >> > >> > > The lack of a "carpdev" option to directly link a carp device to an >> > > interface (similar to "vlandev" for vlan(4)) is what's really >> > > tripping me up. It appears the carp(4) driver looks at all the >> > > interfaces in the box to find one with an IP in the same subnet as >> > > the carp IP and then uses that as the physical device. >> > >> > You could try the attached patch. It adds carpdev support. You'll >> > have to recompile ifconfig to make use of it. >> > >> > This patch has some shortcomings that I wanted to address for a long >> > time now, but never found the time to do so. Mostly that IPv6 over >> > CARP is broken with this patch. Everything else is supposed to work >> > and I'd like to hear if you experience otherwise (success stories >> > welcome, too). This is from back in early January, but should apply >> > to RELENG_7 and HEAD w/o too much trouble. > > Patch applied cleanly to RELENG_7.0. However, there are a few strange > things happening now. > > If there are IPs on the physical devices (em0|em1) things only seem to > work if my ipfw rules allow traffic over em0|em1. If there are no IPs on > em0|em1, then the ipfw rules work fine using carp0|carp1. But it's not > consistent. Sometimes the counters for the em rules increment and > sometimes the counters for the carp rules increment. I'll look into this ... it would help if you could qualify "it's not consistent" a bit, so that I can reproduce. > If there are no IPs on the physical devices, and I configure rc.conf to > put two IPs onto carp0 (one with /24, one with /32) it loses the route > for the /24, can't find the default router, and traffic doesn't go > through. Manually adding the route via "route add -net > 192.168.0.0/24 -iface carp0" allows traffic to flow again. I see where the error is and will try to fix it. > The rc.conf entries are: > cloned_interfaces="carp0 carp2" > ifconfig_em0="up" > ifconfig_em2="up" > ifconfig_carp0="carpdev em0 vhid 100 pass whatever 192.168.0.11/24" > ifconfig_carp0_alias0="192.168.0.10/32" > ifconfig_carp2="carpdev em2 vhid 102 pass whatever2 172.20.0/1/24" > > I only upgraded one of my test boxes to RELENG_7_0. The other is still > RELENG_6_3. They no longer stay in sync. Even though > net.inet.carp.preempt=1 is set on both boxes, only the interface that I > pull the plug on or manually down will fail-over to the other box. > > The ifconfig ouput on the 6.3 box will show (unplug em2 on the 6.3 box): > carp0: flags=49 mtu 1500 > inet 192.168.0.11 netmask 0xffffff00 > inet 192.168.0.10 netmask 0xffffffff > carp: MASTER vhid 100 advbase 1 advskew 150 > carp2: flags=49 mtu 1500 > inet 172.20.0.1 netmask 0xffffff00 > carp: BACKUP vhid 102 advbase 1 advskew 150 > > And the ifconfig output on the 7.0 box will show: > carp0: flags=8843 metric 0 mtu > 1500 > ether 00:00:5e:00:01:64 > inet 192.168.0.10 netmask 0xffffffff > inet 192.168.0.11 netmask 0xffffff00 > carp: MASTER carpdev em0 vhid 100 advbase 1 advskew 0 > carp2: flags=8843 metric 0 mtu > 1500 > ether 00:00:5e:00:01:66 > inet 172.20.0.1 netmask 0xffffff00 > carp: MASTER carpdev em2 vhid 102 advbase 1 advskew 0 What does "netstat -ssp carp" say? It seems that vhid 100 doesn't sync at all. Might be a problem with the order of the address list. > And, finally, if I try to create two carp devices using the same physical > device, with IPs in the same subnet, the box crashes. The first time, it > locked up with the kernel panic. Every other time it just locks the box. > > The commands to do this are reproducable: > ifconfig em0 up > ifconfig carp0 create > ifconfig carp0 carpdev em0 vhid 1 192.168.0.1/24 > ifconfig carp1 create > ifconfig carp1 carpdev em0 vhid 2 192.168.0.2/24 > > It will complain once that it can't assign the requested address. If you > try the ifconfig command again, the box locks up. Might take two or > three tries if you're lucky. :) This is bad - I'll look at it. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Wed Mar 5 22:18:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62E5D1065697 for ; Wed, 5 Mar 2008 22:18:42 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7BEC98FC26 for ; Wed, 5 Mar 2008 22:18:41 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 123151A000B0E; Wed, 5 Mar 2008 14:18:40 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uIMdH3YsPFNl; Wed, 5 Mar 2008 14:18:33 -0800 (PST) Received: from coal.local (s10.sbo [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 472511A000B0B; Wed, 5 Mar 2008 14:18:33 -0800 (PST) From: Freddie Cash Organization: School District 73 To: "Max Laier" Date: Wed, 5 Mar 2008 14:18:32 -0800 User-Agent: KMail/1.9.7 References: <200803041351.46053.fjwcash@gmail.com> <200803051139.01547.fjwcash@gmail.com> <41303.192.168.4.151.1204747767.squirrel@router> In-Reply-To: <41303.192.168.4.151.1204747767.squirrel@router> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803051418.32940.fjwcash@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Understanding the interplay of ipfw, vlan, and carp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2008 22:18:42 -0000 On March 5, 2008 12:09 pm you wrote: > Am Mi, 5.03.2008, 20:39, schrieb Freddie Cash: > > On March 4, 2008 03:25 pm Freddie Cash wrote: > > Patch applied cleanly to RELENG_7.0. However, there are a few > > strange things happening now. > > > > If there are IPs on the physical devices (em0|em1) things only seem > > to work if my ipfw rules allow traffic over em0|em1. If there are no > > IPs on em0|em1, then the ipfw rules work fine using carp0|carp1. But > > it's not consistent. Sometimes the counters for the em rules > > increment and sometimes the counters for the carp rules increment. > > I'll look into this ... it would help if you could qualify "it's not > consistent" a bit, so that I can reproduce. I'll have to run some more tests on this to try and narrow things down, and make sure I'm actually seeing what I think I'm seeing. This might just be me misunderstanding how the network stack works, and how a packet travels through the physical interfaces, through the virtual interfaces, and through the packet filter. > > The rc.conf entries are: > > cloned_interfaces="carp0 carp2" > > ifconfig_em0="up" > > ifconfig_em2="up" > > ifconfig_carp0="carpdev em0 vhid 100 pass whatever > > 192.168.0.11/24" > > ifconfig_carp0_alias0="192.168.0.10/32" > > ifconfig_carp2="carpdev em2 vhid 102 pass whatever2 172.20.0/1/24" > > > > I only upgraded one of my test boxes to RELENG_7_0. The other is > > still RELENG_6_3. They no longer stay in sync. Even though > > net.inet.carp.preempt=1 is set on both boxes, only the interface that > > I pull the plug on or manually down will fail-over to the other box. > > > > The ifconfig ouput on the 6.3 box will show (unplug em2 on the 6.3 > > box): carp0: flags=49 mtu 1500 > > inet 192.168.0.11 netmask 0xffffff00 > > inet 192.168.0.10 netmask 0xffffffff > > carp: MASTER vhid 100 advbase 1 advskew 150 > > carp2: flags=49 mtu 1500 > > inet 172.20.0.1 netmask 0xffffff00 > > carp: BACKUP vhid 102 advbase 1 advskew 150 > > > > And the ifconfig output on the 7.0 box will show: > > carp0: flags=8843 metric 0 > > mtu 1500 > > ether 00:00:5e:00:01:64 > > inet 192.168.0.10 netmask 0xffffffff > > inet 192.168.0.11 netmask 0xffffff00 > > carp: MASTER carpdev em0 vhid 100 advbase 1 advskew 0 > > carp2: flags=8843 metric 0 > > mtu 1500 > > ether 00:00:5e:00:01:66 > > inet 172.20.0.1 netmask 0xffffff00 > > carp: MASTER carpdev em2 vhid 102 advbase 1 advskew 0 > > What does "netstat -ssp carp" say? It seems that vhid 100 doesn't sync > at all. Might be a problem with the order of the address list. FreeBSD 6.3 box: carp: 1649 packets received (IPv4) 1649 discarded for bad authentication 6871 packets sent (IPv4) FreeBSD 7.0 box: carp: 1138 packets received (IPv4) 1138 discarded for bad authentication 1797 packets sent (IPv4) The rc.conf entries from the 6.3 box: ifconfig_carp0="vhid 100 pass nexus-carp-pass advskew 150 192.168.0.11/24" "ifconfig carp0" lists 192.168.0.11/24 first and 192.168.0.10/32 second. The rc.conf entry from the 7.0 box: ifconfig_carp0="carpdev em0 vhid 100 pass nexus-carp-pass 192.168.0.11/24" "ifconfig carp0" lists 192.168.0.10/32 first and 192.168.0.11/24 second. If I create the carp devices in the exact same order on each box, using the exact same commands (but with carpdev added on the 7.0 box), with only 1 IP on each carp interface, then things almost work. If I down carp2 on the 7.0 box, carp2 on the 6.3 box becomes the master, but carp0 remains as BACKUP on the 6.3 box. And vice versa when I down carp0 on the 7.0 box. Changing the advskew option on the 7.0 box to be 200 causes both carp devices switch. 6.3 becomes master and 7.0 becomes backup. BUT, downing one interface still only causes that one to failover. net.inet.carp_preempt is still set to 1 on both boxes. If I create two IPs on the carp interface, even if created in the exact same order on box boxes, then they won't failover at all. Both boxes show all the carp interfaces set to MASTER. And the discarded counters in "netstat -ssp carp" increment on both boxes every second. Thanks for your help on this. If needed, I can upgrade the other 6.3 box to 7.0. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Mar 6 04:51:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D381106566C for ; Thu, 6 Mar 2008 04:51:37 +0000 (UTC) (envelope-from _lion_2000@mail.ru) Received: from ards.ru (mail.ards.ru [212.76.164.163]) by mx1.freebsd.org (Postfix) with SMTP id BE6E08FC13 for ; Thu, 6 Mar 2008 04:51:34 +0000 (UTC) (envelope-from _lion_2000@mail.ru) Received: (qmail 20249 invoked by uid 0); 6 Mar 2008 09:37:28 +0500 Received: from (10.1.201.55); 6 Mar 2008 04:37:28 -0000 X-lion-scan: 0 X-lion-envelope: F_lion_2000@mail.ru Tfreebsd-net@freebsd.org X-RELAYCLIENT: 1 Received: from wtm-ards-itoa01.net.ards.corp (HELO wtmardsITOA01) (10.1.201.55) by mail.net.ards.corp with SMTP; 6 Mar 2008 09:37:28 +0500 From: <_lion_2000@mail.ru> To: Date: Thu, 6 Mar 2008 09:37:27 +0500 Message-ID: <000001c87f43$c8075800$37c9010a@Net.ARDS.Corp> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach/Q8foUg9OQgkfTVicDlZOmyTWaA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Path MTU Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 04:51:37 -0000 Hi, i have a FreeBSD 6.3, fresh install. It is in the corporate network and i can't use any tcp network service on that machine from any other, which is behind cisco routers with tunnels. Well, not all services, but some, when large packets are sent from that box. After some investigation i found, what router sends ICMP Frag packets to that box, but it doesn't reduce packets size and keep sending large packets: trying to 'scp 10.23.0.241:/usr/bin/cc test' from 10.35.1.3 test# tcpdump -s 128 -nvXpi rl0 'icmp or (tcp and host 10.35.1.3)' tcpdump: listening on rl0, link-type EN10MB (Ethernet), capture size 128 bytes 10:32:01.193385 IP (tos 0x0, ttl 62, id 11830, offset 0, flags [DF], proto: TCP (6), length: 64) 10.35.1.3.60122 > 10.23.0.241.22: S, cksum 0xa461 (correct), 1652841827:1652841827(0) win 65535 0x0000: 4500 0040 2e36 4000 3e06 f854 0a23 0103 E..@.6@.>..T.#.. 0x0010: 0a17 00f1 eada 0016 6284 5d63 0000 0000 ........b.]c.... 0x0020: b002 ffff a461 0000 0204 0564 0101 0402 .....a.....d.... 0x0030: 0103 0301 0101 080a 02ea cdfe 0000 0000 ................ 10:32:01.193417 IP (tos 0x0, ttl 64, id 1173, offset 0, flags [DF], proto: TCP (6), length: 64) 10.23.0.241.22 > 10.35.1.3.60122: S, cksum 0xa9cb (correct), 1543933867:1543933867(0) ack 1652841828 win 65535 0x0000: 4500 0040 0495 4000 4006 1ff6 0a17 00f1 E..@..@.@....... 0x0010: 0a23 0103 0016 eada 5c06 8fab 6284 5d64 .#......\...b.]d 0x0020: b012 ffff a9cb 0000 0204 05b4 0103 0301 ................ 0x0030: 0101 080a 0248 0d3c 02ea cdfe 0402 0000 .....H.<........ 10:32:01.226985 IP (tos 0x0, ttl 61, id 11834, offset 0, flags [DF], proto: TCP (6), length: 52) 10.35.1.3.60122 > 10.23.0.241.22: ., cksum 0x6953 (correct), ack 1 win 32832 0x0000: 4500 0034 2e3a 4000 3d06 f95c 0a23 0103 E..4.:@.=..\.#.. 0x0010: 0a17 00f1 eada 0016 6284 5d64 5c06 8fac ........b.]d\... 0x0020: 8010 8040 6953 0000 0101 080a 02ea ce01 ...@iS.......... 0x0030: 0248 0d3c .H.< 10:32:01.240159 IP (tos 0x0, ttl 64, id 1174, offset 0, flags [DF], proto: TCP (6), length: 91) 10.23.0.241.22 > 10.35.1.3.60122: P, cksum 0x7ea9 (correct), 1:40(39) ack 1 win 32832 0x0000: 4500 005b 0496 4000 4006 1fda 0a17 00f1 E..[..@.@....... 0x0010: 0a23 0103 0016 eada 5c06 8fac 6284 5d64 .#......\...b.]d 0x0020: 8018 8040 7ea9 0000 0101 080a 0248 0d6b ...@~........H.k 0x0030: 02ea ce01 5353 482d 322e 302d 4f70 656e ....SSH-2.0-Open 0x0040: 5353 485f 342e 3570 3120 4672 6565 4253 SSH_4.5p1.FreeBS 0x0050: 442d 3230 3036 3131 3130 0a D-20061110. 10:32:01.272877 IP (tos 0x0, ttl 61, id 11842, offset 0, flags [DF], proto: TCP (6), length: 93) 10.35.1.3.60122 > 10.23.0.241.22: P, cksum 0x4a45 (correct), 1:42(41) ack 40 win 32832 0x0000: 4500 005d 2e42 4000 3d06 f92b 0a23 0103 E..].B@.=..+.#.. 0x0010: 0a17 00f1 eada 0016 6284 5d64 5c06 8fd3 ........b.]d\... 0x0020: 8018 8040 4a45 0000 0101 080a 02ea ce06 ...@JE.......... 0x0030: 0248 0d6b 5353 482d 322e 302d 4f70 656e .H.kSSH-2.0-Open 0x0040: 5353 485f 332e 382e 3170 3120 4672 6565 SSH_3.8.1p1.Free 0x0050: 4253 442d 3230 3036 3039 3330 0a BSD-20060930. 10:32:01.274629 IP (tos 0x0, ttl 64, id 1175, offset 0, flags [DF], proto: TCP (6), length: 788) 10.23.0.241.22 > 10.35.1.3.60122: P 40:776(736) ack 42 win 32832 0x0000: 4500 0314 0497 4000 4006 1d20 0a17 00f1 E.....@.@....... 0x0010: 0a23 0103 0016 eada 5c06 8fd3 6284 5d8d .#......\...b.]. 0x0020: 8018 8040 0e95 0000 0101 080a 0248 0d8d ...@.........H.. 0x0030: 02ea ce06 0000 02dc 0a14 6169 6371 0c61 ..........aicq.a 0x0040: f50f 7395 7713 6004 dbfe 0000 007e 6469 ..s.w.`......~di 0x0050: 6666 6965 2d68 656c 6c6d 616e 2d67 726f ffie-hellman-gro 0x0060: 7570 2d65 7863 6861 6e67 652d 7368 6132 up-exchange-sha2 0x0070: 3536 56 ... ssh negotiation skipped 10:32:04.573132 IP (tos 0x8, ttl 64, id 1207, offset 0, flags [DF], proto: TCP (6), length: 116) 10.23.0.241.22 > 10.35.1.3.60122: P 2000:2064(64) ack 1618 win 32832 0x0000: 4508 0074 04b7 4000 4006 1f98 0a17 00f1 E..t..@.@....... 0x0010: 0a23 0103 0016 eada 5c06 977b 6284 63b5 .#......\..{b.c. 0x0020: 8018 8040 25fb 0000 0101 080a 0248 1a5d ...@%........H.] 0x0030: 02ea cf50 2c87 e0f9 2273 b4b0 9484 f73b ...P,..."s.....; 0x0040: 2b6a 55e2 5acc 86c5 dde5 ac66 f45a 4ccf +jU.Z......f.ZL. 0x0050: bad6 fb67 105e c0e7 df4d 2ea9 8db0 38d9 ...g.^...M....8. 0x0060: 8f1a 965f f45a 0a60 e00f f63b cb75 2e9a ..._.Z.`...;.u.. 0x0070: 01d4 .. 10:32:04.609779 IP (tos 0x8, ttl 61, id 12019, offset 0, flags [DF], proto: TCP (6), length: 100) 10.35.1.3.60122 > 10.23.0.241.22: P, cksum 0x413e (correct), 1618:1666(48) ack 2064 win 32832 0x0000: 4508 0064 2ef3 4000 3d06 f86b 0a23 0103 E..d..@.=..k.#.. 0x0010: 0a17 00f1 eada 0016 6284 63b5 5c06 97bb ........b.c.\... 0x0020: 8018 8040 413e 0000 0101 080a 02ea cf53 ...@A>.........S 0x0030: 0248 1a5d 9b63 e667 bd86 a333 8ee5 f061 .H.].c.g...3...a 0x0040: 5ec8 57e3 7017 f6ef e8ed 10ef 49ac dbec ^.W.p.......I... 0x0050: 569b fcc9 8ec7 f8f4 f0e5 6507 ec3a 5642 V.........e..:VB 0x0060: da05 1e81 .... 10:32:04.610317 IP (tos 0x8, ttl 64, id 1208, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 2064:3432(1368) ack 1666 win 32832 0x0000: 4508 058c 04b8 4000 4006 1a7f 0a17 00f1 E.....@.@....... 0x0010: 0a23 0103 0016 eada 5c06 97bb 6284 63e5 .#......\...b.c. 0x0020: 8010 8040 8649 0000 0101 080a 0248 1a82 ...@.I.......H.. 0x0030: 02ea cf53 1edd d5c1 9c1e bf5e 4271 6ac5 ...S.......^Bqj. 0x0040: feb1 a0a2 3b38 6f92 8c95 bb85 11aa 0824 ....;8o........$ 0x0050: f6dd 1e9b 76f3 77e8 25c5 4da1 ec33 2d23 ....v.w.%.M..3-# 0x0060: b3ac ff52 2d2e b3b4 3e42 50a6 ff59 4b26 ...R-...>BP..YK& 0x0070: 355b 5[ 10:32:04.610332 IP (tos 0x8, ttl 64, id 1209, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 3432:4800(1368) ack 1666 win 32832 0x0000: 4508 058c 04b9 4000 4006 1a7e 0a17 00f1 E.....@.@..~.... 0x0010: 0a23 0103 0016 eada 5c06 9d13 6284 63e5 .#......\...b.c. 0x0020: 8010 8040 6e32 0000 0101 080a 0248 1a82 ...@n2.......H.. 0x0030: 02ea cf53 fd9c 908a 064d 14de 22de b6e2 ...S.....M.."... 0x0040: 41f6 c7cf c8e7 23ae 981e 9c6c 0f86 722f A.....#....l..r/ 0x0050: 1c6b 6149 399c e1db da3c 550d a3ea f304 .kaI9.... 10.35.1.3.60122: . 4800:6168(1368) ack 1666 win 32832 0x0000: 4508 058c 04ba 4000 4006 1a7d 0a17 00f1 E.....@.@..}.... 0x0010: 0a23 0103 0016 eada 5c06 a26b 6284 63e5 .#......\..kb.c. 0x0020: 8010 8040 558e 0000 0101 080a 0248 1a82 ...@U........H.. 0x0030: 02ea cf53 01b7 1c4d 52b4 eaba a6c1 388e ...S...MR.....8. 0x0040: 30f1 45ad b6e1 0f0f 14ec a64e 1189 dee7 0.E........N.... 0x0050: b981 4113 da11 4ff2 f300 f06c 468f fbcc ..A...O....lF... 0x0060: e375 7934 c9f9 250c bdac 5bbd 0be6 b1e1 .uy4..%...[..... 0x0070: 32e0 2. 10:32:04.610351 IP (tos 0x8, ttl 64, id 1211, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 6168:7536(1368) ack 1666 win 32832 0x0000: 4508 058c 04bb 4000 4006 1a7c 0a17 00f1 E.....@.@..|.... 0x0010: 0a23 0103 0016 eada 5c06 a7c3 6284 63e5 .#......\...b.c. 0x0020: 8010 8040 0751 0000 0101 080a 0248 1a82 ...@.Q.......H.. 0x0030: 02ea cf53 dc35 4a99 e94d 3f12 5285 f706 ...S.5J..M?.R... 0x0040: 69c9 ac60 8fe3 0065 df29 11a3 89d3 eb11 i..`...e.)...... 0x0050: 7597 53d5 3764 8c01 d593 ff8f 273b bda1 u.S.7d......';.. 0x0060: 477f b179 a2cc 4fd3 ceb8 2316 a831 bc4a G..y..O...#..1.J 0x0070: 10af .. 10:32:04.610457 IP (tos 0x8, ttl 64, id 1212, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 7536:8904(1368) ack 1666 win 32832 0x0000: 4508 058c 04bc 4000 4006 1a7b 0a17 00f1 E.....@.@..{.... 0x0010: 0a23 0103 0016 eada 5c06 ad1b 6284 63e5 .#......\...b.c. 0x0020: 8010 8040 a994 0000 0101 080a 0248 1a82 ...@.........H.. 0x0030: 02ea cf53 7051 ecd2 2b26 f32b ee18 5d47 ...SpQ..+&.+..]G 0x0040: 6c48 cf69 8841 7861 ba2d 2d60 1dcc 732a lH.i.Axa.--`..s* 0x0050: f741 865f e78b 6954 a9c7 0724 3531 b418 .A._..iT...$51.. 0x0060: f66c 6eb2 59fe 1598 c658 2b6f a777 2cb8 .ln.Y....X+o.w,. 0x0070: d7bb .. here comes icmp frag packets. strange what sometimes tcpdump complains about tcp header in icmp packet and sometimes not 10:32:04.612895 IP (tos 0x0, ttl 254, id 15170, offset 0, flags [none], proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP 10.35.1.3 unreachable - need to frag (mtu 1280), length 36 IP (tos 0x8, ttl 61, id 1208, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: tcp 1396 [bad hdr length 4 - too short, < 20] 0x0000: 4500 0038 3b42 0000 fe01 6761 0a17 0503 E..8;B....ga.... 0x0010: 0a17 00f1 0304 479f 0000 0500 4508 058c ......G.....E... 0x0020: 04b8 4000 3d06 1d7f 0a17 00f1 0a23 0103 ..@.=........#.. 0x0030: 0016 eada c207 0364 .......d 10:32:04.896541 IP (tos 0x8, ttl 64, id 1213, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 2064:3432(1368) ack 1666 win 32832 0x0000: 4508 058c 04bd 4000 4006 1a7a 0a17 00f1 E.....@.@..z.... 0x0010: 0a23 0103 0016 eada 5c06 97bb 6284 63e5 .#......\...b.c. 0x0020: 8010 8040 852b 0000 0101 080a 0248 1ba0 ...@.+.......H.. 0x0030: 02ea cf53 1edd d5c1 9c1e bf5e 4271 6ac5 ...S.......^Bqj. 0x0040: feb1 a0a2 3b38 6f92 8c95 bb85 11aa 0824 ....;8o........$ 0x0050: f6dd 1e9b 76f3 77e8 25c5 4da1 ec33 2d23 ....v.w.%.M..3-# 0x0060: b3ac ff52 2d2e b3b4 3e42 50a6 ff59 4b26 ...R-...>BP..YK& 0x0070: 355b 5[ 10:32:05.269815 IP (tos 0x8, ttl 64, id 1228, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 2064:3432(1368) ack 1666 win 32832 0x0000: 4508 058c 04cc 4000 4006 1a6b 0a17 00f1 E.....@.@..k.... 0x0010: 0a23 0103 0016 eada 5c06 97bb 6284 63e5 .#......\...b.c. 0x0020: 8010 8040 83b7 0000 0101 080a 0248 1d14 ...@.........H.. 0x0030: 02ea cf53 1edd d5c1 9c1e bf5e 4271 6ac5 ...S.......^Bqj. 0x0040: feb1 a0a2 3b38 6f92 8c95 bb85 11aa 0824 ....;8o........$ 0x0050: f6dd 1e9b 76f3 77e8 25c5 4da1 ec33 2d23 ....v.w.%.M..3-# 0x0060: b3ac ff52 2d2e b3b4 3e42 50a6 ff59 4b26 ...R-...>BP..YK& 0x0070: 355b 5[ 10:32:05.272005 IP (tos 0x0, ttl 254, id 15172, offset 0, flags [none], proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP 10.35.1.3 unreachable - need to frag (mtu 1280), length 36 IP (tos 0x8, ttl 61, id 1228, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: [|tcp] 0x0000: 4500 0038 3b44 0000 fe01 675f 0a17 0503 E..8;D....g_.... 0x0010: 0a17 00f1 0304 479f 0000 0500 4508 058c ......G.....E... 0x0020: 04cc 4000 3d06 1d6b 0a17 00f1 0a23 0103 ..@.=..k.....#.. 0x0030: 0016 eada c207 0364 .......d 10:32:05.815720 IP (tos 0x8, ttl 64, id 1229, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 2064:3432(1368) ack 1666 win 32832 0x0000: 4508 058c 04cd 4000 4006 1a6a 0a17 00f1 E.....@.@..j.... 0x0010: 0a23 0103 0016 eada 5c06 97bb 6284 63e5 .#......\...b.c. 0x0020: 8010 8040 8197 0000 0101 080a 0248 1f34 ...@.........H.4 0x0030: 02ea cf53 1edd d5c1 9c1e bf5e 4271 6ac5 ...S.......^Bqj. 0x0040: feb1 a0a2 3b38 6f92 8c95 bb85 11aa 0824 ....;8o........$ 0x0050: f6dd 1e9b 76f3 77e8 25c5 4da1 ec33 2d23 ....v.w.%.M..3-# 0x0060: b3ac ff52 2d2e b3b4 3e42 50a6 ff59 4b26 ...R-...>BP..YK& 0x0070: 355b 5[ 10:32:05.817488 IP (tos 0x0, ttl 254, id 15174, offset 0, flags [none], proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP 10.35.1.3 unreachable - need to frag (mtu 1280), length 36 IP (tos 0x8, ttl 61, id 1229, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: tcp 1400 [bad hdr length 0 - too short, < 20] 0x0000: 4500 0038 3b46 0000 fe01 675d 0a17 0503 E..8;F....g].... 0x0010: 0a17 00f1 0304 479f 0000 0500 4508 058c ......G.....E... 0x0020: 04cd 4000 3d06 1d6a 0a17 00f1 0a23 0103 ..@.=..j.....#.. 0x0030: 0016 eada c207 0364 .......d 10:32:06.706827 IP (tos 0x8, ttl 64, id 1234, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 2064:3432(1368) ack 1666 win 32832 0x0000: 4508 058c 04d2 4000 4006 1a65 0a17 00f1 E.....@.@..e.... 0x0010: 0a23 0103 0016 eada 5c06 97bb 6284 63e5 .#......\...b.c. 0x0020: 8010 8040 7e1f 0000 0101 080a 0248 22ac ...@~........H". 0x0030: 02ea cf53 1edd d5c1 9c1e bf5e 4271 6ac5 ...S.......^Bqj. 0x0040: feb1 a0a2 3b38 6f92 8c95 bb85 11aa 0824 ....;8o........$ 0x0050: f6dd 1e9b 76f3 77e8 25c5 4da1 ec33 2d23 ....v.w.%.M..3-# 0x0060: b3ac ff52 2d2e b3b4 3e42 50a6 ff59 4b26 ...R-...>BP..YK& 0x0070: 355b 5[ 10:32:06.708954 IP (tos 0x0, ttl 254, id 15182, offset 0, flags [none], proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP 10.35.1.3 unreachable - need to frag (mtu 1280), length 36 IP (tos 0x8, ttl 61, id 1234, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: [|tcp] 0x0000: 4500 0038 3b4e 0000 fe01 6755 0a17 0503 E..8;N....gU.... 0x0010: 0a17 00f1 0304 479f 0000 0500 4508 058c ......G.....E... 0x0020: 04d2 4000 3d06 1d65 0a17 00f1 0a23 0103 ..@.=..e.....#.. 0x0030: 0016 eada c207 0364 .......d 10:32:08.288344 IP (tos 0x8, ttl 64, id 1236, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 2064:3432(1368) ack 1666 win 32832 0x0000: 4508 058c 04d4 4000 4006 1a63 0a17 00f1 E.....@.@..c.... 0x0010: 0a23 0103 0016 eada 5c06 97bb 6284 63e5 .#......\...b.c. 0x0020: 8010 8040 77f7 0000 0101 080a 0248 28d4 ...@w........H(. 0x0030: 02ea cf53 1edd d5c1 9c1e bf5e 4271 6ac5 ...S.......^Bqj. 0x0040: feb1 a0a2 3b38 6f92 8c95 bb85 11aa 0824 ....;8o........$ 0x0050: f6dd 1e9b 76f3 77e8 25c5 4da1 ec33 2d23 ....v.w.%.M..3-# 0x0060: b3ac ff52 2d2e b3b4 3e42 50a6 ff59 4b26 ...R-...>BP..YK& 0x0070: 355b 5[ 10:32:08.333302 IP (tos 0x0, ttl 254, id 15201, offset 0, flags [none], proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP 10.35.1.3 unreachable - need to frag (mtu 1280), length 36 IP (tos 0x8, ttl 61, id 1236, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: [|tcp] 0x0000: 4500 0038 3b61 0000 fe01 6742 0a17 0503 E..8;a....gB.... 0x0010: 0a17 00f1 0304 479f 0000 0500 4508 058c ......G.....E... 0x0020: 04d4 4000 3d06 1d63 0a17 00f1 0a23 0103 ..@.=..c.....#.. 0x0030: 0016 eada c207 0364 .......d 10:32:10.262231 IP (tos 0x8, ttl 64, id 1238, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 2064:3432(1368) ack 1666 win 32832 0x0000: 4508 058c 04d6 4000 4006 1a61 0a17 00f1 E.....@.@..a.... 0x0010: 0a23 0103 0016 eada 5c06 97bb 6284 63e5 .#......\...b.c. 0x0020: 8010 8040 704f 0000 0101 080a 0248 307c ...@pO.......H0| 0x0030: 02ea cf53 1edd d5c1 9c1e bf5e 4271 6ac5 ...S.......^Bqj. 0x0040: feb1 a0a2 3b38 6f92 8c95 bb85 11aa 0824 ....;8o........$ 0x0050: f6dd 1e9b 76f3 77e8 25c5 4da1 ec33 2d23 ....v.w.%.M..3-# 0x0060: b3ac ff52 2d2e b3b4 3e42 50a6 ff59 4b26 ...R-...>BP..YK& 0x0070: 355b 5[ 10:32:10.264081 IP (tos 0x0, ttl 254, id 15210, offset 0, flags [none], proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP 10.35.1.3 unreachable - need to frag (mtu 1280), length 36 IP (tos 0x8, ttl 61, id 1238, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: [|tcp] 0x0000: 4500 0038 3b6a 0000 fe01 6739 0a17 0503 E..8;j....g9.... 0x0010: 0a17 00f1 0304 479f 0000 0500 4508 058c ......G.....E... 0x0020: 04d6 4000 3d06 1d61 0a17 00f1 0a23 0103 ..@.=..a.....#.. 0x0030: 0016 eada c207 0364 .......d 10:32:10.490936 IP (tos 0x8, ttl 61, id 12360, offset 0, flags [DF], proto: TCP (6), length: 52) 10.35.1.3.60122 > 10.23.0.241.22: F, cksum 0x4a03 (correct), 1666:1666(0) ack 2064 win 32832 0x0000: 4508 0034 3048 4000 3d06 f746 0a23 0103 E..40H@.=..F.#.. 0x0010: 0a17 00f1 eada 0016 6284 63e5 5c06 97bb ........b.c.\... 0x0020: 8011 8040 4a03 0000 0101 080a 02ea d19f ...@J........... 0x0030: 0248 1a5d .H.] 10:32:10.490953 IP (tos 0x8, ttl 64, id 1239, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 3432:4800(1368) ack 1666 win 32832 0x0000: 4508 058c 04d7 4000 4006 1a60 0a17 00f1 E.....@.@..`.... 0x0010: 0a23 0103 0016 eada 5c06 9d13 6284 63e5 .#......\...b.c. 0x0020: 8010 8040 5509 0000 0101 080a 0248 315f ...@U........H1_ 0x0030: 02ea d19f fd9c 908a 064d 14de 22de b6e2 .........M.."... 0x0040: 41f6 c7cf c8e7 23ae 981e 9c6c 0f86 722f A.....#....l..r/ 0x0050: 1c6b 6149 399c e1db da3c 550d a3ea f304 .kaI9.... 10.23.0.241.22: F, cksum 0x49db (correct), 1666:1666(0) ack 2064 win 32832 0x0000: 4508 0034 3070 4000 3d06 f71e 0a23 0103 E..40p@.=....#.. 0x0010: 0a17 00f1 eada 0016 6284 63e5 5c06 97bb ........b.c.\... 0x0020: 8011 8040 49db 0000 0101 080a 02ea d1c7 ...@I........... 0x0030: 0248 1a5d .H.] 10:32:10.883517 IP (tos 0x8, ttl 64, id 1240, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 4800:6168(1368) ack 1666 win 32832 0x0000: 4508 058c 04d8 4000 4006 1a5f 0a17 00f1 E.....@.@.._.... 0x0010: 0a23 0103 0016 eada 5c06 a26b 6284 63e5 .#......\..kb.c. 0x0020: 8010 8040 3ab5 0000 0101 080a 0248 32e7 ...@:........H2. 0x0030: 02ea d1c7 01b7 1c4d 52b4 eaba a6c1 388e .......MR.....8. 0x0040: 30f1 45ad b6e1 0f0f 14ec a64e 1189 dee7 0.E........N.... 0x0050: b981 4113 da11 4ff2 f300 f06c 468f fbcc ..A...O....lF... 0x0060: e375 7934 c9f9 250c bdac 5bbd 0be6 b1e1 .uy4..%...[..... 0x0070: 32e0 2. 10:32:10.883525 IP (tos 0x8, ttl 64, id 1241, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 6168:7536(1368) ack 1666 win 32832 0x0000: 4508 058c 04d9 4000 4006 1a5e 0a17 00f1 E.....@.@..^.... 0x0010: 0a23 0103 0016 eada 5c06 a7c3 6284 63e5 .#......\...b.c. 0x0020: 8010 8040 ec77 0000 0101 080a 0248 32e7 ...@.w.......H2. 0x0030: 02ea d1c7 dc35 4a99 e94d 3f12 5285 f706 .....5J..M?.R... 0x0040: 69c9 ac60 8fe3 0065 df29 11a3 89d3 eb11 i..`...e.)...... 0x0050: 7597 53d5 3764 8c01 d593 ff8f 273b bda1 u.S.7d......';.. 0x0060: 477f b179 a2cc 4fd3 ceb8 2316 a831 bc4a G..y..O...#..1.J 0x0070: 10af .. 10:32:10.885801 IP (tos 0x0, ttl 254, id 15215, offset 0, flags [none], proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP 10.35.1.3 unreachable - need to frag (mtu 1280), length 36 IP (tos 0x8, ttl 61, id 1240, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: [|tcp] 0x0000: 4500 0038 3b6f 0000 fe01 6734 0a17 0503 E..8;o....g4.... 0x0010: 0a17 00f1 0304 3cef 0000 0500 4508 058c ......<.....E... 0x0020: 04d8 4000 3d06 1d5f 0a17 00f1 0a23 0103 ..@.=.._.....#.. 0x0030: 0016 eada c207 0e14 ........ here i cancelled 10:32:11.484055 IP (tos 0x8, ttl 61, id 12413, offset 0, flags [DF], proto: TCP (6), length: 52) 10.35.1.3.60122 > 10.23.0.241.22: F, cksum 0x499f (correct), 1666:1666(0) ack 2064 win 32832 0x0000: 4508 0034 307d 4000 3d06 f711 0a23 0103 E..40}@.=....#.. 0x0010: 0a17 00f1 eada 0016 6284 63e5 5c06 97bb ........b.c.\... 0x0020: 8011 8040 499f 0000 0101 080a 02ea d203 ...@I........... 0x0030: 0248 1a5d .H.] turning PathMTU off or reducing mtu on interface helps, but what the hell? what's wrong whith that? From owner-freebsd-net@FreeBSD.ORG Thu Mar 6 08:34:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5D72106566B for ; Thu, 6 Mar 2008 08:34:18 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id BC6158FC25 for ; Thu, 6 Mar 2008 08:34:17 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mbp15.lan (LRouen-151-72-8-44.w80-13.abo.wanadoo.fr [80.13.167.44]) by mail-n.franken.de (Postfix) with ESMTP id 419841C0B460E; Thu, 6 Mar 2008 09:34:15 +0100 (CET) Message-Id: <645A930A-F67E-465E-8DBB-59FBA4C8593B@lurchi.franken.de> From: Michael Tuexen To: vadim_nuclight@mail.ru In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 6 Mar 2008 09:34:13 +0100 References: <58141B67-8B7F-49FE-BC20-2A0B94A589A0@lurchi.franken.de> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-net@freebsd.org Subject: Re: SCTP using questions (API etc.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 08:34:18 -0000 On Mar 5, 2008, at 8:07 PM, Vadim Goncharov wrote: > Hi Michael Tuexen! > > On Wed, 5 Mar 2008 11:59:14 +0100; Michael Tuexen wrote about 'Re: > SCTP using questions (API etc.)': > >>> "substreams". SCTP can do it for me, it's wonderful, but in practice >>> there >>> are some questions. >>> >>> How long can be one particular SCTP message? Can I rely on the fact >>> that it >>> can be unbounded, e.g. I want to emulate a stream with transfer of >>> 6 Gig-sized file? >> Protocol wise there is no limitation of the message size. API wise, >> for >> this size of a message you need to use the explicit EOR mode to be >> able >> to pass this large message using multiple sequential send() calls. > > And how should I determine from my/remote stack an optimal size for > message > parts when entire message is guaranteed to not fit into buffers/ > windows of > both peers? If the sendbuffer is too small for the message to fit, the send call will return -1 and errno being set to EMSGSIZE. Or you do it in the application by inspecting the sendbuffer size. You do not have to deal with the recv buffer of the peer. > > >>> Can a message be of zero-length data (only headers) ? >> Empty user messages, i.e. a DATA chunk without payload is not >> allowed. >> An empty SCTP message, i.e. only the common header without any chunks >> is allowed and processed by FreeBSD when received, but ever send >> (well, >> I do not know a way to force the FreeBSD implementation to send it). > > OK, understood. So I should include at least 1 byte of my own > headers into > data and do receive into *iov with at least to parts to ensure good > align > for non-header part? What header are you talking about? An application header or any SCTP header? You will never receive any SCTP header as part of a user message via a recv() call. SCTP will give you as much of a message that fits into the buffer you provide or it has, if the partial delivery API has been invoked. > > >>> What is the relation between SCTP streams in both directions? Can >>> streams >>> be opened and closed on-demand, like SSH port forwarding (yet again >>> multiplexing example) or they are preallocated at connection setup >>> all >>> together? What is the minimum number of streams application can rely >>> upon >>> (or it just one stream 0 in general case) ? >> If you restrict to protocols being in RFC status, there is no way of >> modifying the number of streams during the lifetime of an >> association. >> The number of streams in each direction is negotiated during the >> association setup. The streams in bother directions are completely >> independent. There is always at least one stream in each direction, >> which >> is stream 0. >> However, there is an extension (currently specified in an Internet >> Draft) >> which allows the addition of streams during the lifetime of an >> association. >> The ID is at least partially supported by the FreeBSD implementation. >> https://datatracker.ietf.org/drafts/draft-stewart-sctpstrrst/ > > OK. Are there recommended defaults for various stacks about how many > streams they are creating by default / what maximum of them > application > can ever request? The maximum number to request is 2^16 - 1. It is controllable by the applications via socket options. Defaults in OSes are in the order of 10, 16, 32... > > >>> Another important questions are related with blocking and non- >>> blocking I/O. >>> >>> With TCP servers I have two models: in one a thread/process per >>> client >>> (usually blocking), in other - a single-threaded FSM (Finite-State >>> Machine) >>> serving all clients using select()/poll()/kqueue()/etc. Both rely on >>> the >>> usual UNIX way of creading new file descriptor on accept(). >>> >>> My server currently uses FSM model, but question is interesting for >>> both. >>> I didn't find any words about descriptor duplication or non-blocking >>> I/O >>> in SCTP man pages >> Have you looked at >> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg- >> sctpsocket-16.txt > > Yes, I've looked to it briefly before writing my previous letter and > have re-read it after your pointing. I've found answers for some of > my question, but that's overall is too complex for me for the first > time, > so I'll ask some another questions below :) > >>> How can I put request to kernel for a connect, for example, and then >>> sleep >>> until connect will complete or event in some another descriptor will >>> occur? >> If you use the 1-to-1 style API, it should be similar to using TCP. >> Put the socket in non-blocking mode, enable notifications, >> call connect() and wait until the fd becomes readable. You should >> get an >> indication that that association has been established or could not >> start. > > Yes, that's possible, as I see after reading draft-ietf-tsvwg- > sctpsocket. > But several more questions arise. What notifications do I really need > on 1-to-1 non-blocking socket API mode? What use is 'context' in this > 1-to-1 context and why after a failed send I must receive entire > failed > sent message (which can be very long) instead of just an error code? The context is something you provide in the send call and is given back to you. So you can use it to find some state/buffer/whatever again. > > > In usual FSM I can use kqueue()/kevent() with arbitrary void* to my > data, also telling me how many bytes I can read from or write to > the socket (RCVLOWAT etc.), as well as indicating error/EOF conditions > so I don't need to do additional syscalls. Is this working with SCTP? Haven't tried it... Sounds like it would make sense to make sure that it works. > > > If I can't write to TCP socket (due to window shortage from peer), > I leave data in my own application buffers, but SCTP tells something > about unsent messages delivered later, looks somewhat weird, do I > really > need this? Also, all that msg*/cmsg* staff is too complex, and I see > there are simplier sctp_send()/sctp_sendx() interfaces, will they be > enough and really simplier for me?.. sctp_sendx() purpose is to use the multiple addresses provided during the implicit setup of the association. So I think you are not looking for this. sctp_send() can be used to provide the stream id, payload protocol identifier and to on with using the CMSG stuff. So you might be looking for this function. > > >>> How can I put each client to it's fd and then do a kqueue()/kevent() >>> on a >>> set of those fd's (and other items) ? It is very handy to have this >>> architecture as kevent() allows to store an arbitrary void* in it's >>> structure which I can later use to quickly dispatch events. >>> >>> And, of course, all this usual C10K-problem-solving-TCP-server >>> tricks I want >>> with basic SCTP SEQPACKET benefits: multiple streams and message >>> record >>> separation (I don't need other SCTP features currently). Where can I >>> find >>> answers to these questions, like it was with W.R.Stevens books for >>> TCP ?.. >> Have you looked at the third edition of 'Unix Network Programming'? >> Randall Stewart wrote a couple of sections covering SCTP... > > Unfortunately, I have only 2nd edition currently available here, > though > heard about 3rd, yes. May be several months later... It is really worth buying if you are interested in SCTP socket programming... > > > -- > WBR, Vadim Goncharov. ICQ#166852181 > mailto:vadim_nuclight@mail.ru > [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/ > nuclight] > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Mar 6 08:54:09 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43A41106566B for ; Thu, 6 Mar 2008 08:54:09 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 09D958FC20 for ; Thu, 6 Mar 2008 08:54:08 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from japan.t-online.private (people [192.168.2.4]) by people.fsn.hu (Postfix) with ESMTP id E3DEC8B236 for ; Thu, 6 Mar 2008 09:36:23 +0100 (CET) Message-ID: <47CFAD07.6020008@fsn.hu> Date: Thu, 06 Mar 2008 09:36:23 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: pf reply-to broken in RELENG_7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 08:54:09 -0000 Hello, I've just upgraded some of our 6-STABLE servers to 7-STABLE to notice that pf reply-to for directly connected IPs seems to be broken. I have the following relevant rule in pf.conf: pass in on $ext_if reply-to ( $ext_if csmvip ) proto tcp from any to any port 25 label "mxtraffic-tcp" keep state which routes incoming SMTP connections (to be exact, the replies to them) to the csmvip host, which is a load balancer. This is needed because the LB doesn't do source NAT (it does destination NAT however to direct traffic addressed to its virtual IP to the real servers' IPs), and the servers have a different default route than the LB. This way the servers reply to the LB, so it can rewrite the replies' source address to its virtual IP, so the client will see the correct IP (the LB's virtual IP) in the address, instead of the host's real address. It seems that this still works in 7-STABLE for the internet (not directly connected) hosts, but not for directly connected hosts, for example the ones, which are in the same subnet as my servers. To overcome this, I've had to add static ARP entries to the servers, to tell that the clients' hardware address is the address of the load balancer, but it would be better if the previous behaviour (as in 6-STABLE) could be restored. Could anybody help to resolve this? Thanks, -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone: +3630 306 6758 http://www.fsn.hu/ From owner-freebsd-net@FreeBSD.ORG Thu Mar 6 12:17:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C59D91065671 for ; Thu, 6 Mar 2008 12:17:43 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6DC8FC29 for ; Thu, 6 Mar 2008 12:17:43 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-037-226.pools.arcor-ip.net [88.66.37.226]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1JXF2Z1ArA-0003k7; Thu, 06 Mar 2008 13:17:42 +0100 Received: (qmail 10555 invoked by uid 80); 6 Mar 2008 12:17:04 -0000 Received: from 192.168.4.151 (SquirrelMail authenticated user mlaier) by router with HTTP; Thu, 6 Mar 2008 13:17:04 +0100 (CET) Message-ID: <49906.192.168.4.151.1204805824.squirrel@router> In-Reply-To: <47CFAD07.6020008@fsn.hu> References: <47CFAD07.6020008@fsn.hu> Date: Thu, 6 Mar 2008 13:17:04 +0100 (CET) From: "Max Laier" To: "Attila Nagy" User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Provags-ID: V01U2FsdGVkX1/Fp776kC5VURx9PNFn8FqtgcMDnjH1NV6rmVh Krz1VktuGkCATsK7Cnk9vs92khjGiZF6p4+n1bNh0HB8nyz+tq arhmXbdlc+u02AXnY3kag== Cc: freebsd-net@freebsd.org Subject: Re: pf reply-to broken in RELENG_7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 12:17:43 -0000 Am Do, 6.03.2008, 09:36, schrieb Attila Nagy: > Hello, > > I've just upgraded some of our 6-STABLE servers to 7-STABLE to notice > that pf reply-to for directly connected IPs seems to be broken. > > I have the following relevant rule in pf.conf: > pass in on $ext_if reply-to ( $ext_if csmvip ) proto tcp from any to any > port 25 label "mxtraffic-tcp" keep state > > which routes incoming SMTP connections (to be exact, the replies to > them) to the csmvip host, which is a load balancer. This is needed > because the LB doesn't do source NAT (it does destination NAT however to > direct traffic addressed to its virtual IP to the real servers' IPs), > and the servers have a different default route than the LB. This way the > servers reply to the LB, so it can rewrite the replies' source address > to its virtual IP, so the client will see the correct IP (the LB's > virtual IP) in the address, instead of the host's real address. > > It seems that this still works in 7-STABLE for the internet (not > directly connected) hosts, but not for directly connected hosts, for > example the ones, which are in the same subnet as my servers. > To overcome this, I've had to add static ARP entries to the servers, to > tell that the clients' hardware address is the address of the load > balancer, but it would be better if the previous behaviour (as in > 6-STABLE) could be restored. > > Could anybody help to resolve this? Might be the lack of sleep and coffee, but I can't quite figure out the network layout you are talking about. Could you draw up a small example setup so I can follow? Or at least (pseudo-)IP addresses for client, load-balancer, pf-box and servers? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-net@FreeBSD.ORG Thu Mar 6 14:07:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C280106566B for ; Thu, 6 Mar 2008 14:07:18 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id B46588FC21 for ; Thu, 6 Mar 2008 14:07:17 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from japan.t-online.private (people [192.168.2.4]) by people.fsn.hu (Postfix) with ESMTP id 2C8A493D3C; Thu, 6 Mar 2008 15:07:09 +0100 (CET) Message-ID: <47CFFA8D.4060203@fsn.hu> Date: Thu, 06 Mar 2008 15:07:09 +0100 From: Attila Nagy User-Agent: Thunderbird 2.0.0.9 (X11/20080213) MIME-Version: 1.0 To: Max Laier References: <47CFAD07.6020008@fsn.hu> <49906.192.168.4.151.1204805824.squirrel@router> In-Reply-To: <49906.192.168.4.151.1204805824.squirrel@router> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: pf reply-to broken in RELENG_7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 14:07:18 -0000 On 03/06/08 13:17, Max Laier wrote: > Am Do, 6.03.2008, 09:36, schrieb Attila Nagy: > >> Hello, >> >> I've just upgraded some of our 6-STABLE servers to 7-STABLE to notice >> that pf reply-to for directly connected IPs seems to be broken. >> >> I have the following relevant rule in pf.conf: >> pass in on $ext_if reply-to ( $ext_if csmvip ) proto tcp from any to any >> port 25 label "mxtraffic-tcp" keep state >> >> which routes incoming SMTP connections (to be exact, the replies to >> them) to the csmvip host, which is a load balancer. This is needed >> because the LB doesn't do source NAT (it does destination NAT however to >> direct traffic addressed to its virtual IP to the real servers' IPs), >> and the servers have a different default route than the LB. This way the >> servers reply to the LB, so it can rewrite the replies' source address >> to its virtual IP, so the client will see the correct IP (the LB's >> virtual IP) in the address, instead of the host's real address. >> >> It seems that this still works in 7-STABLE for the internet (not >> directly connected) hosts, but not for directly connected hosts, for >> example the ones, which are in the same subnet as my servers. >> To overcome this, I've had to add static ARP entries to the servers, to >> tell that the clients' hardware address is the address of the load >> balancer, but it would be better if the previous behaviour (as in >> 6-STABLE) could be restored. >> >> Could anybody help to resolve this? >> > > Might be the lack of sleep and coffee, but I can't quite figure out the > network layout you are talking about. Could you draw up a small example > setup so I can follow? Or at least (pseudo-)IP addresses for client, > load-balancer, pf-box and servers? > Of course, see: http://people.fsn.hu/~bra/freebsd/route-to-20080306/lb.png 10.0.0.1 is a normal router, which connects the servers to the internet (they can be reached at their real IPs through it and they can reach the internet via them). This is the default GW for the hosts. 10.0.0.2 is a load balancer, which has another address too (10.1.1.2), which is what I've called virtual IP. We do the service on this virtual IP, so the clients on the internet connect to this. 10.0.0.3 and 10.0.0.4 are the real servers behind the virtual IP. The load balancer does this: - a client -say 10.2.2.2 on the internet- connects to the load balancer's virtual IP, 10.1.1.2, for example with TCP/25 - the load balancer then takes a machine out of its configured pool for this service, for example 10.0.0.3 - to reach 10.0.0.3:25, the load balancer changes the packet's destination address from 10.1.1.2 to 10.0.0.3 and sends it out on its 10.0.0.2 interface - the host 10.0.0.3 gets this and sees that the source address is not directly connected, so it tries to send it via the default GW (10.0.0.1), which is of course not good, so we have a reply-to rule, which forces these replies back to 10.0.0.2 - the load balancer gets the reply, then changes its source IP to 10.1.1.2 (the virtual IP for this service) and sends out to the internet We can't send the reply to 10.0.0.1 (the default GW), because it won't do the source NAT and the load balancer will see only one way of the traffic, and it won't let it through (it has a state table, so for example a TCP session must be built up through it, it has to follow the states). We also can't use the load balancer as a default GW, because it's not a router, it's pointless to route normal outgoing traffic through it (which is originated at the hosts), and the load balancer wouldn't allow this anyway, because it only handles configured services and everything must be in its state table. This part works OK both with FreeBSD 6 and 7, the replies to the servers go to the load balancer. What does not work is the scenario, when 10.0.0.4 tries to connect to 10.1.1.2. You can easily see, that this is a problem, because 10.0.0.4 sends the first packet through 10.0.0.1, which in turn forwards it to 10.1.1.2 (the virtual IP of the load balancer). The load balancer then changes the destination IP from 10.1.1.2 to 10.0.0.3 (I really should draw three or more boxes, but please imagine that 10.0.0.4 won't connect to a service in which it is placed, so it won't happen that both the source and the destination is the same machine) and sends it through its 10.0.0.2 interface. The host gets the packet and sees that the source is 10.0.0.4, which is directly connected to it, so it sends the answer directly and 10.0.0.3 will stand confused (sent a request to 10.1.1.2, got the reply from 10.0.0.3). This is the second thing, which is the above reply-to is there: the machine must send the reply to 10.0.0.2, not to 10.0.0.4. The load balancer then will change the source address to 10.1.1.2 and send the reply to 10.0.0.4, so everything will be OK. This is what works in 6.x, but not in 7. I hope I could make this clear enough, if not, please ask. Thanks, -- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone: +3630 306 6758 http://www.fsn.hu/ From owner-freebsd-net@FreeBSD.ORG Thu Mar 6 16:41:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DC7A106566C for ; Thu, 6 Mar 2008 16:41:19 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by mx1.freebsd.org (Postfix) with ESMTP id 4B95D8FC15 for ; Thu, 6 Mar 2008 16:41:19 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 1JXInU-0001hP-SL for freebsd-net@freebsd.org; Thu, 06 Mar 2008 16:18:20 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp3.email.verio.net with esmtp id 1JXInU-0007dD-Ny for freebsd-net@freebsd.org; Thu, 06 Mar 2008 16:18:20 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 7B7218E296; Thu, 6 Mar 2008 10:18:18 -0600 (CST) Date: Thu, 6 Mar 2008 10:18:18 -0600 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20080306161818.GD15130@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: <000001c87f43$c8075800$37c9010a@Net.ARDS.Corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <000001c87f43$c8075800$37c9010a@Net.ARDS.Corp> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: Path MTU Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 16:41:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 _lion_2000@mail.ru <_lion_2000@mail.ru> wrote: > > Hi, i have a FreeBSD 6.3, fresh install. It is in the corporate > network and i can't use any tcp network service on that machine from > any other, which is behind cisco routers with tunnels. This is a classic PMTU Discovery problem. > Well, not all services, but some, when large packets are sent from > that box. After some investigation i found, what router sends ICMP > Frag packets to that box, but it doesn't reduce packets size and keep > sending large packets: Is it possible that you have PF or IPFW filter rules in place that drop ICMP? Just because tcpdump shows you the frame arrived at your system, does not mean that it was "seen" by the kernel. > here comes icmp frag packets. strange what sometimes tcpdump complains about > tcp header in icmp packet and sometimes not The reason for this complaint is that frag_needed packets return a portion of the original IP frame back to the sender, but the number of bytes is not sufficient to see the entire TCP header. However, there is enough to see the src/dest IP's and src/dest port numbers, as tcpdump shows you. But tcpdump cannot decode past the end of the returned frame, so it shows an error. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFH0BlKFSrKRjX5eCoRAoV2AJ4muSN0vV3HfpxfqKB1S/F+pX7TrACfRiQB AzsTCoFsun772YGxCxLj8GM= =BcKe -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Mar 6 22:19:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A34901065675 for ; Thu, 6 Mar 2008 22:19:54 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 9041B8FC14 for ; Thu, 6 Mar 2008 22:19:54 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id 200F43C046F; Thu, 6 Mar 2008 14:19:54 -0800 (PST) Date: Thu, 6 Mar 2008 14:19:54 -0800 From: Christopher Cowart To: freebsd-net@freebsd.org Message-ID: <20080306221954.GN30324@hal.rescomp.berkeley.edu> Mail-Followup-To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PZYVFYZbFYjzBslI" Content-Disposition: inline Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.16 (2007-06-09) Subject: Load Balancing with CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 22:19:54 -0000 --PZYVFYZbFYjzBslI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I followed the instructions in carp(4) and set up a load balancing and failover configuration on vlan interfaces -- it's working fine (as long as I don't `ifconfig carp25 destroy'...). In order to really make use of this functionality, I need a user land method of figuring out whether a MAC address is coming to the local host as the primary or secondary. In other words, let's say I have two clients: IP MAC =2E10 :0a =2E11 :0b And two VHIDs for the virtual router interface (IP .1): VHID MAC 1 :01 2 :02 Router 1 has VHID 1 primary, VHID 2 backup. Router 2 has VHID 2 primary, VHID 1 backup.=20 How can I find out which VHID the sending MAC address hashes to?=20 For example: | which_vhid :0a | 1 | which_vhid :0b | 2 After poking around, the only thing I can figure is reproduce the hash function from the source code myself. I really don't want to do that if there's another way. Thanks, --=20 Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley --PZYVFYZbFYjzBslI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQIVAwUBR9BuCSPHEDszU3zYAQIiLRAAn7xPbHP4Mj9NssOHGQbtdmR6j76voNYo TiMsFR7ir0DSv42M/EqR8ngBjRz1TrZCHtdHgaR2/+MDhMfMLarueGoBqIhFuphp SSMybH9jl2klntdHfcALQp36OzfBpNFu5iEv5jvby5j03BtVQyWXoEaQEfBaci6+ txCrbOCe35j1vUbeNZ5r6lHRy+vnEFblMQ0wmidkAgIy5T/7UJKCb7NW8l+mM20H ormAkjXqWX/JxDNrW7sDRUGpgYaokQ2g8hKX3e2CI3GxV+MOOWQTcplz8k9kd2lr 7dm4mB+2ZSJrTCn3fRwaz9EakW49GYmJFeDZWCB8/Hj3IN/BHi/6UuUPVC5denT9 +KUljhCMo1P0OVjJmG7RbddRon9jTwQV3LJ9+2DoqJ7HsL5ZYMbLxLvS5i0Zf/ek qH5SbHZtsyM8xjxPmrikM4RMI3j29hhN8L3zqVynanamBvRBGPf6vcswJ01a8iv8 Mgpf1sm0Vs/7tZsGyooXylX5Idg4UOC+e256XIkdd//TXI4iwbb2eulG1ywbMgNN y9O7m848ddnlSh0CC17hZ8Xv+b29AVKtPVZGrI+Eo529Y2uG6MdZq9PSo//FdOAM 1EJ482u5i6pZy2QZNCGGG0ywYKKJLwo422IjQbNpYza+jmZfBX1LjhlsLbzQakIz fFkLFtehldE= =Kfhl -----END PGP SIGNATURE----- --PZYVFYZbFYjzBslI-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 04:18:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01377106566B for ; Fri, 7 Mar 2008 04:18:56 +0000 (UTC) (envelope-from _lion_2000@mail.ru) Received: from ards.ru (mail.ards.ru [212.76.164.163]) by mx1.freebsd.org (Postfix) with SMTP id C519F8FC13 for ; Fri, 7 Mar 2008 04:18:54 +0000 (UTC) (envelope-from _lion_2000@mail.ru) Received: (qmail 6531 invoked by uid 0); 7 Mar 2008 09:18:51 +0500 Received: from (10.1.201.55); 7 Mar 2008 04:18:51 -0000 X-lion-scan: 0 X-lion-envelope: F_lion_2000@mail.ru Tfreebsd-net@freebsd.org X-RELAYCLIENT: 1 Received: from wtm-ards-itoa01.net.ards.corp (HELO wtmardsITOA01) (10.1.201.55) by mail.net.ards.corp with SMTP; 7 Mar 2008 09:18:51 +0500 From: "Sergey" <_lion_2000@mail.ru> To: References: <000001c87f43$c8075800$37c9010a@Net.ARDS.Corp> <20080306161818.GD15130@verio.net> Date: Fri, 7 Mar 2008 09:18:51 +0500 Message-ID: <001101c8800a$596d4220$37c9010a@Net.ARDS.Corp> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080306161818.GD15130@verio.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach/qQPMwdmhNDt7SEKSSxXiz74OOgAYPJnA Subject: RE: Path MTU Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 04:18:58 -0000 > Is it possible that you have PF or IPFW filter rules in place > that drop ICMP? Just because tcpdump shows you the frame > arrived at your system, does not mean that it was "seen" by > the kernel. No, it's virgin clean install, without any packet filtering enabled > > here comes icmp frag packets. strange what sometimes > tcpdump complains > > about tcp header in icmp packet and sometimes not > > The reason for this complaint is that frag_needed packets > return a portion of the original IP frame back to the sender, > but the number of bytes is not sufficient to see the entire > TCP header. However, there is enough to see the src/dest > IP's and src/dest port numbers, as tcpdump shows you. But > tcpdump cannot decode past the end of the returned frame, so > it shows an error. I c From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 04:33:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B0A71065670 for ; Fri, 7 Mar 2008 04:33:11 +0000 (UTC) (envelope-from _lion_2000@mail.ru) Received: from ards.ru (mail.ards.ru [212.76.164.163]) by mx1.freebsd.org (Postfix) with SMTP id CC3B98FC1C for ; Fri, 7 Mar 2008 04:33:10 +0000 (UTC) (envelope-from _lion_2000@mail.ru) Received: (qmail 14287 invoked by uid 0); 7 Mar 2008 09:33:09 +0500 Received: from (10.1.201.55); 7 Mar 2008 04:33:09 -0000 X-lion-scan: 0 X-lion-envelope: F_lion_2000@mail.ru Tfreebsd-net@freebsd.org X-RELAYCLIENT: 1 Received: from wtm-ards-itoa01.net.ards.corp (HELO wtmardsITOA01) (10.1.201.55) by mail.net.ards.corp with SMTP; 7 Mar 2008 09:33:09 +0500 From: "Sergey" <_lion_2000@mail.ru> To: References: <000001c87f43$c8075800$37c9010a@Net.ARDS.Corp><20080306161818.GD15130@verio.net> <001101c8800a$596d4220$37c9010a@Net.ARDS.Corp> Date: Fri, 7 Mar 2008 09:33:09 +0500 Message-ID: <001e01c8800c$587059a0$37c9010a@Net.ARDS.Corp> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001101c8800a$596d4220$37c9010a@Net.ARDS.Corp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach/qQPMwdmhNDt7SEKSSxXiz74OOgAYPJnAAABfT+A= Subject: RE: Path MTU Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 04:33:11 -0000 > > > here comes icmp frag packets. strange what sometimes > > tcpdump complains > > > about tcp header in icmp packet and sometimes not After looking more closely, if found something strange: here is part of tcp header of first large packet: 10:32:04.610317 IP (tos 0x8, ttl 64, id 1208, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . 2064:3432(1368) ack 1666 win 32832 0x0000: 4508 058c 04b8 4000 4006 1a7f 0a17 00f1 E.....@.@....... 0x0010: 0a23 0103 0016 eada 5c06 97bb 6284 63e5 .#......\...b.c. take note of numbers after port numbers:------------------------^^^^^^^^^ And now look at bytes in ICMP packet: 10:32:04.612895 IP (tos 0x0, ttl 254, id 15170, offset 0, flags [none], proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP 10.35.1.3 unreachable - need to frag (mtu 1280), length 36 IP (tos 0x8, ttl 61, id 1208, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: tcp 1396 [bad hdr length 4 - too short, < 20] 0x0000: 4500 0038 3b42 0000 fe01 6761 0a17 0503 E..8;B....ga.... 0x0010: 0a17 00f1 0304 479f 0000 0500 4508 058c ......G.....E... 0x0020: 04b8 4000 3d06 1d7f 0a17 00f1 0a23 0103 ..@.=........#.. 0x0030: 0016 eada c207 0364 .......d here:----------------------^^^^^^^^^ Can they be different? Are they taken into account when doing PathMTU ? From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 05:00:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F6521065671 for ; Fri, 7 Mar 2008 05:00:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by mx1.freebsd.org (Postfix) with ESMTP id ECC5B8FC27 for ; Fri, 7 Mar 2008 05:00:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so426538wxd.7 for ; Thu, 06 Mar 2008 21:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=9XJt123jqDK0ryJnJDSfHr8dKxbqBnPRykKjGsQurQg=; b=bcYu7Ju0Bernzw+Ke7bKFONmCS/1EhPGDmhFONpr0LCylyvba7RQFdEvnKndd4iYeGPC4ExSPSJSVDLd14Z1UNYXz2kbndDCT+Y2iWpBLOMmXsRB92zVRTKrPtr8O30i5cS88CfyxVe1ZxViJQZjOmdf+gvnWeqsMsYmTqcF2GU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=obSPJuIKcYMzhmCNBp0gKrPcbrLH5TvR8DZzmWCyao3g5E736uTJQhXM+d49AGt8ojXw36SoJVxy0+62XSM2PIYYDh3zhtEJF9ixr1tRoJ2dMw8pEuRsIervfLWhA99MMdEvs/xuDOIVV0cGh3GflwJgW7nXrQNMssY3vzlhiMA= Received: by 10.70.49.4 with SMTP id w4mr825136wxw.71.1204866011291; Thu, 06 Mar 2008 21:00:11 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id i13sm6887804wxd.3.2008.03.06.21.00.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 06 Mar 2008 21:00:10 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m27504nd092852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Mar 2008 14:00:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m27504l6092851 for freebsd-net@freebsd.org; Fri, 7 Mar 2008 14:00:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 7 Mar 2008 14:00:04 +0900 From: Pyun YongHyeon To: freebsd-net@freebsd.org Message-ID: <20080307050004.GB92656@cdnetworks.co.kr> References: <20080225091712.GM88015@hal.rescomp.berkeley.edu> <20080226074355.GD47750@cdnetworks.co.kr> <20080228023840.GR58253@hal.rescomp.berkeley.edu> <20080229060353.GC60623@cdnetworks.co.kr> <20080303035728.GD58253@hal.rescomp.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080303035728.GD58253@hal.rescomp.berkeley.edu> User-Agent: Mutt/1.4.2.1i Subject: Re: msk driver issues [was: Re: vlan issues with 7.0-RC3] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 05:00:12 -0000 On Sun, Mar 02, 2008 at 07:57:28PM -0800, Christopher Cowart wrote: > On Fri, Feb 29, 2008 at 03:03:53PM +0900, Pyun YongHyeon wrote: > > On Wed, Feb 27, 2008 at 06:38:40PM -0800, Christopher Cowart wrote: > >>On Tue, Feb 26, 2008 at 04:43:55PM +0900, Pyun YongHyeon wrote: > >>>On Mon, Feb 25, 2008 at 01:17:12AM -0800, Christopher Cowart wrote: > >>>> I have a mac mini running 7.0-RC3, which I'm trying to turn it into a > >>>> router. I have a Linksys SRW2008 "fully managed" (via an IE only web > >>>> interface, ick) switch. > >>>> > >>>> Switch: > >>>> Port 1 - Trunk vlans 10,60,98 - FreeBSD Box > >>>> Port 7 - Access vlan 98 - Existing LAN (192.168.1.0/24) > >>>> > >>>> OpenWRT (192.168.1.1): > >>>> WRT54G box on the Existing LAN > >>>> > >>>> FreeBSD Box: > >>>> ifconfig msk0 up > >>>> ifconfig vlan98 create vlan 98 vlandev msk0 inet 192.168.1.67/24 > >>>> > >>>> With this configuration, I can ping hosts on the other lan segment (Port > >>>> 7). Arp and icmp seem to be quite happy. Unfortunately, I'm not having > >>>> any luck with tcp and udp. Any attempt to ssh to OpenWRT or dig > >>>> @OpenWRT hangs indefinitely. If I do a tcpdump, I see the SYN or A? > >>>> leaving and absolutely no response returning. If I run a tcpdump on > >>>> OpenWRT, I see no incoming traffic. > >>>> > >>>> When I try to connect *to* the FreeBSD box from the other lan segment, I > >>>> continue to have problems. tcpdump shows the SYNs arriving via vlan98 > >>>> and the FreeBSD box responding with SYN-ACK. OpenWRT receives the SYNACK. > >>>> > >>>> I disabled ipfw just to be sure (sysctl -w net.inet.ip.fw.enable=0), but > >>>> it had no effect on the problem. If I connect the FreeBSD box to a vlan > >>>> 98 access port and assign the address to msk0, my connectivity problems > >>>> go away. This leads me to believe that the firewall on OpenWRT is not > >>>> the problem and the problem is related to vlans. > >>>> > >>>> Thinking it was a problem with the not-so-cheap Linksys POS (bitterness > >>>> about the IE web interface again), I plugged my MacBook (running > >>>> Leopard, not FreeBSD) into the trunk port. Running the ifconfig commands > >>>> above (s/msk0/en0/), I got up and running without any problems. This > >>>> causes me to suspect the FreeBSD box. > >>>> > >>>> Does anyone have any idea what's going on here? Any suggestions for > >>>> further troubleshooting? > >>> > >>> Try disabling hardware features one by one in msk(4) and see how > >>> it goes. > >>> o Disable TSO. > >>> o Disable Tx checksum offload. > >>> o Disable VLAN hardware tagging. > >> > >>Works great after `sudo ifconfig msk0 -txcsum'. > >> > >>Is this a known bug, or should I file a PR? Let me know if there are any > >>other details I can provide to help somebody squash it. > > > > Would you capture broken TCP/UDP frames with tcpdump on receiving side > > and show it to me? > > Thanks for your help. I will e-mail you the corresponding tracefile > off-list. I wanted to discuss my initial findings here. > > When the FreeBSD box sends tcp or udp traffic to elsewhere on the > network, it is not seen at the receiving side, not even with bad > checksums. I tried setting up the Linksys device with a port mirror, but > apparently that's only supported on native vlan access ports. Great. > > So, I decided to cross-connect the FreeBSD box with my MacBook. I set up > a vlan interface and was able to reproduce the behavior. I did a traffic > dump on the parent interface (not the vlan interface) on the MacBook, > and noticed that the ethernet frames originating from the FreeBSD box > lacked 802.1q tags. Is it possible that the interface is not performing > the hardware tagging when txcsum is enabled? > Fix committed to HEAD, if_msk.c rev 1.30. > While I have your attention, I am also suffering from a problem that was > reported to -questions here[1]. About 3 times a day, I'll see the > watchdog timeout (missed Tx interrupts) message get logged, after which > point the NIC is useless until I reboot. Any ideas? > > [1] http://lists.freebsd.org/pipermail/freebsd-questions/2008-February/169633.html > I'll have a look. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 07:48:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26C8A1065673 for ; Fri, 7 Mar 2008 07:48:03 +0000 (UTC) (envelope-from _lion_2000@mail.ru) Received: from ards.ru (mail.ards.ru [212.76.164.163]) by mx1.freebsd.org (Postfix) with SMTP id 65A518FC1D for ; Fri, 7 Mar 2008 07:48:01 +0000 (UTC) (envelope-from _lion_2000@mail.ru) Received: (qmail 49089 invoked by uid 0); 7 Mar 2008 12:47:57 +0500 Received: from (10.1.201.55); 7 Mar 2008 07:47:57 -0000 X-lion-scan: 0 X-lion-envelope: F_lion_2000@mail.ru Tfreebsd-net@freebsd.org X-RELAYCLIENT: 1 Received: from wtm-ards-itoa01.net.ards.corp (HELO wtmardsITOA01) (10.1.201.55) by mail.net.ards.corp with SMTP; 7 Mar 2008 12:47:57 +0500 From: "Sergey" <_lion_2000@mail.ru> To: References: <000001c87f43$c8075800$37c9010a@Net.ARDS.Corp><20080306161818.GD15130@verio.net><001101c8800a$596d4220$37c9010a@Net.ARDS.Corp> <001e01c8800c$587059a0$37c9010a@Net.ARDS.Corp> Date: Fri, 7 Mar 2008 12:47:57 +0500 Message-ID: <002001c88027$8f20a3e0$37c9010a@Net.ARDS.Corp> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001e01c8800c$587059a0$37c9010a@Net.ARDS.Corp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Ach/qQPMwdmhNDt7SEKSSxXiz74OOgAYPJnAAABfT+AABwVcIA== Subject: RE: Path MTU Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 07:48:03 -0000 alright, i found who changing packets - it's cisco PIX # tcpdump -s 0 -nveXi stge1 icmp and host 10.23.0.241 tcpdump: WARNING: stge1: no IPv4 address assigned tcpdump: listening on stge1, link-type EN10MB (Ethernet), capture size 65535 bytes this is packet from router with lower mtu just before PIX 10:32:54.775244 00:1c:f6:2e:4b:6f > 00:1d:45:21:a6:51, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 255, id 18463, offset 0, flags [none], proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP 10.35.1.3 unreachable - need to frag (mtu 1280), length 36 (tos 0x8, ttl 61, id 2080, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.64856: tcp 1384 [bad hdr length 16 - too short, < 20] 0x0000: 4500 0038 481f 0000 ff01 5984 0a17 0503 E..8H.....Y..... 0x0010: 0a17 00f1 0304 bdf6 0000 0500 4508 058c ............E... 0x0020: 0820 4000 3d06 1a17 0a17 00f1 0a23 0103 ..@.=........#.. 0x0030: 0016 fd58 2723 1573 ...X'#.s --------------------------^^^^^^^^^^^ note the bytes and this is the same packet _after_ PIX 10:32:54.775492 00:1d:45:21:a6:52 > 00:1b:78:e3:c7:66, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 255, id 18463, offset 0, flags [none], proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP 10.35.1.3 unreachable - need to frag (mtu 1280), length 36 (tos 0x8, ttl 61, id 2080, offset 0, flags [DF], proto: TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.64856: tcp 1400 [bad hdr length 0 - too short, < 20] 0x0000: 4500 0038 481f 0000 ff01 5984 0a17 0503 E..8H.....Y..... 0x0010: 0a17 00f1 0304 a065 0000 0500 4508 058c .......e....E... 0x0020: 0820 4000 3d06 1a17 0a17 00f1 0a23 0103 ..@.=........#.. 0x0030: 0016 fd58 2e89 2b9e ...X..+. ---------------------------^^^^^^^^^ bytes changed and it seems what FreeBSD takes into account not only IPs:Ports data of ICMP FRAG packet, but also these four bytes of tcp header after is that RFC-style behaviour? Who's violating RFC? PIX or BSD? > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Sergey > Sent: Friday, March 07, 2008 9:33 AM > To: freebsd-net@freebsd.org > Subject: RE: Path MTU Problem > > > > > here comes icmp frag packets. strange what sometimes > > > tcpdump complains > > > > about tcp header in icmp packet and sometimes not > > After looking more closely, if found something strange: > > here is part of tcp header of first large packet: > > 10:32:04.610317 IP (tos 0x8, ttl 64, id 1208, offset 0, > flags [DF], proto: > TCP (6), length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: . > 2064:3432(1368) ack 1666 win 32832 38279810 48942931> > 0x0000: 4508 058c 04b8 4000 4006 1a7f 0a17 00f1 > E.....@.@....... > 0x0010: 0a23 0103 0016 eada 5c06 97bb 6284 63e5 > .#......\...b.c. > take note of numbers after > port numbers:------------------------^^^^^^^^^ > > And now look at bytes in ICMP packet: > > 10:32:04.612895 IP (tos 0x0, ttl 254, id 15170, offset 0, > flags [none], > proto: ICMP (1), length: 56) 10.23.5.3 > 10.23.0.241: ICMP > 10.35.1.3 unreachable - need to frag (mtu 1280), length 36 > IP (tos 0x8, ttl 61, id 1208, offset 0, flags [DF], > proto: TCP (6), > length: 1420) 10.23.0.241.22 > 10.35.1.3.60122: tcp 1396 > [bad hdr length 4 > - too short, < 20] > 0x0000: 4500 0038 3b42 0000 fe01 6761 0a17 0503 > E..8;B....ga.... > 0x0010: 0a17 00f1 0304 479f 0000 0500 4508 058c > ......G.....E... > 0x0020: 04b8 4000 3d06 1d7f 0a17 00f1 0a23 0103 > ..@.=........#.. > 0x0030: 0016 eada c207 0364 .......d > here:----------------------^^^^^^^^^ > > Can they be different? Are they taken into account when doing > PathMTU ? > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 08:30:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7BED106566C for ; Fri, 7 Mar 2008 08:30:20 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 17F0A8FC29 for ; Fri, 7 Mar 2008 08:30:19 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JXXy3-0003tX-20 for freebsd-net@freebsd.org; Fri, 07 Mar 2008 08:30:15 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Mar 2008 08:30:15 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Mar 2008 08:30:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Vadim Goncharov Date: Fri, 7 Mar 2008 08:29:58 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 185 Message-ID: References: <58141B67-8B7F-49FE-BC20-2A0B94A589A0@lurchi.franken.de> <645A930A-F67E-465E-8DBB-59FBA4C8593B@lurchi.franken.de> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Michael Tuexen User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: SCTP using questions (API etc.) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 08:30:20 -0000 Hi Michael Tuexen! On Thu, 6 Mar 2008 09:34:13 +0100; Michael Tuexen wrote about 'Re: SCTP using questions (API etc.)': >>>> "substreams". SCTP can do it for me, it's wonderful, but in practice >>>> there >>>> are some questions. >>>> >>>> How long can be one particular SCTP message? Can I rely on the fact >>>> that it >>>> can be unbounded, e.g. I want to emulate a stream with transfer of >>>> 6 Gig-sized file? >>> Protocol wise there is no limitation of the message size. API wise, >>> for >>> this size of a message you need to use the explicit EOR mode to be >>> able >>> to pass this large message using multiple sequential send() calls. >> >> And how should I determine from my/remote stack an optimal size for >> message >> parts when entire message is guaranteed to not fit into buffers/ >> windows of >> both peers? > If the sendbuffer is too small for the message to fit, the send call > will return -1 and errno being set to EMSGSIZE. Or you do it in the > application > by inspecting the sendbuffer size. You do not have to deal with the > recv buffer > of the peer. So this means I need no subscription to unsent messages and simply can try to resend message in several steps without EOR, after getting EMSGSIZE ? >>>> Can a message be of zero-length data (only headers) ? >>> Empty user messages, i.e. a DATA chunk without payload is not >>> allowed. >>> An empty SCTP message, i.e. only the common header without any chunks >>> is allowed and processed by FreeBSD when received, but ever send >>> (well, >>> I do not know a way to force the FreeBSD implementation to send it). >> >> OK, understood. So I should include at least 1 byte of my own >> headers into >> data and do receive into *iov with at least to parts to ensure good >> align >> for non-header part? > What header are you talking about? An application header or any SCTP > header? > You will never receive any SCTP header as part of a user message via > a recv() call. SCTP will give you as much of a message that fits into > the buffer you provide or it has, if the partial delivery API has been > invoked. My applicaion-protocol header, of course. Does this mean also that I should always enable partial delivery on receiving? Or what will happen if received msg is too big and don't fir into my buffers? >>>> What is the relation between SCTP streams in both directions? Can >>>> streams >>>> be opened and closed on-demand, like SSH port forwarding (yet again >>>> multiplexing example) or they are preallocated at connection setup >>>> all >>>> together? What is the minimum number of streams application can rely >>>> upon >>>> (or it just one stream 0 in general case) ? >>> If you restrict to protocols being in RFC status, there is no way of >>> modifying the number of streams during the lifetime of an >>> association. >>> The number of streams in each direction is negotiated during the >>> association setup. The streams in bother directions are completely >>> independent. There is always at least one stream in each direction, >>> which >>> is stream 0. >>> However, there is an extension (currently specified in an Internet >>> Draft) >>> which allows the addition of streams during the lifetime of an >>> association. >>> The ID is at least partially supported by the FreeBSD implementation. >>> https://datatracker.ietf.org/drafts/draft-stewart-sctpstrrst/ >> >> OK. Are there recommended defaults for various stacks about how many >> streams they are creating by default / what maximum of them >> application >> can ever request? > The maximum number to request is 2^16 - 1. It is controllable by the > applications via socket options. Defaults in OSes are in the order of > 10, 16, 32... Can I be sure that every OS can give me maximum number of streams if I request it? >>>> How can I put request to kernel for a connect, for example, and then >>>> sleep >>>> until connect will complete or event in some another descriptor will >>>> occur? >>> If you use the 1-to-1 style API, it should be similar to using TCP. >>> Put the socket in non-blocking mode, enable notifications, >>> call connect() and wait until the fd becomes readable. You should >>> get an >>> indication that that association has been established or could not >>> start. >> >> Yes, that's possible, as I see after reading draft-ietf-tsvwg- >> sctpsocket. >> But several more questions arise. What notifications do I really need >> on 1-to-1 non-blocking socket API mode? What use is 'context' in this >> 1-to-1 context and why after a failed send I must receive entire >> failed >> sent message (which can be very long) instead of just an error code? > The context is something you provide in the send call and is given > back to you. So you can use it to find some state/buffer/whatever again. It was unclear from draft whether context is one per SCTP association or per send call. And what the hell are all that unsent messages, why I must retrieve entire unsent message - can I fire-and-forget a 2M msg and receive only context of it instead of all 2 megs? And on which condition such event can ever occur - with TCP it's simple, I either do write() a number of bytes successfully or receive an error from write() - be that EAGAIN for just blocking of peer's recv() or connection termination error. What concept is under unsent msgs? >> In usual FSM I can use kqueue()/kevent() with arbitrary void* to my >> data, also telling me how many bytes I can read from or write to >> the socket (RCVLOWAT etc.), as well as indicating error/EOF conditions >> so I don't need to do additional syscalls. Is this working with SCTP? > Haven't tried it... Sounds like it would make sense to make sure that > it works. Oh, can you please check it?.. Would be good to support all features described in kqueue(2). >> If I can't write to TCP socket (due to window shortage from peer), >> I leave data in my own application buffers, but SCTP tells something >> about unsent messages delivered later, looks somewhat weird, do I >> really >> need this? Also, all that msg*/cmsg* staff is too complex, and I see >> there are simplier sctp_send()/sctp_sendx() interfaces, will they be >> enough and really simplier for me?.. > sctp_sendx() purpose is to use the multiple addresses provided during > the implicit setup of the association. So I think you are not looking > for Ok. > this. sctp_send() can be used to provide the stream id, payload protocol > identifier and to on with using the CMSG stuff. So you might be looking > for this function. With CMSG? May be you wanted to say 'without' ?.. >>>> How can I put each client to it's fd and then do a kqueue()/kevent() >>>> on a >>>> set of those fd's (and other items) ? It is very handy to have this >>>> architecture as kevent() allows to store an arbitrary void* in it's >>>> structure which I can later use to quickly dispatch events. >>>> >>>> And, of course, all this usual C10K-problem-solving-TCP-server >>>> tricks I want >>>> with basic SCTP SEQPACKET benefits: multiple streams and message >>>> record >>>> separation (I don't need other SCTP features currently). Where can I >>>> find >>>> answers to these questions, like it was with W.R.Stevens books for >>>> TCP ?.. >>> Have you looked at the third edition of 'Unix Network Programming'? >>> Randall Stewart wrote a couple of sections covering SCTP... >> >> Unfortunately, I have only 2nd edition currently available here, >> though >> heard about 3rd, yes. May be several months later... > It is really worth buying if you are interested in SCTP socket > programming... I know, but in my province it is currently unavailable for some months... you know, Siberia, bears walking on the streets :) but it is not critical for actual SCTP programming (TCP version will be debugged first), but I need to take architectural decisions now. Also, are there some examples of real-world SCTP applications with source code available? May be something is getting to integrate into our base system?.. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 13:30:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B4D01065675 for ; Fri, 7 Mar 2008 13:30:06 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5998FC1F for ; Fri, 7 Mar 2008 13:30:05 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1JXceA-0001li-PF for freebsd-net@freebsd.org; Fri, 07 Mar 2008 13:30:02 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Mar 2008 13:30:02 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 07 Mar 2008 13:30:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Vadim Goncharov Followup-To: gmane.os.freebsd.stable Date: Fri, 7 Mar 2008 13:28:07 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 177 Message-ID: References: <20080305083930.Q37745@shell.xecu.net> <20080305160143.GA28941@eos.sc1.parodius.com> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Jeremy Chadwick User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Cc: freebsd-stable@freebsd.org Subject: Re: INET6 -- and why I don't use it X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 13:30:06 -0000 Hi Jeremy Chadwick! On Wed, 5 Mar 2008 08:01:43 -0800; Jeremy Chadwick wrote about 'Re: INET6 -- and why I don't use it': >> Makes it harder to debug, etc. Don't want to see anything IPv6 related in >> command output, to let programs to bind on IPv6 addresses, etc. > Changing the Subject (but keeping the thread ID reference), since the > original topic of discussion has now been skewed. > I have the same attitude Vadim does. Actually, most of my IPv6 fear > isn't so much fear as much as it is annoyance and confusion. Here's > my list of things, as trivial as they may sound (and I guarantee they > will): > * I'm not familiar with the intricacies of the protocol. This is > partially my own fault (lack of interest mainly, combined with lack of > need), while I am very familiar with IPv4. This is technically not an argument, but has an economic effect of training staff. > * The last I read about IPv6 in mainstream news, there were major > concerns cited over some of the security aspects of the protocol. I > also remember reading somewhere that IPv6 was supposed to address issues > like packet spoofing and DoS -- what became of this? > * I have never liked how IPv6 denotes its addresses by using colon- > delimited hexadecimal strings. I can expand on this if asked, but it's > more than just "they're MAC-like" (which is also true, even though > they're grouped by 16-bit values and not octets). Reading off an IPv4 > address over the phone is bad enough, and typos are even worse. IPv6? > Good grief. +100. And this 128 bit length is absolutely unnecessary - 64 bits of it are wasted for EUI-64. Moreover, it was debated whether IPv6 will 64 bit or 128 bit - and everyone switched to 128 bit after this message: http://ftp.sayclub.com/pub/ietf/concluded-wg-ietf-mail-archive/sipp/1994-07 - WITHOUT any discussion. And 64 bit addresses could be much better. But even more, look how easily currently IPb5' /24 and another such big blocks are assigned. Do they want to waste 128 bits?!! > * Consumer ISPs here in the States do not "pass packets" -- you aren't > given a raw pipe; you're given a physical transport with IPv4 service. > The reality here is that the vast majority will not embrace IPv6 until > there's an actual market/need for it. No consumer ISP I know of > delegates a customer an IPv6 IP address or netblock. Backbone providers > support IPv6 now, yup -- and even some peering providers and > datacenter/co-location facilities do. But they're all in the minority. All this is for money. As currently much of hardware don't support IPv6, there will be a big upfrade on switching from IPv4. And this would result in a HUGE money piece flowing to hardware vendors. Of course, they are interested in IPv6. > * The "we're running out of address space" argument doesn't hold > much ground with me. Yes, it's getting tight, but it's not THAT tight. > ARIN very regularly returns large amounts of IPv4 space to the world for > use (I used to be subscribed to NANOG, so I'm aware of this). Want to > do something useful? Start campaigns to get General Electric and MIT to > give up huge portions of 3/8 and 18/8, respectively. This is ARIN's > job, and I sure wouldn't want it. Agreed. > * NAT with IPv4 appears to be "solving" most of the address space issues > in this day and age. I use quotes because it adds extra complexities > at the same time (port forwarding, for example, is an annoying > requirement, mainly because so many protocols were written during the > days when NAT didn't exist, or are simply badly-written protocols (I'm > looking at you, Microsoft)). Only once in my life have I seen a single > network so large that it required use of 192.168/16, 172.16/12, and 10/8 > all at once. Another fact is that NAT is **incredibly** integrated in > consumer society now. The attitude given is "NAT suffices, use it". > Until we can teach people "no, it doesn't suffice, and here's why" and > get people to believe and accept that, it isn't going to change. Not only. The NAT is very important in function of hiding internal network structure, may be even more than address limiting problem. I think it is SO important that some kind of NAT with this function will be created for IPv6. Of course, this means additional money for hardware vendors! > * I don't like incorporating "stuff" into my kernel, my utilities, or > my systems in general which I do not use. I don't want to see an IPv6 > address on my machines or my network. Why? It's about minimalism. I > would gladly "embrace" IPv6 if I had reasons to, but I've none, > therefore I do not. Sure, me too. Not counting an imapct on the link if it is enabled (I'll least some below). > Sufficient? Not sufficient. So I'll list some more IPv6' evils. * Too long address. I said about wasted length for EUI-64 - but it means that MAC address is part of IP address. They could say that it is more handy to not have ARP e.g. for small devices (IP address for your toaster? huh) - but that's device memory will be consumpted by too long address, not arp table. Also, this has a security effect - MAC is globally unique - imagine you've bought a notebook from somebody, received an IP address... and then police discovers that his previous owner is a terrorist or MP3s thief. And not only so - L2/L3 separation in IPv4 is a benefit. Imagine a WWW or DNS server which has changed his IP because of a NIC change. Of course it can use logical address, but problem still actual for ordinary users. * Long addressed have impact on routing. Current /24 prefixes consume significant amount of memeory in BGP full-view. Imagine /48 prefixes and four times larger tables due to longer address, huh? * NAT is absent, but source routing resurrected! What a good thing for hackers! Not only all internal network structure is clear (no NAT), but source routing makes it too complex to secure properly... and every entry is again 128 bit. And this was already exploited - remember SA about IPv6 routing header?... * Fragmentation was eliminated! PMTUD is bad, it was invented before dumb admins blocking ICMP, etc. But with IPv4 you can do ``sysctl net.inet.tcp.path_mtu_discovery=0'' - with IPv6 you can't. But this is crucial for tunnels. IPv6 authors live in 80-ties, with no security, tunnels, etc... * TCP/UDP are left unchanged, with 16 bit ports and 32-bit seq numbers. And if ports are enough yet (some years to future, currently this is imapct only for very specific cases), 32-bit seq numbers already have been attacked. Of course, SCTP can address this, but it will not be popular for several years, and IPv6 is already here. * Yes, what we have now? Now we already have bad security. ICMPv6 Routing Advertisement / Router Solicitation - NO auth. No need to fake DHCP - it is ALWAYS enabled. ARP gone, ARP spoofing is still here. ICMPv6 Neighbor Solicitation / Neighbor Advertisement - you can bomb victim with fake addresses and become a Man-in-the-Middle. Already now, together with not authenticated ICMP redirects (Neighbor Discovery Protoco),tested with Linux and Windows! Can be addressed, of course, but that's YEARS ! Currently the ONLY solution is to disable IPv6 on clients and filter it on routers. * IPSEC ?.. How can you use IKE without first discovering peers' MAC ? That's leads to previous problem. And static keys (the same on all machines, huh?) are problematic. * Again routing. Let' take a tester's workstation with two NICs, internal network is NATed, all is clear on external network. But if you enable forwarding with IPv6, it will participate in Router Solicitation, unecessary. * Can list more and describe previous more precisely, but I'm too lazy to continue :) * So, the only IPv6 benefits are: more address space and not recomputing checksum after TTL change. After all, conclusion is clear - IPv6 is a classical effect of secondary system (remember Brooks' Mythical Man-Month?). It's historical mission is collecting bugs for creating IPv8... It is interesting that in early 90-ies, there were several alternatives, but disappeared, e.g. http://www.ietf.cnri.reston.va.us/proceedings/94mar/charters/sipp-charter.html SIPP lived 03.94 - 08.94 "PIP supported variable length addressing in 16-bit units, separation of addresses from identifiers, support for provider selection, mobility, and efficient forwarding." Looks good, instead of IPv6... And for more than 10 years of developing, with spam and hackers, IPv6 still assumes friendly Internet and non-limited expanding, not even trying to look at basics... Ceterum censeo IPv6 esse delendam! P.S. Disclaimer. My additions are briefly translated from russian at http://netch.livejournal.com/tag/ipv6 -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 16:17:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A95D106566C for ; Fri, 7 Mar 2008 16:17:57 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id 596D98FC20 for ; Fri, 7 Mar 2008 16:17:57 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.mx.meer.net (8.12.10/8.12.6) with ESMTP id m27GHhi3027025; Fri, 7 Mar 2008 08:17:57 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m27GHTiJ036506; Fri, 7 Mar 2008 08:17:29 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from gnnbsd.hudson-trading.com.neville-neil.com (hudson-trading.com [66.150.84.160] (may be forged)) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m27GHSof028182; Fri, 7 Mar 2008 08:17:29 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Fri, 07 Mar 2008 11:17:28 -0500 Message-ID: <7ibq5qecfb.wl%gnn@neville-neil.com> From: "George V. Neville-Neil" To: "Jack Vogel" In-Reply-To: <2a41acea0803031343s6627bebaid8b82353e2619dbf@mail.gmail.com> References: <4793072F.9030909@modulus.org> <2a41acea0801201226t3f7eb2d0qfd12102d1d480529@mail.gmail.com> <47947AD3.2040708@yandex-team.ru> <4794895F.7060402@modulus.org> <479492B6.3080400@yandex-team.ru> <15811130.post@talk.nabble.com> <2a41acea0803031343s6627bebaid8b82353e2619dbf@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/21.3 (amd64--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org, Oznon Subject: Re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 16:17:57 -0000 At Mon, 3 Mar 2008 13:43:45 -0800, Jack Vogel wrote: > > The fix to this problem is in the new shared code that got checked into > CURRENT on Friday. I will be MFCing the changes eventually but > if you want to test now you'll need to go with CURRENT. > Rockin. Will this go into 6 as well or is that too far different now? Thanks, George From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 17:35:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AF521065673 for ; Fri, 7 Mar 2008 17:35:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1778FC26 for ; Fri, 7 Mar 2008 17:35:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so606818wfa.7 for ; Fri, 07 Mar 2008 09:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=c9wQCl7oGlMyIabGpx4nfxHBmfhek1bgFI4Q98LIII0=; b=CYxYAgKj4OMhT6dul4VQJirHcAhV5Xg7U+a7NQdy0RNsa+evrsYhRrhhRXKQTNtWImlPmofOBKRtP9KEF3pmOpt6EVlFc5BIDkHpcoTMwmJ1NxFSAMNtipvKtf7FipJQ3E7HH5zKTZ3zefynKeSlukmm2GTG2nedRZ1RvSdXWus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KmIE3iPb1cvi0zhw68Ioud8ljybCw3LNgqL1t2Vi7ZL2m/k2zKnXI382jmh8JxjF0tpbONNs0nf9G2S2FsGRnJzlQtWmYUfMZQpbU44G4bVZgNHr66Bmap2vYexh7sV1wS5gXdGfViqSlIJlMZE5f9WQtzRgBB+qnkX/IkIYrWk= Received: by 10.142.84.3 with SMTP id h3mr860855wfb.34.1204911332962; Fri, 07 Mar 2008 09:35:32 -0800 (PST) Received: by 10.114.177.4 with HTTP; Fri, 7 Mar 2008 09:35:32 -0800 (PST) Message-ID: <2a41acea0803070935v6e89fb7bm7bb565dc3d3d622f@mail.gmail.com> Date: Fri, 7 Mar 2008 09:35:32 -0800 From: "Jack Vogel" To: "George V. Neville-Neil" In-Reply-To: <7ibq5qecfb.wl%gnn@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4793072F.9030909@modulus.org> <2a41acea0801201226t3f7eb2d0qfd12102d1d480529@mail.gmail.com> <47947AD3.2040708@yandex-team.ru> <4794895F.7060402@modulus.org> <479492B6.3080400@yandex-team.ru> <15811130.post@talk.nabble.com> <2a41acea0803031343s6627bebaid8b82353e2619dbf@mail.gmail.com> <7ibq5qecfb.wl%gnn@neville-neil.com> Cc: freebsd-net@freebsd.org, Oznon Subject: Re: 7.0-RC1 onboard em1 intel pro1000 vanishing occasionally X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 17:35:33 -0000 I should be able to get the shared code part into 6.3 once problems are wrung out. Jack On Fri, Mar 7, 2008 at 8:17 AM, George V. Neville-Neil wrote: > At Mon, 3 Mar 2008 13:43:45 -0800, > > Jack Vogel wrote: > > > > The fix to this problem is in the new shared code that got checked into > > CURRENT on Friday. I will be MFCing the changes eventually but > > if you want to test now you'll need to go with CURRENT. > > > > Rockin. Will this go into 6 as well or is that too far different now? > > Thanks, > George > From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 23:20:02 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7333B1065671 for ; Fri, 7 Mar 2008 23:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 62B0A8FC13 for ; Fri, 7 Mar 2008 23:20:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m27NK2jR058156 for ; Fri, 7 Mar 2008 23:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m27NK2uL058131; Fri, 7 Mar 2008 23:20:02 GMT (envelope-from gnats) Date: Fri, 7 Mar 2008 23:20:02 GMT Message-Id: <200803072320.m27NK2uL058131@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bruce Cran Cc: Subject: Re: kern/92552: A serious bug in most network drivers from 5.X to 6.X (regression) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Cran List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 23:20:02 -0000 The following reply was made to PR kern/92552; it has been noted by GNATS. From: Bruce Cran To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/92552: A serious bug in most network drivers from 5.X to 6.X (regression) Date: Fri, 07 Mar 2008 23:18:23 +0000 Hi, Sorry it's taken such a long time to get around to looking at this problem report. I'm not very familiar with the network code but from looking at if_em.c it appears that a dual locking implementation was added in rev 1.65.2.28 (FreeBSD 6.3) so that the core lock is held by both the ioctl and interrupt handlers and so this problems should no longer occur. However, the _CORE_LOCK macros are only used in if_em so unless the problem has been fixed in the other network drivers this problem will still exist. Do you remember which other network drivers are affected? Thanks, Bruce From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 23:23:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FD411065673; Fri, 7 Mar 2008 23:23:03 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 25FB58FC1D; Fri, 7 Mar 2008 23:23:03 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m27NN3HQ058420; Fri, 7 Mar 2008 23:23:03 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m27NN3v3058416; Fri, 7 Mar 2008 23:23:03 GMT (envelope-from vwe) Date: Fri, 7 Mar 2008 23:23:03 GMT Message-Id: <200803072323.m27NN3v3058416@freefall.freebsd.org> To: liangyi571@hotmail.com, vwe@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/92552: A serious bug in most network drivers from 5.X to 6.X (regression) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 23:23:03 -0000 Synopsis: A serious bug in most network drivers from 5.X to 6.X (regression) State-Changed-From-To: open->feedback State-Changed-By: vwe State-Changed-When: Fri Mar 7 23:22:40 UTC 2008 State-Changed-Why: Note that submitter has been asked for feedback. http://www.freebsd.org/cgi/query-pr.cgi?pr=92552 From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 23:24:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74B261065670 for ; Fri, 7 Mar 2008 23:24:14 +0000 (UTC) (envelope-from rizzojake@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA5E8FC22 for ; Fri, 7 Mar 2008 23:24:13 +0000 (UTC) (envelope-from rizzojake@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so809273wxd.7 for ; Fri, 07 Mar 2008 15:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=EE/AGndkZLdL9QGMjZWmwr8eh5YmqBguPB4OGWxWSBY=; b=Pt2uIVWayrBsRFVOpSUkACHIgdc2eh3oXGtsQ+pTCrOE60/xzlCJvHjk47MdVHUAJNKDL0cr5L6lqCvRxQ1IQSi15EcP54xAVeEq1gbh8kH6/Fht4zx6jun9XFhXYg88Qt1/gGds8EVRS7kx48B1yc/agqa3Gg834dPd7Vao2h4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=w5MNRxxHYIAk1BiAUBs0BJUPafr1Nj8yBLZPV7nRlLxT/bWnr7pUIdRfsT1LhtXzGaId9mJiOlu29lZfsY/qd+EBvq/MfWSpOWBY4cekHgMOte5erGNxh+qMmx0YukKz/ylZw9p3hLcVKZlfKjebWA89pW7/uJQTTCKZ56qWJNk= Received: by 10.140.128.11 with SMTP id a11mr1095964rvd.232.1204930556142; Fri, 07 Mar 2008 14:55:56 -0800 (PST) Received: by 10.141.22.11 with HTTP; Fri, 7 Mar 2008 14:55:56 -0800 (PST) Message-ID: Date: Fri, 7 Mar 2008 22:55:56 +0000 From: "Jake Rizzo" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: RELENG-7 tcp connectivity problems with certain clients X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 23:24:14 -0000 Hi, I had two 6.3-STABLE boxen which have been happily running away for months on end now without any problems. Last week I upgraded (via buildworld) both boxes to 7.0-STABLE. Since then I've had reports of some clients being unable to connect via tcp. I've seen this happen first hand on an affected remote machine. Traceroute & ping gets to the machine just fine but connecting to an open tcp port on the machine just times out. The remote box was a XP machine and so I didn't have the luxury of tcp dump on that end, however I did get a chance to run it at the freebsd end: 16:04:31.445390 IP (tos 0x20, ttl 109, id 41184, offset 0, flags [DF], proto TCP (6), length 48) xxxxx.comcastbusiness.net.22625 > 192.168.1.104.http: S, cksum 0x81e2 (correct), 3539746141:3539746141(0) win 16384 16:04:31.445405 IP (tos 0x0, ttl 64, id 55077, offset 0, flags [DF], proto TCP (6), length 48, bad cksum 0 (->b21)!) 192.168.1.104.http > xxxxx.comcastbusiness.net.22625: S, cksum 0x58a4 (incorrect (-> 0x8f6e), 152644170:152644170(0) ack 3539746142 win 65535 16:04:34.444871 IP (tos 0x0, ttl 64, id 56095, offset 0, flags [DF], proto TCP (6), length 48, bad cksum 0 (->727)!) 192.168.1.104.http > xxxxx.comcastbusiness.net.22625: S, cksum 0x58a4 (incorrect (-> 0x8f6e), 152644170:152644170(0) ack 3539746142 win 65535 16:04:40.444521 IP (tos 0x0, ttl 64, id 57587, offset 0, flags [DF], proto TCP (6), length 48, bad cksum 0 (->153)!) 192.168.1.104.http > xxxxx.comcastbusiness.net.22625: S, cksum 0x58a4 (incorrect (-> 0x8f6e), 152644170:152644170(0) ack 3539746142 win 65535 It seems the the tcp handshake is not happening for one reason or another. I downgraded one of the boxes back to 6.3-STABLE and now the same client's connectivity issues disappeared. Has anyone any ideas of where to look? I'd really like to stay on 7.0-STABLE if I can because of the performance increase! Here's some additional configuration details: Ifconfig output: bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:e0:81:33:48:f6 inet 192.168.1.197 netmask 0xffffff00 broadcast 192.168.1.255 inet 192.168.1.104 netmask 0xffffffff broadcast 192.168.1.104 media: Ethernet autoselect (100baseTX ) status: active dmesg| grep bge0: bge0: mem 0xfc9c0000-0xfc9cffff,0xfc9b0000-0xfc9bffff irq 24 at device 9.0 on pci2 miibus0: on bge0 bge0: Ethernet address: 00:e0:81:33:48:f6 bge0: [ITHREAD] I have a few network related sysctl's defined since 6.3-STABLE too: security.bsd.see_other_uids=0 net.inet.icmp.icmplim=50 kern.ipc.somaxconn=12768 net.inet.udp.blackhole=1 net.inet.tcp.blackhole=2 net.inet.tcp.msl=7500 Any help would be greatly appreciated. Thanks, Regards, Jerry From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 23:52:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C281065675 for ; Fri, 7 Mar 2008 23:52:42 +0000 (UTC) (envelope-from silby@silby.com) Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by mx1.freebsd.org (Postfix) with SMTP id A70C78FC1E for ; Fri, 7 Mar 2008 23:52:41 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 29545 invoked by uid 3193); 7 Mar 2008 23:52:40 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Mar 2008 23:52:40 -0000 Date: Fri, 7 Mar 2008 18:52:39 -0500 (EST) From: Mike Silbersack X-X-Sender: silby@niwun.pair.com To: Jake Rizzo In-Reply-To: Message-ID: <20080307185203.J27119@niwun.pair.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: RELENG-7 tcp connectivity problems with certain clients X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 23:52:42 -0000 On Fri, 7 Mar 2008, Jake Rizzo wrote: > Hi, > > I had two 6.3-STABLE boxen which have been happily running away for months > on end now without any problems. Last week I upgraded (via buildworld) both > boxes to 7.0-STABLE. Since then I've had reports of some clients being > unable to connect via tcp. I've seen this happen first hand on an affected > remote machine. Traceroute & ping gets to the machine just fine > but connecting to an open tcp port on the machine just times out. The > remote box was a XP machine and so I didn't have the luxury of tcp dump on > that end, however I did get a chance to run it at the freebsd end: Try this change; it was too late to be put in 7.0, but it will be merged to 7-stable in a few days: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_var.h.diff?r1=1.160;r2=1.161 -Mike From owner-freebsd-net@FreeBSD.ORG Fri Mar 7 23:53:38 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21952106567A for ; Fri, 7 Mar 2008 23:53:38 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by mx1.freebsd.org (Postfix) with ESMTP id F38B38FC30 for ; Fri, 7 Mar 2008 23:53:37 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 1JXmNd-0007Ru-Gw for freebsd-net@freebsd.org; Fri, 07 Mar 2008 23:53:37 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp3.email.verio.net with esmtp id 1JXmNd-0000wQ-Cu for freebsd-net@freebsd.org; Fri, 07 Mar 2008 23:53:37 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id 491608E296; Fri, 7 Mar 2008 17:53:37 -0600 (CST) Date: Fri, 7 Mar 2008 17:53:37 -0600 From: David DeSimone To: freebsd-net@freebsd.org Message-ID: <20080307235336.GB16791@verio.net> Mail-Followup-To: freebsd-net@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: RELENG-7 tcp connectivity problems with certain clients X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2008 23:53:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jake Rizzo wrote: > > 16:04:31.445390 IP (tos 0x20, ttl 109, id 41184, offset 0, flags [DF], proto > TCP (6), length 48) xxxxx.comcastbusiness.net.22625 > 192.168.1.104.http: S, > cksum 0x81e2 (correct), 3539746141:3539746141(0) win 16384 1380,nop,nop,sackOK> > 16:04:31.445405 IP (tos 0x0, ttl 64, id 55077, offset 0, flags [DF], proto > TCP (6), length 48, bad cksum 0 (->b21)!) 192.168.1.104.http > > xxxxx.comcastbusiness.net.22625: S, cksum 0x58a4 (incorrect (-> 0x8f6e), tcpdump is pointing out some bad checksums in your outgoing packets. Maybe you should try ifconfig -txcsum? - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFH0dWAFSrKRjX5eCoRAsHaAKCVgiF/mYtzNCfh/UDpPRLfh49+4ACdEbNi xCNLaoT01jm/ovz/cGyXUvQ= =Oy/W -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Sat Mar 8 00:23:37 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 823431065671; Sat, 8 Mar 2008 00:23:37 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 58E708FC15; Sat, 8 Mar 2008 00:23:37 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m280Nbup062998; Sat, 8 Mar 2008 00:23:37 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m280NbLo062994; Sat, 8 Mar 2008 00:23:37 GMT (envelope-from vwe) Date: Sat, 8 Mar 2008 00:23:37 GMT Message-Id: <200803080023.m280NbLo062994@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/35442: [sis] [patch] Problem transmitting runts in if_sis driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 00:23:37 -0000 Synopsis: [sis] [patch] Problem transmitting runts in if_sis driver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sat Mar 8 00:21:57 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). Please have a look at it. Thx! http://www.freebsd.org/cgi/query-pr.cgi?pr=35442 From owner-freebsd-net@FreeBSD.ORG Sat Mar 8 00:40:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1F65106566C for ; Sat, 8 Mar 2008 00:40:19 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 785AF8FC1D for ; Sat, 8 Mar 2008 00:40:19 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-25-183.bredband.comhem.se ([83.253.25.183]:49754 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1JXmrv-0003nt-7f for freebsd-net@freebsd.org; Sat, 08 Mar 2008 01:24:55 +0100 Received: (qmail 80760 invoked from network); 8 Mar 2008 01:24:52 +0100 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 8 Mar 2008 01:24:52 +0100 Received: (qmail 96342 invoked by uid 1001); 8 Mar 2008 01:24:52 +0100 Date: Sat, 8 Mar 2008 01:24:52 +0100 From: Erik Trulsson To: freebsd-net@freebsd.org Message-ID: <20080308002451.GA96289@owl.midgard.homeip.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20080307235336.GB16791@verio.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080307235336.GB16791@verio.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Originating-IP: 83.253.25.183 X-Scan-Result: No virus found in message 1JXmrv-0003nt-7f. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1JXmrv-0003nt-7f 5a0c2e33cd32e8f4d852e6c0ed2d68ac Subject: Re: RELENG-7 tcp connectivity problems with certain clients X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 00:40:19 -0000 On Fri, Mar 07, 2008 at 05:53:37PM -0600, David DeSimone wrote: > Jake Rizzo wrote: > > > > 16:04:31.445390 IP (tos 0x20, ttl 109, id 41184, offset 0, flags [DF], proto > > TCP (6), length 48) xxxxx.comcastbusiness.net.22625 > 192.168.1.104.http: S, > > cksum 0x81e2 (correct), 3539746141:3539746141(0) win 16384 > 1380,nop,nop,sackOK> > > 16:04:31.445405 IP (tos 0x0, ttl 64, id 55077, offset 0, flags [DF], proto > > TCP (6), length 48, bad cksum 0 (->b21)!) 192.168.1.104.http > > > xxxxx.comcastbusiness.net.22625: S, cksum 0x58a4 (incorrect (-> 0x8f6e), > > tcpdump is pointing out some bad checksums in your outgoing packets. Yes, of course it does, since tcpdump sees the packet before the card has filled in the checksum. This will always happen whenever you use tcpdump with a NIC that has hardware checksums enabled. > > Maybe you should try ifconfig -txcsum? -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-net@FreeBSD.ORG Sat Mar 8 03:40:30 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD1D9106566C; Sat, 8 Mar 2008 03:40:30 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8401E8FC1D; Sat, 8 Mar 2008 03:40:30 +0000 (UTC) (envelope-from vwe@FreeBSD.org) Received: from freefall.freebsd.org (vwe@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m283eUcU078366; Sat, 8 Mar 2008 03:40:30 GMT (envelope-from vwe@freefall.freebsd.org) Received: (from vwe@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m283eUQ9078362; Sat, 8 Mar 2008 03:40:30 GMT (envelope-from vwe) Date: Sat, 8 Mar 2008 03:40:30 GMT Message-Id: <200803080340.m283eUQ9078362@freefall.freebsd.org> To: vwe@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: vwe@FreeBSD.org Cc: Subject: Re: kern/120232: [nfe] [patch] Bring in nfe(4) to RELENG_6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 03:40:30 -0000 Synopsis: [nfe] [patch] Bring in nfe(4) to RELENG_6 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: vwe Responsible-Changed-When: Sat Mar 8 03:40:09 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=120232 From owner-freebsd-net@FreeBSD.ORG Sat Mar 8 05:53:53 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69D64106566B; Sat, 8 Mar 2008 05:53:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3FF6A8FC15; Sat, 8 Mar 2008 05:53:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m285rrEp090867; Sat, 8 Mar 2008 05:53:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m285rrri090863; Sat, 8 Mar 2008 05:53:53 GMT (envelope-from linimon) Date: Sat, 8 Mar 2008 05:53:53 GMT Message-Id: <200803080553.m285rrri090863@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/121437: [vlan] Routing to layer-2 address does not work on VLAN interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 05:53:53 -0000 Old Synopsis: Routing to layer-2 address does not work on VLAN interface New Synopsis: [vlan] Routing to layer-2 address does not work on VLAN interface Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 8 05:53:10 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121437 From owner-freebsd-net@FreeBSD.ORG Sat Mar 8 06:02:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0BCE1065670; Sat, 8 Mar 2008 06:02:04 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 873E58FC1B; Sat, 8 Mar 2008 06:02:04 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m28624Oa091310; Sat, 8 Mar 2008 06:02:04 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m28624gu091306; Sat, 8 Mar 2008 06:02:04 GMT (envelope-from linimon) Date: Sat, 8 Mar 2008 06:02:04 GMT Message-Id: <200803080602.m28624gu091306@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/121443: [gif] LOR icmp6_input/nd6_lookup X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 06:02:05 -0000 Old Synopsis: LOR icmp6_input/nd6_lookup New Synopsis: [gif] LOR icmp6_input/nd6_lookup Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 8 06:01:35 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=121443 From owner-freebsd-net@FreeBSD.ORG Sat Mar 8 06:23:28 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EC771065673 for ; Sat, 8 Mar 2008 06:23:28 +0000 (UTC) (envelope-from kotak_surat_iyus@yahoo.com) Received: from web63414.mail.re1.yahoo.com (web63414.mail.re1.yahoo.com [69.147.97.54]) by mx1.freebsd.org (Postfix) with SMTP id C0E848FC1D for ; Sat, 8 Mar 2008 06:23:27 +0000 (UTC) (envelope-from kotak_surat_iyus@yahoo.com) Received: (qmail 92648 invoked by uid 60001); 8 Mar 2008 06:23:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=T+2yQZVQjSvWp85KDjAb2x/bZsZw9PthxeqimMU4FrPBbK+nnPkTsVEKmarGq0N3RqRcDYWZIQnb6dh/y7SdZ9j0r/4T3zBWmt14KlUmrtruR2Nwxft5FbB5DKlpG8mRD+wKyIXx/qjAdUrGj11c4wiYhZTSfLteWL2Cjj/OiB8=; X-YMail-OSG: 6qFH89EVM1nxKmq2aZGNo0cA_ohD.IwuBIWk5zgqP6JvCAoin2Oi5iXcjd8czgw2hJX6D9kkbne68EfArD_PsWWXFzBl0h9B.3f1IhA1IbUYQb49jurua7RTlHicToJCLuhuvL54ZVz27PEYVSQjXltb Received: from [125.163.77.146] by web63414.mail.re1.yahoo.com via HTTP; Fri, 07 Mar 2008 22:23:26 PST X-Mailer: YahooMailRC/902.35 YahooMailWebService/0.7.162 Date: Fri, 7 Mar 2008 22:23:26 -0800 (PST) From: iyus supriatna To: freebsd-net@freebsd.org MIME-Version: 1.0 Message-ID: <770281.92187.qm@web63414.mail.re1.yahoo.com> X-Mailman-Approved-At: Sat, 08 Mar 2008 12:24:04 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: help me X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 06:23:28 -0000 dear all,=0Asory if my english is false=0A=0Ai want to ask how to build voi= p in free BSD please... and the complete how to, if you don't mind he he he= ...=0A=0A=0A=0ASend instant messages to your online friends http://uk.messe= nger.yahoo.com From owner-freebsd-net@FreeBSD.ORG Sat Mar 8 20:27:23 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 816FD1065674; Sat, 8 Mar 2008 20:27:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 709798FC1E; Sat, 8 Mar 2008 20:27:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (rwatson@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m28KRNCX061699; Sat, 8 Mar 2008 20:27:23 GMT (envelope-from rwatson@freefall.freebsd.org) Received: (from rwatson@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m28KRMj8061695; Sat, 8 Mar 2008 20:27:22 GMT (envelope-from rwatson) Date: Sat, 8 Mar 2008 20:27:22 GMT Message-Id: <200803082027.m28KRMj8061695@freefall.freebsd.org> To: johan@nocrew.org, rwatson@FreeBSD.org, freebsd-net@FreeBSD.org From: rwatson@FreeBSD.org Cc: Subject: Re: kern/95665: [if_tun] "ping: sendto: No buffer space available" with TUN interface (easily reproducable with test program) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 20:27:23 -0000 Synopsis: [if_tun] "ping: sendto: No buffer space available" with TUN interface (easily reproducable with test program) State-Changed-From-To: suspended->closed State-Changed-By: rwatson State-Changed-When: Sat Mar 8 20:24:15 UTC 2008 State-Changed-Why: Closing the PR as it appears that any bug in if_tun queue handling has now been resolved. If you are still able to reproduce a *permanent* hang in processing of if_tun under load, please let us know; temporarily returning ENOBUFS when things get full due to the user process falling behind is expected. Note that some other operating systems return success rather than ENOBUFS for datagram send to an interface with a full send queue, so if you see ENOBUFS only on FreeBSD (and not, say, Linux), this doesn't mean it's a bug. If you reply with further information confirming a problem on a recent (FreeBSD 6.3, 7.0) version, I can re-open the PR and investigate further. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=95665 From owner-freebsd-net@FreeBSD.ORG Sat Mar 8 20:58:53 2008 Return-Path: Delivered-To: net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEB63106566B; Sat, 8 Mar 2008 20:58:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 94F218FC12; Sat, 8 Mar 2008 20:58:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from freefall.freebsd.org (rwatson@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m28KwrsO064890; Sat, 8 Mar 2008 20:58:53 GMT (envelope-from rwatson@freefall.freebsd.org) Received: (from rwatson@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m28Kwr10064886; Sat, 8 Mar 2008 20:58:53 GMT (envelope-from rwatson) Date: Sat, 8 Mar 2008 20:58:53 GMT Message-Id: <200803082058.m28Kwr10064886@freefall.freebsd.org> To: rwatson@FreeBSD.org, freebsd-bugs@FreeBSD.org, net@FreeBSD.org From: rwatson@FreeBSD.org Cc: Subject: Re: kern/93378: [tcp] Slow data transfer in Postfix and Cyrus IMAP (workaround known) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 20:58:53 -0000 Synopsis: [tcp] Slow data transfer in Postfix and Cyrus IMAP (workaround known) Responsible-Changed-From-To: freebsd-bugs->net Responsible-Changed-By: rwatson Responsible-Changed-When: Sat Mar 8 20:58:36 UTC 2008 Responsible-Changed-Why: Over to maintainers. http://www.freebsd.org/cgi/query-pr.cgi?pr=93378 From owner-freebsd-net@FreeBSD.ORG Sat Mar 8 22:00:08 2008 Return-Path: Delivered-To: net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 075451065671 for ; Sat, 8 Mar 2008 22:00:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EAB608FC1D for ; Sat, 8 Mar 2008 22:00:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m28M07g9069831 for ; Sat, 8 Mar 2008 22:00:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m28M07bZ069830; Sat, 8 Mar 2008 22:00:07 GMT (envelope-from gnats) Date: Sat, 8 Mar 2008 22:00:07 GMT Message-Id: <200803082200.m28M07bZ069830@freefall.freebsd.org> To: net@FreeBSD.org From: Anton Yuzhaninov Cc: Subject: Re: kern/93378: [tcp] Slow data transfer in Postfix and Cyrus IMAP (workaround known) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anton Yuzhaninov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 22:00:08 -0000 The following reply was made to PR kern/93378; it has been noted by GNATS. From: Anton Yuzhaninov To: bug-followup@FreeBSD.org, jollyroger@one.lv Cc: Subject: Re: kern/93378: [tcp] Slow data transfer in Postfix and Cyrus IMAP (workaround known) Date: Sun, 09 Mar 2008 00:43:45 +0300 Probably it is interact between delayed ack and Nagle's algorithm. They shouldn't be used together: http://developers.slashdot.org/comments.pl?sid=174457&cid=14515105 So application which may be affected by this problem should disable Nagle's algorithm for via socket option TCP_NODELAY. As I can see current postfix uses setsockopt TCP_NODELAY so consider to upgrade postfix to 2.4.7 or 2.5.1 first. Postifx 2.2.8 is too old. -- WBR, Anton Yuzhaninov From owner-freebsd-net@FreeBSD.ORG Sat Mar 8 22:39:05 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39E6E106567A; Sat, 8 Mar 2008 22:39:05 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 103F38FC1C; Sat, 8 Mar 2008 22:39:05 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (bz@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m28Md4Ca073674; Sat, 8 Mar 2008 22:39:04 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m28Md4ku073670; Sat, 8 Mar 2008 22:39:04 GMT (envelope-from bz) Date: Sat, 8 Mar 2008 22:39:04 GMT Message-Id: <200803082239.m28Md4ku073670@freefall.freebsd.org> To: crahman@gmail.com, bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/121384: [ipsec] New IPSEC fails to obey policy levels X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 22:39:05 -0000 Synopsis: [ipsec] New IPSEC fails to obey policy levels State-Changed-From-To: open->feedback State-Changed-By: bz State-Changed-When: Sat Mar 8 22:38:07 UTC 2008 State-Changed-Why: A patch was presented for testing. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Sat Mar 8 22:38:07 UTC 2008 Responsible-Changed-Why: Take this one, as I have a patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=121384 From owner-freebsd-net@FreeBSD.ORG Sat Mar 8 23:05:14 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C4691065671; Sat, 8 Mar 2008 23:05:14 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D60218FC14; Sat, 8 Mar 2008 23:05:13 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (bz@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m28N5D8Z075124; Sat, 8 Mar 2008 23:05:13 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m28N5DkU075120; Sat, 8 Mar 2008 23:05:13 GMT (envelope-from bz) Date: Sat, 8 Mar 2008 23:05:13 GMT Message-Id: <200803082305.m28N5DkU075120@freefall.freebsd.org> To: crahman@gmail.com, bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/121374: [ipsec] SP refcnt increases with each packet in ipv6 with new IPSEC X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 23:05:14 -0000 Synopsis: [ipsec] SP refcnt increases with each packet in ipv6 with new IPSEC State-Changed-From-To: open->feedback State-Changed-By: bz State-Changed-When: Sat Mar 8 23:03:52 UTC 2008 State-Changed-Why: Wait for feedback if the patch presented is fine. Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Sat Mar 8 23:03:52 UTC 2008 Responsible-Changed-Why: Take this. I have a patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=121374 From owner-freebsd-net@FreeBSD.ORG Sat Mar 8 23:07:16 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C186C106566B; Sat, 8 Mar 2008 23:07:16 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9878F8FC19; Sat, 8 Mar 2008 23:07:16 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (bz@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m28N7G70075177; Sat, 8 Mar 2008 23:07:16 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m28N7Grc075173; Sat, 8 Mar 2008 23:07:16 GMT (envelope-from bz) Date: Sat, 8 Mar 2008 23:07:16 GMT Message-Id: <200803082307.m28N7Grc075173@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-net@FreeBSD.org, bz@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/121373: [ipsec] New IPSEC & IPV6 & AH+ESP Broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2008 23:07:16 -0000 Synopsis: [ipsec] New IPSEC & IPV6 & AH+ESP Broken Responsible-Changed-From-To: freebsd-net->bz Responsible-Changed-By: bz Responsible-Changed-When: Sat Mar 8 23:06:45 UTC 2008 Responsible-Changed-Why: Take this. Might take a few days before I can come up with a patch. http://www.freebsd.org/cgi/query-pr.cgi?pr=121373