From owner-freebsd-net@FreeBSD.ORG Sun Sep 18 00:40:13 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 612E816A41F for ; Sun, 18 Sep 2005 00:40:13 +0000 (GMT) (envelope-from fergus@cobbled.net) Received: from ni-mail3.dna.utvinternet.net (mail3.u.tv [194.46.8.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8E7043D48 for ; Sun, 18 Sep 2005 00:40:12 +0000 (GMT) (envelope-from fergus@cobbled.net) Received: from mail.cobbled.net (unverified [195.218.107.228]) by ni-mail3.dna.utvinternet.net (Vircom SMTPRS 4.1.361.20) with ESMTP id for ; Sun, 18 Sep 2005 01:40:07 +0100 Received: from eyore.cobbled.net (localhost [127.0.0.1]) by mail.cobbled.net (8.12.10/8.12.10) with ESMTP id j8I0dom7007624 for ; Sun, 18 Sep 2005 01:39:52 +0100 (BST) (envelope-from fergus@eyore.public.cobbled.net) Received: (from fergus@localhost) by eyore.cobbled.net (8.12.10/8.12.10/Submit) id j8I0dkVi007623 for freebsd-net@freebsd.org; Sun, 18 Sep 2005 01:39:46 +0100 (BST) (envelope-from fergus) Date: Sun, 18 Sep 2005 01:39:46 +0100 From: n0g0013 To: freebsd-net@freebsd.org Message-ID: <20050918003946.GM6440@eyore.cobbled.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: the purpose/use of "opt_netgraph.h" ? 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, 18 Sep 2005 00:40:13 -0000 could anybody enlighten me as to the purpose of the "opt_netgraph.h" dependancy in a netgraph module? got some errors, added it to SRCS and it gets generated as an empty file. think there is a minimal one in "sr" driver but can't guess it's intent. -- t t w From owner-freebsd-net@FreeBSD.ORG Sun Sep 18 15:45:39 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DFED16A420 for ; Sun, 18 Sep 2005 15:45:39 +0000 (GMT) (envelope-from mshindo@mshindo.net) Received: from ober.mshindo.net (221x245x168x210.ap221.ftth.ucom.ne.jp [221.245.168.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C15B43D6A for ; Sun, 18 Sep 2005 15:45:34 +0000 (GMT) (envelope-from mshindo@mshindo.net) Received: from localhost (221x245x168x211.ap221.ftth.ucom.ne.jp [221.245.168.211]) by ober.mshindo.net (Postfix) with ESMTP id 8856E336423 for ; Mon, 19 Sep 2005 00:52:27 +0900 (JST) Date: Mon, 19 Sep 2005 00:45:31 +0900 (JST) Message-Id: <20050919.004531.92589257.mshindo@mshindo.net> To: freebsd-net@freebsd.org From: Motonori Shindo X-Mailer: Mew version 4.1.53 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: ARP behavior in FreeBSD vs Linux 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, 18 Sep 2005 15:45:39 -0000 On FreeBSD (and I guess most Operating Systems as well), ARP reply is sent back only when the target IP address in ARP request matches with one of the IP addresses assigned to the interface through which the ARP Request is received. In contrast, on Linux (by default), it responds as long as the target IP address in ARP Request matches with any "local" IP address on the system, which is not necessarily an IP address assigned to the interface through which the ARP request is received. Is there any advantage/disadvantage in ARP implementation on FreeBSD over that of Linux? Thanks. Regards, Motonori Shindo From owner-freebsd-net@FreeBSD.ORG Sun Sep 18 16:14:02 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63C8D16A41F for ; Sun, 18 Sep 2005 16:14:02 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04DC743D45 for ; Sun, 18 Sep 2005 16:14:01 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 79BF95D8C; Sun, 18 Sep 2005 12:14:01 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04044-02; Sun, 18 Sep 2005 12:14:00 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-68-11.ny325.east.verizon.net [68.161.68.11]) by pi.codefab.com (Postfix) with ESMTP id BCFE85C70; Sun, 18 Sep 2005 12:13:59 -0400 (EDT) Message-ID: <432D9249.9090202@mac.com> Date: Sun, 18 Sep 2005 12:14:01 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Motonori Shindo References: <20050919.004531.92589257.mshindo@mshindo.net> In-Reply-To: <20050919.004531.92589257.mshindo@mshindo.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-net@freebsd.org Subject: Re: ARP behavior in FreeBSD vs Linux 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, 18 Sep 2005 16:14:02 -0000 Motonori Shindo wrote: > On FreeBSD (and I guess most Operating Systems as well), ARP reply is > sent back only when the target IP address in ARP request matches with > one of the IP addresses assigned to the interface through which the > ARP Request is received. This is correct behavior. Normally, you should only be able to ARP an IP address which is on an interface connected to that subnet. > In contrast, on Linux (by default), it > responds as long as the target IP address in ARP Request matches with > any "local" IP address on the system, which is not necessarily an IP > address assigned to the interface through which the ARP request is > received. This sounds like "proxy ARPing" is enabled by default on your particular flavor of Linux. I don't think they all do that, hopefully, any more than ipforwarding should be enabled by default just because a machine has two NICs. > Is there any advantage/disadvantage in ARP implementation on FreeBSD > over that of Linux? Thanks. This information disclosure could potentially be a security problem, if Linux is providing the MAC address of a NIC not connected to the subnet without being explicitly configured to do so...although in practice very few people actually implement layer-2 security measures. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Sun Sep 18 17:15:34 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8998316A41F for ; Sun, 18 Sep 2005 17:15:34 +0000 (GMT) (envelope-from pieter@thedarkside.nl) Received: from mail.thelostparadise.com (129pc197.sshunet.nl [145.97.197.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4E9143D46 for ; Sun, 18 Sep 2005 17:15:29 +0000 (GMT) (envelope-from pieter@thedarkside.nl) Received: from [195.16.84.92] (92-unused.virt-ix.net [195.16.84.92]) by mail.thelostparadise.com (8.13.1/8.13.1) with ESMTP id j8IHFPiG039468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2005 19:15:25 +0200 (CEST) (envelope-from pieter@thedarkside.nl) Message-ID: <432DA0AC.8010802@thedarkside.nl> Date: Sun, 18 Sep 2005 19:15:24 +0200 From: Pieter de Boer User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050805) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Swiger References: <20050919.004531.92589257.mshindo@mshindo.net> <432D9249.9090202@mac.com> In-Reply-To: <432D9249.9090202@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ARP behavior in FreeBSD vs Linux 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, 18 Sep 2005 17:15:34 -0000 Chuck Swiger wrote: >> In contrast, on Linux (by default), it >> responds as long as the target IP address in ARP Request matches with >> any "local" IP address on the system, which is not necessarily an IP >> address assigned to the interface through which the ARP request is >> received. > This sounds like "proxy ARPing" is enabled by default on your particular > flavor of Linux. I don't think they all do that, hopefully, any more > than ipforwarding should be enabled by default just because a machine > has two NICs. What Motonori Shindo described is actually the default behaviour for Linux kernels (at least my 2.6.8-kernel does it by default). It could be seen as a sort of proxy-arp, but only for the host itself, not other systems. Let me try to describe when it happens. Say you have 192.168.42.42 bound on eth0 and have eth1 connected to some ethernet LAN. When a host on that eth1-connected LAN sends an 'arp who-has 192.168.42.42', a Linux system will answer that arp-request with it's eth1 MAC-address, although the IP-address is bound on eth0 and the arp request comes in on eth0. FreeBSD obviously doesn't do this. >> Is there any advantage/disadvantage in ARP implementation on FreeBSD >> over that of Linux? Thanks. I was unhappily surprised by this 'feature'. I find it pretty counter-intuitive. I expect two interfaces to be seperated inside a kernel, but Linux more or less binds them together. Incoming traffic on the 'wrong' interface will gladly be accepted, too. This broke things for me, because I didn't want to have that certain IP-address accessible. That said, this happens only when you have two interfaces connected to the same subnet, which is a bit evil anyhow. It may be beneficial for Linux to do things this way, perhaps for redundancy-purposes (two interfaces, one IP-address, IP reachable over both interfaces, when one fails, the other takes over.. no idea if that works out-of-the-box). -- Pieter From owner-freebsd-net@FreeBSD.ORG Sun Sep 18 17:52:57 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD48A16A41F for ; Sun, 18 Sep 2005 17:52:57 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC6B043D45 for ; Sun, 18 Sep 2005 17:52:56 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.192] ([10.0.0.192]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j8IHqt6j073585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Sep 2005 10:52:56 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <432DA922.5030303@errno.com> Date: Sun, 18 Sep 2005 10:51:30 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pieter de Boer References: <20050919.004531.92589257.mshindo@mshindo.net> <432D9249.9090202@mac.com> <432DA0AC.8010802@thedarkside.nl> In-Reply-To: <432DA0AC.8010802@thedarkside.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ARP behavior in FreeBSD vs Linux 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, 18 Sep 2005 17:52:57 -0000 Pieter de Boer wrote: > Chuck Swiger wrote: > >>> In contrast, on Linux (by default), it >>> responds as long as the target IP address in ARP Request matches with >>> any "local" IP address on the system, which is not necessarily an IP >>> address assigned to the interface through which the ARP request is >>> received. >> >> This sounds like "proxy ARPing" is enabled by default on your >> particular flavor of Linux. I don't think they all do that, >> hopefully, any more than ipforwarding should be enabled by default >> just because a machine has two NICs. > > What Motonori Shindo described is actually the default behaviour for > Linux kernels (at least my 2.6.8-kernel does it by default). It could be > seen as a sort of proxy-arp, but only for the host itself, not other > systems. Let me try to describe when it happens. Say you have > 192.168.42.42 bound on eth0 and have eth1 connected to some ethernet > LAN. When a host on that eth1-connected LAN sends an 'arp who-has > 192.168.42.42', a Linux system will answer that arp-request with it's > eth1 MAC-address, although the IP-address is bound on eth0 and the arp > request comes in on eth0. FreeBSD obviously doesn't do this. > >>> Is there any advantage/disadvantage in ARP implementation on FreeBSD >>> over that of Linux? Thanks. > > I was unhappily surprised by this 'feature'. I find it pretty > counter-intuitive. I expect two interfaces to be seperated inside a > kernel, but Linux more or less binds them together. Incoming traffic on > the 'wrong' interface will gladly be accepted, too. This broke things > for me, because I didn't want to have that certain IP-address accessible. > > That said, this happens only when you have two interfaces connected to > the same subnet, which is a bit evil anyhow. It may be beneficial for > Linux to do things this way, perhaps for redundancy-purposes (two > interfaces, one IP-address, IP reachable over both interfaces, when one > fails, the other takes over.. no idea if that works out-of-the-box). > The linux design philosophy, based on postings from various implementors, is that ip addresses are bound to a host, not to a particular interface. I believe the arp behaviour reflects this. Sam From owner-freebsd-net@FreeBSD.ORG Sun Sep 18 18:16:50 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C58816A41F for ; Sun, 18 Sep 2005 18:16:50 +0000 (GMT) (envelope-from ben@benswebs.com) Received: from ms-smtp-01.nyroc.rr.com (ms-smtp-01.nyroc.rr.com [24.24.2.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FA2443D45 for ; Sun, 18 Sep 2005 18:16:48 +0000 (GMT) (envelope-from ben@benswebs.com) Received: from [127.0.0.1] (cpe-72-224-114-15.nycap.res.rr.com [72.224.114.15]) by ms-smtp-01.nyroc.rr.com (8.12.10/8.12.10) with ESMTP id j8IIGgFg016102 for ; Sun, 18 Sep 2005 14:16:45 -0400 (EDT) Message-ID: <432DAED7.9070404@benswebs.com> Date: Sun, 18 Sep 2005 14:15:51 -0400 From: Benjamin Rosenblum User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: Problems with SK and EM network cards/drivers on my system 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, 18 Sep 2005 18:16:50 -0000 Im having an issue with my new linksys eg1032 nic and the onboard intel 82547EI on my new server. ill go over both problems individually and include my dmesg below that. First the SK problem. Sep 18 13:43:50 Valhalla kernel: skc0: port 0xc400-0xc4ff mem 0xfeafec00-0xfeafecff irq 21 at device 5.0 on pci3 Sep 18 13:43:50 Valhalla kernel: skc0: failed: rid 0x10 is ioport, requested 3 Sep 18 13:43:50 Valhalla kernel: sk0: couldn't map ports/memory i have run this network card before on another system with out any problems, cant figure this one out im sure its something easy but i cant figure it out at all please help. now the EM problem. when i am running a very high network load (streaming video, dumping ALOT of data across the network, etc) the network card disconnects (i loose pings and all my transfers drop) and 15-20 seconds later it pops up on the console with "em0: Link is up 1000 Mbps Full Duplex" and then it starts working again. again im at a dead wall and really want my network to work properly so i can do what i need to do. Here are my uname and dmesg FreeBSD Valhalla.PHISIG 5.4-RELEASE FreeBSD 5.4-RELEASE #5: Sun Sep 18 13:41:21 EDT 2005 laser@Valhalla.PHISIG:/usr/src/sys/i386/compile/VALHALLA i386 Sep 18 14:11:16 Valhalla syslogd: kernel boot file is /boot/kernel/kernel Sep 18 14:11:16 Valhalla kernel: Copyright (c) 1992-2005 The FreeBSD Project. Sep 18 14:11:16 Valhalla kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Sep 18 14:11:16 Valhalla kernel: The Regents of the University of California. All rights reserved. Sep 18 14:11:16 Valhalla kernel: FreeBSD 5.4-RELEASE #5: Sun Sep 18 13:41:21 EDT 2005 Sep 18 14:11:16 Valhalla kernel: laser@Valhalla.PHISIG:/usr/src/sys/i386/compile/VALHALLA Sep 18 14:11:16 Valhalla kernel: WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant Sep 18 14:11:16 Valhalla kernel: WARNING: MPSAFE network stack disabled, expect reduced performance. Sep 18 14:11:16 Valhalla kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Sep 18 14:11:16 Valhalla kernel: CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3192.02-MHz 686-class CPU) Sep 18 14:11:16 Valhalla kernel: Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Sep 18 14:11:16 Valhalla kernel: Features=0xbfebfbff Sep 18 14:11:16 Valhalla kernel: Hyperthreading: 2 logical CPUs Sep 18 14:11:16 Valhalla kernel: real memory = 2147418112 (2047 MB) Sep 18 14:11:16 Valhalla kernel: avail memory = 2095964160 (1998 MB) Sep 18 14:11:16 Valhalla kernel: ACPI APIC Table: Sep 18 14:11:16 Valhalla kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Sep 18 14:11:16 Valhalla kernel: cpu0 (BSP): APIC ID: 0 Sep 18 14:11:16 Valhalla kernel: cpu1 (AP): APIC ID: 1 Sep 18 14:11:16 Valhalla kernel: ioapic0 irqs 0-23 on motherboard Sep 18 14:11:16 Valhalla kernel: ioapic1 irqs 24-47 on motherboard Sep 18 14:11:16 Valhalla kernel: hptmv6: RocketRAID 222x controller driver v1.01 (Jun 15 2005 10:17:49) Sep 18 14:11:16 Valhalla kernel: npx0: on motherboard Sep 18 14:11:16 Valhalla kernel: npx0: INT 16 interface Sep 18 14:11:16 Valhalla kernel: acpi0: on motherboard Sep 18 14:11:16 Valhalla kernel: acpi0: Power Button (fixed) Sep 18 14:11:16 Valhalla kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Sep 18 14:11:16 Valhalla kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Sep 18 14:11:16 Valhalla kernel: cpu0: on acpi0 Sep 18 14:11:16 Valhalla kernel: cpu1: on acpi0 Sep 18 14:11:16 Valhalla kernel: pcib0: port 0xcf8-0xcff on acpi0 Sep 18 14:11:16 Valhalla kernel: pci0: on pcib0 Sep 18 14:11:16 Valhalla kernel: pcib1: at device 3.0 on pci0 Sep 18 14:11:16 Valhalla kernel: pci1: on pcib1 Sep 18 14:11:16 Valhalla kernel: em0: port 0xac00-0xac1f mem 0xfc4c0000-0xfc4dffff,0xfc4e0000-0xfc4fffff irq 18 at device 1.0 on pci1 Sep 18 14:11:16 Valhalla kernel: em0: Ethernet address: 00:13:d4:5a:de:3d Sep 18 14:11:16 Valhalla kernel: em0: Speed:N/A Duplex:N/A Sep 18 14:11:16 Valhalla kernel: pcib2: at device 28.0 on pci0 Sep 18 14:11:16 Valhalla kernel: pci2: on pcib2 Sep 18 14:11:16 Valhalla kernel: hptmv60: port 0xb800-0xb8ff mem 0xfc900000-0xfc9fffff irq 25 at device 3.0 on pci2 Sep 18 14:11:16 Valhalla kernel: hptmv6: adapter at PCI 2:3:0, IRQ 25 Sep 18 14:11:16 Valhalla kernel: atapci0: port 0xb000-0xb07f,0xb400-0xb40f,0xbc00-0xbc3f mem 0xfc7c0000-0xfc7dffff,0xfc7ff000-0xfc7fffff irq 27 at device 5.0 on pci2 Sep 18 14:11:16 Valhalla kernel: atapci0: failed: rid 0x20 is memory, requested 4 Sep 18 14:11:16 Valhalla kernel: ata2: channel #0 on atapci0 Sep 18 14:11:16 Valhalla kernel: ata3: channel #1 on atapci0 Sep 18 14:11:16 Valhalla kernel: ata4: channel #2 on atapci0 Sep 18 14:11:16 Valhalla kernel: ata5: channel #3 on atapci0 Sep 18 14:11:16 Valhalla kernel: uhci0: port 0xe800-0xe81f irq 16 at device 29.0 on pci0 Sep 18 14:11:16 Valhalla kernel: usb0: on uhci0 Sep 18 14:11:16 Valhalla kernel: usb0: USB revision 1.0 Sep 18 14:11:16 Valhalla kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 18 14:11:16 Valhalla kernel: uhub0: 2 ports with 2 removable, self powered Sep 18 14:11:16 Valhalla kernel: uhci1: port 0xec00-0xec1f irq 19 at device 29.1 on pci0 Sep 18 14:11:16 Valhalla kernel: usb1: on uhci1 Sep 18 14:11:16 Valhalla kernel: usb1: USB revision 1.0 Sep 18 14:11:16 Valhalla kernel: uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Sep 18 14:11:16 Valhalla kernel: uhub1: 2 ports with 2 removable, self powered Sep 18 14:11:16 Valhalla kernel: pci0: at device 29.4 (no driver attached) Sep 18 14:11:16 Valhalla kernel: pci0: at device 29.5 (no driver attached) Sep 18 14:11:16 Valhalla kernel: pci0: at device 29.7 (no driver attached) Sep 18 14:11:16 Valhalla kernel: pcib3: at device 30.0 on pci0 Sep 18 14:11:16 Valhalla kernel: pci3: on pcib3 Sep 18 14:11:16 Valhalla kernel: pci3: at device 3.0 (no driver attached) Sep 18 14:11:16 Valhalla kernel: skc0: port 0xc400-0xc4ff mem 0xfeafec00-0xfeafecff irq 21 at device 5.0 on pci3 Sep 18 14:11:16 Valhalla kernel: skc0: failed: rid 0x10 is ioport, requested 3 Sep 18 14:11:16 Valhalla kernel: sk0: couldn't map ports/memory Sep 18 14:11:16 Valhalla kernel: device_attach: skc0 attach returned 6 Sep 18 14:11:16 Valhalla kernel: adv0: port 0xc000-0xc0ff mem 0xfeafe800-0xfeafe8ff irq 22 at device 6.0 on pci3 Sep 18 14:11:16 Valhalla kernel: adv0: Warning EEPROM Checksum mismatch. Using default device parameters Sep 18 14:11:16 Valhalla kernel: adv0: AdvanSys SCSI Host Adapter, SCSI ID 7, queue depth 16 Sep 18 14:11:16 Valhalla kernel: isab0: at device 31.0 on pci0 Sep 18 14:11:16 Valhalla kernel: isa0: on isab0 Sep 18 14:11:16 Valhalla kernel: atapci1: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 Sep 18 14:11:16 Valhalla kernel: ata0: channel #0 on atapci1 Sep 18 14:11:16 Valhalla kernel: ata1: channel #1 on atapci1 Sep 18 14:11:16 Valhalla kernel: pci0: at device 31.3 (no driver attached) Sep 18 14:11:16 Valhalla kernel: acpi_button0: on acpi0 Sep 18 14:11:16 Valhalla kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Sep 18 14:11:16 Valhalla kernel: sio0: port may not be enabled Sep 18 14:11:16 Valhalla kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Sep 18 14:11:16 Valhalla kernel: sio0: type 16550A Sep 18 14:11:16 Valhalla kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Sep 18 14:11:16 Valhalla kernel: sio1: port may not be enabled Sep 18 14:11:16 Valhalla kernel: sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 Sep 18 14:11:16 Valhalla kernel: sio1: type 16550A Sep 18 14:11:16 Valhalla kernel: fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 Sep 18 14:11:16 Valhalla kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Sep 18 14:11:16 Valhalla kernel: ppc0: port 0x378-0x37f irq 7 on acpi0 Sep 18 14:11:16 Valhalla kernel: ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode Sep 18 14:11:16 Valhalla kernel: ppbus0: on ppc0 Sep 18 14:11:16 Valhalla kernel: plip0: on ppbus0 Sep 18 14:11:16 Valhalla kernel: lpt0: on ppbus0 Sep 18 14:11:16 Valhalla kernel: lpt0: Interrupt-driven port Sep 18 14:11:16 Valhalla kernel: ppi0: on ppbus0 Sep 18 14:11:16 Valhalla kernel: atkbdc0: port 0x64,0x60 irq 1 on acpi0 Sep 18 14:11:16 Valhalla kernel: atkbd0: irq 1 on atkbdc0 Sep 18 14:11:16 Valhalla kernel: kbd0 at atkbd0 Sep 18 14:11:16 Valhalla kernel: orm0: at iomem 0xc0000-0xc7fff on isa0 Sep 18 14:11:16 Valhalla kernel: pmtimer0 on isa0 Sep 18 14:11:16 Valhalla kernel: sc0: at flags 0x100 on isa0 Sep 18 14:11:16 Valhalla kernel: sc0: VGA <16 virtual consoles, flags=0x300> Sep 18 14:11:16 Valhalla kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Sep 18 14:11:16 Valhalla kernel: hptmv6: start channel [0,0] Sep 18 14:11:16 Valhalla kernel: hptmv6: channel [0,0] started successfully Sep 18 14:11:16 Valhalla kernel: hptmv6: start channel [0,1] Sep 18 14:11:16 Valhalla kernel: hptmv6: channel [0,1] started successfully Sep 18 14:11:16 Valhalla kernel: hptmv6: start channel [0,2] Sep 18 14:11:16 Valhalla kernel: hptmv6: channel [0,2] started successfully Sep 18 14:11:16 Valhalla kernel: hptmv6: start channel [0,3] Sep 18 14:11:16 Valhalla kernel: hptmv6: channel [0,3] started successfully Sep 18 14:11:16 Valhalla kernel: hptmv6: start channel [0,4] Sep 18 14:11:16 Valhalla kernel: hptmv6: channel [0,4] started successfully Sep 18 14:11:16 Valhalla kernel: Timecounters tick every 1.000 msec Sep 18 14:11:16 Valhalla kernel: IPsec: Initialized Security Association Processing. Sep 18 14:11:16 Valhalla kernel: ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to accept, logging disabled Sep 18 14:11:16 Valhalla kernel: ad0: 114440MB [232514/16/63] at ata0-master UDMA100 Sep 18 14:11:16 Valhalla kernel: acd0: DVDR at ata1-master PIO4 Sep 18 14:11:16 Valhalla kernel: acd1: DVDR at ata1-slave PIO4 Sep 18 14:11:16 Valhalla kernel: Waiting 15 seconds for SCSI devices to settle Sep 18 14:11:16 Valhalla kernel: da0 at hptmv60 bus 0 target 0 lun 0 Sep 18 14:11:16 Valhalla kernel: da0: Fixed Direct Access SCSI-0 device Sep 18 14:11:16 Valhalla kernel: da0: 1525760MB (3124756480 512 byte sectors: 255H 63S/T 194507C) Sep 18 14:11:16 Valhalla kernel: SMP: AP CPU #1 Launched! Sep 18 14:11:16 Valhalla kernel: Mounting root from ufs:/dev/ad0s1a Sep 18 14:11:18 Valhalla kernel: em0: Link is up 1000 Mbps Full Duplex Sep 18 14:11:19 Valhalla ntpd[453]: ntpd 4.2.0-a Sun May 8 06:01:21 UTC 2005 (1) Sep 18 14:14:13 Valhalla su: laser to root on /dev/ttyp0 From owner-freebsd-net@FreeBSD.ORG Sun Sep 18 19:08:20 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26B6E16A41F for ; Sun, 18 Sep 2005 19:08:20 +0000 (GMT) (envelope-from comte0@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8182C43D53 for ; Sun, 18 Sep 2005 19:08:19 +0000 (GMT) (envelope-from comte0@gmail.com) Received: by nproxy.gmail.com with SMTP id a4so274355nfc for ; Sun, 18 Sep 2005 12:08:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=BxRJLUkt+F2JLW1jfSQPDCQbvx7joz/3bVCyiravWaTmLdrRIHnGxBjCh/txQvC3sutxsHz/fGUBGqZR0sNX+kKkD0zO/cyO/66T21ng20rf2iHIi0X+LvsTpLBFUxkFXOfz4xebNuH4XmZhUvalw+EWowbeLQeXVF1xEDD4uG0= Received: by 10.48.3.12 with SMTP id 12mr46683nfc; Sun, 18 Sep 2005 12:08:17 -0700 (PDT) Received: by 10.48.157.6 with HTTP; Sun, 18 Sep 2005 12:08:17 -0700 (PDT) Message-ID: <1d881b2f05091812085ef72335@mail.gmail.com> Date: Sun, 18 Sep 2005 21:08:17 +0200 From: ComteZero _ To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: how to modify OpenBSD pppoe discovery ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: comte0@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2005 19:08:20 -0000 hello, I use a 3Com ADSL Modem HomeConnect. 3Com made something really stupid, the= =20 modem do not comply with PPPoE RFC standards in discovery packet. Under FreeBSD, there is an option to tell the system that we use this modem= ,=20 but under OpenBSD, I can't find this feature. Do you know how I can modify (and where) the discovery packet value in=20 source code under OpenBSD ? Thx,=20 http://www.free.bsd.com.br/noticia.php3?CAD=3D1&NOT=3D82 --- ng_pppoe.h.orig=09Wed Jun 27 23:19:34 2001 +++ ng_pppoe.h=09Thu Jun 28 06:57:20 2001 @@ -148,8 +148,8 @@ #define PTT_SYS_ERR =09(0x0202) #define PTT_GEN_ERR =09(0x0203) =20 -#define ETHERTYPE_PPPOE_DISC=090x8863=09/* pppoe discovery packets */ -#define ETHERTYPE_PPPOE_SESS=090x8864=09/* pppoe session packets */ +#define ETHERTYPE_PPPOE_DISC=090x3c12=09/* pppoe discovery packets */ +#define ETHERTYPE_PPPOE_SESS=090x3c13=09/* pppoe session packets */ #else #define PTT_EOL=09=09(0x0000) #define PTT_SRV_NAME=09(0x0101) @@ -162,8 +162,8 @@ #define PTT_SYS_ERR =09(0x0202) #define PTT_GEN_ERR =09(0x0302) =20 -#define ETHERTYPE_PPPOE_DISC=090x6388=09/* pppoe discovery packets */ -#define ETHERTYPE_PPPOE_SESS=090x6488=09/* pppoe session packets */ +#define ETHERTYPE_PPPOE_DISC=090x123c=09/* pppoe discovery packets */ +#define ETHERTYPE_PPPOE_SESS=090x133c=09/* pppoe session packets */ #endif =20 struct pppoe_tag { From owner-freebsd-net@FreeBSD.ORG Sun Sep 18 21:21:11 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1672516A41F for ; Sun, 18 Sep 2005 21:21:11 +0000 (GMT) (envelope-from millueradfa@yahoo.com) Received: from web54501.mail.yahoo.com (web54501.mail.yahoo.com [206.190.49.151]) by mx1.FreeBSD.org (Postfix) with SMTP id 8F28E43D45 for ; Sun, 18 Sep 2005 21:21:10 +0000 (GMT) (envelope-from millueradfa@yahoo.com) Received: (qmail 61964 invoked by uid 60001); 18 Sep 2005 21:21:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HNBnr1r+RzX3Vz2cWr3XCfQaF6WmPT0QV9S3SPZNZjHI6LXb//mrQktYfN/YAd0jmONQ7KjzePK2yMbTn5Bmwzq6HHT4lGBh60SHIQtfPPnclmwSEVic0MOQny8HIel95j0xJpBMfN5CQmvX0L/Ctt7Z9dA4XCd6moY3s1O7qTY= ; Message-ID: <20050918212110.61962.qmail@web54501.mail.yahoo.com> Received: from [212.202.49.90] by web54501.mail.yahoo.com via HTTP; Sun, 18 Sep 2005 14:21:09 PDT Date: Sun, 18 Sep 2005 14:21:09 -0700 (PDT) From: Milscvaer To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: UDP dont fragment bit 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, 18 Sep 2005 21:21:11 -0000 FreeBSD ought to add per-socket socket options to allow a programmer to turn on and off the don't fragment bit for UDP and the UDP checksum, on a per socket basis. FreeBSD needs to implement this feature. We requested this same feature years ago and I cannot believe such a simple, basic feature is still not implemented, or not documented in the setsockopt manpage anyhow. This needs to be implemented. We need it. Trust me. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-net@FreeBSD.ORG Sun Sep 18 21:38:32 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CAC216A41F for ; Sun, 18 Sep 2005 21:38:32 +0000 (GMT) (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 E598343D45 for ; Sun, 18 Sep 2005 21:38:31 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 88390 invoked from network); 18 Sep 2005 21:12:58 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 18 Sep 2005 21:12:58 -0000 Message-ID: <432DDE69.AF006CA0@freebsd.org> Date: Sun, 18 Sep 2005 23:38:49 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Milscvaer References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: UDP dont fragment bit 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, 18 Sep 2005 21:38:32 -0000 Milscvaer wrote: > > FreeBSD ought to add per-socket socket options to > allow a programmer to turn on and off the don't > fragment bit for UDP and the UDP checksum, on a per > socket basis. > > FreeBSD needs to implement this feature. We requested > this same feature years ago and I cannot believe such > a simple, basic feature is still not implemented, or > not documented in the setsockopt manpage anyhow. This > needs to be implemented. We need it. Trust me. Feel free to send either a suitable patch or a cheque. FreeBSD is a volunteer project and trust me, we do the best we can in with the available resources but we can't do everything. Priorities have to be set and are being set. Your behaviour certainly doesn't help your cause. -- Andre From owner-freebsd-net@FreeBSD.ORG Sun Sep 18 22:00:16 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFD8416A41F for ; Sun, 18 Sep 2005 22:00:16 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87D3143D48 for ; Sun, 18 Sep 2005 22:00:16 +0000 (GMT) (envelope-from mike@sentex.net) Received: from BLUELAPIS.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost2.sentex.ca (8.13.3/8.13.3) with SMTP id j8IM0C1B078279; Sun, 18 Sep 2005 18:00:13 -0400 (EDT) (envelope-from mike@sentex.net) From: Mike Tancsa To: Benjamin Rosenblum Date: Sun, 18 Sep 2005 18:00:51 -0400 Message-ID: References: <432DAED7.9070404@benswebs.com> In-Reply-To: <432DAED7.9070404@benswebs.com> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: freebsd-net@freebsd.org Subject: Re: Problems with SK and EM network cards/drivers on my system 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, 18 Sep 2005 22:00:17 -0000 On Sun, 18 Sep 2005 14:15:51 -0400, in sentex.lists.freebsd.net you wrote: >Im having an issue with my new linksys eg1032 nic and the onboard intel=20 >82547EI on my new server. ill go over both problems individually and=20 >include my dmesg below that.=20 > >now the EM problem. > >when i am running a very high network load (streaming video, dumping=20 >ALOT of data across the network, etc) the network card disconnects (i=20 >loose pings and all my transfers drop) and 15-20 seconds later it pops=20 >up on the console with "em0: Link is up 1000 Mbps Full Duplex" and then=20 >it starts working again. again im at a dead wall and really want my=20 >network to work properly so i can do what i need to do. > Not sure about the sk issue, but there have been some changes to the em driver since 5.4. If you can, I would try moving to 6.0R when it comes out. Also, what is the em nic plugged into ? Does the port have any logging facilities to see what might be going on from the switch's perspective ? ---Mike -------------------------------------------------------- Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 mike@sentex.net, (http://www.tancsa.com) From owner-freebsd-net@FreeBSD.ORG Sun Sep 18 22:47:39 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B6A516A41F for ; Sun, 18 Sep 2005 22:47:39 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id E732243D45 for ; Sun, 18 Sep 2005 22:47:38 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 3323C5E19; Sun, 18 Sep 2005 18:47:38 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07807-07; Sun, 18 Sep 2005 18:47:37 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-68-11.ny325.east.verizon.net [68.161.68.11]) by pi.codefab.com (Postfix) with ESMTP id E57985DE0; Sun, 18 Sep 2005 18:47:36 -0400 (EDT) Message-ID: <432DEE8E.2080902@mac.com> Date: Sun, 18 Sep 2005 18:47:42 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Milscvaer References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> In-Reply-To: <20050918212110.61962.qmail@web54501.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-net@freebsd.org Subject: Re: UDP dont fragment bit 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, 18 Sep 2005 22:47:39 -0000 Milscvaer wrote: > FreeBSD ought to add per-socket socket options to > allow a programmer to turn on and off the don't > fragment bit for UDP and the UDP checksum, on a per > socket basis. Sounds like a fine suggestion. > FreeBSD needs to implement this feature. We requested > this same feature years ago and I cannot believe such > a simple, basic feature is still not implemented, or > not documented in the setsockopt manpage anyhow. This > needs to be implemented. We need it. Trust me. Have you submitted a PR? Are you willing to work on it yourself? In the meantime, you can use libnet in advanced mode to create arbitrary UDP packets, altering any values you want including the checksum. Make sure you disable your NIC's hardware checksum capabilities, if it has them. -- -Chuck From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 00:04:39 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BCC216A41F for ; Mon, 19 Sep 2005 00:04:39 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: from seddon.ca (seddon.ca [203.209.212.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 8A51B43D45 for ; Mon, 19 Sep 2005 00:04:38 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: (qmail 73005 invoked by uid 89); 19 Sep 2005 00:04:36 -0000 Received: by seddon.ca (tmda-sendmail, from uid 89); Mon, 19 Sep 2005 10:04:34 +1000 (EST) References: <432DAED7.9070404@benswebs.com> In-Reply-To: To: Mike Tancsa Date: Mon, 19 Sep 2005 10:04:32 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <1127088274.72881.TMDA@seddon.ca> X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Dave+Seddon Cc: freebsd-net@freebsd.org, Benjamin Rosenblum Subject: Re: Problems with SK and EM network cards/drivers on my system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: das-keyword-net.6770cb@seddon.ca List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 00:04:39 -0000 It would also be interesting to know if you've got device polling enabled. If so, what sysctl settings do you have. Regards, Dave Seddon Mike Tancsa writes: > On Sun, 18 Sep 2005 14:15:51 -0400, in sentex.lists.freebsd.net you > wrote: > >>Im having an issue with my new linksys eg1032 nic and the onboard intel >>82547EI on my new server. ill go over both problems individually and >>include my dmesg below that. >> >>now the EM problem. >> >>when i am running a very high network load (streaming video, dumping >>ALOT of data across the network, etc) the network card disconnects (i >>loose pings and all my transfers drop) and 15-20 seconds later it pops >>up on the console with "em0: Link is up 1000 Mbps Full Duplex" and then >>it starts working again. again im at a dead wall and really want my >>network to work properly so i can do what i need to do. >> > > Not sure about the sk issue, but there have been some changes to the > em driver since 5.4. If you can, I would try moving to 6.0R when it > comes out. Also, what is the em nic plugged into ? Does the port have > any logging facilities to see what might be going on from the switch's > perspective ? > > ---Mike > -------------------------------------------------------- > Mike Tancsa, Sentex communications http://www.sentex.net > Providing Internet Access since 1994 > mike@sentex.net, (http://www.tancsa.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 Sep 19 00:11:24 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA3BD16A44D for ; Mon, 19 Sep 2005 00:11:24 +0000 (GMT) (envelope-from toasty@dragondata.com) Received: from tokyo01.jp.mail.your.org (tokyo01.jp.mail.your.org [204.9.54.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5444243D46 for ; Mon, 19 Sep 2005 00:11:22 +0000 (GMT) (envelope-from toasty@dragondata.com) Received: from mail.dragondata.com (server3-b.your.org [64.202.113.67]) by tokyo01.jp.mail.your.org (Postfix) with ESMTP id AC6B72AD5DDA; Mon, 19 Sep 2005 00:30:07 +0000 (UTC) Received: from [69.31.99.45] (pool045.dhcp.your.org [69.31.99.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.dragondata.com (Postfix) with ESMTP id A1A633D1854; Sun, 18 Sep 2005 19:11:19 -0500 (CDT) In-Reply-To: <432DAED7.9070404@benswebs.com> References: <432DAED7.9070404@benswebs.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F70CDCE-3DEF-4928-98AB-3FFA8B7A0812@dragondata.com> Content-Transfer-Encoding: 7bit From: Kevin Day Date: Sun, 18 Sep 2005 19:11:30 -0500 To: Benjamin Rosenblum X-Mailer: Apple Mail (2.734) Cc: freebsd-net@freebsd.org Subject: Re: Problems with SK and EM network cards/drivers on my system 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, 19 Sep 2005 00:11:24 -0000 On Sep 18, 2005, at 1:15 PM, Benjamin Rosenblum wrote: > > when i am running a very high network load (streaming video, > dumping ALOT of data across the network, etc) the network card > disconnects (i loose pings and all my transfers drop) and 15-20 > seconds later it pops up on the console with "em0: Link is up 1000 > Mbps Full Duplex" and then it starts working again. again im at a > dead wall and really want my network to work properly so i can do > what i need to do. > I've seen the same problem on em devices under two situations. The first being a bad cable. The second being a switch that was trying to use flow control(unsuccessfully). Try locking both the switch and the card to 1000BaseTX with full duplex. From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 00:41:00 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 996F216A41F for ; Mon, 19 Sep 2005 00:41:00 +0000 (GMT) (envelope-from andre@netvision.com.br) Received: from mx.netvision.com.br (mx12.netvision.com.br [200.247.230.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6EE143D46 for ; Mon, 19 Sep 2005 00:40:58 +0000 (GMT) (envelope-from andre@netvision.com.br) Received: from localhost (localhost [127.0.0.1]) by mailer.netvision.com.br (Postfix) with ESMTP id 1645620D9E7 for ; Sun, 18 Sep 2005 21:40:57 -0300 (BRT) Received: from mail.server.home (unknown [201.2.208.213]) by mx.netvision.com.br (Postfix) with ESMTP id 7D8771F80FB for ; Sun, 18 Sep 2005 21:40:56 -0300 (BRT) Received: from [192.168.7.3] (unknown [192.168.7.3]) by mail.server.home (Postfix) with ESMTP id A2B3A6215 for ; Sun, 18 Sep 2005 21:46:08 -0300 (BRT) Message-ID: <432E0908.8030101@netvision.com.br> Date: Sun, 18 Sep 2005 21:40:40 -0300 From: Andre User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at netvision.com.br Subject: PF and "set limit src-nodes" error. 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, 19 Sep 2005 00:41:00 -0000 I can't set 'limit src-nodes' with pfctl on a FreeBSD 5.4-RELEASE system. This is the error I get: # echo "set limit src-nodes 1000" | pfctl -f - pfctl: DIOCSETLIMIT: Invalid argument I'm able to set 'states' and 'frags' just fine: # echo "set limit { states 50000, frags 2000 }" | pfctl -f - Since 'limit src-nodes' is documented in the pf.conf(5) man page, my guess is I'm missing something in the kernel configuration. I'm running GENERIC with the following additions: device pf device pflog device pfsync Anything else I should have put in there? From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 02:14:22 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6329316A41F for ; Mon, 19 Sep 2005 02:14:22 +0000 (GMT) (envelope-from mshindo@mshindo.net) Received: from ober.mshindo.net (221x245x168x210.ap221.ftth.ucom.ne.jp [221.245.168.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id E91AB43D48 for ; Mon, 19 Sep 2005 02:14:21 +0000 (GMT) (envelope-from mshindo@mshindo.net) Received: from localhost (221x245x168x211.ap221.ftth.ucom.ne.jp [221.245.168.211]) by ober.mshindo.net (Postfix) with ESMTP id CDCBF336494; Mon, 19 Sep 2005 11:21:18 +0900 (JST) Date: Mon, 19 Sep 2005 11:14:18 +0900 (JST) Message-Id: <20050919.111418.71083866.mshindo@mshindo.net> To: sam@errno.com From: Motonori Shindo In-Reply-To: <432DA922.5030303@errno.com> References: <432D9249.9090202@mac.com> <432DA0AC.8010802@thedarkside.nl> <432DA922.5030303@errno.com> X-Mailer: Mew version 4.1.53 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, pieter@thedarkside.nl Subject: Re: ARP behavior in FreeBSD vs Linux 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, 19 Sep 2005 02:14:22 -0000 Chuck, Pieter, and Sam, From: Sam Leffler Subject: Re: ARP behavior in FreeBSD vs Linux Date: Sun, 18 Sep 2005 10:51:30 -0700 > Pieter de Boer wrote: > > Chuck Swiger wrote: > > > >>> In contrast, on Linux (by default), it > >>> responds as long as the target IP address in ARP Request matches with > >>> any "local" IP address on the system, which is not necessarily an IP > >>> address assigned to the interface through which the ARP request is > >>> received. > >> > >> This sounds like "proxy ARPing" is enabled by default on your > >> particular flavor of Linux. I don't think they all do that, > >> hopefully, any more than ipforwarding should be enabled by default > >> just because a machine has two NICs. > > > > What Motonori Shindo described is actually the default behaviour for > > Linux kernels (at least my 2.6.8-kernel does it by default). It seems that it has been so for a long time since 2.2 kernel days. > > It could be > > seen as a sort of proxy-arp, but only for the host itself, not other > > systems. Let me try to describe when it happens. Say you have > > 192.168.42.42 bound on eth0 and have eth1 connected to some ethernet > > LAN. When a host on that eth1-connected LAN sends an 'arp who-has > > 192.168.42.42', a Linux system will answer that arp-request with it's > > eth1 MAC-address, although the IP-address is bound on eth0 and the arp > > request comes in on eth0. FreeBSD obviously doesn't do this. This is exactly the situation I experienced this Linux ARP behavior. > >>> Is there any advantage/disadvantage in ARP implementation on FreeBSD > >>> over that of Linux? Thanks. > > > > I was unhappily surprised by this 'feature'. I find it pretty > > counter-intuitive. I expect two interfaces to be seperated inside a > > kernel, but Linux more or less binds them together. I have the same feeling as yours. > > Incoming traffic on > > the 'wrong' interface will gladly be accepted, too. This broke things > > for me, because I didn't want to have that certain IP-address accessible. > > > > That said, this happens only when you have two interfaces connected to > > the same subnet, which is a bit evil anyhow. It may be beneficial for > > Linux to do things this way, perhaps for redundancy-purposes (two > > interfaces, one IP-address, IP reachable over both interfaces, when one > > fails, the other takes over.. no idea if that works out-of-the-box). > > > > The linux design philosophy, based on postings from various > implementors, is that ip addresses are bound to a host, not to a > particular interface. I believe the arp behaviour reflects this. Good point! Some router today have similar philosophy. It is sometimes convenient, but at the same time it can be counter-intuitive particularly for those who are familiar with host-based TCP/IP implementation such as the one in most UNIX systems. Based on the feedback returned so far, I guess it is fair to say that there is no obvious drawback in the way how ARP Reply is implemented in FreeBSD compared to that of Linux. Thanks! Best Regards, Motonori Shindo From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 02:34:19 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50C5816A41F for ; Mon, 19 Sep 2005 02:34:19 +0000 (GMT) (envelope-from gjp@in-addr.com) Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2FB043D49 for ; Mon, 19 Sep 2005 02:34:18 +0000 (GMT) (envelope-from gjp@in-addr.com) Received: from uucp by noop.colo.erols.net with local-rmail (Exim 4.51 (FreeBSD)) id 1EHBU1-000OOm-UD; Sun, 18 Sep 2005 22:34:17 -0400 Received: from localhost.home.in-addr.com ([127.0.0.1]:49551) by rimmer.home.in-addr.com with esmtp (Exim 4.52 (FreeBSD)) id 1EHBTu-000LgS-9u; Mon, 19 Sep 2005 03:34:10 +0100 Message-ID: <432E23A2.8000801@in-addr.com> Date: Mon, 19 Sep 2005 03:34:10 +0100 From: Gary Palmer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.11) Gecko/20050914 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20050919.004531.92589257.mshindo@mshindo.net> <432D9249.9090202@mac.com> <432DA0AC.8010802@thedarkside.nl> In-Reply-To: <432DA0AC.8010802@thedarkside.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ARP behavior in FreeBSD vs Linux 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, 19 Sep 2005 02:34:19 -0000 Pieter de Boer wrote: >>> Is there any advantage/disadvantage in ARP implementation on FreeBSD >>> over that of Linux? Thanks. >> > I was unhappily surprised by this 'feature'. I find it pretty > counter-intuitive. I expect two interfaces to be seperated inside a > kernel, but Linux more or less binds them together. Incoming traffic > on the 'wrong' interface will gladly be accepted, too. This broke > things for me, because I didn't want to have that certain IP-address > accessible. > > That said, this happens only when you have two interfaces connected to > the same subnet, which is a bit evil anyhow. It may be beneficial for > Linux to do things this way, perhaps for redundancy-purposes (two > interfaces, one IP-address, IP reachable over both interfaces, when > one fails, the other takes over.. no idea if that works out-of-the-box). There is another side effect, which comes into view with certain configurations behind load balancers. Foundry has an option (I believe called "DSR" for Direct Server Return) which just fiddles with the MAC address of the destination. Other companies load balancers will probably have the same option, but I've no idea what they'll call it. For the connection to be accepted, all servers which are expected to answer for a particular load balanced IP address have to have that IP configured on one of their interfaces, typically loopback. The host sees that the connection is for one of its interfaces, accepts the connection and life is happy. The return path from the host to the originator bypasses the load balancer, and effectively halves the traffic that the LB is having to process and do table lookups on, etc. This obviously greatly increases the available capacity of the LB. With a Linux box answering ARP as described above, it is possible that the upstream router (or routers) COULD learn that the load balanced IP actually belongs on one of the servers rather than the load balancer. If that happens, your load balanced farm will quickly degrade and you'll be scratching your head for hours to try and figure out whats going on. Or the LB and the Linux box will get into an ARP war and random TCP connections will get RSTs from the Linux box. From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 03:11:14 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 258AB16A41F for ; Mon, 19 Sep 2005 03:11:14 +0000 (GMT) (envelope-from brett@lariat.org) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67D1E43D45 for ; Mon, 19 Sep 2005 03:11:13 +0000 (GMT) (envelope-from brett@lariat.org) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id VAA27997 for ; Sun, 18 Sep 2005 21:11:08 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.2.3.4.2.20050918205708.08cff430@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 18 Sep 2005 21:11:07 -0600 To: net@freebsd.org From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 03:11:14 -0000 For years, we've used "Dummynet" in FreeBSD for bandwidth control. Unfortunately, the semantics of IPFW can, at times, make the use of Dummynet awkward and inefficient. For example, suppose you want to create a set of rules that does bandwidth limiting first and then blocks certain ports (e.g. TCP ports 137 through 139). You want to throttle first and then block ports, so that (a) blocked packets count against the user's bandwidth limit and (b) a flood of packets will be bandwidth-limited before it runs through the rest of the rules. If net.ip.fw.one_pass is set to 0, packets emerging from a Dummynet pipe or queue will re-emerge at the next rule. This is good, because the packet can be passed on to the rules that block ports. But there's a problem: you usually do not want to go to the next rule (which is likely to be one that tests the packet to see if it is to go into a different Dummynet pipe). Rather, you want the packet to next be tested against a rule farther down -- after all of the rules involving bandwidth limiting. Here's an example of what I mean. Suppose you have several groups of users, at IP addresses 0.0.0.1, 0.0.0.2, etc. Each group has a separate pipe regulating its bandwidth consumption. You might have rules like this: # First group ${fwcmd} pipe 1 config bw 512kbit/s ${fwcmd} pipe 2 config bw 512kbit/s ${fwcmd} add pipe 1 ip from 0.0.0.0/24{55,56,57} to any in via fxp1 ${fwcmd} add pipe 2 ip from any to 0.0.0.0/24{55,56,57} out via fxp1 # Second group ${fwcmd} pipe 3 config bw 1024bit/s ${fwcmd} pipe 4 config bw 1024kbit/s ${fwcmd} add pipe 3 ip from 0.0.0.0/24{35-40} to any in via fxp1 ${fwcmd} add pipe 4 ip from any to 0.0.0.0/24{35-40} out via fxp1 # Filtering here What you'd really like is to have any packet that satisfies one of the "pipe" rules jump down to the filtering rules after being reinjected into IPFW. Unfortunately, because IPFW doesn't have a "not" that can cover the "and" of all the conditions in the rule -- that is, you can't say "not (ip from A to any in via fxp1)" -- it's very difficult to do this with a single rule containing a "skipto" action. What's more, there's no "resume at" clause available in IPFW that would change where a packet was reinjected, and no such thing as a "come from" directive (something that's often joked about in programming classes). So, what's the best way get a packet to skip past the remaining bandwidth limiting rules once it was selected to go into a pipe? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 03:24:13 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 341F316A41F for ; Mon, 19 Sep 2005 03:24:13 +0000 (GMT) (envelope-from dave-dated-1127532249.eb624a@seddon.ca) Received: from seddon.ca (seddon.ca [203.209.212.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 6FD1343D48 for ; Mon, 19 Sep 2005 03:24:12 +0000 (GMT) (envelope-from dave-dated-1127532249.eb624a@seddon.ca) Received: (qmail 18317 invoked by uid 89); 19 Sep 2005 03:24:10 -0000 Received: by seddon.ca (tmda-sendmail, from uid 89); Mon, 19 Sep 2005 13:24:08 +1000 (EST) References: <6.2.3.4.2.20050918205708.08cff430@localhost> In-Reply-To: <6.2.3.4.2.20050918205708.08cff430@localhost> To: Brett Glass Date: Mon, 19 Sep 2005 13:24:07 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <1127100248.18218.TMDA@seddon.ca> X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Dave+Seddon Cc: net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 03:24:13 -0000 skipto man ipfw -> e.g. ipfw add 10 skipto 4000 all from any to any layer2 out Brett Glass writes: > For years, we've used "Dummynet" in FreeBSD for bandwidth control. > Unfortunately, the semantics of IPFW can, at times, make the use of > Dummynet awkward and inefficient. For example, suppose you want to create > a set of rules that does bandwidth limiting first > and then blocks certain ports (e.g. TCP ports 137 through 139). You want > to throttle first and then block ports, so that (a) blocked packets count > against the user's bandwidth limit and (b) a flood of packets will be > bandwidth-limited before it runs > through the rest of the rules. > > If net.ip.fw.one_pass is set to 0, packets emerging from a Dummynet pipe > or queue will re-emerge at the next rule. This is good, because the packet > can be passed on to the rules that block ports. But there's a problem: you > usually do not want to go to the next rule (which is likely to be one that > tests the packet to see if it is to go into a different Dummynet pipe). > Rather, you want the packet to next be tested against a rule farther down > -- after all of the rules involving bandwidth limiting. > > Here's an example of what I mean. Suppose you have several groups of > users, at IP addresses 0.0.0.1, 0.0.0.2, etc. Each group has a separate > pipe regulating its bandwidth consumption. You might have rules like this: > > # First group > > ${fwcmd} pipe 1 config bw 512kbit/s > ${fwcmd} pipe 2 config bw 512kbit/s > > ${fwcmd} add pipe 1 ip from 0.0.0.0/24{55,56,57} to any in via fxp1 > ${fwcmd} add pipe 2 ip from any to 0.0.0.0/24{55,56,57} out via fxp1 > > # Second group > > ${fwcmd} pipe 3 config bw 1024bit/s > ${fwcmd} pipe 4 config bw 1024kbit/s > > ${fwcmd} add pipe 3 ip from 0.0.0.0/24{35-40} to any in via fxp1 > ${fwcmd} add pipe 4 ip from any to 0.0.0.0/24{35-40} out via fxp1 > > # Filtering here > > What you'd really like is to have any packet that satisfies one of the > "pipe" rules jump down to the filtering rules after being reinjected into > IPFW. > > Unfortunately, because IPFW doesn't have a "not" that can cover the "and" > of all the conditions in the rule -- that is, you can't say "not (ip from > A to any in via fxp1)" -- it's very difficult to do this with a single > rule containing a "skipto" action. What's more, there's no "resume at" > clause available in IPFW that would change where a packet was reinjected, > and no such thing as a "come from" directive (something that's often joked > about in programming classes). So, what's the best way get a packet to > skip past the remaining bandwidth limiting rules once it was selected to > go into a pipe? > > --Brett Glass > > _______________________________________________ > 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 Sep 19 03:33:22 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FFFC16A41F for ; Mon, 19 Sep 2005 03:33:22 +0000 (GMT) (envelope-from brett@lariat.org) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0993543D45 for ; Mon, 19 Sep 2005 03:33:21 +0000 (GMT) (envelope-from brett@lariat.org) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id VAA28158; Sun, 18 Sep 2005 21:33:12 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.2.3.4.2.20050918212944.08cf8d80@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 18 Sep 2005 21:33:09 -0600 To: Dave+Seddon From: Brett Glass In-Reply-To: <1127100248.18218.TMDA@seddon.ca> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <1127100248.18218.TMDA@seddon.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 03:33:22 -0000 At 09:24 PM 9/18/2005, Dave+Seddon wrote: >skipto >man ipfw -> e.g. ipfw add 10 skipto 4000 all from any to any layer2 out It's not that simple. Each rule that can send packets into a pipe has at least two conditions (e.g. IP address, interface name, and in or out via that interface). Do you propose that I apply DeMorgan's theorem to every rule that sends packets into a pipe? If I did, I'd produce a whole long list of "skipto" rules for each individual rule I had before. Could get very messy -- and create overhead. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 06:08:46 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B61F916A420 for ; Mon, 19 Sep 2005 06:08:46 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3750743D45 for ; Mon, 19 Sep 2005 06:08:44 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j8J67cHV094467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Sep 2005 13:07:38 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id j8J66JbO095192; Mon, 19 Sep 2005 13:06:19 +0700 (ICT) Date: Mon, 19 Sep 2005 13:06:19 +0700 (ICT) Message-Id: <200509190606.j8J66JbO095192@banyan.cs.ait.ac.th> From: Olivier Nicole To: freebsd-net@freebsd.org In-reply-to: <432DA922.5030303@errno.com> (message from Sam Leffler on Sun, 18 Sep 2005 10:51:30 -0700) References: <20050919.004531.92589257.mshindo@mshindo.net> <432D9249.9090202@mac.com> <432DA0AC.8010802@thedarkside.nl> <432DA922.5030303@errno.com> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Subject: Re: ARP behavior in FreeBSD vs Linux 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, 19 Sep 2005 06:08:46 -0000 > What Motonori Shindo described is actually the default behaviour for > Linux kernels (at least my 2.6.8-kernel does it by default). It could be > seen as a sort of proxy-arp, but only for the host itself, not other > systems. Let me try to describe when it happens. Say you have > 192.168.42.42 bound on eth0 and have eth1 connected to some ethernet > LAN. When a host on that eth1-connected LAN sends an 'arp who-has > 192.168.42.42', a Linux system will answer that arp-request with it's > eth1 MAC-address, although the IP-address is bound on eth0 and the arp > request comes in on eth0. FreeBSD obviously doesn't do this. To me, it seems that FreeBSD does just that too once bridge is enabled. Olivier From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 06:33:29 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BA0416A421 for ; Mon, 19 Sep 2005 06:33:29 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: from useful.dataloss.nl (useful.dataloss.nl [80.84.249.161]) by mx1.FreeBSD.org (Postfix) with SMTP id 8E7F943D45 for ; Mon, 19 Sep 2005 06:33:26 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: (qmail 36131 invoked by uid 1001); 19 Sep 2005 06:33:22 -0000 Date: Mon, 19 Sep 2005 08:33:22 +0200 From: Peter van Dijk To: freebsd-net@freebsd.org Message-ID: <20050919063322.GA17888@dataloss.nl> References: <20050919.004531.92589257.mshindo@mshindo.net> <432D9249.9090202@mac.com> <432DA0AC.8010802@thedarkside.nl> <432DA922.5030303@errno.com> <200509190606.j8J66JbO095192@banyan.cs.ait.ac.th> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509190606.j8J66JbO095192@banyan.cs.ait.ac.th> User-Agent: Mutt/1.4i Subject: Re: ARP behavior in FreeBSD vs Linux 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, 19 Sep 2005 06:33:29 -0000 On Mon, Sep 19, 2005 at 01:06:19PM +0700, Olivier Nicole wrote: > To me, it seems that FreeBSD does just that too once bridge is enabled. 'Enabling' bridging is a no-op.. However, when you -configure- a couple of interfaces together in a bridge, they share this behaviour; but this is correct as bridging is supposed to effectively merge the chosen interfaces into one. This does not affect any other interfaces, which makes it substantially different from the Linux behaviour. Cheers, Peter -- peter@dataloss.nl | ~ tonight tonight, what is this potion http://blog.dataloss.nl/ | ~ that makes a fool of me UnderNet/#clue | Wayfinder, fr-025 soundtrack From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 06:40:37 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85AC816A41F for ; Mon, 19 Sep 2005 06:40:37 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D0BA43D45 for ; Mon, 19 Sep 2005 06:40:35 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j8J6dHMe096222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Sep 2005 13:39:17 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id j8J6bxu6095963; Mon, 19 Sep 2005 13:37:59 +0700 (ICT) Date: Mon, 19 Sep 2005 13:37:59 +0700 (ICT) Message-Id: <200509190637.j8J6bxu6095963@banyan.cs.ait.ac.th> From: Olivier Nicole To: peter@dataloss.nl In-reply-to: <20050919063322.GA17888@dataloss.nl> (message from Peter van Dijk on Mon, 19 Sep 2005 08:33:22 +0200) References: <20050919.004531.92589257.mshindo@mshindo.net> <432D9249.9090202@mac.com> <432DA0AC.8010802@thedarkside.nl> <432DA922.5030303@errno.com> <200509190606.j8J66JbO095192@banyan.cs.ait.ac.th> <20050919063322.GA17888@dataloss.nl> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Cc: freebsd-net@freebsd.org Subject: Re: ARP behavior in FreeBSD vs Linux 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, 19 Sep 2005 06:40:37 -0000 > 'Enabling' bridging is a no-op.. However, when you -configure- a > couple of interfaces together in a bridge, they share this behaviour; > but this is correct as bridging is supposed to effectively merge the > chosen interfaces into one. This does not affect any other interfaces, > which makes it substantially different from the Linux behaviour. OK, enabling bridge is useless unless you bridge a pair of interfaces :) But that ARP thing happens also with interfaces that are not part of the bridge! Even if the interfaces are ifconfiged NOARP. Olivier From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 06:49:29 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E41E216A41F for ; Mon, 19 Sep 2005 06:49:29 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: from useful.dataloss.nl (useful.dataloss.nl [80.84.249.161]) by mx1.FreeBSD.org (Postfix) with SMTP id 3954243D48 for ; Mon, 19 Sep 2005 06:49:29 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: (qmail 37646 invoked by uid 1001); 19 Sep 2005 06:49:28 -0000 Date: Mon, 19 Sep 2005 08:49:28 +0200 From: Peter van Dijk To: freebsd-net@freebsd.org Message-ID: <20050919064927.GB17888@dataloss.nl> References: <20050919.004531.92589257.mshindo@mshindo.net> <432D9249.9090202@mac.com> <432DA0AC.8010802@thedarkside.nl> <432E23A2.8000801@in-addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <432E23A2.8000801@in-addr.com> User-Agent: Mutt/1.4i Subject: Re: ARP behavior in FreeBSD vs Linux 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, 19 Sep 2005 06:49:30 -0000 On Mon, Sep 19, 2005 at 03:34:10AM +0100, Gary Palmer wrote: > There is another side effect, which comes into view with certain > configurations behind load balancers. Foundry has an option (I believe > called "DSR" for Direct Server Return) which just fiddles with the MAC > address of the destination. Other companies load balancers will > probably have the same option, but I've no idea what they'll call it. Linux Virtual Server calls it 'DR' for Direct Routing. I like this feature a lot as it means our loadbalancer is basically idle :) > connection and life is happy. The return path from the host to the > originator bypasses the load balancer, and effectively halves the > traffic that the LB is having to process and do table lookups on, etc. > This obviously greatly increases the available capacity of the LB. All true; except in most cases the win is much more than 50%.. compare HTTP request size (<1KB) to HTTP response size (often >50KB) :) > With a Linux box answering ARP as described above, it is possible that > the upstream router (or routers) COULD learn that the load balanced IP > actually belongs on one of the servers rather than the load balancer. > If that happens, your load balanced farm will quickly degrade and you'll > be scratching your head for hours to try and figure out whats going on. > Or the LB and the Linux box will get into an ARP war and random TCP > connections will get RSTs from the Linux box. In setting up such a configuration, making sure the backend hosts do not respond to ARP is always important; I've seen people assign the frontend IP to normal ethernet interfaces on FreeBSD boxes and wonder why it didn't work.. On FreeBSD, we solve this issue by assigning the IPs to lo0. For Linux, this approach works equally well and is what the Linux Virtual Server documentation recommends. So, unless you have a weird policy of assigning these IPs to -other- Ethernet interfaces, there is no problem on FreeBSD nor Linux :) Cheers, Peter -- peter@dataloss.nl | ~ tonight tonight, what is this potion http://blog.dataloss.nl/ | ~ that makes a fool of me UnderNet/#clue | Wayfinder, fr-025 soundtrack From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 06:50:19 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B8C116A41F for ; Mon, 19 Sep 2005 06:50:19 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: from useful.dataloss.nl (useful.dataloss.nl [80.84.249.161]) by mx1.FreeBSD.org (Postfix) with SMTP id CEE0343D4C for ; Mon, 19 Sep 2005 06:50:18 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: (qmail 37738 invoked by uid 1001); 19 Sep 2005 06:50:17 -0000 Date: Mon, 19 Sep 2005 08:50:17 +0200 From: Peter van Dijk To: freebsd-net@freebsd.org Message-ID: <20050919065017.GC17888@dataloss.nl> References: <20050919.004531.92589257.mshindo@mshindo.net> <432D9249.9090202@mac.com> <432DA0AC.8010802@thedarkside.nl> <432DA922.5030303@errno.com> <200509190606.j8J66JbO095192@banyan.cs.ait.ac.th> <20050919063322.GA17888@dataloss.nl> <200509190637.j8J6bxu6095963@banyan.cs.ait.ac.th> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509190637.j8J6bxu6095963@banyan.cs.ait.ac.th> User-Agent: Mutt/1.4i Subject: Re: ARP behavior in FreeBSD vs Linux 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, 19 Sep 2005 06:50:19 -0000 On Mon, Sep 19, 2005 at 01:37:59PM +0700, Olivier Nicole wrote: > OK, enabling bridge is useless unless you bridge a pair of interfaces :) > > But that ARP thing happens also with interfaces that are not part of > the bridge! Even if the interfaces are ifconfiged NOARP. This is not what I observed... which of the 3 bridging implementations (bridge, if_bridge, ng_bridge) have you seen this behaviour with? Cheers, Peter -- peter@dataloss.nl | ~ tonight tonight, what is this potion http://blog.dataloss.nl/ | ~ that makes a fool of me UnderNet/#clue | Wayfinder, fr-025 soundtrack From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 06:57:03 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 694FE16A41F for ; Mon, 19 Sep 2005 06:57:03 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4481243D5F for ; Mon, 19 Sep 2005 06:57:00 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j8J6ux1W060453; Sun, 18 Sep 2005 23:56:59 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j8J6uxWh060452; Sun, 18 Sep 2005 23:56:59 -0700 (PDT) (envelope-from rizzo) Date: Sun, 18 Sep 2005 23:56:59 -0700 From: Luigi Rizzo To: Brett Glass Message-ID: <20050918235659.B60185@xorpc.icir.org> References: <6.2.3.4.2.20050918205708.08cff430@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6.2.3.4.2.20050918205708.08cff430@localhost>; from brett@lariat.org on Sun, Sep 18, 2005 at 09:11:07PM -0600 Cc: net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 06:57:03 -0000 [see long original request below] Bret, you want a block structured ipfw control language, but ipfw is an assembly language. You have to live with that. Your only way out is A. write a translator from high level to low level language (many people do use sh scripts to generate ipfw configurations) B. write the sequential blocks of instructions you need, and connect them through skipto. It can be tedious, but generally ipfw configurations are not so complex, _and_ when they are is not terribly complex to generate this through scripts. The way i usually write things is the following: 1) do not put the action in the filtering rules: rather, put a 'skipto N' in the matching rules. So if there are 20 different paths that lead to the same action (e.g. pipe, queue, deny, icmp, whatever) they all end up to rule N This makes your life a lot easier when you need to add/remove paths, whereas if you hand-optimize rulesets, you might end up having to rewrite (and revalidate) blocks of rules just because the ipfw opcode syntax does not support the new configuration. 2) at rule N, do whatever processing is necessary, without any filtering: It could be as simple as ipfw pipe 12 ip from any to any but if you need to add more rules afterwards then you can easily do that without making the configuration any harder to read. cheers luigi On Sun, Sep 18, 2005 at 09:11:07PM -0600, Brett Glass wrote: > For years, we've used "Dummynet" in FreeBSD for bandwidth control. > Unfortunately, the semantics of IPFW can, at times, make the use of > Dummynet awkward and inefficient. For example, suppose you want to > create a set of rules that does bandwidth limiting first > and then blocks certain ports (e.g. TCP ports 137 through 139). You > want to throttle first and then block ports, so that (a) blocked > packets count against the user's bandwidth limit and (b) a flood of > packets will be bandwidth-limited before it runs > through the rest of the rules. > > If net.ip.fw.one_pass is set to 0, packets emerging from a Dummynet > pipe or queue will re-emerge at the next rule. This is good, > because the packet can be passed on to the rules that block ports. > But there's a problem: you usually do not want to go to the next > rule (which is likely to be one that tests the packet to see if it > is to go into a different Dummynet pipe). Rather, you want the > packet to next be tested against a rule farther down -- after all > of the rules involving bandwidth limiting. > > Here's an example of what I mean. Suppose you have several groups > of users, at IP addresses 0.0.0.1, 0.0.0.2, etc. Each group has a > separate pipe regulating its bandwidth consumption. You might have > rules like this: > > # First group > > ${fwcmd} pipe 1 config bw 512kbit/s > ${fwcmd} pipe 2 config bw 512kbit/s > > ${fwcmd} add pipe 1 ip from 0.0.0.0/24{55,56,57} to any in via fxp1 > ${fwcmd} add pipe 2 ip from any to 0.0.0.0/24{55,56,57} out via fxp1 > > # Second group > > ${fwcmd} pipe 3 config bw 1024bit/s > ${fwcmd} pipe 4 config bw 1024kbit/s > > ${fwcmd} add pipe 3 ip from 0.0.0.0/24{35-40} to any in via fxp1 > ${fwcmd} add pipe 4 ip from any to 0.0.0.0/24{35-40} out via fxp1 > > # Filtering here > > What you'd really like is to have any packet that satisfies one of > the "pipe" rules jump down to the filtering rules after being > reinjected into IPFW. > > Unfortunately, because IPFW doesn't have a "not" that can cover the > "and" of all the conditions in the rule -- that is, you can't say > "not (ip from A to any in via fxp1)" -- it's very difficult to do > this with a single rule containing a "skipto" action. What's more, > there's no "resume at" clause available in IPFW that would change > where a packet was reinjected, and no such thing as a "come from" > directive (something that's often joked about in programming > classes). So, what's the best way get a packet to skip past the > remaining bandwidth limiting rules once it was selected to go into a pipe? > > --Brett Glass > > _______________________________________________ > 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 Sep 19 06:57:53 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C93AF16A41F for ; Mon, 19 Sep 2005 06:57:53 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: from useful.dataloss.nl (useful.dataloss.nl [80.84.249.161]) by mx1.FreeBSD.org (Postfix) with SMTP id 4C6FD43D49 for ; Mon, 19 Sep 2005 06:57:53 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: (qmail 38495 invoked by uid 1001); 19 Sep 2005 06:57:52 -0000 Date: Mon, 19 Sep 2005 08:57:52 +0200 From: Peter van Dijk To: freebsd-net@freebsd.org Message-ID: <20050919065752.GD17888@dataloss.nl> References: <20050919.004531.92589257.mshindo@mshindo.net> <432D9249.9090202@mac.com> <432DA0AC.8010802@thedarkside.nl> <432E23A2.8000801@in-addr.com> <20050919064927.GB17888@dataloss.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050919064927.GB17888@dataloss.nl> User-Agent: Mutt/1.4i Subject: Re: ARP behavior in FreeBSD vs Linux 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, 19 Sep 2005 06:57:53 -0000 On Mon, Sep 19, 2005 at 08:49:28AM +0200, Peter van Dijk wrote: > On FreeBSD, we solve this issue by assigning the IPs to lo0. For > Linux, this approach works equally well and is what the Linux Virtual > Server documentation recommends. Oops.. the docs I read were for Linux 2.0. The docs for 2.2 recommend flipping some 'hidden' flag in /proc/sys/net/ipv4; this suggests that Linux responds to ARP even for lo0 by default. So indeed, Linux requires -extra- care to get a DR loadbalanced situation right.. Cheers, Peter -- peter@dataloss.nl | ~ tonight tonight, what is this potion http://blog.dataloss.nl/ | ~ that makes a fool of me UnderNet/#clue | Wayfinder, fr-025 soundtrack From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 07:32:45 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39D4A16A41F for ; Mon, 19 Sep 2005 07:32:45 +0000 (GMT) (envelope-from brett@lariat.org) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9162E43D46 for ; Mon, 19 Sep 2005 07:32:44 +0000 (GMT) (envelope-from brett@lariat.org) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id BAA00256; Mon, 19 Sep 2005 01:32:34 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.2.3.4.2.20050919010035.07dfc448@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 19 Sep 2005 01:32:33 -0600 To: Luigi Rizzo From: Brett Glass In-Reply-To: <20050918235659.B60185@xorpc.icir.org> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 07:32:45 -0000 At 12:56 AM 9/19/2005, Luigi Rizzo wrote: >[see long original request below] > >Bret, you want a block structured ipfw control language, but >ipfw is an assembly language. You have to live with that. >Your only way out is >A. write a translator from high level to low level language > (many people do use sh scripts to generate ipfw configurations) I've tried this. Alas, it quickly gets out of hand because objects in IPFW (for example pipes) aren't named. You wind up literally having to build a symbol table to keep track of rule numbers, pipe numbers, etc. Yes, you can do it, but it's very awkward. >B. write the sequential blocks of instructions you need, > and connect them through skipto. It can be tedious, but generally > ipfw configurations are not so complex, _and_ when they are > is not terribly complex to generate this through scripts. Unfortunately, this requires inverting the sense of rules. And in IPFW's very simplistic language, you can't invert a single rule with more than one condition into another single rule because you can only negate each individual criterion and not the whole rule. Thus, when you do the NAND->OR conversion (DeMorgan's Theorem), you will find yourself with an explosion in the number of rules. What's more, the inversion can't be easily automated (there are quite a lot of IPFW options, and some are not directly invertable). So, every time you add a rule you have to write its inverse manually as multiple rules, with skipto's whose targets may change if you ever edit the rule set. It's total spaghetti. It occurs to me that there might be a simpler way. What if one could add an IPFW option called "resume" to a rule, with the following syntax and semantics? pipe 25 ip from 0.0.0.1 to any in via tun* resume 5000 The semantics would be as follows: If the rule was matched and the packet was sent off to a Dummynet pipe (or queue), a "skipto 5000" would be executed when the packet was re-injected into IPFW. This would skip you around the other bandwidth throttling rules. Problem solved. The same option might also be useful if you wanted to combine some other action that doesn't terminate the search (e.g. logging) with a "skipto". It wouldn't be valid if the action terminated the search. I believe that there's a field that goes along with a packet into Dummynet which carries information about where to reinject the packet if ip.fw.one_pass is set to 0. Thus, adding this option might just be a simple matter of modifying that field. I've looked at the source and it's fragmented and virtually undocumented, so I'd probably spend a long time blundering around trying to add this and get it right (and also have the rules display correctly, etc.). I seem to recall (correct me if I'm wrong here) that you've hacked on both IPFilter and IPFW. How hard would this be to add? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 07:32:51 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7407716A41F for ; Mon, 19 Sep 2005 07:32:51 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EFB043D46 for ; Mon, 19 Sep 2005 07:32:48 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j8J7VeRp098633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Sep 2005 14:31:40 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id j8J7UHoV096429; Mon, 19 Sep 2005 14:30:17 +0700 (ICT) Date: Mon, 19 Sep 2005 14:30:17 +0700 (ICT) Message-Id: <200509190730.j8J7UHoV096429@banyan.cs.ait.ac.th> From: Olivier Nicole To: freebsd-net@freebsd.org In-reply-to: <20050919065017.GC17888@dataloss.nl> (message from Peter van Dijk on Mon, 19 Sep 2005 08:50:17 +0200) References: <20050919.004531.92589257.mshindo@mshindo.net> <432D9249.9090202@mac.com> <432DA0AC.8010802@thedarkside.nl> <432DA922.5030303@errno.com> <200509190606.j8J66JbO095192@banyan.cs.ait.ac.th> <20050919063322.GA17888@dataloss.nl> <200509190637.j8J6bxu6095963@banyan.cs.ait.ac.th> <20050919065017.GC17888@dataloss.nl> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Subject: Re: ARP behavior in FreeBSD vs Linux 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, 19 Sep 2005 07:32:51 -0000 > > But that ARP thing happens also with interfaces that are not part of > > the bridge! Even if the interfaces are ifconfiged NOARP. > > This is not what I observed... which of the 3 bridging implementations > (bridge, if_bridge, ng_bridge) have you seen this behaviour with? Hummm, I am not sure, the one enabled with the option BRIDGE in the kernel (4.10 RELENG), so I guess the first on. Of course not netgraph. And of course i cannot find anymore syslog message :( The situtation was: - fxp1: one interface with no IP, NOARP connected to my inside lan, bridge to fxp0 - fxp0: one interface with no IP, NOARP connected to my outside lan, bridge to fxp1 - xl0: one interface with IP connected to my inside lan. At random times, fxp1 would respond to ARP requests about the IP of xl0. Olivier From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 07:59:33 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2802E16A41F for ; Mon, 19 Sep 2005 07:59:33 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E014143D48 for ; Mon, 19 Sep 2005 07:59:32 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j8J7xW1u061187; Mon, 19 Sep 2005 00:59:32 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j8J7xWxt061186; Mon, 19 Sep 2005 00:59:32 -0700 (PDT) (envelope-from rizzo) Date: Mon, 19 Sep 2005 00:59:32 -0700 From: Luigi Rizzo To: Brett Glass Message-ID: <20050919005932.B60737@xorpc.icir.org> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6.2.3.4.2.20050919010035.07dfc448@localhost>; from brett@lariat.org on Mon, Sep 19, 2005 at 01:32:33AM -0600 Cc: net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 07:59:33 -0000 On Mon, Sep 19, 2005 at 01:32:33AM -0600, Brett Glass wrote: ... > Unfortunately, this requires inverting the sense of rules. And in IPFW's > very simplistic language, you can't invert a single rule with more > than one condition into another single rule because you can only yes i know. you need to make it into two rules. you have to live with what is there. Same for as the 'resume' option. It might be nice to have, however but there is already a two-rule version (the one i suggested, follow the non-terminating action with a skipto rule) so its absence is not blocking you from doing what you want. in terms of implementation, if you want to add it, the best place would be to add the 'skipto' fields to each 'action' opcode. I am not very interested in implementing it, though, because i still see ipfw as a low-level language. > I've looked at the source and it's fragmented and virtually undocumented, are you talking about the userland part or the kernel code ? i agree the userland part is a mess. But the kernel code i believe is reasonably documented (of course it could be documented better - patches welcome). the first 250 or so lines in ip_fw2.h are almost all comments describing the opcode formats. ip_fw2.c tries to describe rule parsing in the body of ipfw_chk() cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 09:40:15 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0025B16A41F for ; Mon, 19 Sep 2005 09:40:14 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78C3143D49 for ; Mon, 19 Sep 2005 09:40:14 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j8J9eDis051780; Mon, 19 Sep 2005 02:40:13 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j8J9eC4u051749; Mon, 19 Sep 2005 02:40:12 -0700 (PDT) (envelope-from jmg) Date: Mon, 19 Sep 2005 02:40:12 -0700 From: John-Mark Gurney To: Brett Glass Message-ID: <20050919094012.GB821@funkthat.com> Mail-Followup-To: Brett Glass , Luigi Rizzo , net@freebsd.org References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.3.4.2.20050919010035.07dfc448@localhost> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 09:40:15 -0000 Brett Glass wrote this message on Mon, Sep 19, 2005 at 01:32 -0600: > At 12:56 AM 9/19/2005, Luigi Rizzo wrote: > > >[see long original request below] > > > >Bret, you want a block structured ipfw control language, but > >ipfw is an assembly language. You have to live with that. > >Your only way out is > >A. write a translator from high level to low level language > > (many people do use sh scripts to generate ipfw configurations) > > I've tried this. Alas, it quickly gets out of hand because objects > in IPFW (for example pipes) aren't named. You wind up literally > having to build a symbol table to keep track of rule numbers, pipe > numbers, etc. Yes, you can do it, but it's very awkward. What's awkward about: #define PIPE_FOO 1 #define PIPE_BAR 2 add pipe PIPE_FOO config bw 64kbit/sec /* ... etc ... */ ?? There's this nice option -p that passes your firewall file through a preprocessor.. and cpp is quite nice for this... I little bit of my firewall.conf: #ifndef SET #define SET #endif /* little useful macros */ #if 1 #define DENY deny #else #define DENY skipto BLACKHOLE #endif /* Defines for rules */ #if 0 #define IPSEC(x) x #else #define IPSEC(x) #endif #if 1 #define PIF vlan0 #define PIP 69.17.45.168 #define PNET 69.17.45.0/24 #define PUB(x) x #else #define PUB(x) #endif [...] /* labels */ #define DIVERT 15900 #define BLACKHOLE 65000 #define THEEND BLACKHOLE #define DECL(x) add x SET count ip from any to any #define GOTO_THEEND add SET skipto THEEND ip from any to any /* nat */ DECL(DIVERT) PUB(add SET divert 8668 ip from any to any via PIF) MAN(add SET divert 8669 ip from any to any via MIF) This lets me enable/disable parts of my configuration a lot easier... and use those symbols you like to use... :) and to enable all this: firewall_flags="-p /usr/bin/cpp" # Flags passed to ipfw when type is a file -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 11:02:17 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62A1416A420 for ; Mon, 19 Sep 2005 11:02:17 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BFDC43D49 for ; Mon, 19 Sep 2005 11:02:17 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j8JB2GAJ018144 for ; Mon, 19 Sep 2005 11:02:16 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j8JB2FZm018139 for freebsd-net@freebsd.org; Mon, 19 Sep 2005 11:02:15 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 19 Sep 2005 11:02:15 GMT Message-Id: <200509191102.j8JB2FZm018139@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 19 Sep 2005 11:02:17 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 13:48:51 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2296E16A46F for ; Mon, 19 Sep 2005 13:48:50 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id D59C643D45 for ; Mon, 19 Sep 2005 13:48:48 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3C977.dip.t-dialin.net [84.163.201.119] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0ML2Dk-1EHM0e0tMz-0003um; Mon, 19 Sep 2005 15:48:40 +0200 From: Max Laier To: freebsd-net@freebsd.org Date: Mon, 19 Sep 2005 15:48:25 +0200 User-Agent: KMail/1.8.2 References: <432E0908.8030101@netvision.com.br> In-Reply-To: <432E0908.8030101@netvision.com.br> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1266059.rOltI5Ykkl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509191548.37693.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Andre Subject: Re: PF and "set limit src-nodes" error. 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, 19 Sep 2005 13:48:52 -0000 --nextPart1266059.rOltI5Ykkl Content-Type: multipart/mixed; boundary="Boundary-01=_wGsLDM4vk3VJOZT" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_wGsLDM4vk3VJOZT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 19 September 2005 02:40, Andre wrote: > I can't set 'limit src-nodes' with pfctl on a FreeBSD 5.4-RELEASE > system. This is the error I get: > > # echo "set limit src-nodes 1000" | pfctl -f - > pfctl: DIOCSETLIMIT: Invalid argument > > I'm able to set 'states' and 'frags' just fine: > > # echo "set limit { states 50000, frags 2000 }" | pfctl -f - > > Since 'limit src-nodes' is documented in the pf.conf(5) man page, my > guess is I'm missing something in the kernel configuration. I'm running > GENERIC with the following additions: > > device pf > device pflog > device pfsync > > Anything else I should have put in there? Can you please try the attached patch and report back. Seems like I missed= an=20 initialization there :-\ Thanks. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_wGsLDM4vk3VJOZT Content-Type: text/x-diff; charset="iso-8859-1"; name="pf_ioctl.c.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pf_ioctl.c.diff" Index: pf_ioctl.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/store/mlaier/fcvs/src/sys/contrib/pf/net/pf_ioctl.c,v retrieving revision 1.12.2.7 diff -u -r1.12.2.7 pf_ioctl.c =2D-- pf_ioctl.c 12 Sep 2005 14:46:55 -0000 1.12.2.7 +++ pf_ioctl.c 19 Sep 2005 13:46:05 -0000 @@ -284,6 +284,8 @@ =20 pf_pool_limits[PF_LIMIT_STATES].pp =3D pf_state_pl; pf_pool_limits[PF_LIMIT_STATES].limit =3D PFSTATE_HIWAT; + pf_pool_limits[PF_LIMIT_SRC_NODES].pp =3D pf_src_tree_pl; + pf_pool_limits[PF_LIMIT_SRC_NODES].limit =3D PFSNODE_HIWAT; pf_pool_limits[PF_LIMIT_FRAGS].pp =3D pf_frent_pl; pf_pool_limits[PF_LIMIT_FRAGS].limit =3D PFFRAG_FRENT_HIWAT; uma_zone_set_max(pf_pool_limits[PF_LIMIT_STATES].pp, --Boundary-01=_wGsLDM4vk3VJOZT-- --nextPart1266059.rOltI5Ykkl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDLsG1XyyEoT62BG0RAvBJAJ9qUxA+7Aow7nPXzvhFfjTcBTXwoACeOtlI gAqmoGyH/Ek9770okHQ8BYY= =/5ZX -----END PGP SIGNATURE----- --nextPart1266059.rOltI5Ykkl-- From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 15:11:46 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E13B416A420 for ; Mon, 19 Sep 2005 15:11:46 +0000 (GMT) (envelope-from brett@lariat.org) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0698A43D4C for ; Mon, 19 Sep 2005 15:11:45 +0000 (GMT) (envelope-from brett@lariat.org) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id JAA04249; Mon, 19 Sep 2005 09:11:36 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.2.3.4.2.20050919085600.07f783f0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 19 Sep 2005 09:11:33 -0600 To: Luigi Rizzo From: Brett Glass In-Reply-To: <20050919005932.B60737@xorpc.icir.org> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> <20050919005932.B60737@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 15:11:47 -0000 At 01:59 AM 9/19/2005, Luigi Rizzo wrote: >Same for as the 'resume' option. It might be nice to have, >however but there is already a two-rule version (the one i >suggested, follow the non-terminating action with a skipto rule) >so its absence is not blocking you from doing what you want. That option requires repeating ALL of the matching on the packet. Not efficient, especially if the rule is complex. And pipes are usually used in pairs, so the inefficiency is doubled. >in terms of implementation, if you want to add it, the best place >would be to add the 'skipto' fields to each 'action' opcode. >I am not very interested in implementing it, though, because i still see >ipfw as a low-level language. I don't see it that way, because low level languages like assembler are normally very efficient and highly granular. The underlying opcode language of IPFW is low level for sure. But I would classify IPFW's "language," as presented by the userland utility, as "high level but limited." Sort of like the MS-DOS shell. >> I've looked at the source and it's fragmented and virtually undocumented, > >are you talking about the userland part or the kernel code ? Both. There are some parts that are better than others; for example, the kernel part is more straightforward than the userland part and has more comments. Yes, I know: some coders (the NetBSD folks are notorious for this) seem to think that if you don't want to read (and mentally reverse- engineer) all of the C code, you shouldn't be touching it. But this leads to bugs, because even a good coder won't know about "contracts" involving code in other places. >i agree the userland part is a mess. >But the kernel code i believe is reasonably documented >(of course it could be documented better - patches welcome). >the first 250 or so lines in ip_fw2.h are almost all comments >describing the opcode formats. >ip_fw2.c tries to describe rule parsing in the body of ipfw_chk() Yep, I see that. But there are implicit contracts with the userland side.... Some are obvious but some seem to be subtle. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 15:16:26 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA64416A41F for ; Mon, 19 Sep 2005 15:16:26 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E33243D48 for ; Mon, 19 Sep 2005 15:16:26 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j8JFGQK9068815; Mon, 19 Sep 2005 08:16:26 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j8JFGQAp068814; Mon, 19 Sep 2005 08:16:26 -0700 (PDT) (envelope-from rizzo) Date: Mon, 19 Sep 2005 08:16:26 -0700 From: Luigi Rizzo To: Brett Glass Message-ID: <20050919081626.B67259@xorpc.icir.org> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> <20050919005932.B60737@xorpc.icir.org> <6.2.3.4.2.20050919085600.07f783f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <6.2.3.4.2.20050919085600.07f783f0@localhost>; from brett@lariat.org on Mon, Sep 19, 2005 at 09:11:33AM -0600 Cc: net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 15:16:26 -0000 On Mon, Sep 19, 2005 at 09:11:33AM -0600, Brett Glass wrote: > At 01:59 AM 9/19/2005, Luigi Rizzo wrote: > > >Same for as the 'resume' option. It might be nice to have, > >however but there is already a two-rule version (the one i > >suggested, follow the non-terminating action with a skipto rule) > >so its absence is not blocking you from doing what you want. > > That option requires repeating ALL of the matching on the packet. absolutely not. it is the same as your 'resume' only split on two lines. > >in terms of implementation, if you want to add it, the best place > >would be to add the 'skipto' fields to each 'action' opcode. > >I am not very interested in implementing it, though, because i still see > >ipfw as a low-level language. > > I don't see it that way, because low level languages like assembler > are normally very efficient and highly granular. The underlying > opcode language of IPFW is low level for sure. But I would classify > IPFW's "language," as presented by the userland utility, as "high > level but limited." Sort of like the MS-DOS shell. whatever. feel free to write a high level interpreter, since i don't see it that way you can't expect me to do that :) cheers luigi > >> I've looked at the source and it's fragmented and virtually undocumented, > > > >are you talking about the userland part or the kernel code ? > > Both. There are some parts that are better than others; for > example, the kernel part is more straightforward than the > userland part and has more comments. > > Yes, I know: some coders (the NetBSD folks are notorious for this) > seem to think that if you don't want to read (and mentally reverse- > engineer) all of the C code, you shouldn't be touching it. But this > leads to bugs, because even a good coder won't know about "contracts" > involving code in other places. > > >i agree the userland part is a mess. > >But the kernel code i believe is reasonably documented > >(of course it could be documented better - patches welcome). > >the first 250 or so lines in ip_fw2.h are almost all comments > >describing the opcode formats. > >ip_fw2.c tries to describe rule parsing in the body of ipfw_chk() > > Yep, I see that. But there are implicit contracts with the userland > side.... Some are obvious but some seem to be subtle. > > --Brett Glass From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 15:33:05 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16D7216A41F for ; Mon, 19 Sep 2005 15:33:05 +0000 (GMT) (envelope-from brett@lariat.org) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86C1943D48 for ; Mon, 19 Sep 2005 15:33:04 +0000 (GMT) (envelope-from brett@lariat.org) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id JAA04531; Mon, 19 Sep 2005 09:32:57 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.2.3.4.2.20050919091248.07f767e8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 19 Sep 2005 09:32:36 -0600 To: John-Mark Gurney From: Brett Glass In-Reply-To: <20050919094012.GB821@funkthat.com> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> <20050919094012.GB821@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 15:33:05 -0000 At 03:40 AM 9/19/2005, John-Mark Gurney wrote: >What's awkward about: >#define PIPE_FOO 1 >#define PIPE_BAR 2 > >add pipe PIPE_FOO config bw 64kbit/sec >/* ... etc ... */ I've done that, and unfortunately it does not solve the problem I'm describing. The awkward and inefficient part comes when you have nontrivial criteria for passing the packets into the pipe. Due to the limited semantics of IPFW's "language," you must manually generate inverses of rules. This is tricky and error-prone and replaces each single rule with multiple rules, creating lots of overhead. And when you surround the rules with other rules (both manually and automatically generated), you can run into BASIC-like numbering problems. In the end, even with a preprocessor you wind up generating a rule set that's huge, complex, inefficient, spaghetti-like, and very difficult to read and maintain. To put it another way: this isn't the sort of situation that lends itself to the use of a preprocessor because the preprocessor can't solve the underlying problem: the constraints of the language it is generating. If the goal is to keep IPFW's language straightforward, simple, and readable (important for firewalls, since the results of messing up can be a catatonic machine and angry users), it's best to give it the semantics it needs to do what's necessary. The ability to negate an entire IPFW rule rather than just the individual conditions in it (that is, do a "short circuit NAND" of all the conditions in it) would be a big help, not only in this situation but in others. But the "resume" option would be even more efficient in many cases. --Brett Glass From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 15:39:51 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A3E616A447 for ; Mon, 19 Sep 2005 15:39:51 +0000 (GMT) (envelope-from andre@netvision.com.br) Received: from mx.netvision.com.br (mx12.netvision.com.br [200.247.230.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8258F43D45 for ; Mon, 19 Sep 2005 15:39:45 +0000 (GMT) (envelope-from andre@netvision.com.br) Received: from localhost (localhost [127.0.0.1]) by mailer.netvision.com.br (Postfix) with ESMTP id D90E320D9F7; Mon, 19 Sep 2005 12:39:43 -0300 (BRT) Received: from mail.server.home (unknown [201.2.208.213]) by mx.netvision.com.br (Postfix) with ESMTP id 4D9ED1F7547; Mon, 19 Sep 2005 12:39:43 -0300 (BRT) Received: from [192.168.7.3] (unknown [192.168.7.3]) by mail.server.home (Postfix) with ESMTP id 6867D6215; Mon, 19 Sep 2005 12:44:59 -0300 (BRT) Message-ID: <432EDBAD.90704@netvision.com.br> Date: Mon, 19 Sep 2005 12:39:25 -0300 From: Andre User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <432E0908.8030101@netvision.com.br> <200509191548.37693.max@love2party.net> In-Reply-To: <200509191548.37693.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at netvision.com.br Cc: Max Laier Subject: Re: PF and "set limit src-nodes" error. 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, 19 Sep 2005 15:39:51 -0000 Max Laier wrote: > On Monday 19 September 2005 02:40, Andre wrote: >>[...] >> >># echo "set limit src-nodes 1000" | pfctl -f - >>pfctl: DIOCSETLIMIT: Invalid argument >> >>[...] > > Can you please try the attached patch and report back. Seems like I missed an > initialization there :-\ It worked! Thank you! From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 15:55:50 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F334716A41F for ; Mon, 19 Sep 2005 15:55:49 +0000 (GMT) (envelope-from brett@lariat.org) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 681D143D46 for ; Mon, 19 Sep 2005 15:55:49 +0000 (GMT) (envelope-from brett@lariat.org) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id JAA04874; Mon, 19 Sep 2005 09:55:46 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.2.3.4.2.20050919093314.07f62fd8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 19 Sep 2005 09:55:34 -0600 To: Luigi Rizzo From: Brett Glass In-Reply-To: <20050919081626.B67259@xorpc.icir.org> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> <20050919005932.B60737@xorpc.icir.org> <6.2.3.4.2.20050919085600.07f783f0@localhost> <20050919081626.B67259@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 15:55:50 -0000 At 09:16 AM 9/19/2005, Luigi Rizzo wrote: >> >Same for as the 'resume' option. It might be nice to have, >> >however but there is already a two-rule version (the one i >> >suggested, follow the non-terminating action with a skipto rule) >> >so its absence is not blocking you from doing what you want. >> >> That option requires repeating ALL of the matching on the packet. > >absolutely not. it is the same as your 'resume' only split on two lines. Please explain how you would render the following as just two lines without doing all of the matching twice. pipe 17 tcp from 0.0.0.1 to any 80 in via tun* established resume 5000 See the problem? (Hint: You can't do it in less than 3 lines -- 4 if you're using a one pass preprocessor because you need to generate a jump target. And jump targets in IPFW have overhead because there really is no such thing as a NOP in IPFW. Every rule, even a jump target, is a counter.) >whatever. feel free to write a high level interpreter, >since i don't see it that way you can't expect me to do that :) I'm certainly not asking for that! I think that the "resume" option is a good way to deal with the problem. --Brett Glass P.S. -- The ability to negate an entire rule (that is, a "short circuit NAND" of all of the conditions) would also come in handy, though I am not sure what syntax would be best for it. Maybe placing the "not" before the action, like this: not skipto 5000 tcp from 0.0.0.1 to any 80 in via tun* established Note that this isn't as efficient as a "resume" in the example I've shown above, but can be very efficient in other situations. From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 16:09:02 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AB3D16A41F for ; Mon, 19 Sep 2005 16:09:02 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47B8843D6D for ; Mon, 19 Sep 2005 16:08:54 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp1-g19.free.fr (Postfix) with ESMTP id 574CC2F626; Mon, 19 Sep 2005 18:08:53 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id C84EB405D; Mon, 19 Sep 2005 18:08:53 +0200 (CEST) Date: Mon, 19 Sep 2005 18:08:53 +0200 From: Jeremie Le Hen To: Brett Glass Message-ID: <20050919160853.GA24643@obiwan.tataz.chchile.org> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> <20050919005932.B60737@xorpc.icir.org> <6.2.3.4.2.20050919085600.07f783f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.3.4.2.20050919085600.07f783f0@localhost> User-Agent: Mutt/1.5.10i Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 16:09:02 -0000 Luigi, Brett, > >in terms of implementation, if you want to add it, the best place > >would be to add the 'skipto' fields to each 'action' opcode. > >I am not very interested in implementing it, though, because i still see > >ipfw as a low-level language. Is it a goal or an observation ? > I don't see it that way, because low level languages like assembler > are normally very efficient and highly granular. The underlying > opcode language of IPFW is low level for sure. But I would classify > IPFW's "language," as presented by the userland utility, as "high > level but limited." Sort of like the MS-DOS shell. While I'm quite reluctant to complixify ipfw syntax, I must admit that having the possibility to negate a whole rule could speed up well-thought rulesets. Efficiency _is_ a goal of ipfw. This would certainly simplify some rulesets, avoiding to use De Morgan's theorem, but more importantly, this will also prevent to tests for N rules when you just want to test for the negation of N criterions. At very high PPS, when pf is not an option any more but ipfw still is, this might create a gap with the current implementation. OTOH, I agree with Luigi about the "resume" keyword. This introduces a kind of linked-lists, but this is just syntactic sugar and I can't see any performance improvement with this. This might be worth to have but I'm a little but scared about adding such options because there would be no reason then to not add other syntactic facilities, which would end up messing the whole syntax. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 16:20:08 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EA9816A41F for ; Mon, 19 Sep 2005 16:20:08 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BB0743D60 for ; Mon, 19 Sep 2005 16:20:03 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j8JGK3xO069520; Mon, 19 Sep 2005 09:20:03 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j8JGK3vZ069519; Mon, 19 Sep 2005 09:20:03 -0700 (PDT) (envelope-from rizzo) Date: Mon, 19 Sep 2005 09:20:03 -0700 From: Luigi Rizzo To: Jeremie Le Hen Message-ID: <20050919092003.A69332@xorpc.icir.org> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> <20050919005932.B60737@xorpc.icir.org> <6.2.3.4.2.20050919085600.07f783f0@localhost> <20050919160853.GA24643@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20050919160853.GA24643@obiwan.tataz.chchile.org>; from jeremie@le-hen.org on Mon, Sep 19, 2005 at 06:08:53PM +0200 Cc: Brett Glass , net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 16:20:08 -0000 On Mon, Sep 19, 2005 at 06:08:53PM +0200, Jeremie Le Hen wrote: > Luigi, Brett, > > > >in terms of implementation, if you want to add it, the best place > > >would be to add the 'skipto' fields to each 'action' opcode. > > >I am not very interested in implementing it, though, because i still see > > >ipfw as a low-level language. > > Is it a goal or an observation ? > > > I don't see it that way, because low level languages like assembler > > are normally very efficient and highly granular. The underlying > > opcode language of IPFW is low level for sure. But I would classify > > IPFW's "language," as presented by the userland utility, as "high > > level but limited." Sort of like the MS-DOS shell. > > While I'm quite reluctant to complixify ipfw syntax, I must admit that > having the possibility to negate a whole rule could speed up well-thought original ipfw add 1000 dosomething cond1 cond2 cond3 cond4 cond5 ... condN negated: ipfw add 1000 skipto 1001 cond1 cond2 cond3 cond4 cond5 ... condN ipfw add 1000 dosomething sure if 'dosomething' is non-terminal in some cases you need 3 instead of 2 rules skipto are extremely efficient (just a pointer dereference), almost as efficient as it would be a 'resume' option. cheers luigi > rulesets. Efficiency _is_ a goal of ipfw. This would certainly > simplify some rulesets, avoiding to use De Morgan's theorem, but more > importantly, this will also prevent to tests for N rules when you just > want to test for the negation of N criterions. At very high PPS, when > pf is not an option any more but ipfw still is, this might create a gap > with the current implementation. > > OTOH, I agree with Luigi about the "resume" keyword. This introduces > a kind of linked-lists, but this is just syntactic sugar and I can't > see any performance improvement with this. This might be worth to have > but I'm a little but scared about adding such options because there > would be no reason then to not add other syntactic facilities, which > would end up messing the whole syntax. > > Best regards, > -- > Jeremie Le Hen > < jeremie at le-hen dot org >< ttz at chchile dot 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" From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 16:25:52 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E47F16A41F for ; Mon, 19 Sep 2005 16:25:52 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA6CA43D46 for ; Mon, 19 Sep 2005 16:25:51 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp2-g19.free.fr (Postfix) with ESMTP id CE767258C7; Mon, 19 Sep 2005 18:25:49 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 60BA5405D; Mon, 19 Sep 2005 18:25:50 +0200 (CEST) Date: Mon, 19 Sep 2005 18:25:50 +0200 From: Jeremie Le Hen To: Motonori Shindo Message-ID: <20050919162550.GB24643@obiwan.tataz.chchile.org> References: <432D9249.9090202@mac.com> <432DA0AC.8010802@thedarkside.nl> <432DA922.5030303@errno.com> <20050919.111418.71083866.mshindo@mshindo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050919.111418.71083866.mshindo@mshindo.net> User-Agent: Mutt/1.5.10i Cc: pieter@thedarkside.nl, freebsd-net@freebsd.org Subject: Re: ARP behavior in FreeBSD vs Linux 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, 19 Sep 2005 16:25:52 -0000 Hi, > > >>> In contrast, on Linux (by default), it > > >>> responds as long as the target IP address in ARP Request matches with > > >>> any "local" IP address on the system, which is not necessarily an IP > > >>> address assigned to the interface through which the ARP request is > > >>> received. > > >> > > >> This sounds like "proxy ARPing" is enabled by default on your > > >> particular flavor of Linux. I don't think they all do that, > > >> hopefully, any more than ipforwarding should be enabled by default > > >> just because a machine has two NICs. > > > > > > What Motonori Shindo described is actually the default behaviour for > > > Linux kernels (at least my 2.6.8-kernel does it by default). > > It seems that it has been so for a long time since 2.2 kernel days. > > > > It could be > > > seen as a sort of proxy-arp, but only for the host itself, not other > > > systems. Let me try to describe when it happens. Say you have > > > 192.168.42.42 bound on eth0 and have eth1 connected to some ethernet > > > LAN. When a host on that eth1-connected LAN sends an 'arp who-has > > > 192.168.42.42', a Linux system will answer that arp-request with it's > > > eth1 MAC-address, although the IP-address is bound on eth0 and the arp > > > request comes in on eth0. FreeBSD obviously doesn't do this. FYI, proxy ARPing for a whole subnet might be enabled on Linux with the following sysctl, in order to create what they call a "pseudo-bridge" : /proc/sys/net/ipv4/conf//proxy_arp When a Linux box is a router between two subnets A and B, if a host on A issues an ARP request about a host on B (because they think to be on the same physical network), the Linux box will reply with its own MAC address, and conversely. > > > Incoming traffic on > > > the 'wrong' interface will gladly be accepted, too. This broke things > > > for me, because I didn't want to have that certain IP-address accessible. This behaviour can be controlled with : /proc/sys/net/ipv4/conf//rp_filter These sysctl are explained in the Linux kernel source : linux/Documentation/networking/ip-sysctl.txt Please, don't blame me because this is not FreeBSD-centric. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 16:51:40 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A90FE16A41F for ; Mon, 19 Sep 2005 16:51:40 +0000 (GMT) (envelope-from brett@lariat.org) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09D2F43D46 for ; Mon, 19 Sep 2005 16:51:39 +0000 (GMT) (envelope-from brett@lariat.org) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id KAA05893; Mon, 19 Sep 2005 10:51:34 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.2.3.4.2.20050919103431.07f59008@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 19 Sep 2005 10:51:31 -0600 To: Jeremie Le Hen From: Brett Glass In-Reply-To: <20050919160853.GA24643@obiwan.tataz.chchile.org> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> <20050919005932.B60737@xorpc.icir.org> <6.2.3.4.2.20050919085600.07f783f0@localhost> <20050919160853.GA24643@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 16:51:40 -0000 At 10:08 AM 9/19/2005, Jeremie Le Hen wrote: >OTOH, I agree with Luigi about the "resume" keyword. This introduces >a kind of linked-lists, but this is just syntactic sugar and I can't >see any performance improvement with this. I think that a few examples might show why it'd be more than syntactic sugar. Let's take the one I just sent to Luigi: pipe 17 tcp from 0.0.0.1 to any 80 in via tun* established resume 5000 Let's look at how would you render this without the "resume 5000" at the end. There are really three ways: 1) You could duplicate all of the conditions in a "skipto" rule, which would be inefficient because all the matching would be done twice. 2) You could do a "skipto around a skipto", but this would require at least four rules (including a final jump target) if you generated it automatically in one pass or wanted it to be maintainable by hand without tedious manual renumbering. 3) You could DeMorganize, which is very inefficient on matching packets and generates extremely complex rulesets. >This might be worth to have >but I'm a little but scared about adding such options because there >would be no reason then to not add other syntactic facilities, which >would end up messing the whole syntax. I am concerned about this too, and that's why I suggested "resume" as a trailing option. IPFW rules currently have all kinds of trailing options, involving everything from test for arcane TCP flags to "verrevpath" (a firewall function which incurs a lot of overhead but is quite powerful). A "resume" option wouldn't introduce any backward incompatibilities, and if the user didn't know about it, it would not get in the way. I agree with you that the ability to negate the "AND" of all conditions in the rule would greatly clarify some rulesets. I know it would help with many of mine! --Brett Glass From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 17:20:58 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C89816A41F for ; Mon, 19 Sep 2005 17:20:58 +0000 (GMT) (envelope-from brett@lariat.org) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4617743D48 for ; Mon, 19 Sep 2005 17:20:56 +0000 (GMT) (envelope-from brett@lariat.org) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id LAA06333; Mon, 19 Sep 2005 11:20:49 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.2.3.4.2.20050919105218.07f5b0d8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 19 Sep 2005 11:20:46 -0600 To: Luigi Rizzo , Jeremie Le Hen From: Brett Glass In-Reply-To: <20050919092003.A69332@xorpc.icir.org> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> <20050919005932.B60737@xorpc.icir.org> <6.2.3.4.2.20050919085600.07f783f0@localhost> <20050919160853.GA24643@obiwan.tataz.chchile.org> <20050919092003.A69332@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 17:20:58 -0000 At 10:20 AM 9/19/2005, Luigi Rizzo wrote: >original > > ipfw add 1000 dosomething cond1 cond2 cond3 cond4 cond5 ... condN > >negated: > > ipfw add 1000 skipto 1001 cond1 cond2 cond3 cond4 cond5 ... condN > ipfw add 1000 dosomething This doesn't work, because you must transform cond1 && cond2 && cond3... into multiple rules that implement ~(cond1 || cond2 || cond3...). So, you'd need do do the following: ipfw add 1000 skipto 1001 not cond1 ipfw add 1000 skipto 1001 not cond2 ... (N rules total) ipfw add 1000 skipto 1001 not condN ipfw add 1000 dosomething ipfw add 1000 skipto 5000 // Where to resume on success ipfw add 1001 // Jump target; implemented in IPFW as "count ip from any to any" The other way to do it is via "spaghetti rules:" ipfw add 1000 skipto 1002 cond1 cond2 cond3 cond4 cond5 ... condN ipfw add 1001 skipto 1003 ipfw add 1002 dosomething ipfw add 1002 skipto 5000 // Where to resume on success ipfw add 1003 // Jump target; implemented inside IPFW as "count ip from any to any" Or you can do the entire pattern match twice: ipfw add 1000 dosomething cond1 cond2 cond3 cond4 cond5 ... condN ipfw add 1000 skipto 5000 cond1 cond2 cond3 cond4 cond5 ... condN --Brett From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 19:05:30 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D56716A41F for ; Mon, 19 Sep 2005 19:05:30 +0000 (GMT) (envelope-from brett@lariat.org) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6A1743D45 for ; Mon, 19 Sep 2005 19:05:29 +0000 (GMT) (envelope-from brett@lariat.org) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id NAA07636; Mon, 19 Sep 2005 13:05:23 -0600 (MDT) X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. Message-Id: <6.2.3.4.2.20050919130155.07b45850@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 19 Sep 2005 13:05:20 -0600 To: Luigi Rizzo , Jeremie Le Hen From: Brett Glass Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 19 Sep 2005 19:05:30 -0000 Oops! In my earlier message, I said: >This doesn't work, because you must transform cond1 && cond2 && cond3... >into multiple rules that implement ~(cond1 || cond2 || cond3...). I should have said that you must implement !(!cond1 || !cond2 || !cond3...). --Brett From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 20:27:13 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CA0116A41F for ; Mon, 19 Sep 2005 20:27:13 +0000 (GMT) (envelope-from david.vos@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BD9043D46 for ; Mon, 19 Sep 2005 20:27:12 +0000 (GMT) (envelope-from david.vos@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so69272nzk for ; Mon, 19 Sep 2005 13:27:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EKGRN6fy+kvzyOl+0iFCFDULAapZ6M66otMm6NHmEg2tbi7NjmO4V24hD6lBRmFxWy1Vr85/s+Sq5pMh94YIsk0zzbHrcb+DW6k7iJBNmJKkEKu/pG/Punlz5efjXrKkF+KqWK1MkmVRBP/B8KYCV6/4vu7ASKJZmAKNeNZBeWU= Received: by 10.54.32.36 with SMTP id f36mr1310884wrf; Mon, 19 Sep 2005 13:27:11 -0700 (PDT) Received: by 10.54.98.5 with HTTP; Mon, 19 Sep 2005 13:27:11 -0700 (PDT) Message-ID: <16e39c510509191327197c2c44@mail.gmail.com> Date: Mon, 19 Sep 2005 14:27:11 -0600 From: David Vos To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: ng_split.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.vos@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 20:27:13 -0000 The version of ng_split.c packaged with 5.4 Release has a bug in it that causes items to get lost (not freed) if there are no nodes connected on the other end. This has been fixed in the CVS, Revision 1.7 Would it be possible to bring this 1.7 revision into FreeBSD 5.4 Release? David From owner-freebsd-net@FreeBSD.ORG Mon Sep 19 20:55:03 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2273016A41F for ; Mon, 19 Sep 2005 20:55:03 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9651D43D45 for ; Mon, 19 Sep 2005 20:55:02 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j8JKt1e6069200; Mon, 19 Sep 2005 13:55:01 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j8JKt0Yc069177; Mon, 19 Sep 2005 13:55:00 -0700 (PDT) (envelope-from jmg) Date: Mon, 19 Sep 2005 13:54:59 -0700 From: John-Mark Gurney To: Brett Glass Message-ID: <20050919205459.GD821@funkthat.com> Mail-Followup-To: Brett Glass , Luigi Rizzo , net@freebsd.org References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> <20050919094012.GB821@funkthat.com> <6.2.3.4.2.20050919091248.07f767e8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.3.4.2.20050919091248.07f767e8@localhost> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Luigi Rizzo , net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2005 20:55:03 -0000 Brett Glass wrote this message on Mon, Sep 19, 2005 at 09:32 -0600: > At 03:40 AM 9/19/2005, John-Mark Gurney wrote: > > >What's awkward about: > >#define PIPE_FOO 1 > >#define PIPE_BAR 2 > > > >add pipe PIPE_FOO config bw 64kbit/sec > >/* ... etc ... */ > > I've done that, and unfortunately it does not solve the problem > I'm describing. If you paid attention to what I quoted, I never said my message addressed your overall problem... if you paid attention to what I quoted, you would see that I was simply replying to your message text: I've tried this. Alas, it quickly gets out of hand because objects in IPFW (for example pipes) aren't named. You wind up literally having to build a symbol table to keep track of rule numbers, pipe numbers, etc. Yes, you can do it, but it's very awkward. But with the suggestion of someone else, you can build a set of rules that do: #define PIPE_FOO 1 #define PIPE_BAR 1 #define FOO 10000 #define BAR 11000 #define CONT 30000 add skipto FOO tcp from any to any 22 add skipto BAR tcp from any to any 80 add skipto CONT ip from any to any add FOO pipe PIPE_FOO ip from any to any add skipto CONT ip from any to any add BAR pipe PIPE_BAR ip from any to any add skipto CONT ip from any to any add CONT count ip from any to any and there you go... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Tue Sep 20 02:53:09 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F4D416A41F; Tue, 20 Sep 2005 02:53:09 +0000 (GMT) (envelope-from dmehler26@woh.rr.com) Received: from ms-smtp-02-eri0.ohiordc.rr.com (ms-smtp-02-smtplb.ohiordc.rr.com [65.24.5.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AB6043D45; Tue, 20 Sep 2005 02:53:08 +0000 (GMT) (envelope-from dmehler26@woh.rr.com) Received: from titan (cpe-65-31-44-187.woh.res.rr.com [65.31.44.187]) by ms-smtp-02-eri0.ohiordc.rr.com (8.12.10/8.12.7) with SMTP id j8K2r5XV008516; Mon, 19 Sep 2005 22:53:06 -0400 (EDT) Message-ID: <000701c5bd8e$98fa18a0$0100a8c0@titan> From: "Dave" To: Date: Mon, 19 Sep 2005 22:54:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: freebsd-pf@freebsd.org Subject: pftpx failing on freebsd 5.4-stable 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, 20 Sep 2005 02:53:09 -0000 Hello, I'm trying to get ftp working from my lan to the internet. I'm using a deny by default policy and only allowing out specific traffic. My rules are below. I start pftpx and load the pf.conf file, all is good, until i try to ftp. Going from the gateway box ftp can at least log on to the site and does a 200EPRT command which eventually times out, anything behind the gateway doesn't even get that far. I log everything via pflog and i do not see any ftp or pftpx output in the logs at all. In /var/log/messages i do see this: Sep 19 22:36:07 guardian kernel: pflog0: promiscuous mode enabled Sep 19 22:36:55 guardian pftpx[630]: #3 pf operation failed: Invalid argument Sep 19 22:36:55 guardian pftpx[630]: #3 pf rule removal failed: Invalid argument Sep 19 22:39:55 guardian pftpx[630]: #4 pf operation failed: Invalid argument Sep 19 22:39:55 guardian pftpx[630]: #4 pf rule removal failed: Invalid argument Any help appreciated, i'd really like to get this going. Thanks. Dave. # pf.conf # for use on gateway box # Required order: options, normalization, queueing, translation, filtering. # Macros and tables may be defined and used anywhere. # Note that translation rules are first match while filter rules are last match. # macros # define the two network interfaces ext_if="xl0" int_if="xl1" # define our networks lan_net="192.168.7.0/24" # define servers lan_server="192.168.7.3" nameservers = "{ xxx }" isp_dhcp_server = "xxx" # define services int_to_lan_services = "{ ssh, smtp, www, pop3, https, pop3s, 8000 }" lan_to_int_services = "{ ftp-data, ftp, ssh, smtp, 43, domain, http, pop3, nntp, imap, https, imaps, pop3s, 1790, 1791, 1792, 1793, 1794, 1795, 2401, 4000, 5000, 5001, 5190, cvsup, 6112, 6667, 8000, 8080, 8505, 8880, 9102 }" # options set optimization normal set block-policy return set require-order yes set fingerprints "/etc/pf.os" # This helps protect against my maximum states being reached # when being port scanned. set timeout tcp.closed 1 set timeout { interval 10, frag 30 } set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 } set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 } set timeout { udp.first 60, udp.single 30, udp.multiple 60 } set timeout { icmp.first 20, icmp.error 10 } set timeout { other.first 60, other.single 30, other.multiple 60 } set timeout { adaptive.start 0, adaptive.end 0 } set limit { states 10000, frags 5000 } # normalize packets to prevent fragmentation attacks scrub on $ext_if all random-id reassemble tcp scrub on $int_if inet no-df # nat # translate lan client addresses to that of the externalinterface nat on $ext_if from $int_if:network to any -> ($ext_if) nat-anchor "pftpx/*" # redirections rdr on $ext_if proto tcp from any to any port $int_to_lan_services -> $lan_server # pftpx ftp proxy rdr-anchor "pftpx/*" rdr pass on $int_if proto tcp from $int_if:network to any port 21 -> 127.0.0.1 port 8021 # default deny block log all # immediately prevent IPv6 traffic from entering or leaving all interfaces block quick inet6 all # pass loopback traffic pass quick on lo0 all # pftpx proxy traffic anchor "pftpx /*" # antispoof options antispoof quick for $ext_if inet antispoof quick for $int_if inet # External interface (Incoming) # Allow dhcp in pass in quick on $ext_if inet proto udp from $isp_dhcp_server port bootps to 255.255.255.255 port bootpc # Allow internet requests through in order to contact lan server # keep state on this connection pass in quick on $ext_if inet proto tcp from any to $lan_server port $int_to_lan_services flags S/SA keep state pass in quick on $ext_if inet proto udp from any to $lan_server port 1194 keep state # External interface (outgoing) # allow dhcp out pass out quick on $ext_if inet proto udp from $ext_if to any port bootps # allow UDP requests to port 53 from firewall to exit ext_if # in order to contact internet nameservers (keep state on this connection) pass out quick on $ext_if inet proto udp from $ext_if to $nameservers port 53 keep state # allow UDP requests to port 123 from firewall to exit ext_if # in order to contact internet ntp servers # (keep state on this connection) pass out quick on $ext_if inet proto udp from $ext_if to any port 123 keep state # Allow traffic from lan clients to exit $ext_if # (After natting is performed) in order to contact internet servers # (Keep state on this connection) pass out quick on $ext_if inet proto tcp from $ext_if to any port $lan_to_int_services flags S/SA keep state # allow out the default range for traceroute(8): # "base+nhops*nqueries-1" (33434+64*3-1) pass out quick on $ext_if inet proto udp from any to any \ port 33433 >< 33626 keep state # Internal interface (incoming) # allow lan broadcasts pass in quick on $int_if proto { tcp, udp } from $lan_net to $int_if:broadcast # allow UDP requests to port 53 from lan clients to enter LAN # in order to perform dns queries on the firewall # (keep state on this connection) pass in quick on $int_if inet proto udp from $lan_net to $int_if port 53 keep state # allow UDP requests to ports 67, 68, and 123 from lan clients to enter lan # in order to perform dhcp and ntp queries on the firewall # ( Keep state on this connection) pass in quick on $int_if inet proto udp from $lan_net to $int_if port { 67, 68, 123, 6112 } keep state # allow lan traffic from lan clients to enter lan # in order to contact internet servers (keep state on this connection) pass in quick on $int_if inet proto tcp from $lan_net to any port $lan_to_int_services flags S/SA keep state # allow requests from lan admin to enter LAN # in order to ping/traceroute any system (firewall, dmz server, and internet hosts) pass in quick on $int_if inet proto icmp from $lan_net to any icmp-type 8 keep state # Internal interface (Outgoing) # Allow internet requests to exit lan # in order to contact internet servers pass out quick on $int_if inet proto tcp from any to $lan_server port $int_to_lan_services keep state # Firewall connects to the lan server via scp/ssh for backup purposes pass out quick on $int_if inet proto tcp from $int_if to $lan_server port 22 flags S/SA keep state # firewall connects back to the storage daemon # on the lan server port 9103 to enable it to back up pass out quick on $int_if inet proto tcp from $int_if to $lan_server port { 9101, 9102, 9103 } flags S/SA keep state From owner-freebsd-net@FreeBSD.ORG Tue Sep 20 04:05:33 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A3C516A41F for ; Tue, 20 Sep 2005 04:05:33 +0000 (GMT) (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 785DB43D45 for ; Tue, 20 Sep 2005 04:05:28 +0000 (GMT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.4) with SMTP id OAA07842; Tue, 20 Sep 2005 14:04:50 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 20 Sep 2005 14:04:49 +1000 (EST) From: Ian Smith To: Brett Glass In-Reply-To: <6.2.3.4.2.20050919105218.07f5b0d8@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Luigi Rizzo , Jeremie Le Hen , net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 20 Sep 2005 04:05:33 -0000 On Mon, 19 Sep 2005, Brett Glass wrote: > At 10:20 AM 9/19/2005, Luigi Rizzo wrote: > > >original > > > > ipfw add 1000 dosomething cond1 cond2 cond3 cond4 cond5 ... condN > > > >negated: > > > > ipfw add 1000 skipto 1001 cond1 cond2 cond3 cond4 cond5 ... condN > > ipfw add 1000 dosomething > > This doesn't work, because you must transform cond1 && cond2 && cond3... > into multiple rules that implement ~(cond1 || cond2 || cond3...). So, .. later corrected? to .. > I should have said that you must implement !(!cond1 || !cond2 || !cond3...). That would be silly, either way. It does work. You started off saying: | Unfortunately, because IPFW doesn't have a "not" that can cover the | "and" of all the conditions in the rule -- that is, you can't say | "not (ip from A to any in via fxp1)" -- it's very difficult to do | this with a single rule containing a "skipto" action. What's more, | there's no "resume at" clause available in IPFW that would change | where a packet was reinjected, and no such thing as a "come from" [..] So what Luigi says is absolutely correct for that desired negation. No, you can't do it with a SINGLE rule; it is low level, consider it RISC. > you'd need do do the following: > > ipfw add 1000 skipto 1001 not cond1 > ipfw add 1000 skipto 1001 not cond2 > ... (N rules total) > ipfw add 1000 skipto 1001 not condN > ipfw add 1000 dosomething > ipfw add 1000 skipto 5000 // Where to resume on success > ipfw add 1001 // Jump target; implemented in IPFW as "count ip from any to any" 1000 skipto 1001 cond1 cond2 cond3 .. # ie (cond1 AND cond2 AND ..) 1000 dosomethingsuchasyourpipe # performed on NOT (cond1 AND ...) 1000 skipto 5000 ip from any to any # your 'resume after pipe' .. rule 1001, your 'jump target' will just be your next test, or the next rule can be any number rule >= 1001. So there's extra no cost for it. And as Luigi pointed out, skipto is fast. > The other way to do it is via "spaghetti rules:" > > ipfw add 1000 skipto 1002 cond1 cond2 cond3 cond4 cond5 ... condN > ipfw add 1001 skipto 1003 > ipfw add 1002 dosomething > ipfw add 1002 skipto 5000 // Where to resume on success > ipfw add 1003 // Jump target; implemented inside IPFW as "count ip from any to any" Spaghetti like that is just not needed. See above. > Or you can do the entire pattern match twice: > > ipfw add 1000 dosomething cond1 cond2 cond3 cond4 cond5 ... condN > ipfw add 1000 skipto 5000 cond1 cond2 cond3 cond4 cond5 ... condN I can't see your desire to save ONE rule is worth trying to convince somebody ELSE to tackle the code for a feature only you seem to want. And if lots of similar rulesets are needed, write a script or use the preprocessor as suggested (the latter's beyond me, but not the former) cheers, Ian From owner-freebsd-net@FreeBSD.ORG Tue Sep 20 07:15:07 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84F5416A41F for ; Tue, 20 Sep 2005 07:15:07 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7167243D45 for ; Tue, 20 Sep 2005 07:15:06 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp1-g19.free.fr (Postfix) with ESMTP id B1F0E10478; Tue, 20 Sep 2005 09:15:04 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id A063C405D; Tue, 20 Sep 2005 09:15:04 +0200 (CEST) Date: Tue, 20 Sep 2005 09:15:04 +0200 From: Jeremie Le Hen To: Brett Glass Message-ID: <20050920071504.GC24643@obiwan.tataz.chchile.org> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> <20050919005932.B60737@xorpc.icir.org> <6.2.3.4.2.20050919085600.07f783f0@localhost> <20050919160853.GA24643@obiwan.tataz.chchile.org> <20050919092003.A69332@xorpc.icir.org> <6.2.3.4.2.20050919105218.07f5b0d8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.3.4.2.20050919105218.07f5b0d8@localhost> User-Agent: Mutt/1.5.10i Cc: Luigi Rizzo , Jeremie Le Hen , net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 20 Sep 2005 07:15:07 -0000 Hi Brett, Luigi, all, > >original > > > > ipfw add 1000 dosomething cond1 cond2 cond3 cond4 cond5 ... condN > > > >negated: > > > > ipfw add 1000 skipto 1001 cond1 cond2 cond3 cond4 cond5 ... condN > > ipfw add 1000 dosomething > > This doesn't work, because you must transform cond1 && cond2 && cond3... > into multiple rules that implement ~(cond1 || cond2 || cond3...). So, > you'd need do do the following: > > ipfw add 1000 skipto 1001 not cond1 > ipfw add 1000 skipto 1001 not cond2 > ... (N rules total) > ipfw add 1000 skipto 1001 not condN > ipfw add 1000 dosomething > ipfw add 1000 skipto 5000 // Where to resume on success > ipfw add 1001 I tend to agree with Luigi now. I didn't realize this before, but let's apply De Morgan's theorem. Each condition is identified as a small letter "a", "b", "c". "/a" means "not a" and the "." operator is AND, while the "+" operator is OR. The above "original" rule is therefore : a.b.c The above "negated" rule is obviously : /(a.b.c) With your ruleset may be summed up as : /a+/b+/c Which is the same as the "negated" rule in regard to De Morgan's theorem. Do you agree with this ? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Tue Sep 20 12:45:43 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1B3216A41F for ; Tue, 20 Sep 2005 12:45:43 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34BEB43D48 for ; Tue, 20 Sep 2005 12:45:43 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 5E17246B80; Tue, 20 Sep 2005 08:45:42 -0400 (EDT) Date: Tue, 20 Sep 2005 13:45:42 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Milscvaer In-Reply-To: <20050918212110.61962.qmail@web54501.mail.yahoo.com> Message-ID: <20050920134408.Y34322@fledge.watson.org> References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: UDP dont fragment bit 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, 20 Sep 2005 12:45:43 -0000 On Sun, 18 Sep 2005, Milscvaer wrote: > FreeBSD ought to add per-socket socket options to allow a programmer to > turn on and off the don't fragment bit for UDP and the UDP checksum, on > a per socket basis. > > FreeBSD needs to implement this feature. We requested this same feature > years ago and I cannot believe such a simple, basic feature is still not > implemented, or not documented in the setsockopt manpage anyhow. This > needs to be implemented. We need it. Trust me. For whatever reason, it turns out that you and only you have requested this feature. For typicaly network debugging applications, a raw socket is used, which allows the direct frobbing the the IP DF bit. For example, in traceroute(8). Could you tell us a bit more about the application and proposed use? Presumably forcing the DF bit isn't much use unless you can also retrieve useful reporting on the ICMP errors associated with needing the fragment? Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Tue Sep 20 15:12:27 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EAC216A41F for ; Tue, 20 Sep 2005 15:12:27 +0000 (GMT) (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 EC10743D46 for ; Tue, 20 Sep 2005 15:12:26 +0000 (GMT) (envelope-from freebsd-net@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1EHjkx-0004o7-6K for freebsd-net@freebsd.org; Tue, 20 Sep 2005 17:10:03 +0200 Received: from mulder.f5.com ([205.229.151.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Sep 2005 17:10:03 +0200 Received: from atkin901 by mulder.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Sep 2005 17:10:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: othermark Date: Tue, 20 Sep 2005 07:51:32 -0700 Lines: 35 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulder.f5.com User-Agent: KNode/0.9.2 Sender: news Subject: rfc2385 (tcp md5 checksums) in -current 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: Tue, 20 Sep 2005 15:12:27 -0000 I am posting this to -net since I got zip response on -current... Hi, I'm testing rfc2385 support with some of our equipment with current as of a few days ago, and the support seems, well, rather broken. I have the following options in my kernel options TCP_SIGNATURE #include support for RFC 2385 options FAST_IPSEC device crypto and have loaded the following entry via setkey: add 172.16.17.1 172.16.18.164 tcp 0x1000 -A tcp-md5 "password" ; but when I dump a test link to the inetd tcp echo server, I get no connection. The dump shows the sending box 172.16.18.164 has the correct signature for the shared secret (with the tcpdump -M option), but the FreeBSD boxes response shows invalid. 12:46:25.377320 IP 172.16.18.164.50850 > 172.16.17.1.echo: S 371298114:371298114(0) win 4380 12:46:25.377401 IP 172.16.17.1.echo > 172.16.18.164.50850: S 3974454780:3974454780(0) ack 371298115 win 65535 Now it could be that the tcp stack is just sending garbage for the MD5 option when it receives it on a socket that doesn't have some sort of socket option configured (which would be bad). othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); From owner-freebsd-net@FreeBSD.ORG Tue Sep 20 16:26:47 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC8F516A41F for ; Tue, 20 Sep 2005 16:26:47 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 501EF43D45 for ; Tue, 20 Sep 2005 16:26:47 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (221x117x177x135.ap221.ftth.ucom.ne.jp [221.117.177.135]) by r-dd.iij4u.or.jp (4U-MR/r-dd) id j8KGQjDo021231; Wed, 21 Sep 2005 01:26:46 +0900 (JST) Date: Wed, 21 Sep 2005 01:26:26 +0900 (JST) Message-Id: <20050921.012626.74752754.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: othermark In-Reply-To: References: X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: rfc2385 (tcp md5 checksums) in -current 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: Tue, 20 Sep 2005 16:26:48 -0000 > I'm testing rfc2385 support with some of our equipment with current > as of a few days ago, and the support seems, well, rather broken. I think there is a bug in syncache_respond(). In tcp_syncache.c rev 1.77, tcp_signature_compute() is called before filling the TCP SACK Permitted option and the TCP EOL option. I guess it should be called after filling both the SACK Permitted and EOL option. If this is the cause of the problem, I think it was broken when SACK was imported. However, when we suggested the change of rev 1.73, I should notice the bug. I am sorry I did not know how to test the signature option well. I will try to make a patch tomorrow. Regards, Noritoshi Demizu From owner-freebsd-net@FreeBSD.ORG Tue Sep 20 18:24:43 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D08E616A41F for ; Tue, 20 Sep 2005 18:24:43 +0000 (GMT) (envelope-from flag@oltrelinux.com) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6656E43D45 for ; Tue, 20 Sep 2005 18:24:42 +0000 (GMT) (envelope-from flag@oltrelinux.com) Received: from southcross.homeunix.org (ip-90-199.sn1.eutelia.it [62.94.90.199]) by mail.oltrelinux.com (Postfix) with ESMTP id 9C9A711AE44; Tue, 20 Sep 2005 20:24:42 +0200 (CEST) Received: by southcross.homeunix.org (Postfix, from userid 1001) id 4169040D5; Tue, 20 Sep 2005 20:26:54 +0200 (CEST) Date: Tue, 20 Sep 2005 20:26:54 +0200 From: Paolo Pisati To: Brett Glass Message-ID: <20050920182654.GA1384@tin.it> References: <6.2.3.4.2.20050918205708.08cff430@localhost> <20050918235659.B60185@xorpc.icir.org> <6.2.3.4.2.20050919010035.07dfc448@localhost> <20050919005932.B60737@xorpc.icir.org> <6.2.3.4.2.20050919085600.07f783f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.3.4.2.20050919085600.07f783f0@localhost> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: net@freebsd.org Subject: Re: Efficient use of Dummynet pipes in IPFW 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, 20 Sep 2005 18:24:43 -0000 On Mon, Sep 19, 2005 at 09:11:33AM -0600, Brett Glass wrote: > I don't see it that way, because low level languages like assembler > are normally very efficient and highly granular. The underlying > opcode language of IPFW is low level for sure. But I would classify > IPFW's "language," as presented by the userland utility, as "high > level but limited." Sort of like the MS-DOS shell. just out of curiosity, what are the abilities that you miss in ipfw? (apart from the already mentioned problem) let me quote you again: > I would classify IPFW's "language," as presented by the userland > utility, as "high level but limited." what are the lowlevel bits that you miss? are you talking about the ability to directly manipulate data in a network packet or what? i'm very interested in this topic... -- Paolo From owner-freebsd-net@FreeBSD.ORG Tue Sep 20 18:41:51 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86E0916A41F for ; Tue, 20 Sep 2005 18:41:51 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from mail-svr1.cs.utah.edu (brahma.cs.utah.edu [155.98.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3813243D46 for ; Tue, 20 Sep 2005 18:41:51 +0000 (GMT) (envelope-from vaibhave@cs.utah.edu) Received: from localhost (localhost [127.0.0.1]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 8B2C8346ED; Tue, 20 Sep 2005 12:41:50 -0600 (MDT) Received: from mail-svr1.cs.utah.edu ([127.0.0.1]) by localhost (mail-svr1.cs.utah.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05919-10; Tue, 20 Sep 2005 12:41:50 -0600 (MDT) Received: from trust.cs.utah.edu (trust.cs.utah.edu [155.98.65.28]) by mail-svr1.cs.utah.edu (Postfix) with ESMTP id 3BF33346EC; Tue, 20 Sep 2005 12:41:50 -0600 (MDT) Received: by trust.cs.utah.edu (Postfix, from userid 4969) id 16F953F6C; Tue, 20 Sep 2005 12:41:50 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by trust.cs.utah.edu (Postfix) with ESMTP id 07C2B3F6B; Tue, 20 Sep 2005 12:41:50 -0600 (MDT) Date: Tue, 20 Sep 2005 12:41:50 -0600 (MDT) From: Vaibhave Agarwal To: rizzo@icir.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at cs.utah.edu Cc: freebsd-net@freebsd.org Subject: options Hz=100000, scheduling at 10 microseconds 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, 20 Sep 2005 18:41:51 -0000 hi, Just a little background - I want to fire events at 10 microsecond granularity in FreeBSD, and it was suggested to use Hz=100000 in the kernel config file. This is a good approach, only if I schedule events every 10 us ( which i am not doing ). Due to this high frequency interrupts, I am incurring a lot of overheads and deviations in firing events. I came across this other way of firing events at micro-seconds granularity, which uses "local APIC timer", by writing a us value into a register and generating the event when timer reaches zero. The implementation I know of is only in Linux. http://www.oberle.org/apic_timer.html and the technical paper is: http://stillhq.com/pdfdb/000522/data.pdf The paper shows that mean deviation of this approach is less than 3 us. But I can't find any such support for FreeBSD. Do you guys know of any such implementation for FreeBSD? Thanks for help, vaibhave From owner-freebsd-net@FreeBSD.ORG Tue Sep 20 20:29:20 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42F7316A41F for ; Tue, 20 Sep 2005 20:29:20 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBF9E43D45 for ; Tue, 20 Sep 2005 20:29:19 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by zproxy.gmail.com with SMTP id z31so45789nzd for ; Tue, 20 Sep 2005 13:29:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=DShQCXGaBCaCXKOmvaKimHaA/b3j5d7F45X8akLaR30mCOH24A3N/GN8j7MJMXuy84vHoUJj+o3+vlQfEqHSfY3RKgNX/sgSnM9TrIo1xHxLQVzd082SLMoQqwXnJcZjxzkXxZAuVX5ydRYYpCWb8dKpZgYo2c5uoKZAh9i+2h4= Received: by 10.54.46.37 with SMTP id t37mr2042439wrt; Tue, 20 Sep 2005 13:29:19 -0700 (PDT) Received: from ?192.168.0.143? ( [80.217.193.226]) by mx.gmail.com with ESMTP id d61sm2846379wra.2005.09.20.13.29.17; Tue, 20 Sep 2005 13:29:18 -0700 (PDT) Message-ID: <4330711A.4040808@gmail.com> Date: Tue, 20 Sep 2005 22:29:14 +0200 From: Pawel Worach User-Agent: Thunderbird 1.4 (X11/20050918) MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [panic] page fault in tcp_timer_2msl_tw 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, 20 Sep 2005 20:29:20 -0000 Got this on a SMP (2 physical, HTT off) box during moderate tcp (http) load. Any ideas? FreeBSD pxecmb3 5.4-RELEASE-p6 FreeBSD 5.4-RELEASE-p6 #0: Fri Jul 29 19:57:15 CEST 2005 root@pxecma1:/usr/obj/usr/src/sys/PROXY i386 SCHED_4BSD, ADAPTIVE_GIANT, mpsafenet=1 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xac fault code = supervisor write, page not present instruction pointer = 0x8:0xc057a8f9 stack pointer = 0x10:0xe4cf7c34 frame pointer = 0x10:0xe4cf7c58 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 = 63 (swi5: clock sio) db> tr Tracing pid 63 tid 100063 td 0xc1f0d480 tcp_timer_2msl_tw(0,c04e3a90,c0684660,c06848e0,0) at tcp_timer_2msl_tw+0x49 tcp_slowtimo(c1f0ba98,e4cf7cd4,c04d7a79,246,e) at tcp_slowtimo+0x6c pfslowtimo(0,0,e4cf7cb8,418700,32ccaeb3) at pfslowtimo+0x39 softclock(0,0,0,0,0) at softclock+0x34b ithread_loop(c1f1bb80,e4cf7d48,0,0,0) at ithread_loop+0x1b8 fork_exit(c04b4be0,c1f1bb80,e4cf7d48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4cf7d7c, ebp = 0 --- db> call doadump Dumping 1023 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 Dump complete 0xf (kgdb) bt ... #9 0xc061d1ca in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #10 0x00000018 in ?? () #11 0x00000010 in ?? () ---Type to continue, or q to quit--- #12 0xc1e70010 in ?? () #13 0xc06a8280 in twl_2msl () #14 0xc06a827c in twl_2msl () #15 0xe4cf7c58 in ?? () #16 0xe4cf7c20 in ?? () #17 0xc4a30118 in ?? () #18 0xc1f0d480 in ?? () #19 0x00000000 in ?? () #20 0x00000004 in ?? () #21 0x0000000c in ?? () #22 0x00000002 in ?? () #23 0xc057a8f9 in tcp_timer_2msl_tw (reuse=0) at atomic.h:154 #24 0xc057a29c in tcp_slowtimo () at /usr/src/sys/netinet/tcp_timer.c:136 #25 0xc050f379 in pfslowtimo (arg=0x0) at /usr/src/sys/kern/uipc_domain.c:245 #26 0xc04debcb in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:279 #27 0xc04b4d98 in ithread_loop (arg=0xc1f1bb80) at /usr/src/sys/kern/kern_intr.c:547 #28 0xc04b39b0 in fork_exit (callout=0xc04b4be0 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:791 #29 0xc061d22c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:209 (kgdb) frame 23 #23 0xc057a8f9 in tcp_timer_2msl_tw (reuse=0) at atomic.h:154 154 atomic.h: No such file or directory. in atomic.h (kgdb) info loc tw = (struct tcptw *) 0xc4a30118 tw_tail = (struct tcptw *) 0xc06a8280 twl = (struct twlist *) 0xc06a827c i = 1 (kgdb) print *tw $1 = {tw_inpcb = 0x0, snd_nxt = 438603527, rcv_nxt = 3383864561, iss = 438603320, irs = 3383863898, cc_recv = 0, cc_send = 0, last_win = 65534, tw_so_options = 4, tw_cred = 0x0, t_recent = 0, t_starttime = 4294952294, tw_time = 0, tw_2msl = {le_next = 0xc24680a8, le_prev = 0xc06a827c}} (kgdb) print *tw_tail $2 = {tw_inpcb = 0x0, snd_nxt = 0, rcv_nxt = 0, iss = 0, irs = 0, cc_recv = 0, cc_send = 0, last_win = 0, tw_so_options = 0, tw_cred = 0x0, t_recent = 0, t_starttime = 0, tw_time = 0, tw_2msl = {le_next = 0x0, le_prev = 0xc267d110}} (kgdb) print *twl $3 = {tw_list = {lh_first = 0xc4a30118}, tw_tail = {tw_inpcb = 0x0, snd_nxt = 0, rcv_nxt = 0, iss = 0, irs = 0, cc_recv = 0, cc_send = 0, last_win = 0, tw_so_options = 0, tw_cred = 0x0, t_recent = 0, t_starttime = 0, tw_time = 0, tw_2msl = {le_next = 0x0, le_prev = 0xc267d110}}} /usr/src/sys/netinet/tcp_timer.c: $FreeBSD: src/sys/netinet/tcp_timer.c,v 1.66.2.6 2005/01/31 23:26:37 imp Exp $ vmcore and kernel.debug saved if more info needed. -- Pawel From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 07:11:32 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93D4416A41F for ; Wed, 21 Sep 2005 07:11:32 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1170043D46 for ; Wed, 21 Sep 2005 07:11:31 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (h168.p058.iij4u.or.jp [210.130.58.168]) by r-dd.iij4u.or.jp (4U-MR/r-dd) id j8L7BR7H027474; Wed, 21 Sep 2005 16:11:28 +0900 (JST) Date: Wed, 21 Sep 2005 16:11:13 +0900 (JST) Message-Id: <20050921.161113.59648691.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: othermark In-Reply-To: <20050921.012626.74752754.Noritoshi@Demizu.ORG> References: <20050921.012626.74752754.Noritoshi@Demizu.ORG> X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: rfc2385 (tcp md5 checksums) in -current 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, 21 Sep 2005 07:11:32 -0000 > > I'm testing rfc2385 support with some of our equipment with current > > as of a few days ago, and the support seems, well, rather broken. tcpdump seems to be broken. I think the patch at the tail of this e-mail needs to be applied to src/contrib/tcpdump/print-tcp.c. Could you try this patch? I think this patch can also be applied to tcpdump 3.9.3. > I think there is a bug in syncache_respond(). I'm trying to fix this problem. But,,, I found you don't use SACK in your trace :-). Anyway, I will try to fix the bug in syncache_respond(). Regards, Noritoshi Demizu --- print-tcp.c-ORG Thu Apr 21 15:36:05 2005 +++ print-tcp.c Wed Sep 21 16:07:40 2005 @@ -799,7 +799,7 @@ MD5_Update(&ctx, tcpmd5secret, strlen(tcpmd5secret)); MD5_Final(sig, &ctx); - if (memcmp(rcvsig, sig, 16)) + if (memcmp(rcvsig, sig, 16) == 0) return (SIGNATURE_VALID); else return (SIGNATURE_INVALID); From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 08:55:00 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21CAF16A41F for ; Wed, 21 Sep 2005 08:55:00 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from dmzraw4.extranet.tce.com (dmzraw4.extranet.tce.com [157.254.234.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 618C743D46 for ; Wed, 21 Sep 2005 08:54:59 +0000 (GMT) (envelope-from david.mao@thomson.net) Received: from indyvss2.am.thmulti.com (unknown [157.254.92.61]) by dmzraw4.extranet.tce.com (Postfix) with ESMTP id 354391744 for ; Wed, 21 Sep 2005 08:54:58 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by indyvss2.am.thmulti.com (Postfix) with ESMTP id 2538344624 for ; Wed, 21 Sep 2005 08:54:58 +0000 (GMT) Received: from indyvss2.am.thmulti.com ([127.0.0.1]) by localhost (indyvss2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10986-01-93 for ; Wed, 21 Sep 2005 08:54:55 +0000 (GMT) Received: from indysmailcs01.am.thmulti.com (indysmailcs01.am.thmulti.com [157.254.96.5]) by indyvss2.am.thmulti.com (Postfix) with ESMTP id ECA8744602 for ; Wed, 21 Sep 2005 08:54:54 +0000 (GMT) Received: from indysmailbh01.am.thmulti.com ([157.254.96.4]) by indysmailcs01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 03:54:55 -0500 Received: from tahkexch2k.ap.thmulti.com ([141.11.13.12]) by indysmailbh01.am.thmulti.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 03:54:54 -0500 Received: from bjngsmail01.ap.thmulti.com ([10.11.70.35]) by tahkexch2k.ap.thmulti.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Sep 2005 16:54:14 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Sep 2005 16:54:13 +0800 Message-ID: <31021C278A7A6B4AB95E9A085C3552181CE58F@bjngsmail01> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About guideline of parameters tuning while in polling mode. Thread-Index: AcW+igfR4Zek9+GpT2STJrbV2STo7g== From: "Mao Shou Yan" To: X-OriginalArrivalTime: 21 Sep 2005 08:54:14.0105 (UTC) FILETIME=[0A830490:01C5BE8A] X-Virus-Scanned: amavisd-new at thomson.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: About guideline of parameters tuning while in polling mode. 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, 21 Sep 2005 08:55:00 -0000 Hi, everybody Can anyone give some guidelines on tuning the following parameters when the system is in polling mode and works in high throughput network environment. Thanks a lot! =20 =20 /* * EM_TIDV - Transmit Interrupt Delay Value=20 * Valid Range: 0-65535 (0=3Doff) * Default Value: 64 * This value delays the generation of transmit interrupts in units of * 1.024 microseconds. Transmit interrupt reduction can improve CPU * efficiency if properly tuned for specific network traffic. If the * system is reporting dropped transmits, this value may be set too high * causing the driver to run out of available transmit descriptors. */ #define EM_TIDV 64 =20 /* * EM_TADV - Transmit Absolute Interrupt Delay Value (Not valid for 82542/82543/82544) * Valid Range: 0-65535 (0=3Doff) * Default Value: 64 * This value, in units of 1.024 microseconds, limits the delay in which a * transmit interrupt is generated. Useful only if EM_TIDV is non-zero, * this value ensures that an interrupt is generated after the initial * packet is sent on the wire within the set amount of time. Proper tuning, * along with EM_TIDV, may improve traffic throughput in specific * network conditions. */ #define EM_TADV 64 =20 /* * EM_RDTR - Receive Interrupt Delay Timer (Packet Timer)=20 * Valid Range: 0-65535 (0=3Doff) * Default Value: 0 * This value delays the generation of receive interrupts in units of 1.024 * microseconds. Receive interrupt reduction can improve CPU efficiency if * properly tuned for specific network traffic. Increasing this value adds * extra latency to frame reception and can end up decreasing the throughput * of TCP traffic. If the system is reporting dropped receives, this value * may be set too high, causing the driver to run out of available receive * descriptors. * * CAUTION: When setting EM_RDTR to a value other than 0, adapters * may hang (stop transmitting) under certain network conditions. * If this occurs a WATCHDOG message is logged in the system event log. * In addition, the controller is automatically reset, restoring the * network connection. To eliminate the potential for the hang * ensure that EM_RDTR is set to 0. */ #define EM_RDTR 0 =20 /* * Receive Interrupt Absolute Delay Timer (Not valid for 82542/82543/82544) * Valid Range: 0-65535 (0=3Doff) * Default Value: 64 * This value, in units of 1.024 microseconds, limits the delay in which a * receive interrupt is generated. Useful only if EM_RDTR is non-zero, * this value ensures that an interrupt is generated after the initial * packet is received within the set amount of time. Proper tuning, * along with EM_RDTR, may improve traffic throughput in specific network * conditions. */ #define EM_RADV 64 =20 From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 09:41:50 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B4A716A41F for ; Wed, 21 Sep 2005 09:41:50 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id D446243D45 for ; Wed, 21 Sep 2005 09:41:49 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (h168.p058.iij4u.or.jp [210.130.58.168]) by r-dd.iij4u.or.jp (4U-MR/r-dd) id j8L9fY8B013913; Wed, 21 Sep 2005 18:41:44 +0900 (JST) Date: Wed, 21 Sep 2005 18:41:14 +0900 (JST) Message-Id: <20050921.184114.115904070.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: othermark In-Reply-To: <20050921.161113.59648691.Noritoshi@Demizu.ORG> References: <20050921.012626.74752754.Noritoshi@Demizu.ORG> <20050921.161113.59648691.Noritoshi@Demizu.ORG> X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: rfc2385 (tcp md5 checksums) in -current 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, 21 Sep 2005 09:41:50 -0000 > > I think there is a bug in syncache_respond(). I am sorry I was wrong. syncache_respond() does not have such bug. Buggy thing was my brain... > > In tcp_syncache.c rev 1.77, tcp_signature_compute() is called before > > filling the TCP SACK Permitted option and the TCP EOL option. I guess > > it should be called after filling both the SACK Permitted and EOL option. According to RFC2385, TCP options are excluded when computing MD5 hash. So, TCP options fields can be rewritten after MD5 hash is computed. I misunderstood it. I am sorry if I made you confused. My conclusion is that src/contrib/tcpdump/print-tcp.c has a bug. And the patch below will fix it. Regards, Noritoshi Demizu --- print-tcp.c-ORG Thu Apr 21 15:36:05 2005 +++ print-tcp.c Wed Sep 21 18:43:51 2005 @@ -799,7 +799,7 @@ MD5_Update(&ctx, tcpmd5secret, strlen(tcpmd5secret)); MD5_Final(sig, &ctx); - if (memcmp(rcvsig, sig, 16)) + if (memcmp(rcvsig, sig, TCP_SIGLEN) == 0) return (SIGNATURE_VALID); else return (SIGNATURE_INVALID); From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 10:42:50 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53BFE16A41F; Wed, 21 Sep 2005 10:42:50 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4AD243D45; Wed, 21 Sep 2005 10:42:49 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.9.8] (14.80-203-184.nextgentel.com [80.203.184.14]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j8LAgjam031996; Wed, 21 Sep 2005 12:42:47 +0200 Message-ID: <43313924.9050009@wm-access.no> Date: Wed, 21 Sep 2005 12:42:44 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> In-Reply-To: <20050920134408.Y34322@fledge.watson.org> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=C308A003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Milscvaer Subject: Re: UDP dont fragment bit 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, 21 Sep 2005 10:42:50 -0000 > > For whatever reason, it turns out that you and only you have requested > this feature. For typicaly network debugging applications, a raw socket > is used, which allows the direct frobbing the the IP DF bit. For > example, in traceroute(8). > > Could you tell us a bit more about the application and proposed use? > Presumably forcing the DF bit isn't much use unless you can also > retrieve useful reporting on the ICMP errors associated with needing the > fragment? > I have been looking for such a feature too. My Application; Bandwidth tester (also as a support app for an UDP file transfer utility) The reason i want DF bit removed? I want to be able to generate my own fragments or let the routers generate the fragments. I also want to be able to receive bad UDP packets to gather statistics. This would be userland applications. -- Sten Daniel Sψrsdal From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 10:50:03 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 095EA16A41F for ; Wed, 21 Sep 2005 10:50:03 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 953C843D45 for ; Wed, 21 Sep 2005 10:50:02 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 176C846B86; Wed, 21 Sep 2005 06:50:02 -0400 (EDT) Date: Wed, 21 Sep 2005 11:50:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= In-Reply-To: <43313924.9050009@wm-access.no> Message-ID: <20050921114511.D34322@fledge.watson.org> References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1679374524-1127299801=:34322" Cc: freebsd-net@freebsd.org, Milscvaer Subject: Re: UDP dont fragment bit 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, 21 Sep 2005 10:50:03 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1679374524-1127299801=:34322 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 21 Sep 2005, Sten Daniel S=F8rsdal wrote: >> For whatever reason, it turns out that you and only you have requested= =20 >> this feature. For typicaly network debugging applications, a raw=20 >> socket is used, which allows the direct frobbing the the IP DF bit.=20 >> For example, in traceroute(8). >> >> Could you tell us a bit more about the application and proposed use?=20 >> Presumably forcing the DF bit isn't much use unless you can also=20 >> retrieve useful reporting on the ICMP errors associated with needing=20 >> the fragment? > > I have been looking for such a feature too. My Application; Bandwidth=20 > tester (also as a support app for an UDP file transfer utility) The=20 > reason i want DF bit removed? I want to be able to generate my own=20 > fragments or let the routers generate the fragments. I also want to be=20 > able to receive bad UDP packets to gather statistics. This would be=20 > userland applications. By default, we don't generate UDP with the IP DF bit set. If you want to= =20 receive the detailed ICMP responses, you currently need to to use a raw=20 socket, which is what most network exploration tools (such as traceroute)= =20 do. If we want to be able to manage more detailed state information using= =20 unprivileged UDP sockets, then we need to have more complex state=20 management on UDP sockets when ICMPs are received. Hence my asking for=20 requirements: what is it that is really being looked for here? Just being= =20 able to set the DF bit isn't very much use for a casual application, as=20 there's no real reporting of the resulting ICMP MTU messages to UDP=20 sockets. So presumably, what's being looked for is more than just a=20 socket option to say "Set or don't set the DF bit", but a way to query=20 recent ICMP received state on the socket. So if someone could generate some application pseudo-code that suggests=20 what specifically is necessary from the socket layer in order for the=20 application to function, we can talk about socket service extensions that= =20 might support the application. For example, a way to query detailed error= =20 information rather than just the SO_ERROR socket option. Or a longer haul= =20 PMTU data gathering mechanism for UDP sockets. Or ways for UDP=20 applications to more usefully query the kernel for the TCP PMTU data=20 already being recorded. It sounds like for the bandwidth tester, IP raw sockets already provide=20 what you need, since you want to be able to do fairly irregular UDP things= =20 (i.e., receive UDP packets with bad checksums, and see fragments). Robert N M Watson --0-1679374524-1127299801=:34322-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 11:50:48 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BB1016A41F for ; Wed, 21 Sep 2005 11:50:48 +0000 (GMT) (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 68AF243D46 for ; Wed, 21 Sep 2005 11:50:47 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 16047 invoked from network); 21 Sep 2005 11:24:45 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Sep 2005 11:24:45 -0000 Message-ID: <43314916.2451ED6A@freebsd.org> Date: Wed, 21 Sep 2005 13:50:46 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= , Milscvaer Subject: Re: UDP dont fragment bit 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, 21 Sep 2005 11:50:48 -0000 Robert Watson wrote: > > On Wed, 21 Sep 2005, Sten Daniel Sψrsdal wrote: > > >> For whatever reason, it turns out that you and only you have requested > >> this feature. For typicaly network debugging applications, a raw > >> socket is used, which allows the direct frobbing the the IP DF bit. > >> For example, in traceroute(8). > >> > >> Could you tell us a bit more about the application and proposed use? > >> Presumably forcing the DF bit isn't much use unless you can also > >> retrieve useful reporting on the ICMP errors associated with needing > >> the fragment? > > > > I have been looking for such a feature too. My Application; Bandwidth > > tester (also as a support app for an UDP file transfer utility) The > > reason i want DF bit removed? I want to be able to generate my own > > fragments or let the routers generate the fragments. I also want to be > > able to receive bad UDP packets to gather statistics. This would be > > userland applications. > > By default, we don't generate UDP with the IP DF bit set. If you want to > receive the detailed ICMP responses, you currently need to to use a raw > socket, which is what most network exploration tools (such as traceroute) > do. If we want to be able to manage more detailed state information using > unprivileged UDP sockets, then we need to have more complex state > management on UDP sockets when ICMPs are received. Hence my asking for > requirements: what is it that is really being looked for here? Just being > able to set the DF bit isn't very much use for a casual application, as > there's no real reporting of the resulting ICMP MTU messages to UDP > sockets. So presumably, what's being looked for is more than just a > socket option to say "Set or don't set the DF bit", but a way to query > recent ICMP received state on the socket. I can think of a couple of uses to say IP DF on a UDP socket. Will cook up a patch to add such a sysctl in a few hours. -- Andre > So if someone could generate some application pseudo-code that suggests > what specifically is necessary from the socket layer in order for the > application to function, we can talk about socket service extensions that > might support the application. For example, a way to query detailed error > information rather than just the SO_ERROR socket option. Or a longer haul > PMTU data gathering mechanism for UDP sockets. Or ways for UDP > applications to more usefully query the kernel for the TCP PMTU data > already being recorded. > > It sounds like for the bandwidth tester, IP raw sockets already provide > what you need, since you want to be able to do fairly irregular UDP things > (i.e., receive UDP packets with bad checksums, and see fragments). > > Robert N M Watson > > -------------------------------------------------------------------------------- > _______________________________________________ > 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 Sep 21 11:55:54 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C52C116A41F; Wed, 21 Sep 2005 11:55:54 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B48143D48; Wed, 21 Sep 2005 11:55:54 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 94AF646B9C; Wed, 21 Sep 2005 07:55:53 -0400 (EDT) Date: Wed, 21 Sep 2005 12:55:53 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <43314916.2451ED6A@freebsd.org> Message-ID: <20050921125325.E34322@fledge.watson.org> References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> <43314916.2451ED6A@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= , Milscvaer Subject: Re: UDP dont fragment bit 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, 21 Sep 2005 11:55:54 -0000 On Wed, 21 Sep 2005, Andre Oppermann wrote: > I can think of a couple of uses to say IP DF on a UDP socket. Will cook > up a patch to add such a sysctl in a few hours. The problem is that I think this solves only half of the likely problem. If what application developers really want is a way to do PMTU for UDP-based applications, the other half has to be done too: the ability to receive and process MTU data on the socket. Given that UDP sockets are often used unconnected, this means providing at least two additional pieces of information for ICMP MTU events: host/path information, and the MTU cap reported. And as UDP sockets are often used for quite a bit of traffic to different hosts at once, we might want to find a way to do this under load with an event stream rather than a condition queried using a simple socket option. So I think learning a bit more about the specific applications would be quite helpful -- in particular, what ICMP/MTU information they want, and how they will use it. Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 12:35:45 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D822716A41F; Wed, 21 Sep 2005 12:35:45 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36B4843D48; Wed, 21 Sep 2005 12:35:44 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.9.8] (14.80-203-184.nextgentel.com [80.203.184.14]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j8LCZiLD009116; Wed, 21 Sep 2005 14:35:44 +0200 Message-ID: <4331539D.9030204@wm-access.no> Date: Wed, 21 Sep 2005 14:35:41 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> In-Reply-To: <20050921114511.D34322@fledge.watson.org> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=C308A003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: UDP dont fragment bit 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, 21 Sep 2005 12:35:46 -0000 Robert Watson wrote: > > So if someone could generate some application pseudo-code that suggests > what specifically is necessary from the socket layer in order for the > application to function, we can talk about socket service extensions > that might support the application. For example, a way to query > detailed error information rather than just the SO_ERROR socket option. > Or a longer haul PMTU data gathering mechanism for UDP sockets. Or ways > for UDP applications to more usefully query the kernel for the TCP PMTU > data already being recorded. > > It sounds like for the bandwidth tester, IP raw sockets already provide > what you need, since you want to be able to do fairly irregular UDP > things (i.e., receive UDP packets with bad checksums, and see fragments). > IP raw sockets? Sure, Everything can be solved the complicated way :o) Some userland applications could benefit from having the option of DF flag set/unset. What about applications that wants to have a way of optimizing UDP transfers in their network path? Some networks filter icmp and fragments irresponsibly (imho) and sometimes the combination of two or more networks that would cause problems for multicast/video/voip applications. Sometimes in one network udp packets need fragmenting and in the next network fragments need to get reassembled to pass a firewall which in turn runs out of reassembling resources. ( It is more common to block icmp messages about reassembly problems than DF problems IF a message is generated in the first place. ) Sure, all of this could be fixed the complicated way but what if one already has an application that runs in unprivileged userland. How many lines of code would a simple socket option plus the "tuning" code require? -- Sten Daniel Sψrsdal From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 12:48:46 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6E0D16A41F for ; Wed, 21 Sep 2005 12:48:46 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DD1343D45 for ; Wed, 21 Sep 2005 12:48:46 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 7B3D046B3C; Wed, 21 Sep 2005 08:48:45 -0400 (EDT) Date: Wed, 21 Sep 2005 13:48:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= In-Reply-To: <4331539D.9030204@wm-access.no> Message-ID: <20050921134029.M34322@fledge.watson.org> References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> <4331539D.9030204@wm-access.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1545815129-1127306925=:34322" Cc: freebsd-net@freebsd.org Subject: Re: UDP dont fragment bit 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, 21 Sep 2005 12:48:46 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1545815129-1127306925=:34322 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 21 Sep 2005, Sten Daniel S=F8rsdal wrote: > Robert Watson wrote: >> >> So if someone could generate some application pseudo-code that suggests >> what specifically is necessary from the socket layer in order for the >> application to function, we can talk about socket service extensions >> that might support the application. For example, a way to query >> detailed error information rather than just the SO_ERROR socket option. >> Or a longer haul PMTU data gathering mechanism for UDP sockets. Or ways >> for UDP applications to more usefully query the kernel for the TCP PMTU >> data already being recorded. >> >> It sounds like for the bandwidth tester, IP raw sockets already provide= =20 >> what you need, since you want to be able to do fairly irregular UDP=20 >> things (i.e., receive UDP packets with bad checksums, and see=20 >> fragments). > > IP raw sockets? Sure, Everything can be solved the complicated way :o)=20 > Some userland applications could benefit from having the option of DF=20 > flag set/unset. UDP sockets are defined as being a way to send and receive valid UDP=20 datagrams. Your list of things to receive included fragments and invalid= =20 datagrams. While I agree with your comments below about things UDP=20 applications want to do, I don't agree that we should teach UDP sockets to= =20 receive UDP datagram fragments or packets with bad checksums.=20 Applications looking for non-accepted IP packets and complete ICMP=20 messages should be using the raw socket interface. Applications looking=20 for post-processed abstracted interfaces to a datagram service should be=20 using UDP sockets. See below for discussion of enhancing UDP sockets. > What about applications that wants to have a way of optimizing UDP > transfers in their network path? > > Some networks filter icmp and fragments irresponsibly (imho) and=20 > sometimes the combination of two or more networks that would cause=20 > problems for multicast/video/voip applications. > > Sometimes in one network udp packets need fragmenting and in the next=20 > network fragments need to get reassembled to pass a firewall which in=20 > turn runs out of reassembling resources. ( It is more common to block=20 > icmp messages about reassembly problems than DF problems IF a message is= =20 > generated in the first place. ) > > Sure, all of this could be fixed the complicated way but what if one=20 > already has an application that runs in unprivileged userland. How many= =20 > lines of code would a simple socket option plus the "tuning" code=20 > require? You're still not answering my question about application pseudo-code,=20 however. Adding an IP_DF option to UDP sockets is easy, and can be done in= =20 ten lines of code or less. Adding a way to provide detailed feedback on=20 error conditions associated with UDP packets sent at arbitrary points in=20 the path is not something that falls naturally out of the socket API, and= =20 will require non-trivial amounts of work. Hence my asking about the=20 structure and event model of your application: what exactly do you want to= =20 know about UDP packet delivery? Specifically, what information do you as a developer need in order to=20 handle asynchronous error delivery from UDP packet send, and how will it=20 affect your application's interaction with the network stack? We can=20 already deliver an synchronous EMSGSIZE when you try to send a UDP packet= =20 out of an interface with an MTU that is lower than the packet size, given= =20 a socket option to force IP_DF. However, if the packet hits a potential=20 fragmentation problem out in the wide area network, that notification is=20 completely asynchronous from packet transmission, and we will need a way=20 to feed more detailed ICMP information to the application. Right now=20 asynchronous error delivery on a UDP socket is already fairly messy due to= =20 the fact that generally applications can only pick up the error when doing= =20 further I/O, confusing the issue of which operation actually generated the= =20 error. Robert N M Watson --0-1545815129-1127306925=:34322-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 13:21:56 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9E0016A41F; Wed, 21 Sep 2005 13:21:56 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id E80A943D5A; Wed, 21 Sep 2005 13:21:54 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.9.8] (14.80-203-184.nextgentel.com [80.203.184.14]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j8LDLrqC013536; Wed, 21 Sep 2005 15:21:53 +0200 Message-ID: <43315E6F.1020003@wm-access.no> Date: Wed, 21 Sep 2005 15:21:51 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> <4331539D.9030204@wm-access.no> <20050921134029.M34322@fledge.watson.org> In-Reply-To: <20050921134029.M34322@fledge.watson.org> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=C308A003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org Subject: Re: UDP dont fragment bit 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, 21 Sep 2005 13:21:57 -0000 Robert Watson wrote: > > On Wed, 21 Sep 2005, Sten Daniel Sψrsdal wrote: > >> Robert Watson wrote: >> >>> >>> So if someone could generate some application pseudo-code that suggests >>> what specifically is necessary from the socket layer in order for the >>> application to function, we can talk about socket service extensions >>> that might support the application. For example, a way to query >>> detailed error information rather than just the SO_ERROR socket option. >>> Or a longer haul PMTU data gathering mechanism for UDP sockets. Or ways >>> for UDP applications to more usefully query the kernel for the TCP PMTU >>> data already being recorded. >>> >>> It sounds like for the bandwidth tester, IP raw sockets already >>> provide what you need, since you want to be able to do fairly >>> irregular UDP things (i.e., receive UDP packets with bad checksums, >>> and see fragments). >> >> >> IP raw sockets? Sure, Everything can be solved the complicated way :o) >> Some userland applications could benefit from having the option of DF >> flag set/unset. > > > UDP sockets are defined as being a way to send and receive valid UDP > datagrams. Your list of things to receive included fragments and > invalid datagrams. While I agree with your comments below about things > UDP applications want to do, I don't agree that we should teach UDP > sockets to receive UDP datagram fragments or packets with bad checksums. > Applications looking for non-accepted IP packets and complete ICMP > messages should be using the raw socket interface. Applications looking > for post-processed abstracted interfaces to a datagram service should be > using UDP sockets. See below for discussion of enhancing UDP sockets. > >> What about applications that wants to have a way of optimizing UDP >> transfers in their network path? >> >> Some networks filter icmp and fragments irresponsibly (imho) and >> sometimes the combination of two or more networks that would cause >> problems for multicast/video/voip applications. >> >> Sometimes in one network udp packets need fragmenting and in the next >> network fragments need to get reassembled to pass a firewall which in >> turn runs out of reassembling resources. ( It is more common to block >> icmp messages about reassembly problems than DF problems IF a message >> is generated in the first place. ) >> >> Sure, all of this could be fixed the complicated way but what if one >> already has an application that runs in unprivileged userland. How >> many lines of code would a simple socket option plus the "tuning" code >> require? > > > You're still not answering my question about application pseudo-code, > however. Adding an IP_DF option to UDP sockets is easy, and can be done > in ten lines of code or less. Adding a way to provide detailed feedback > on error conditions associated with UDP packets sent at arbitrary points > in the path is not something that falls naturally out of the socket API, > and will require non-trivial amounts of work. Hence my asking about the > structure and event model of your application: what exactly do you want > to know about UDP packet delivery? > > Specifically, what information do you as a developer need in order to > handle asynchronous error delivery from UDP packet send, and how will it > affect your application's interaction with the network stack? We can > already deliver an synchronous EMSGSIZE when you try to send a UDP > packet out of an interface with an MTU that is lower than the packet > size, given a socket option to force IP_DF. However, if the packet hits > a potential fragmentation problem out in the wide area network, that > notification is completely asynchronous from packet transmission, and we > will need a way to feed more detailed ICMP information to the > application. Right now asynchronous error delivery on a UDP socket is > already fairly messy due to the fact that generally applications can > only pick up the error when doing further I/O, confusing the issue of > which operation actually generated the error. > Your assumption is that you can rely on routers in your path to inform you that you that your packet size is causing fragments. Consider a client connected to an isp's network(1). The isp drops all ICMP packets. That network is then connected to a third network(2) which has a data path that has an MTU of 1400 bytes but also mangles tcp mss to 1360, udp packets must get fragmented. On server size the firewall must reassemble all udp fragments before passing them on to server. I hope my pseudo-code works for you, the example is over simplified. With DF set: tcp_socket = tcp_connect_controlchannel_to_server('1.2.3.4); [ .. transmit and receive hello messages .. ] [ .. request datagram size discovery .. ] int max_size = 1500; int found = FALSE; while (!$found || max_size == 500) { udp_send_test_datagram('1.2.3.4', max_size); if ( tcp_receive_message( tcp_socket ) == DATAGRAM_RECEIVED ) { found = TRUE; break; // exit loop } max_size = max_size - 1; } if ( !$found ) { return ( OPTIMAL_SIZE_NOT_FOUND ); } [ .. continue if optimal size was found .. ] ----------------------------------- DATAGRAM_RECEIVED would be the message/token that indicates the udp test datagram was received by server. -- Sten Daniel Sψrsdal From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 13:32:08 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 636EE16A421 for ; Wed, 21 Sep 2005 13:32:08 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id D190443D49 for ; Wed, 21 Sep 2005 13:32:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 277EA46BB8; Wed, 21 Sep 2005 09:32:07 -0400 (EDT) Date: Wed, 21 Sep 2005 14:32:07 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= In-Reply-To: <43315E6F.1020003@wm-access.no> Message-ID: <20050921142903.J34322@fledge.watson.org> References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> <4331539D.9030204@wm-access.no> <20050921134029.M34322@fledge.watson.org> <43315E6F.1020003@wm-access.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-228681796-1127309527=:34322" Cc: freebsd-net@FreeBSD.org Subject: Re: UDP dont fragment bit 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, 21 Sep 2005 13:32:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-228681796-1127309527=:34322 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 21 Sep 2005, Sten Daniel S=F8rsdal wrote: > Your assumption is that you can rely on routers in your path to inform=20 > you that you that your packet size is causing fragments. > > Consider a client connected to an isp's network(1). The isp drops all=20 > ICMP packets. That network is then connected to a third network(2) which= =20 > has a data path that has an MTU of 1400 bytes but also mangles tcp mss=20 > to 1360, udp packets must get fragmented. On server size the firewall=20 > must reassemble all udp fragments before passing them on to server. > > I hope my pseudo-code works for you, the example is over simplified.=20 > With DF set: While the below is perfectly valid and useful and should be easy to=20 implement with andre's proposed change, would you prefer an interface that= =20 allowed you to query the TCP connection and ask it what pathwise MTU it=20 had already probed for the route? The kernel host cache already maintains= =20 a number of paramaters associated with built TCP connections to a host,=20 such as the probed PMTU, estimated RTT and variance, estimated bandwidth,= =20 congestion window, and so on. While it wouldn't necessarily replace logic= =20 to reprobe connection conditions, it seems as though if you're going to go= =20 to the trouble of building a separate control TCP connection, you might as= =20 well benefit from what it finds. You can find a list of current host cache properties in=20 src/sys/netinet/tcp_hostcache.c, struct hc_metrics. Robert N M Watson > > tcp_socket =3D tcp_connect_controlchannel_to_server('1.2.3.4); > > [ .. transmit and receive hello messages .. ] > [ .. request datagram size discovery .. ] > > int max_size =3D 1500; > int found =3D FALSE; > while (!$found || max_size =3D=3D 500) > { > =09udp_send_test_datagram('1.2.3.4', max_size); > =09if ( tcp_receive_message( tcp_socket ) =3D=3D DATAGRAM_RECEIVED ) > =09{ > =09=09found =3D TRUE; > =09=09break;=09=09=09// exit loop > =09} > =09max_size =3D max_size - 1; > } > if ( !$found ) { return ( OPTIMAL_SIZE_NOT_FOUND ); } > > [ .. continue if optimal size was found .. ] > > ----------------------------------- > > DATAGRAM_RECEIVED would be the message/token that indicates the udp test > datagram was received by server. > > --=20 > Sten Daniel S=F8rsdal > --0-228681796-1127309527=:34322-- From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 13:53:05 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9930A16A41F for ; Wed, 21 Sep 2005 13:53:05 +0000 (GMT) (envelope-from m.jakeman@lancaster.ac.uk) Received: from errol.lancs.ac.uk (errol.lancs.ac.uk [148.88.0.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48C3143D81 for ; Wed, 21 Sep 2005 13:52:54 +0000 (GMT) (envelope-from m.jakeman@lancaster.ac.uk) Received: from marl.lancs.ac.uk ([148.88.1.10]) by errol.lancs.ac.uk with esmtp (Exim 4.52) id 1EI51p-0000JG-JK for freebsd-net@freebsd.org; Wed, 21 Sep 2005 14:52:53 +0100 Received: from ina044000004.lancs.ac.uk ([194.80.37.87]) by marl.lancs.ac.uk with esmtp (Exim 4.52) id 1EI51p-0001n0-O8 for freebsd-net@freebsd.org; Wed, 21 Sep 2005 14:52:53 +0100 From: Matthew Jakeman Organization: Lancaster University To: freebsd-net@freebsd.org Date: Wed, 21 Sep 2005 14:58:19 +0000 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509211458.19739.m.jakeman@lancaster.ac.uk> Subject: iperf results X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: m.jakeman@lancaster.ac.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 13:53:05 -0000 Hi, Some colleagues and myself have performed some simple tests on various OS's using iperf to simply fire packets from one pc to another over ethernet to test a few characteristics such as packet loss, jitter etc between IPv4 and IPv6. The configuration for all three OS's were 'out of the box' installs. The results we got back from that are strange for FreeBSD with regards to the packet loss iperf reports and I was wondering if anyone has any ideas why they might be as they are. The image at the link below shows the packet loss results for windows, Linux and FreeBSD for comparison! As you can see the packet loss for v6 is substantially less than v4 on FreeBSD, however this is still substantially larger than for the other two OS's, does anyone have any idea why this might be? http://www.mjakeman.co.uk/images/4v6tests.jpg One other question is that I tried altering the Mbuf size in the kernel config to 1500 using "options MSIZE=1500" but when i try to recompile the kernel with this value i get a compilation error "/usr/src/sys/kern/kern_mbuf.c: error: size of array `__assert123' is negative", be aware I have not looked much into why this might be happening at present but if there is a hard upper limit or any other reason that this might be happening I would be grateful to be informed of it. Thanks in advance for any replies Matt From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 14:05:21 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2365616A41F for ; Wed, 21 Sep 2005 14:05:21 +0000 (GMT) (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 16E2843D48 for ; Wed, 21 Sep 2005 14:05:19 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 17064 invoked from network); 21 Sep 2005 13:39:16 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 21 Sep 2005 13:39:16 -0000 Message-ID: <4331689F.FF450404@freebsd.org> Date: Wed, 21 Sep 2005 16:05:19 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> <4331539D.9030204@wm-access.no> <20050921134029.M34322@fledge.watson.org> <43315E6F.1020003@wm-access.no> <20050921142903.J34322@fledge.watson.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org, Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= Subject: Re: UDP dont fragment bit 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, 21 Sep 2005 14:05:21 -0000 Robert Watson wrote: > > On Wed, 21 Sep 2005, Sten Daniel Sψrsdal wrote: > > > Your assumption is that you can rely on routers in your path to inform > > you that you that your packet size is causing fragments. > > > > Consider a client connected to an isp's network(1). The isp drops all > > ICMP packets. That network is then connected to a third network(2) which > > has a data path that has an MTU of 1400 bytes but also mangles tcp mss > > to 1360, udp packets must get fragmented. On server size the firewall > > must reassemble all udp fragments before passing them on to server. > > > > I hope my pseudo-code works for you, the example is over simplified. > > With DF set: > > While the below is perfectly valid and useful and should be easy to > implement with andre's proposed change, would you prefer an interface that > allowed you to query the TCP connection and ask it what pathwise MTU it > had already probed for the route? The kernel host cache already maintains > a number of paramaters associated with built TCP connections to a host, > such as the probed PMTU, estimated RTT and variance, estimated bandwidth, > congestion window, and so on. While it wouldn't necessarily replace logic > to reprobe connection conditions, it seems as though if you're going to go > to the trouble of building a separate control TCP connection, you might as > well benefit from what it finds. > > You can find a list of current host cache properties in > src/sys/netinet/tcp_hostcache.c, struct hc_metrics. The tcp hostcache only gets updated when a TCP connection closes. BTW: I have written the socket option to enable IP_DF on UDP packets. It is at least useful to get notified when the packet is larger than the local interface MTU. All functionality on top of this is left to the application programmer. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 14:13:15 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D629716A41F for ; Wed, 21 Sep 2005 14:13:15 +0000 (GMT) (envelope-from mt@smtp.top.net.ua) Received: from smtp.top.net.ua (smtp.top.net.ua [193.109.60.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39AC043D53 for ; Wed, 21 Sep 2005 14:13:15 +0000 (GMT) (envelope-from mt@smtp.top.net.ua) Received: from smtp.top.net.ua (localhost [127.0.0.1]) by smtp.top.net.ua (Postfix) with ESMTP id A32161B8909; Wed, 21 Sep 2005 17:13:11 +0300 (EEST) Received: by smtp.top.net.ua (Postfix, from userid 1012) id 816051B8944; Wed, 21 Sep 2005 17:13:11 +0300 (EEST) Date: Wed, 21 Sep 2005 17:13:11 +0300 From: Maxim Tuliuk To: Benjamin Rosenblum Message-ID: <20050921141311.GA40222@top.net.ua> References: <432DAED7.9070404@benswebs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <432DAED7.9070404@benswebs.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org Subject: Re: Problems with SK and EM network cards/drivers on my system 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, 21 Sep 2005 14:13:15 -0000 On Sun, Sep 18, 2005 at 14:15 -0400, Benjamin Rosenblum wrote: ... > now the EM problem. > > when i am running a very high network load (streaming video, dumping > ALOT of data across the network, etc) the network card disconnects (i > loose pings and all my transfers drop) and 15-20 seconds later it pops > up on the console with "em0: Link is up 1000 Mbps Full Duplex" and then > it starts working again. again im at a dead wall and really want my > network to work properly so i can do what i need to do. Hello! I've same problems on 5.4-STABLE: /var/run/dmesg.boot: FreeBSD 5.4-STABLE #5: Tue Sep 13 16:14:10 EEST 2005 em0: port 0xbc00-0xbc1f mem 0xff8e0000-0xff8fffff irq 18 at device 1.0 on pci1 em0: Ethernet address: 00:0c:f1:cf:7e:b6 em0: Speed:N/A Duplex:N/A /etc/rc.conf: ifconfig_em0="inet ... netmask ... media 100baseTX mediaopt full-duplex" /var/log/messages: Sep 20 15:51:40 tak kernel: em0: Link is up 100 Mbps Full Duplex Sep 20 17:01:40 tak kernel: em0: Link is up 100 Mbps Full Duplex Sep 20 18:48:16 tak kernel: em0: Link is up 100 Mbps Full Duplex switch: Catalyst 3550 I changed ports: 100M to 1GB and back; changed cables, but... no positive results :( -- Maxim Tuliuk WWW: http://primats.org.ua/~mt/ ICQ: 21134222 The bike is absolute freedom of moving From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 15:19:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 498AC16A41F for ; Wed, 21 Sep 2005 15:19:18 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9ED543D49 for ; Wed, 21 Sep 2005 15:19:15 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 2B6B95D67; Wed, 21 Sep 2005 11:19:15 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40424-08; Wed, 21 Sep 2005 11:19:06 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-68-11.ny325.east.verizon.net [68.161.68.11]) by pi.codefab.com (Postfix) with ESMTP id 74AC55C53; Wed, 21 Sep 2005 11:19:06 -0400 (EDT) Message-ID: <433179EA.7050304@mac.com> Date: Wed, 21 Sep 2005 11:19:06 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: m.jakeman@lancaster.ac.uk References: <200509211458.19739.m.jakeman@lancaster.ac.uk> In-Reply-To: <200509211458.19739.m.jakeman@lancaster.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-net@freebsd.org Subject: Re: iperf 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: Wed, 21 Sep 2005 15:19:18 -0000 Matthew Jakeman wrote: > Some colleagues and myself have performed some simple tests on various OS's > using iperf to simply fire packets from one pc to another over ethernet to > test a few characteristics such as packet loss, jitter etc between IPv4 and > IPv6. The configuration for all three OS's were 'out of the box' installs. > The results we got back from that are strange for FreeBSD with regards to the > packet loss iperf reports and I was wondering if anyone has any ideas why > they might be as they are. The image at the link below shows the packet loss > results for windows, Linux and FreeBSD for comparison! As you can see the > packet loss for v6 is substantially less than v4 on FreeBSD, however this is > still substantially larger than for the other two OS's, does anyone have any > idea why this might be? > > http://www.mjakeman.co.uk/images/4v6tests.jpg You're probably getting packet loss either because you are filling up the network buffer space without pausing until it drains, or are running into ICMP response limits. If you're going to be testing latency around the millisecond level, you'll need to increase HZ to at least 1000, if not better. For example, set "sysctl net.inet.icmp.icmplim=20" on a machine called shot. # ping -c 1000 -i 0.01 -s 1280 shot PING shot (199.103.21.228): 1280 data bytes 1288 bytes from 199.103.21.228: icmp_seq=0 ttl=64 time=0.935 ms [ ... ] --- shot ping statistics --- 1000 packets transmitted, 220 packets received, 78% packet loss round-trip min/avg/max/stddev = 0.842/0.877/1.234/0.077 ms With "sysctl net.inet.icmp.icmplim=2000": [ ... ] 1288 bytes from 199.103.21.228: icmp_seq=999 ttl=64 time=0.870 ms --- shot ping statistics --- 1000 packets transmitted, 1000 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.838/0.858/1.068/0.020 ms ...or even: # ping -c 1000 -i 0.001 -s 1280 shot [ ... ] 1288 bytes from 199.103.21.228: icmp_seq=999 ttl=64 time=0.849 ms --- shot ping statistics --- 1000 packets transmitted, 1000 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.839/0.856/1.010/0.015 ms ----- You haven't provided a test methodology. You haven't provided the source code for the benchmark program you are using. You also haven't provided any details about the hardware being used, the network topology, or even what some of the values in this .jpg image mean. (For example, what is the first column, "duration", measuring?) -- -Chuck From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 17:16:33 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 921C216A420; Wed, 21 Sep 2005 17:16:33 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FD9843D46; Wed, 21 Sep 2005 17:16:32 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.9.8] (14.80-203-184.nextgentel.com [80.203.184.14]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j8LHGVxD032080; Wed, 21 Sep 2005 19:16:31 +0200 Message-ID: <4331956A.2060406@wm-access.no> Date: Wed, 21 Sep 2005 19:16:26 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> <4331539D.9030204@wm-access.no> <20050921134029.M34322@fledge.watson.org> <43315E6F.1020003@wm-access.no> <20050921142903.J34322@fledge.watson.org> In-Reply-To: <20050921142903.J34322@fledge.watson.org> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=C308A003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: UDP dont fragment bit 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, 21 Sep 2005 17:16:33 -0000 Robert Watson wrote: > > On Wed, 21 Sep 2005, Sten Daniel Sψrsdal wrote: > > While the below is perfectly valid and useful and should be easy to > implement with andre's proposed change, would you prefer an interface > that allowed you to query the TCP connection and ask it what pathwise > MTU it had already probed for the route? The kernel host cache already > maintains a number of paramaters associated with built TCP connections > to a host, such as the probed PMTU, estimated RTT and variance, > estimated bandwidth, congestion window, and so on. While it wouldn't > necessarily replace logic to reprobe connection conditions, it seems as > though if you're going to go to the trouble of building a separate > control TCP connection, you might as well benefit from what it finds. > > You can find a list of current host cache properties in > src/sys/netinet/tcp_hostcache.c, struct hc_metrics. > Often there already is need for a tcp connection for authentication, negotiation and so forth. RTT could, among other things, make a discovery process choose how fine the increments/descrements should be. Estimated bandwidth could also help the actual data transport start out with a more situation correct value. However with the abundance of routers modifying TCP MSS correctly incorrectly and the odd chance that the data path of UDP packets is different than TCP packets it wouldnt really give anything necessarily reliable discovery process. And taking advantage of such values could make the process more complex or less reliable. -- Sten Daniel Sψrsdal From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 17:23:45 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A40416A41F for ; Wed, 21 Sep 2005 17:23:45 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: from useful.dataloss.nl (useful.dataloss.nl [80.84.249.161]) by mx1.FreeBSD.org (Postfix) with SMTP id 018AA43D48 for ; Wed, 21 Sep 2005 17:23:44 +0000 (GMT) (envelope-from peter@dataloss.nl) Received: (qmail 4775 invoked by uid 1001); 21 Sep 2005 17:23:43 -0000 Date: Wed, 21 Sep 2005 19:23:43 +0200 From: Peter van Dijk To: freebsd-net@freebsd.org, current@freebsd.org Message-ID: <20050921172343.GF17888@dataloss.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Cc: Subject: sparc64 if_bridge broken between BETA4 and BETA5 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, 21 Sep 2005 17:23:45 -0000 Hello, with 6.0-BETA4 (from september 10th) if_tap and if_bridge cooperate perfectly. After upgrading to BETA5 my machine panics seconds after I ifconfig bridge0 up.. I tested if_tap independently and it is fine; if_bridge panics without if_tap too. The error message is along the lines of 'unaligned access'. I'm sorry I don't have more information right now; my keyboard doesn't work in the kernel debugger and my serial cable is not here. Running a BETA5 kernel with the .ko from BETA4 produces the same panic. If anything else is needed, please ask; hints on getting my keyboard working again (I seem to recall it worked with 5.3) are welcome too :) I may have misplaced options in the general area of syscons.. Cheers, Peter -- peter@dataloss.nl | ~ tonight tonight, what is this potion http://blog.dataloss.nl/ | ~ that makes a fool of me UnderNet/#clue | Wayfinder, fr-025 soundtrack From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 17:33:14 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4676916A41F for ; Wed, 21 Sep 2005 17:33:14 +0000 (GMT) (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 A5D9C43D46 for ; Wed, 21 Sep 2005 17:33:13 +0000 (GMT) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EI8Oo-0001hk-J6 for freebsd-net@freebsd.org; Wed, 21 Sep 2005 19:28:50 +0200 Received: from mulder.f5.com ([205.229.151.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 19:28:50 +0200 Received: from atkin901 by mulder.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2005 19:28:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: othermark Date: Wed, 21 Sep 2005 10:26:11 -0700 Lines: 22 Message-ID: References: <20050921.012626.74752754.Noritoshi@Demizu.ORG> <20050921.161113.59648691.Noritoshi@Demizu.ORG> <20050921.184114.115904070.Noritoshi@Demizu.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mulder.f5.com User-Agent: KNode/0.9.2 Sender: news Subject: Re: rfc2385 (tcp md5 checksums) in -current 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, 21 Sep 2005 17:33:14 -0000 Noritoshi Demizu wrote: > --- print-tcp.c-ORG Thu Apr 21 15:36:05 2005 > +++ print-tcp.c Wed Sep 21 18:43:51 2005 > @@ -799,7 +799,7 @@ > MD5_Update(&ctx, tcpmd5secret, strlen(tcpmd5secret)); > MD5_Final(sig, &ctx); > > - if (memcmp(rcvsig, sig, 16)) > + if (memcmp(rcvsig, sig, TCP_SIGLEN) == 0) > return (SIGNATURE_VALID); > else > return (SIGNATURE_INVALID); The original code there certainly looks wrong! After patching, FreeBSD's checksum returns valid. I'll have to see what's up with the originating checksum. Many Thanks! -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 19:14:26 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCC5716A420; Wed, 21 Sep 2005 19:14:26 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B90043D53; Wed, 21 Sep 2005 19:14:26 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id 969911CCD4; Thu, 22 Sep 2005 07:14:24 +1200 (NZST) Date: Thu, 22 Sep 2005 07:14:24 +1200 From: Andrew Thompson To: Peter van Dijk Message-ID: <20050921191424.GB62131@heff.fud.org.nz> Mail-Followup-To: Andrew Thompson , Peter van Dijk , freebsd-net@freebsd.org, current@freebsd.org References: <20050921172343.GF17888@dataloss.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921172343.GF17888@dataloss.nl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: sparc64 if_bridge broken between BETA4 and BETA5 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, 21 Sep 2005 19:14:27 -0000 On Wed, Sep 21, 2005 at 07:23:43PM +0200, Peter van Dijk wrote: > Hello, > > with 6.0-BETA4 (from september 10th) if_tap and if_bridge cooperate > perfectly. > > After upgrading to BETA5 my machine panics seconds after I ifconfig > bridge0 up.. I tested if_tap independently and it is fine; if_bridge > panics without if_tap too. Thanks for the report. > The error message is along the lines of 'unaligned access'. I'm sorry > I don't have more information right now; my keyboard doesn't work in > the kernel debugger and my serial cable is not here. > > Running a BETA5 kernel with the .ko from BETA4 produces the same > panic. > > If anything else is needed, please ask; hints on getting my keyboard > working again (I seem to recall it worked with 5.3) are welcome too :) > I may have misplaced options in the general area of syscons.. > If there is any chance you could get a backtrace or a line number it would be great. I'll start looking at this problem now. cheers, Andrew From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 20:45:25 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A596716A420 for ; Wed, 21 Sep 2005 20:45:25 +0000 (GMT) (envelope-from ddg@yan.com.br) Received: from zeus.yan.com.br (zeus.yan.com.br [200.202.253.10]) by mx1.FreeBSD.org (Postfix) with SMTP id 69F8043D46 for ; Wed, 21 Sep 2005 20:45:23 +0000 (GMT) (envelope-from ddg@yan.com.br) Received: (qmail 12296 invoked by uid 1023); 21 Sep 2005 20:44:42 -0000 Received: from ddg@yan.com.br by zeus by uid 1023 with qmail-scanner-1.22 (uvscan: v4.1.60/v4366. fsecure: 4.11/3190/2003-09-23/2002-12-17. 2003-09-22/. Clear:RC:1(200.202.253.204):. Processed in 0.554822 secs); 21 Sep 2005 20:44:42 -0000 Received: from unknown (HELO ?192.168.1.1?) (daniel@dgnetwork.com.br@200.202.253.204) by zeus.yan.com.br with SMTP; 21 Sep 2005 20:44:42 -0000 Message-ID: <4331C65C.5030308@yan.com.br> Date: Wed, 21 Sep 2005 17:45:16 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: pt-br, pt MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: IPFW NATD = NAT POOL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ddg@yan.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 20:45:25 -0000 Exists the possibility to make NAT POOL with IPFW + NATD ? -- daniel From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 23:46:58 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB5C816A421 for ; Wed, 21 Sep 2005 23:46:58 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: from seddon.ca (seddon.ca [203.209.212.18]) by mx1.FreeBSD.org (Postfix) with SMTP id CF65743D55 for ; Wed, 21 Sep 2005 23:46:55 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: (qmail 31732 invoked by uid 89); 21 Sep 2005 23:46:53 -0000 Received: by seddon.ca (tmda-sendmail, from uid 89); Thu, 22 Sep 2005 09:46:52 +1000 (EST) References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> <4331539D.9030204@wm-access.no> <20050921134029.M34322@fledge.watson.org> <43315E6F.1020003@wm-access.no> In-Reply-To: <43315E6F.1020003@wm-access.no> To: Sten Daniel =?utf-8?B?U8O4cnNkYWw=?= Date: Thu, 22 Sep 2005 09:46:50 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <1127346412.31633.TMDA@seddon.ca> X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Dave+Seddon Cc: freebsd-net@FreeBSD.org Subject: Re: UDP dont fragment bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: das-keyword-net.6770cb@seddon.ca List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2005 23:46:58 -0000 Greeting Sten, I'm a little worried about a couple of the things you've said: 1. "It is more common to block icmp messages about reassembly problems than DF problems IF a message is generated in the first place." I think that's crap. Most firewalls DO correctly and statefully accept the ICMP messages for existing sockets. ipf and pf do, but I'm not sure about IPFW2, but I'd be surprised if it didn't. I'd also be surprised if iptables in linux land didn't track the ICMP. Most commercial firewalls, like Netscreen, Checkpoint, PIX, all do also. 2. "Consider a client connected to an isp's network(1). The isp drops all ICMP packets. That network is then connected to a third network(2) which has a data path that has an MTU of 1400 bytes but also mangles tcp mss to 1360, udp packets must get fragmented. On server size the firewall must reassemble all udp fragments before passing them on to server." If your ISP doesn't understand the importance of ICMP and they just drop it, change ISPs. ICMP is critical to efficient TCP, and your whole thread is about getting that ability for UDP. If you ISP does drop ICMP then the don't defragment option will just result in packets disappearing anyway. Regards, Dave Seddon From owner-freebsd-net@FreeBSD.ORG Wed Sep 21 23:58:32 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34F3516A41F for ; Wed, 21 Sep 2005 23:58:32 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id A74F643D46 for ; Wed, 21 Sep 2005 23:58:31 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by zproxy.gmail.com with SMTP id z31so14245nzd for ; Wed, 21 Sep 2005 16:58:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=SRz/VAX/uOnqYkOK15fa0Cx/vIRpn9Y7xwg5RYSggCxDNsCJ1kGJIJ6Fwnk0c2CVk5tzjTpXnFhkVLtrJuhaw/inV2X1hvhTCLxhB0ZwkoN1ht7CIw+dX5rl6o7ov/6Xf0CSE11t/SrH09dG/iKnjuVRJRZNtdCP8Y41A8ZgOeU= Received: by 10.54.45.76 with SMTP id s76mr2851379wrs; Wed, 21 Sep 2005 16:58:30 -0700 (PDT) Received: from ?192.168.0.143? ( [80.217.193.226]) by mx.gmail.com with ESMTP id g9sm32527wra.2005.09.21.16.58.30; Wed, 21 Sep 2005 16:58:30 -0700 (PDT) Message-ID: <4331F3A3.1060707@gmail.com> Date: Thu, 22 Sep 2005 01:58:27 +0200 From: Pawel Worach User-Agent: Thunderbird 1.4 (X11/20050918) MIME-Version: 1.0 To: net@freebsd.org References: <4330711A.4040808@gmail.com> In-Reply-To: <4330711A.4040808@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: [panic] page fault in tcp_timer_2msl_tw 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, 21 Sep 2005 23:58:32 -0000 Pawel Worach wrote: > (kgdb) print *tw > $1 = {tw_inpcb = 0x0, snd_nxt = 438603527, rcv_nxt = 3383864561, > iss = 438603320, irs = 3383863898, cc_recv = 0, cc_send = 0, > last_win = 65534, tw_so_options = 4, tw_cred = 0x0, t_recent = 0, > t_starttime = 4294952294, tw_time = 0, tw_2msl = {le_next = 0xc24680a8, > le_prev = 0xc06a827c}} I poked a bit more and it looks like the dereference happens here in tcp_timer_2msl_tw(). tcp_timer.c:294 INP_LOCK(tw->tw_inpcb); INP_LOCK macro tries to reference tw->tw_inpcb->inp_mtx while tw->tw_inpcb is null. However I have no idea how it got to this point. -- Pawel From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 00:19:07 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA66E16A41F for ; Thu, 22 Sep 2005 00:19:07 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: from seddon.ca (seddon.ca [203.209.212.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 338D543D46 for ; Thu, 22 Sep 2005 00:19:06 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: (qmail 87253 invoked by uid 89); 22 Sep 2005 00:19:05 -0000 Received: by seddon.ca (tmda-sendmail, from uid 89); Thu, 22 Sep 2005 10:19:05 +1000 (EST) References: <432DAED7.9070404@benswebs.com> <20050921141311.GA40222@top.net.ua> In-Reply-To: <20050921141311.GA40222@top.net.ua> To: freebsd-net@freebsd.org Date: Thu, 22 Sep 2005 10:19:03 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit From: Dave+Seddon Message-ID: <1127348345.87179.TMDA@seddon.ca> X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) Subject: Re: Problems with SK and EM network cards/drivers on my system X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: das-keyword-net.6770cb@seddon.ca List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 00:19:08 -0000 Greetings, There seems to be heaps of people on the list reporting errors with em cards and FreeBSD 5.4 -stable-ish (as in cvsup-ed within the last couple of months). Are there many people running these ok? Perhaps is not the network card so much as some other element of the computer? Regarding the below issue- what about spanning tree? Is portfast enabled? Regards, Dave Maxim Tuliuk writes: > On Sun, Sep 18, 2005 at 14:15 -0400, Benjamin Rosenblum wrote: > ... >> now the EM problem. >> >> when i am running a very high network load (streaming video, dumping >> ALOT of data across the network, etc) the network card disconnects (i >> loose pings and all my transfers drop) and 15-20 seconds later it pops >> up on the console with "em0: Link is up 1000 Mbps Full Duplex" and then >> it starts working again. again im at a dead wall and really want my >> network to work properly so i can do what i need to do. > > Hello! > I've same problems on 5.4-STABLE: > /var/run/dmesg.boot: > FreeBSD 5.4-STABLE #5: Tue Sep 13 16:14:10 EEST 2005 > em0: port 0xbc00-0xbc1f mem 0xff8e0000-0xff8fffff irq 18 at device 1.0 on pci1 > em0: Ethernet address: 00:0c:f1:cf:7e:b6 > em0: Speed:N/A Duplex:N/A > > /etc/rc.conf: > ifconfig_em0="inet ... netmask ... media 100baseTX mediaopt full-duplex" > > /var/log/messages: > Sep 20 15:51:40 tak kernel: em0: Link is up 100 Mbps Full Duplex > Sep 20 17:01:40 tak kernel: em0: Link is up 100 Mbps Full Duplex > Sep 20 18:48:16 tak kernel: em0: Link is up 100 Mbps Full Duplex > > switch: Catalyst 3550 > I changed ports: 100M to 1GB and back; changed cables, but... > no positive results :( > -- > Maxim Tuliuk > WWW: http://primats.org.ua/~mt/ > ICQ: 21134222 > > The bike is absolute freedom of moving > _______________________________________________ > 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 Sep 22 00:27:06 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92A0516A41F for ; Thu, 22 Sep 2005 00:27:06 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: from seddon.ca (seddon.ca [203.209.212.18]) by mx1.FreeBSD.org (Postfix) with SMTP id B48E543D45 for ; Thu, 22 Sep 2005 00:27:05 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: (qmail 1207 invoked by uid 89); 22 Sep 2005 00:27:04 -0000 Received: by seddon.ca (tmda-sendmail, from uid 89); Thu, 22 Sep 2005 10:27:03 +1000 (EST) References: <200509211458.19739.m.jakeman@lancaster.ac.uk> <433179EA.7050304@mac.com> In-Reply-To: <433179EA.7050304@mac.com> To: m.jakeman@lancaster.ac.uk Date: Thu, 22 Sep 2005 10:27:01 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <1127348823.1107.TMDA@seddon.ca> X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Dave+Seddon Cc: freebsd-net@freebsd.org Subject: Re: iperf results X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: das-keyword-net.6770cb@seddon.ca List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 00:27:06 -0000 Greetings, We would all be very interested to see the complete report. Particularly if you fix up the results for FreeBSD :) Chucks right, we need waaay more info. We don't even know what version of FreeBSD your running. There are lots of sysctl variables to adjust. Here's a bunch I played with, importantly, you don't need to recompile the kernel to adjust most of the settings. /etc/sysctl.conf & /boot/loader.conf should do it. See defaults in /boot/defaults/loader.conf --------------------------------- > cat /etc/sysctl.conf #kern.polling.enable=1 kern.polling.enable=1 #kern.polling.user_frac: 50 #kern.polling.reg_frac: 20 ##kern.polling.user_frac=70 ##kern.polling.reg_frac=40 #kern.polling.burst: 5 #kern.polling.each_burst: 5 #kern.polling.burst_max: 150 #default for 100MB/s ##kern.polling.burst=50 kern.polling.each_burst=50 kern.polling.burst_max=1500 #example I found on the web #kern.polling.burst: 1000 #kern.polling.each_burst: 80 #kern.polling.burst_max: 1000 #net.inet.tcp.sendspace: 32768 #net.inet.tcp.recvspace: 65536 #net.inet.tcp.sendspace=65536 #net.inet.tcp.recvspace=65536 #DO NOT SET THIS HIGHER THAN 65536 * 2 (FREEBSD BUG_ net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 #sysctl net.inet.tcp.rfc1323=1 Activate window scaling and timestamp options according to RFC 1323. #net.inet.tcp.rfc1323=1 net.inet.tcp.delayed_ack=0 net.inet.icmp.icmplim=1000 #kern.ipc.maxsockbuf: 262144 ###kern.ipc.maxsockbuf=20480000 #The kern.ipc.somaxconn sysctl variable limits the size of the listen queue for accepting new TCP connections. The default value of 128 is typically too low for robust handling of new connections in a heavily loaded web server environment. #kern.ipc.somaxconn: 128 kern.ipc.somaxconn=1024 #The TCP Bandwidth Delay Product Limiting is similar to TCP/Vegas in NetBSD. It can be enabled by setting net.inet.tcp.inflight.enable sysctl variable to 1. The system will attempt to calculate the bandwidth delay product for each connection and limit the amount of data queued to the network to just the amount required to maintain optimum throughput. #This feature is useful if you are serving data over modems, Gigabit Ethernet, or even high speed WAN links (or any other link with a high bandwidth delay product), especially if you are also using window scaling or have configured a large send window. If you enable this option, you should also be sure to set net.inet.tcp.inflight.debug to 0 (disable debugging), and for production use setting net.inet.tcp.inflight.min to at least 6144 may be beneficial. #these are the defaults #net.inet.tcp.inflight.enable: 1 #net.inet.tcp.inflight.debug: 0 #net.inet.tcp.inflight.min: 6144 #net.inet.tcp.inflight.max: 1073725440 #net.inet.tcp.inflight.stab: 20 #Disable entropy harvesting for ethernet devices and interrupts. There are optimizations present in 6.x that have not yet been backported that improve the overhead of entropy harvesting, but you can get the same benefits by disabling it. In your environment, it's likely not needed. I hope to backport these changes in a couple of weeks to 5-STABLE. kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 #################################################3 #/boot/loader stuff #kern.ipc.maxsockets: 131072 #sysctl: Tunable values are set in /boot/loader.conf #sysctl kern.ipc.nmbclusters View maximum number of mbuf clusters. Used for storage of data packets to/from the network interface. Can only be set att boot time - see above. #kern.ipc.nmbclusters: 25600 --------------------------------- Regards, Dave Chuck Swiger writes: > Matthew Jakeman wrote: >> Some colleagues and myself have performed some simple tests on various >> OS's using iperf to simply fire packets from one pc to another over >> ethernet to test a few characteristics such as packet loss, jitter etc >> between IPv4 and IPv6. The configuration for all three OS's were 'out of >> the box' installs. The results we got back from that are strange for >> FreeBSD with regards to the packet loss iperf reports and I was wondering >> if anyone has any ideas why they might be as they are. The image at the >> link below shows the packet loss results for windows, Linux and FreeBSD >> for comparison! As you can see the packet loss for v6 is substantially >> less than v4 on FreeBSD, however this is still substantially larger than >> for the other two OS's, does anyone have any idea why this might be? >> >> http://www.mjakeman.co.uk/images/4v6tests.jpg > > You're probably getting packet loss either because you are filling up the > network buffer space without pausing until it drains, or are running into > ICMP response limits. If you're going to be testing latency around the > millisecond level, you'll need to increase HZ to at least 1000, if not > better. > > For example, set "sysctl net.inet.icmp.icmplim=20" on a machine called > shot. > > # ping -c 1000 -i 0.01 -s 1280 shot > PING shot (199.103.21.228): 1280 data bytes > 1288 bytes from 199.103.21.228: icmp_seq=0 ttl=64 time=0.935 ms > [ ... ] > --- shot ping statistics --- > 1000 packets transmitted, 220 packets received, 78% packet loss > round-trip min/avg/max/stddev = 0.842/0.877/1.234/0.077 ms > > With "sysctl net.inet.icmp.icmplim=2000": > > [ ... ] > 1288 bytes from 199.103.21.228: icmp_seq=999 ttl=64 time=0.870 ms > > --- shot ping statistics --- > 1000 packets transmitted, 1000 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.838/0.858/1.068/0.020 ms > > ...or even: > > # ping -c 1000 -i 0.001 -s 1280 shot > [ ... ] > 1288 bytes from 199.103.21.228: icmp_seq=999 ttl=64 time=0.849 ms > > --- shot ping statistics --- > 1000 packets transmitted, 1000 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.839/0.856/1.010/0.015 ms > > ----- > > You haven't provided a test methodology. You haven't provided the source > code for the benchmark program you are using. You also haven't provided > any details about the hardware being used, the network topology, or even > what some of the values in this .jpg image mean. (For example, what is > the first column, "duration", measuring?) > > -- > -Chuck > > _______________________________________________ > 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 Sep 22 01:18:27 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 215B916A41F for ; Thu, 22 Sep 2005 01:18:27 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CC3743D45 for ; Thu, 22 Sep 2005 01:18:26 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (h229.p049.iij4u.or.jp [210.130.49.229]) by r-dd.iij4u.or.jp (4U-MR/r-dd) id j8M1IMwT001064; Thu, 22 Sep 2005 10:18:23 +0900 (JST) Date: Thu, 22 Sep 2005 10:18:09 +0900 (JST) Message-Id: <20050922.101809.45174516.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: freebsd-net@freebsd.org In-Reply-To: References: <20050921.161113.59648691.Noritoshi@Demizu.ORG> <20050921.184114.115904070.Noritoshi@Demizu.ORG> X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: rfc2385 (tcp md5 checksums) in -current 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: Thu, 22 Sep 2005 01:18:27 -0000 > > --- print-tcp.c-ORG Thu Apr 21 15:36:05 2005 > > +++ print-tcp.c Wed Sep 21 18:43:51 2005 > > @@ -799,7 +799,7 @@ > > MD5_Update(&ctx, tcpmd5secret, strlen(tcpmd5secret)); > > MD5_Final(sig, &ctx); > > > > - if (memcmp(rcvsig, sig, 16)) > > + if (memcmp(rcvsig, sig, TCP_SIGLEN) == 0) > > return (SIGNATURE_VALID); > > else > > return (SIGNATURE_INVALID); > > The original code there certainly looks wrong! After patching, FreeBSD's > checksum returns valid. I'll have to see what's up with the originating > checksum. Many Thanks! Thanks. I submitted this problem to the bug tracker of the tcpdump project at http://sourceforge.net/projects/tcpdump/ . The request ID is 1298259. Regards, Noritoshi Demizu From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 07:22:47 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB06116A41F; Thu, 22 Sep 2005 07:22:47 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D86343D46; Thu, 22 Sep 2005 07:22:47 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EILPO-0000eO-30; Thu, 22 Sep 2005 09:22:18 +0200 Date: Thu, 22 Sep 2005 09:22:50 +0200 From: Marcin Jessa To: FreeBSD-Current , FreeBSD-net Message-Id: <20050922092250.55b4716a.lists@yazzy.org> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: Subject: tap devices and DHCP. 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, 22 Sep 2005 07:22:47 -0000 Hi guys. I do not know if it's meant to be that way but tap devices cannot get IPs assigned with DHCP. I did not check the old dhclient code but the new one cannot hand over DHCP requests to tap devices. I was sure a tap device acted as an ethernet device even though it's a virtual one, since one can manually assign IP to tap. It can however assign IP to a bridge (with DHCP) with dev tap as a member of it. Could someone explain me please if this behaviour is on purpose or just a problem with DHCP? Cheers, Marcin. From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 08:34:18 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82BDA16A41F; Thu, 22 Sep 2005 08:34:18 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (mail.writemehere.com [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 526E243D45; Thu, 22 Sep 2005 08:34:18 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ddg@yan.com.br References: <4331C65C.5030308@yan.com.br> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20050922084116.132E970DCD6@mail.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Thu, 22 Sep 2005 08:41:16 +0000 (GMT) Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW NATD = NAT POOL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 08:34:18 -0000 No. I think each instance of natd (at least last time I looked at it) could only use one IP address as it's public address. Cheers, Nate Daniel Dias Gonηalves wrote: > Exists the possibility to make NAT POOL with IPFW + NATD ? > From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 08:39:52 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B78D16A41F; Thu, 22 Sep 2005 08:39:52 +0000 (GMT) (envelope-from regnauld@moof.catpipe.net) Received: from moof.catpipe.net (moof.catpipe.net [195.249.214.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id B54A343D45; Thu, 22 Sep 2005 08:39:51 +0000 (GMT) (envelope-from regnauld@moof.catpipe.net) Received: from localhost (localhost [127.0.0.1]) by localhost.catpipe.net (Postfix) with ESMTP id E9CC71B3F7; Thu, 22 Sep 2005 10:39:47 +0200 (CEST) Received: from moof.catpipe.net ([127.0.0.1]) by localhost (moof.catpipe.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47658-05; Thu, 22 Sep 2005 10:39:43 +0200 (CEST) Received: by moof.catpipe.net (Postfix, from userid 1001) id 6992A1B3E6; Thu, 22 Sep 2005 10:39:41 +0200 (CEST) Date: Thu, 22 Sep 2005 10:39:41 +0200 From: Phil Regnauld To: nielsen@memberwebs.com Message-ID: <20050922083941.GD46081@moof.catpipe.net> References: <4331C65C.5030308@yan.com.br> <20050922084116.132E970DCD6@mail.npubs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050922084116.132E970DCD6@mail.npubs.com> X-Operating-System: FreeBSD 4.8-STABLE i386 Organization: catpipe Systems ApS User-Agent: Mutt/1.5.6i X-Virus-Scanned: amavisd-new at catpipe.net Cc: freebsd-hackers@freebsd.org, ddg@yan.com.br, freebsd-net@freebsd.org Subject: Re: IPFW NATD = NAT POOL 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, 22 Sep 2005 08:39:52 -0000 Nate Nielsen (nielsen-list) writes: > No. I think each instance of natd (at least last time I looked at it) > could only use one IP address as it's public address. One could use probability rules to divert to different natds with different NAT addresses, and use choparp / aliases to get the traffic back. So: divert 10001 ip from to any prob 0.25 via (appropriate skiptos) divert 10004 ip from to any prob 0.25 via ... divert 10001 ip from any to 1.2.3.4 in via divert 10002 ip from any to 1.2.3.5 in via ... Then natd -alias_address 1.2.3.4 -p 10001 natd -alias_address 1.2.3.5 -p 10002 natd -alias_address 1.2.3.6 -p 10003 natd -alias_address 1.2.3.7 -p 10004 ... + relevant ifconfig alias or choparp to force trafic your way when someone ARPs for the additional "pool" addresses. Gross, eh ? :) From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 09:50:10 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC2B216A41F; Thu, 22 Sep 2005 09:50:10 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F65543D45; Thu, 22 Sep 2005 09:50:10 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by smtp3-g19.free.fr (Postfix) with ESMTP id F09D12398F; Thu, 22 Sep 2005 11:50:04 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 1DD6E405D; Thu, 22 Sep 2005 11:50:03 +0200 (CEST) Date: Thu, 22 Sep 2005 11:50:02 +0200 From: Jeremie Le Hen To: Sten Daniel =?iso-8859-1?Q?S=F8rsdal?= Message-ID: <20050922095002.GN24643@obiwan.tataz.chchile.org> References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> <4331539D.9030204@wm-access.no> <20050921134029.M34322@fledge.watson.org> <43315E6F.1020003@wm-access.no> <20050921142903.J34322@fledge.watson.org> <4331956A.2060406@wm-access.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4331956A.2060406@wm-access.no> User-Agent: Mutt/1.5.10i Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: UDP dont fragment bit 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, 22 Sep 2005 09:50:11 -0000 Hi, > Often there already is need for a tcp connection for authentication, > negotiation and so forth. > > RTT could, among other things, make a discovery process choose how fine > the increments/descrements should be. > > Estimated bandwidth could also help the actual data transport start out > with a more situation correct value. > > However with the abundance of routers modifying TCP MSS correctly > incorrectly and the odd chance that the data path of UDP packets is > different than TCP packets it wouldnt really give anything necessarily > reliable discovery process. And taking advantage of such values could > make the process more complex or less reliable. This is a rather specific case IMHO. BSD community didn't use to take care of such non standard behaviours, AFAIK. What you describe here is not really what's currently stated in RFCs. I would not be in favor of adding such an option in the FreeBSD kernel because, as Robert stated, this doesn't bring anything if not coupled with a non-trivial mechanim that could provide the user with ICMP MTU events. If one adds this option to the manual page, this will lead for sure to have mails emitted on this even list asking for how to retrieve those informations. Furthermore, I ought to add that the algorithm you described in pseudo-code lacks of robustness because of possible network congestion, which means this isn't something one would really see in wide use. In other words, I think the feature you're calling for is really specific to your problem, regarding your current network environnement. The misbehaviour of some particular network-fascist ISP should not reach the FreeBSD source tree. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 10:35:07 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DE6F16A41F; Thu, 22 Sep 2005 10:35:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7F2043D45; Thu, 22 Sep 2005 10:35:06 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 3D41B46B4D; Thu, 22 Sep 2005 06:35:06 -0400 (EDT) Date: Thu, 22 Sep 2005 11:35:06 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Marcin Jessa In-Reply-To: <20050922092250.55b4716a.lists@yazzy.org> Message-ID: <20050922113336.K34322@fledge.watson.org> References: <20050922092250.55b4716a.lists@yazzy.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-net , FreeBSD-Current Subject: Re: tap devices and DHCP. 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, 22 Sep 2005 10:35:07 -0000 On Thu, 22 Sep 2005, Marcin Jessa wrote: > I do not know if it's meant to be that way but tap devices cannot get > IPs assigned with DHCP. I did not check the old dhclient code but the > new one cannot hand over DHCP requests to tap devices. I was sure a tap > device acted as an ethernet device even though it's a virtual one, since > one can manually assign IP to tap. It can however assign IP to a bridge > (with DHCP) with dev tap as a member of it. Could someone explain me > please if this behaviour is on purpose or just a problem with DHCP? That's certainly undesirable. Could you tell us a little bit about the setup you're running? Specifically, what's on the other end of the tap device, and how does it hook up to the DHCP server? Could you show the ifconfig output for the interface before and after running dhclient? And then again after manually assigning an address? Thanks, Robert N M Watson From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 10:40:58 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C92C216A41F for ; Thu, 22 Sep 2005 10:40:58 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id F41A643D48 for ; Thu, 22 Sep 2005 10:40:57 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (ripyjs@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j8MAep3m063280 for ; Thu, 22 Sep 2005 12:40:56 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j8MAep8Q063279; Thu, 22 Sep 2005 12:40:51 +0200 (CEST) (envelope-from olli) Date: Thu, 22 Sep 2005 12:40:51 +0200 (CEST) Message-Id: <200509221040.j8MAep8Q063279@lurza.secnetix.de> From: Oliver Fromme To: freebsd-net@FreeBSD.ORG X-Newsgroups: list.freebsd-net User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: VIA VT6103 support (VIA EPIA PD) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@FreeBSD.ORG List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 10:40:58 -0000 Hi, I'm currently considering to buy a VIA EPIA PD-class main- board as a replacement for my current LAN router. The mainboard has two fastethernet ports, according to the spec it is one VIA VT6105 and one VIA VT6103. I know that both are supposed to be supported by FreeBSD. However, searching the lists and PR database reveals that a few people had problems with the VT6103 (and VT6102, it seems), causing the interface to hang randomly when there is a lot of traffic. I couldn't find any definite infor- mation about whether those problems have been solved or not. Therefore I'd like to ask: Does the VIA VT6103 work with- out problems under FreeBSD (RELENG_5 or RELENG_6, or maybe even RELENG_4)? Better yet: Does someone use an EPIA PD* board with both on-board interfaces under FreeBSD without problems? Thank you very much in advance! Best regards Oliver PS: The board has only one PCI slot, and I already need that slot for a SCSI card, so I cannot use a CPI network card. Therefore it is critical that the on-board NICs work. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 10:41:14 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87A1C16A41F; Thu, 22 Sep 2005 10:41:14 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDFA243D53; Thu, 22 Sep 2005 10:41:11 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j8MAf5uo015327; Thu, 22 Sep 2005 14:41:06 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j8MAf5V8015322; Thu, 22 Sep 2005 14:41:05 +0400 (MSD) (envelope-from yar) Date: Thu, 22 Sep 2005 14:41:05 +0400 From: Yar Tikhiy To: freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-ID: <20050922104104.GA13539@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: "ifconfig -vlandev" syntax 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, 22 Sep 2005 10:41:14 -0000 Hi folks, As our ifconfig(8) is growing more options for special interface types, inconsistencies sneak into their syntax. In particular, -vlandev takes a useless argument (vlan(4) cannot attach to more than one parent anyway) while, e.g., -carpdev doesn't need one. Personally, I like the latter since having to type unneeded words on the command line annoys me. Do you think that making -vlandev need no arguments in CURRENT would break many existing things? -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 10:50:02 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C03916A41F; Thu, 22 Sep 2005 10:50:02 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 718FF43D45; Thu, 22 Sep 2005 10:49:59 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=marcin) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EIOdv-0007AE-NK; Thu, 22 Sep 2005 12:49:32 +0200 Date: Thu, 22 Sep 2005 12:50:03 +0200 From: Marcin Jessa To: Robert Watson Message-Id: <20050922125003.67071cb1.lists@yazzy.org> In-Reply-To: <20050922113336.K34322@fledge.watson.org> References: <20050922092250.55b4716a.lists@yazzy.org> <20050922113336.K34322@fledge.watson.org> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.0 (GTK+ 2.6.8; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: tap devices and DHCP. 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, 22 Sep 2005 10:50:02 -0000 On Thu, 22 Sep 2005 11:35:06 +0100 (BST) Robert Watson wrote: > > On Thu, 22 Sep 2005, Marcin Jessa wrote: > > > I do not know if it's meant to be that way but tap devices cannot > > get IPs assigned with DHCP. I did not check the old dhclient code > > but the new one cannot hand over DHCP requests to tap devices. I > > was sure a tap device acted as an ethernet device even though it's > > a virtual one, since one can manually assign IP to tap. It can > > however assign IP to a bridge (with DHCP) with dev tap as a member > > of it. Could someone explain me please if this behaviour is on > > purpose or just a problem with DHCP? > > That's certainly undesirable. Could you tell us a little bit about > the setup you're running? Specifically, what's on the other end of > the tap device, and how does it hook up to the DHCP server? I have a bridge with one fxp0 nic (which I renamed to net0) and one tap1 device. The other end runs linux as DHCP server on LAN. It communicates with the DHCP server through the fxp0 device which is a member of the same bridge. > Could you show the ifconfig output for the interface before and after > running dhclient? And then again after manually assigning an address? # ifconfig bridge0 create # ifconfig bridge0 addm net0 stp net0 addm tap1 stp tap1 up wlan0: flags=8843 mtu 1500 inet6 fe80::212:f0ff:fe12:29b3%wlan0 prefixlen 64 scopeid 0x1 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:12:f0:12:29:b3 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g (DS/2Mbps) status: associated ssid XXYYZZ channel 2 bssid 00:20:a6:4c:ef:62 authmode OPEN privacy OFF txpowmax 100 protmode CTS bintval 100 net0: flags=8943 mtu 1500 options=8 inet6 fe80::20a:e4ff:fe2f:9dce%net0 prefixlen 64 scopeid 0x2 ether 00:0a:e4:2f:9d:ce media: Ethernet autoselect (100baseTX ) status: active pflog0: flags=0<> mtu 33208 pfsync0: flags=0<> mtu 2020 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff000000 tap0: flags=8842 mtu 1500 ether 00:bd:16:8d:03:00 tap1: flags=8943 mtu 1500 inet6 fe80::2bd:16ff:fe8d:301%tap1 prefixlen 64 scopeid 0x7 inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 ether 00:bd:16:8d:03:01 bridge0: flags=8041 mtu 1500 inet 192.168.2.222 netmask 0xffffff00 ether ac:de:48:ca:32:d3 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: tap1 flags=7 member: net0 flags=7 From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 10:54:24 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30E4C16A41F; Thu, 22 Sep 2005 10:54:24 +0000 (GMT) (envelope-from justas@vusa.lt) Received: from vusa.lt (ns.vusa.lt [193.219.44.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id B37C943D45; Thu, 22 Sep 2005 10:54:23 +0000 (GMT) (envelope-from justas@vusa.lt) Received: from localhost (localhost [127.0.0.1]) by vusa.lt (Postfix) with ESMTP id 42C551028D; Thu, 22 Sep 2005 13:54:22 +0300 (EEST) Received: from vusa.lt ([127.0.0.1]) by localhost (vusa.lt [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94867-09; Thu, 22 Sep 2005 13:54:22 +0300 (EEST) Received: from mail.vusa.lt (localhost [127.0.0.1]) by vusa.lt (Postfix) with SMTP id DBA3A1028B; Thu, 22 Sep 2005 13:54:21 +0300 (EEST) Received: from 81.7.76.219 (proxying for 127.0.0.1) (SquirrelMail authenticated user justas) by mail.vusa.lt with HTTP; Thu, 22 Sep 2005 13:54:21 +0300 (EEST) Message-ID: <53380.81.7.76.219.1127386461.squirrel@mail.vusa.lt> In-Reply-To: <20050922104104.GA13539@comp.chem.msu.su> References: <20050922104104.GA13539@comp.chem.msu.su> Date: Thu, 22 Sep 2005 13:54:21 +0300 (EEST) From: "Justas Jakubauskas" To: "Yar Tikhiy" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: "ifconfig -vlandev" syntax X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: justas@vusa.lt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 10:54:24 -0000 > -vlandev takes a useless argument (vlan(4) cannot attach to more > than one parent anyway) while, e.g., -carpdev doesn't need one. And how system should know, to which device attach your vlan ? From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 11:05:26 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E10016A420; Thu, 22 Sep 2005 11:05:26 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84CC843D46; Thu, 22 Sep 2005 11:05:17 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.3/8.13.3) with ESMTP id j8MB5AlW016461; Thu, 22 Sep 2005 15:05:10 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.3/8.13.3/Submit) id j8MB5ADw016459; Thu, 22 Sep 2005 15:05:10 +0400 (MSD) (envelope-from yar) Date: Thu, 22 Sep 2005 15:05:09 +0400 From: Yar Tikhiy To: Justas Jakubauskas Message-ID: <20050922110509.GA16325@comp.chem.msu.su> References: <20050922104104.GA13539@comp.chem.msu.su> <53380.81.7.76.219.1127386461.squirrel@mail.vusa.lt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53380.81.7.76.219.1127386461.squirrel@mail.vusa.lt> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: "ifconfig -vlandev" syntax 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, 22 Sep 2005 11:05:26 -0000 On Thu, Sep 22, 2005 at 01:54:21PM +0300, Justas Jakubauskas wrote: > > > -vlandev takes a useless argument (vlan(4) cannot attach to more > > than one parent anyway) while, e.g., -carpdev doesn't need one. > > And how system should know, to which device attach your vlan ? "-vlandev" is for _detaching_ a vlan interface from its parent. The option is used more often than it could because one cannot move a vlan interface to another parent or VLAN tag w/o detaching it first. -- Yar From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 11:07:14 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EED4816A41F for ; Thu, 22 Sep 2005 11:07:14 +0000 (GMT) (envelope-from mt@smtp.top.net.ua) Received: from smtp.top.net.ua (smtp.top.net.ua [193.109.60.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7563343D45 for ; Thu, 22 Sep 2005 11:07:14 +0000 (GMT) (envelope-from mt@smtp.top.net.ua) Received: from smtp.top.net.ua (localhost [127.0.0.1]) by smtp.top.net.ua (Postfix) with ESMTP id A68781B880E; Thu, 22 Sep 2005 14:07:12 +0300 (EEST) Received: by smtp.top.net.ua (Postfix, from userid 1012) id 834941B8850; Thu, 22 Sep 2005 14:07:12 +0300 (EEST) Date: Thu, 22 Sep 2005 14:07:12 +0300 From: Maxim Tuliuk To: das-keyword-net.6770cb@seddon.ca Message-ID: <20050922110712.GA15512@top.net.ua> References: <432DAED7.9070404@benswebs.com> <20050921141311.GA40222@top.net.ua> <1127348345.87179.TMDA@seddon.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1127348345.87179.TMDA@seddon.ca> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-net@freebsd.org Subject: Re: Problems with SK and EM network cards/drivers on my system 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, 22 Sep 2005 11:07:15 -0000 Yes, portfast is enabled, switchport mode trunk, spanning tree is enabled too. On Thu, Sep 22, 2005 at 10:19 +1000, Dave+Seddon wrote: > Greetings, > > There seems to be heaps of people on the list reporting errors with em > cards and FreeBSD 5.4 -stable-ish (as in cvsup-ed within the last couple of > months). Are there many people running these ok? Perhaps is not the > network card so much as some other element of the computer? > > Regarding the below issue- what about spanning tree? Is portfast enabled? > > Regards, > Dave > > > Maxim Tuliuk writes: > > >On Sun, Sep 18, 2005 at 14:15 -0400, Benjamin Rosenblum wrote: > >... > >>now the EM problem. > >> > >>when i am running a very high network load (streaming video, dumping > >>ALOT of data across the network, etc) the network card disconnects (i > >>loose pings and all my transfers drop) and 15-20 seconds later it pops > >>up on the console with "em0: Link is up 1000 Mbps Full Duplex" and then > >>it starts working again. again im at a dead wall and really want my > >>network to work properly so i can do what i need to do. > > > >Hello! > >I've same problems on 5.4-STABLE: > >/var/run/dmesg.boot: > >FreeBSD 5.4-STABLE #5: Tue Sep 13 16:14:10 EEST 2005 > >em0: port > >0xbc00-0xbc1f mem 0xff8e0000-0xff8fffff irq 18 at device 1.0 on pci1 > >em0: Ethernet address: 00:0c:f1:cf:7e:b6 > >em0: Speed:N/A Duplex:N/A > > > >/etc/rc.conf: > >ifconfig_em0="inet ... netmask ... media 100baseTX mediaopt full-duplex" > > > >/var/log/messages: > >Sep 20 15:51:40 tak kernel: em0: Link is up 100 Mbps Full Duplex > >Sep 20 17:01:40 tak kernel: em0: Link is up 100 Mbps Full Duplex > >Sep 20 18:48:16 tak kernel: em0: Link is up 100 Mbps Full Duplex > > > >switch: Catalyst 3550 > >I changed ports: 100M to 1GB and back; changed cables, but... > >no positive results :( > >-- > >Maxim Tuliuk > >WWW: http://primats.org.ua/~mt/ > >ICQ: 21134222 > > > >The bike is absolute freedom of moving > >_______________________________________________ > >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" -- Maxim Tuliuk, Network Engineer ISP "TopNet": http://top.net.ua/ Phone: (+38044) 246 3669 From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 11:13:38 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C23D16A440 for ; Thu, 22 Sep 2005 11:13:38 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD21343D4C for ; Thu, 22 Sep 2005 11:13:37 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.9.8] (14.80-203-184.nextgentel.com [80.203.184.14]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j8MBDZ7F000721; Thu, 22 Sep 2005 13:13:35 +0200 Message-ID: <433291DD.6060801@wm-access.no> Date: Thu, 22 Sep 2005 13:13:33 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave+Seddon References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> <4331539D.9030204@wm-access.no> <20050921134029.M34322@fledge.watson.org> <43315E6F.1020003@wm-access.no> <1127346412.31633.TMDA@seddon.ca> In-Reply-To: <1127346412.31633.TMDA@seddon.ca> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=C308A003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@FreeBSD.org Subject: Re: UDP dont fragment bit 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, 22 Sep 2005 11:13:38 -0000 Dave+Seddon wrote: > Greeting Sten, > I'm a little worried about a couple of the things you've said: > > 1. "It is more common to block icmp messages about reassembly problems > than DF problems IF a message is generated in the first place." > I think that's crap. Most firewalls DO correctly and statefully accept > the ICMP messages for existing sockets. ipf and pf do, but I'm not sure > about IPFW2, but I'd be surprised if it didn't. I'd also be surprised > if iptables in linux land didn't track the ICMP. Most commercial > firewalls, like Netscreen, Checkpoint, PIX, all do also. You said it, most do it correctly but many do not. I dont think IPFW2 does. Many low end DSL routers dont. But it's not the firewalls fault, it's admins who block wrong icmp types. I.e. ICMP ECHO may pass but ICMP FRAGMENT TIME EXCEEDED may not. People are taught that they need to specifically permit ICMP types and drop all others. Often they do not identify the correct ones or only identify the correct ones for their network only. > > 2. "Consider a client connected to an isp's network(1). The isp drops all > ICMP packets. That network is then connected to a third network(2) which > has a data path that has an MTU of 1400 bytes but also mangles tcp mss > to 1360, udp packets must get fragmented. On server size the firewall > must reassemble all udp fragments before passing them on to server." > If your ISP doesn't understand the importance of ICMP and they just drop > it, change ISPs. ICMP is critical to efficient TCP, and your whole > thread is about getting that ability for UDP. If you ISP does drop ICMP > then the don't defragment option will just result in packets > disappearing anyway. > My ISP would never but they did drop ICMP's then the whole point is that the packet would disappear and not get fragmented. You assume that UDP packets would have DF set by default. This is not a discussion about wether it should be set by default because it shouldn't. DF should never ever be set by default! One application would be to be able to find the most efficient packet size for UDP from unprivileged userland in a multicast or unicast environment regardless of both ICMP and fragmentation issues. With DF set one would not need ICMP's to find the most efficient packet size in a multicast application. With DF NOT set, one is subject to fragmentation thus it would not necessarily be the most efficient packet size. -- Sten Daniel Sψrsdal From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 11:34:13 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF74816A41F; Thu, 22 Sep 2005 11:34:13 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AAAB43D45; Thu, 22 Sep 2005 11:34:13 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.9.8] (14.80-203-184.nextgentel.com [80.203.184.14]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j8MBYCrn005058; Thu, 22 Sep 2005 13:34:12 +0200 Message-ID: <433296B2.2000803@wm-access.no> Date: Thu, 22 Sep 2005 13:34:10 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeremie Le Hen References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org> <4331539D.9030204@wm-access.no> <20050921134029.M34322@fledge.watson.org> <43315E6F.1020003@wm-access.no> <20050921142903.J34322@fledge.watson.org> <4331956A.2060406@wm-access.no> <20050922095002.GN24643@obiwan.tataz.chchile.org> In-Reply-To: <20050922095002.GN24643@obiwan.tataz.chchile.org> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=C308A003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Robert Watson Subject: Re: UDP dont fragment bit 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, 22 Sep 2005 11:34:14 -0000 Jeremie Le Hen wrote: > Hi, > > >>Often there already is need for a tcp connection for authentication, >>negotiation and so forth. >> >>RTT could, among other things, make a discovery process choose how fine >>the increments/descrements should be. >> >>Estimated bandwidth could also help the actual data transport start out >>with a more situation correct value. >> >>However with the abundance of routers modifying TCP MSS correctly >>incorrectly and the odd chance that the data path of UDP packets is >>different than TCP packets it wouldnt really give anything necessarily >>reliable discovery process. And taking advantage of such values could >>make the process more complex or less reliable. > > > This is a rather specific case IMHO. BSD community didn't use to take > care of such non standard behaviours, AFAIK. What you describe here > is not really what's currently stated in RFCs. That it is not stated in an RFC is true. Please explain why it would have to be? > I would not be in favor of adding such an option in the FreeBSD kernel > because, as Robert stated, this doesn't bring anything if not coupled > with a non-trivial mechanim that could provide the user with ICMP MTU > events. If one adds this option to the manual page, this will lead > for sure to have mails emitted on this even list asking for how to > retrieve those informations. Furthermore, I ought to add that the > algorithm you described in pseudo-code lacks of robustness because > of possible network congestion, which means this isn't something one > would really see in wide use. You assume such an application would need ICMP. Again, let me state that such an application would not need ICMP's and it would work despite fragmentation issues. Retrieve what information? And an application based solely on my pseudo-code lacks robustness to network congestion is correct. So what? > In other words, I think the feature you're calling for is really > specific to your problem, regarding your current network environnement. > The misbehaviour of some particular network-fascist ISP should not > reach the FreeBSD source tree. You are mistaken in assuming my isp would block icmps or fragments. And you are mistaken that this was meant to solve a problem specific to one network. It is about giving unprivileged applications the opportunity to find the optimal packet size without relying on network policies or flaws. -- Sten Daniel Sψrsdal From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 12:10:56 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE49F16A41F for ; Thu, 22 Sep 2005 12:10:56 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from lakepoint.domeneshop.no (lakepoint.domeneshop.no [194.63.248.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E96A43D46 for ; Thu, 22 Sep 2005 12:10:53 +0000 (GMT) (envelope-from lists@wm-access.no) Received: from [192.168.9.8] (14.80-203-184.nextgentel.com [80.203.184.14]) (authenticated bits=0) by lakepoint.domeneshop.no (8.13.4/8.13.4) with ESMTP id j8MCArJC007946; Thu, 22 Sep 2005 14:10:53 +0200 Message-ID: <43329F4A.4050904@wm-access.no> Date: Thu, 22 Sep 2005 14:10:50 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin Jessa References: <20050922092250.55b4716a.lists@yazzy.org> <20050922113336.K34322@fledge.watson.org> <20050922125003.67071cb1.lists@yazzy.org> In-Reply-To: <20050922125003.67071cb1.lists@yazzy.org> X-Enigmail-Version: 0.92.0.0 OpenPGP: id=C308A003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: tap devices and DHCP. 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, 22 Sep 2005 12:10:56 -0000 > > > I have a bridge with one fxp0 nic (which I renamed to net0) and one tap1 > device. The other end runs linux as DHCP server on LAN. > It communicates with the DHCP server through the fxp0 device which is a > member of the same bridge. > Then it would in my opinion be more correct to run dhclient on the bridge interface. However bridge0 doesnt seem to support broadcast packets which are necessary for DHCP to work. That could be the problem. I see that tap1 does support broadcast but since it is a member of the bridge it should/shouldn't support it depending on how you see it. -- Sten Daniel Sψrsdal From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 14:46:37 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10AC716A41F for ; Thu, 22 Sep 2005 14:46:37 +0000 (GMT) (envelope-from m.jakeman@lancaster.ac.uk) Received: from hedwig.lancs.ac.uk (hedwig.lancs.ac.uk [148.88.0.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 710C943D45 for ; Thu, 22 Sep 2005 14:46:35 +0000 (GMT) (envelope-from m.jakeman@lancaster.ac.uk) Received: from marl.lancs.ac.uk ([148.88.1.10]) by hedwig.lancs.ac.uk with esmtp (Exim 4.52) id 1EISLK-0006IJ-R4 for freebsd-net@freebsd.org; Thu, 22 Sep 2005 15:46:34 +0100 Received: from ina044000004.lancs.ac.uk ([194.80.37.87]) by marl.lancs.ac.uk with esmtp (Exim 4.52) id 1EISLL-0000E3-8R; Thu, 22 Sep 2005 15:46:35 +0100 From: Matthew Jakeman Organization: Lancaster University To: freebsd-net@freebsd.org Date: Thu, 22 Sep 2005 15:52:02 +0000 User-Agent: KMail/1.8 References: <200509211458.19739.m.jakeman@lancaster.ac.uk> <433179EA.7050304@mac.com> In-Reply-To: <433179EA.7050304@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509221552.02900.m.jakeman@lancaster.ac.uk> Cc: Subject: Re: iperf results X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: m.jakeman@lancaster.ac.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 14:46:37 -0000 On Wednesday 21 September 2005 15:19, Chuck Swiger wrote: > Matthew Jakeman wrote: > > Some colleagues and myself have performed some simple tests on various > > OS's using iperf to simply fire packets from one pc to another over > > ethernet to test a few characteristics such as packet loss, jitter etc > > between IPv4 and IPv6. The configuration for all three OS's were 'out of > > the box' installs. The results we got back from that are strange for > > FreeBSD with regards to the packet loss iperf reports and I was wondering > > if anyone has any ideas why they might be as they are. The image at the > > link below shows the packet loss results for windows, Linux and FreeBSD > > for comparison! As you can see the packet loss for v6 is substantially > > less than v4 on FreeBSD, however this is still substantially larger than > > for the other two OS's, does anyone have any idea why this might be? > > > > http://www.mjakeman.co.uk/images/4v6tests.jpg > > You're probably getting packet loss either because you are filling up the > network buffer space without pausing until it drains, or are running into > ICMP response limits. If you're going to be testing latency around the > millisecond level, you'll need to increase HZ to at least 1000, if not > better. > > For example, set "sysctl net.inet.icmp.icmplim=20" on a machine called > shot. > > # ping -c 1000 -i 0.01 -s 1280 shot > PING shot (199.103.21.228): 1280 data bytes > 1288 bytes from 199.103.21.228: icmp_seq=0 ttl=64 time=0.935 ms > [ ... ] > --- shot ping statistics --- > 1000 packets transmitted, 220 packets received, 78% packet loss > round-trip min/avg/max/stddev = 0.842/0.877/1.234/0.077 ms > > With "sysctl net.inet.icmp.icmplim=2000": > > [ ... ] > 1288 bytes from 199.103.21.228: icmp_seq=999 ttl=64 time=0.870 ms > > --- shot ping statistics --- > 1000 packets transmitted, 1000 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.838/0.858/1.068/0.020 ms > > ...or even: > > # ping -c 1000 -i 0.001 -s 1280 shot > [ ... ] > 1288 bytes from 199.103.21.228: icmp_seq=999 ttl=64 time=0.849 ms > > --- shot ping statistics --- > 1000 packets transmitted, 1000 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.839/0.856/1.010/0.015 ms > > ----- > > You haven't provided a test methodology. You haven't provided the source > code for the benchmark program you are using. You also haven't provided > any details about the hardware being used, the network topology, or even > what some of the values in this .jpg image mean. (For example, what is the > first column, "duration", measuring?) Thanks for the reply, I will provide more detail about the setup and how the experiments have been run now! The PC's are both dual processor Intel xeon 3Ghz using Broadcom NetXtreme BCM5704 Gigabit Ethernet cards and they are directly connected together via an Ethernet cable. The duration field in the table is the number of seconds the experiments were run for! The program that we used to run the tests simply runs all the iperf expermints one after the other by reading in the values to supply iperf from a config file, a snippet of which is shown below : { # # 1st run v4 # -c 10.30.200.20 -S 10.30.200.20 -l 64 -t 3600 -b 64M -o v4run1 -p /root/4vs6/ } This simply provides the arguments for iperf to run with! Thanks again for the replies, if anyone has any other suggestions I would be grateful to hear them! Thanks Matt From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 17:49:43 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 519F916A41F; Thu, 22 Sep 2005 17:49:43 +0000 (GMT) (envelope-from flag@oltrelinux.com) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF04A43D45; Thu, 22 Sep 2005 17:49:39 +0000 (GMT) (envelope-from flag@oltrelinux.com) Received: from southcross.homeunix.org (ip-90-199.sn1.eutelia.it [62.94.90.199]) by mail.oltrelinux.com (Postfix) with ESMTP id 0CF0511AE44; Thu, 22 Sep 2005 19:49:39 +0200 (CEST) Received: by southcross.homeunix.org (Postfix, from userid 1001) id 8F14F40C8; Thu, 22 Sep 2005 19:52:07 +0200 (CEST) Date: Thu, 22 Sep 2005 19:52:07 +0200 From: Paolo Pisati To: nielsen@memberwebs.com Message-ID: <20050922175207.GA1194@tin.it> References: <4331C65C.5030308@yan.com.br> <20050922084116.132E970DCD6@mail.npubs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050922084116.132E970DCD6@mail.npubs.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: freebsd-hackers@freebsd.org, ddg@yan.com.br, freebsd-net@freebsd.org Subject: Re: IPFW NATD = NAT POOL 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, 22 Sep 2005 17:49:43 -0000 On Thu, Sep 22, 2005 at 08:41:16AM +0000, Nate Nielsen wrote: > No. I think each instance of natd (at least last time I looked at it) > could only use one IP address as it's public address. FYI you can use nat inside ipfw[*]: ipfw nat 1 config ip 192.168.0.123 ipfw nat 2 config ip 192.168.0.456 ... ipfw add 100 nat 1 all from any to any via [if0] ipfw add 200 nat 2 all from any to any via [if1] ... so someone will finally test it... :) [*] http://wikitest.freebsd.org/moin.cgi/PaoloPisati -- Paolo From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 19:31:03 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 889AA16A41F; Thu, 22 Sep 2005 19:31:03 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: from smtp.freemail.gr (smtp.freemail.gr [213.239.180.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BEE243D45; Thu, 22 Sep 2005 19:31:03 +0000 (GMT) (envelope-from dionch@freemail.gr) Received: by smtp.freemail.gr (Postfix, from userid 101) id 8480BBC21F; Thu, 22 Sep 2005 22:30:59 +0300 (EEST) Received: from [10.0.0.1] (vdp1074.ath03.dsl.hol.gr [62.38.168.75])by smtp.freemail.gr (Postfix) with ESMTP id 9CD17BC021; Thu, 22 Sep 2005 22:30:58 +0300 (EEST) Message-ID: <4333064C.6080804@freemail.gr> Date: Thu, 22 Sep 2005 22:30:20 +0300 From: Chris Dionissopoulos User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paolo Pisati References: <4331C65C.5030308@yan.com.br> <20050922084116.132E970DCD6@mail.npubs.com> <20050922175207.GA1194@tin.it> In-Reply-To: <20050922175207.GA1194@tin.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Subject: Re: IPFW NATD = NAT POOL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dionch@freemail.gr List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2005 19:31:03 -0000 Nice work! Is possible to implement a "port address forwarding" (aka PAT) using some ipfw rules? (or with any other way) Something similar to "-redirect_port" option of natd(8). TIA, Chris. Paolo Pisati wrote: >On Thu, Sep 22, 2005 at 08:41:16AM +0000, Nate Nielsen wrote: > > >>No. I think each instance of natd (at least last time I looked at it) >>could only use one IP address as it's public address. >> >> > >FYI you can use nat inside ipfw[*]: > >ipfw nat 1 config ip 192.168.0.123 >ipfw nat 2 config ip 192.168.0.456 >... >ipfw add 100 nat 1 all from any to any via [if0] >ipfw add 200 nat 2 all from any to any via [if1] >... > >so someone will finally test it... :) > >[*] http://wikitest.freebsd.org/moin.cgi/PaoloPisati > > ____________________________________________________________________ http://www.freemail.gr - δωρεάν υπηρεσία ηλεκτρονικού ταχυδρομείου. http://www.freemail.gr - free email service for the Greek-speaking. From owner-freebsd-net@FreeBSD.ORG Thu Sep 22 23:40:26 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A884E16A41F for ; Thu, 22 Sep 2005 23:40:26 +0000 (GMT) (envelope-from fbsd-net@mawer.org) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 230CF43D45 for ; Thu, 22 Sep 2005 23:40:25 +0000 (GMT) (envelope-from fbsd-net@mawer.org) Received: from [127.0.0.1] (c220-237-120-88.thorn1.nsw.optusnet.com.au [220.237.120.88]) by mail04.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j8MNeGEs016857; Fri, 23 Sep 2005 09:40:21 +1000 Message-ID: <433340EA.7080202@mawer.org> Date: Fri, 23 Sep 2005 09:40:26 +1000 From: Antony Mawer User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: freebsd-net@FreeBSD.ORG References: <200509221040.j8MAep8Q063279@lurza.secnetix.de> In-Reply-To: <200509221040.j8MAep8Q063279@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: olli@lurza.secnetix.de Subject: Re: VIA VT6103 support (VIA EPIA PD) 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, 22 Sep 2005 23:40:26 -0000 On 22/09/2005 8:40 PM, Oliver Fromme wrote: > Therefore I'd like to ask: Does the VIA VT6103 work with- > out problems under FreeBSD (RELENG_5 or RELENG_6, or maybe > even RELENG_4)? > > Better yet: Does someone use an EPIA PD* board with both > on-board interfaces under FreeBSD without problems? I'm using one of the PD10000 EPIA machines as a mail server/router/firewall/etc at home and it performs quite nicely at the job. I haven't noticed any problems with the network on it...: > # netstat -I vr0 > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > vr0 1500 00:40:63:df:4d:59 38411131 0 7849020 0 0 > vr0 1500 fe80:1::240:6 fe80:1::240:63ff: 0 - 4 - - > vr0 1500 220.237.120 c220-237-120-88.t 6020433 - 3433159 - - > # netstat -I vr1 > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > vr1 1500 00:40:63:df:4d:09 17437095 0 16348674 0 0 > vr1 1500 10.4/16 scooby 20150 - 10852607 - - > vr1 1500 fe80:2::240:6 fe80:2::240:63ff: 0 - 4 - - and > # dmesg | grep -E 'vr0|vr1' > vr0: port 0xd000-0xd0ff mem 0xe6400000-0xe64000ff irq 10 at device 15.0 on pci0 > miibus0: on vr0 > vr0: Ethernet address: 00:40:63:df:4d:59 > vr1: port 0xe400-0xe4ff mem 0xe6402000-0xe64020ff irq 11 at device 18.0 on pci0 > miibus1: on vr1 > vr1: Ethernet address: 00:40:63:df:4d:09 It's currently running 6.0-BETA2 (although I'll be bringing it up-to-date with the latest RELENG_6 shortly; buildworld on the machine does take a while so I'll probably NFS mount it off another faster machine!) Cheers Antony From owner-freebsd-net@FreeBSD.ORG Fri Sep 23 02:02:04 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FD7F16A41F for ; Fri, 23 Sep 2005 02:02:04 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from S2.cableone.net (s2.cableone.net [24.116.0.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D0AF43D45 for ; Fri, 23 Sep 2005 02:02:01 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from vixen42.vulpes (unverified [24.119.122.41]) by S2.cableone.net (CableOne SMTP Service S2) with ESMTP id 30950071 for ; Thu, 22 Sep 2005 19:54:33 -0700 Date: Thu, 22 Sep 2005 20:55:05 -0500 From: Vulpes Velox To: freebsd-net@freebsd.org Message-ID: <20050922205505.0bbd2ff4@vixen42.vulpes> X-Mailer: Sylpheed-Claws 1.9.14 (GTK+ 2.6.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IP-stats: Incoming Last 0, First 126, in=185, out=0, spam=0 X-External-IP: 24.119.122.41 X-Abuse-Info: Send abuse complaints to abuse@cableone.net Subject: wierd problems with openvpn 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, 23 Sep 2005 02:02:04 -0000 Just been messing around with openvpn and trying to get it up and running using http://openvpn.net/static.html as a guide. It works, but I run into a weird problem with data moving across the vpn. I can send a ping across from the client to the server, but the server never sends any thing back. I used tcpdump to make sure the server is seeing it and it is. I see it going there on both machines, but I never see a reply. I am running pf on the server... but it should not be doing any thing... server pf.conf... ext_if="fxp1" int_if="fxp0" internal_net="192.168.0.0/8" dcc = "{ 6115:6130 }" bittorrent = "{ 6881:6889 }" nat on $ext_if from $internal_net to any -> ($ext_if) rdr on $ext_if proto tcp from any to any port $dcc -> 192.168.0.2 rdr on $ext_if proto tcp from any to any port $bittorrent -> 192.168.0.2 rdr on $ext_if proto udp from any to any port 27960 -> 192.168.0.2 pass in all pass out all server config... dev tun secret vulpes-static.key ifconfig 10.8.0.1 10.8.0.2 comp-lzo host config... dev tun secret vulpes-static.key ifconfig 10.8.0.2 10.8.0.1 remote inari comp-lzo From owner-freebsd-net@FreeBSD.ORG Fri Sep 23 03:59:02 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38ACE16A41F for ; Fri, 23 Sep 2005 03:59:02 +0000 (GMT) (envelope-from vvelox@vvelox.net) Received: from S2.cableone.net (s2.cableone.net [24.116.0.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0DDA43D45 for ; Fri, 23 Sep 2005 03:59:01 +0000 (GMT) (envelope-from vvelox@vvelox.net) Received: from vixen42.vulpes (unverified [24.119.122.41]) by S2.cableone.net (CableOne SMTP Service S2) with ESMTP id 30959180 for ; Thu, 22 Sep 2005 22:07:43 -0700 Date: Thu, 22 Sep 2005 23:08:21 -0500 From: "Z.C.B." To: freebsd-net@freebsd.org Message-ID: <20050922230821.65570d8c@vixen42.vulpes> In-Reply-To: <20050922205505.0bbd2ff4@vixen42.vulpes> References: <20050922205505.0bbd2ff4@vixen42.vulpes> X-Mailer: Sylpheed-Claws 1.9.14 (GTK+ 2.6.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IP-stats: Incoming Last 0, First 127, in=187, out=0, spam=0 X-External-IP: 24.119.122.41 X-Abuse-Info: Send abuse complaints to abuse@cableone.net Subject: Re: wierd problems with openvpn [update] 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, 23 Sep 2005 03:59:02 -0000 I am positive it is something to do with pf. I copied the exact same config file from the vpn server over to another box and pointed the client at it and it worked perfectly fine. Any one see any thing odd in that pf setup or have any suggestions or the like? On Thu, 22 Sep 2005 20:55:05 -0500 Vulpes Velox wrote: > Just been messing around with openvpn and trying to get it up and > running using http://openvpn.net/static.html as a guide. It works, > but I run into a weird problem with data moving across the vpn. I > can send a ping across from the client to the server, but the server > never sends any thing back. I used tcpdump to make sure the server > is seeing it and it is. I see it going there on both machines, but I > never see a reply. > > I am running pf on the server... but it should not be doing any > thing... > > > server pf.conf... > ext_if="fxp1" > int_if="fxp0" > internal_net="192.168.0.0/8" > dcc = "{ 6115:6130 }" > bittorrent = "{ 6881:6889 }" > nat on $ext_if from $internal_net to any -> ($ext_if) > rdr on $ext_if proto tcp from any to any port $dcc -> 192.168.0.2 > rdr on $ext_if proto tcp from any to any port $bittorrent -> > 192.168.0.2 rdr on $ext_if proto udp from any to any port 27960 -> > 192.168.0.2 pass in all > pass out all > > > > server config... > dev tun > secret vulpes-static.key > ifconfig 10.8.0.1 10.8.0.2 > comp-lzo > > > > host config... > dev tun > secret vulpes-static.key > ifconfig 10.8.0.2 10.8.0.1 > remote inari > comp-lzo > _______________________________________________ > 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 Sep 23 04:08:17 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E23516A41F for ; Fri, 23 Sep 2005 04:08:17 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: from seddon.ca (seddon.ca [203.209.212.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 8CBC043D53 for ; Fri, 23 Sep 2005 04:08:16 +0000 (GMT) (envelope-from dave-sender-1932b5@seddon.ca) Received: (qmail 82178 invoked by uid 89); 23 Sep 2005 04:08:14 -0000 Received: by seddon.ca (tmda-sendmail, from uid 89); Fri, 23 Sep 2005 14:08:13 +1000 (EST) References: <20050922205505.0bbd2ff4@vixen42.vulpes> <20050922230821.65570d8c@vixen42.vulpes> In-Reply-To: <20050922230821.65570d8c@vixen42.vulpes> To: "Z.C.B." Date: Fri, 23 Sep 2005 14:08:11 +1000 Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <1127448493.82079.TMDA@seddon.ca> X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Dave+Seddon Cc: freebsd-net@freebsd.org Subject: Re: wierd problems with openvpn [update] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: das-keyword-net.6770cb@seddon.ca List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2005 04:08:17 -0000 So ditch pf and let us know. Or swap to ipf Z.C.B. writes: > I am positive it is something to do with pf. I copied the exact same > config file from the vpn server over to another box and pointed the > client at it and it worked perfectly fine. Any one see any thing odd > in that pf setup or have any suggestions or the like? > > On Thu, 22 Sep 2005 20:55:05 -0500 > Vulpes Velox wrote: > >> Just been messing around with openvpn and trying to get it up and >> running using http://openvpn.net/static.html as a guide. It works, >> but I run into a weird problem with data moving across the vpn. I >> can send a ping across from the client to the server, but the server >> never sends any thing back. I used tcpdump to make sure the server >> is seeing it and it is. I see it going there on both machines, but I >> never see a reply. >> >> I am running pf on the server... but it should not be doing any >> thing... >> >> >> server pf.conf... >> ext_if="fxp1" >> int_if="fxp0" >> internal_net="192.168.0.0/8" >> dcc = "{ 6115:6130 }" >> bittorrent = "{ 6881:6889 }" >> nat on $ext_if from $internal_net to any -> ($ext_if) >> rdr on $ext_if proto tcp from any to any port $dcc -> 192.168.0.2 >> rdr on $ext_if proto tcp from any to any port $bittorrent -> >> 192.168.0.2 rdr on $ext_if proto udp from any to any port 27960 -> >> 192.168.0.2 pass in all >> pass out all >> >> >> >> server config... >> dev tun >> secret vulpes-static.key >> ifconfig 10.8.0.1 10.8.0.2 >> comp-lzo >> >> >> >> host config... >> dev tun >> secret vulpes-static.key >> ifconfig 10.8.0.2 10.8.0.1 >> remote inari >> comp-lzo >> _______________________________________________ >> 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" From owner-freebsd-net@FreeBSD.ORG Fri Sep 23 10:24:17 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B70A516A41F for ; Fri, 23 Sep 2005 10:24:17 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1873443D46 for ; Fri, 23 Sep 2005 10:24:16 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (qdovsj@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j8NAOElx008038 for ; Fri, 23 Sep 2005 12:24:15 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j8NAOEK0008037; Fri, 23 Sep 2005 12:24:14 +0200 (CEST) (envelope-from olli) Date: Fri, 23 Sep 2005 12:24:14 +0200 (CEST) Message-Id: <200509231024.j8NAOEK0008037@lurza.secnetix.de> From: Oliver Fromme To: freebsd-net@FreeBSD.ORG In-Reply-To: <433340EA.7080202@mawer.org> X-Newsgroups: list.freebsd-net User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: VIA VT6103 support (VIA EPIA PD) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@FreeBSD.ORG List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2005 10:24:17 -0000 Antony Mawer wrote: > On 22/09/2005 8:40 PM, Oliver Fromme wrote: > > Therefore I'd like to ask: Does the VIA VT6103 work with- > > out problems under FreeBSD (RELENG_5 or RELENG_6, or maybe > > even RELENG_4)? > > > > Better yet: Does someone use an EPIA PD* board with both > > on-board interfaces under FreeBSD without problems? > > I'm using one of the PD10000 EPIA machines as a mail > server/router/firewall/etc at home and it performs quite nicely at the > job. I haven't noticed any problems with the network on it...: Cool, thanks! I just ordered mine. :-) So I can assume that the problems mentioned in the PR and mailing lists have been solved. > It's currently running 6.0-BETA2 (although I'll be bringing it > up-to-date with the latest RELENG_6 shortly; buildworld on the machine > does take a while so I'll probably NFS mount it off another faster machine!) How long does a buildworld take? Best regards Oliver PS: An related question (although off-topic here): I assume a Mini-ITX board fits into a standard ATX Midi- tower without problems, right? -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "I have stopped reading Stephen King novels. Now I just read C code instead." -- Richard A. O'Keefe From owner-freebsd-net@FreeBSD.ORG Fri Sep 23 10:27:45 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0194116A41F for ; Fri, 23 Sep 2005 10:27:45 +0000 (GMT) (envelope-from lourik@wtec.co.za) Received: from meerkat.wtec.co.za (meerkat.wtec.co.za [69.67.33.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30A1443D46 for ; Fri, 23 Sep 2005 10:27:33 +0000 (GMT) (envelope-from lourik@wtec.co.za) Received: from lourik.wtec.co.za ([192.168.2.200]) (AUTH: PLAIN lourik@wtec.co.za) by meerkat.wtec.co.za with esmtp; Fri, 23 Sep 2005 12:30:36 +0200 From: Lourik Malan Organization: Woodlands Technologies Pty(LTD) To: freebsd-net@freebsd.org Date: Fri, 23 Sep 2005 10:27:09 +0000 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509231027.09686.lourik@wtec.co.za> Subject: ipnat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lourik@wtec.co.za List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2005 10:27:45 -0000 Hi There I need some help. I've always used Freebsd 4.x as my main firewall, now i've upgrade to 5.4 with the same config files. I can ping the net from the BSD-server, but not from the lan. All my config files is below Please help. Thanks # This is my config rc.conf ifconfig_xl1_alias0=" inet 196.23.176.188 netmask 255.255.255.255" ifconfig_xl1_alias1=" inet 196.23.176.189 netmask 255.255.255.255" ifconfig_xl1_alias2=" inet 196.23.176.190 netmask 255.255.255.255" ifconfig_xl1_alias3=" inet 196.23.176.186 netmask 255.255.255.255" ifconfig_xl1_alias4=" inet 196.23.176.185 netmask 255.255.255.255" ifconfig_xl1_alias5=" inet 196.23.176.184 netmask 255.255.255.255" ifconfig_xl1_alias6=" inet 196.23.176.183 netmask 255.255.255.255" ifconfig_xl1=" inet 196.23.176.187 netmask 255.255.255.240" ifconfig_xl0=" inet 172.20.154.2 netmask 255.255.255.0" # This is my ipnat.rules bimap xl1 172.20.154.199/32 -> 196.23.176.188/32 bimap xl1 172.20.154.198/32 -> 196.23.176.189/32 bimap xl1 172.20.154.197/32 -> 196.23.176.190/32 bimap xl1 172.20.154.3/32 -> 196.23.176.186/32 map xl1 172.20.154.0/24 -> 196.23.176.187/32 RC.conf firewall_enable="YES" firewall_script="/etc/rc.firewall" firewall_type="OPEN" firewall_quiet="NO" firewall_logging="YES" firewall_flags="" ipfilter_enable="YES" ipfilter_program="/sbin/ipf" ipfilter_rules="/etc/ipf.rules" ipfilter_flags="" ipnat_enable="YES" ipnat_program="/sbin/ipnat" ipnat_rules="/etc/ipnat.rules" ipnat_flags="" ipmon_enable="YES" ipmon_program="/sbin/ipmon" ipmon_flags="-Ds" In my kernel options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT options DUMMYNET options HZ=1000 ipf.rules pass in all pass out all From owner-freebsd-net@FreeBSD.ORG Fri Sep 23 10:31:37 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7688C16A41F for ; Fri, 23 Sep 2005 10:31:37 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04ADF43D45 for ; Fri, 23 Sep 2005 10:31:36 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 0BAAC9977C4 for ; Fri, 23 Sep 2005 12:31:36 +0200 (CEST) Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 68618-02 for ; Fri, 23 Sep 2005 12:31:32 +0200 (CEST) Received: from [80.98.133.57] (catv-50628539.catv.broadband.hu [80.98.133.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.t-hosting.hu (Postfix) with ESMTP id 8598F99741E for ; Fri, 23 Sep 2005 12:31:32 +0200 (CEST) Message-ID: <4333D980.9000206@t-hosting.hu> Date: Fri, 23 Sep 2005 12:31:28 +0200 From: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at t-hosting.hu Subject: Portforwarding how? 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, 23 Sep 2005 10:31:37 -0000 Hello, sorry for the silly question, but I don't know where to look for. How can I set up a simple portforwarding? The machine is the same, the network interface and the IP address is the same, I just want to forward a privileged port to an unprivileged one so that the daemon don't have to run as root. I know there's mac_portacl, but I have some troubles with that, and I would avoid using that. An IPF or an IPFW-based solution would be nice. Cheers, Gabor Kovesdan From owner-freebsd-net@FreeBSD.ORG Fri Sep 23 10:54:19 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26D8416A41F for ; Fri, 23 Sep 2005 10:54:19 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB1E243D46 for ; Fri, 23 Sep 2005 10:54:18 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=lapdance.yazzy.net) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1EIlBc-0005yh-VA; Fri, 23 Sep 2005 12:53:49 +0200 Date: Fri, 23 Sep 2005 10:53:50 +0000 From: Marcin Jessa To: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= Message-Id: <20050923105350.6f042c37.lists@yazzy.org> In-Reply-To: <4333D980.9000206@t-hosting.hu> References: <4333D980.9000206@t-hosting.hu> Organization: YazzY.org X-Mailer: Sylpheed version 2.0.1 (GTK+ 2.6.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.5 (--) Cc: freebsd-net@freebsd.org Subject: Re: Portforwarding how? 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, 23 Sep 2005 10:54:19 -0000 On Fri, 23 Sep 2005 12:31:28 +0200 K=F6vesd=E1n G=E1bor wrote: > Hello, >=20 > sorry for the silly question, but I don't know where to look for.=20 This question if suitable for questions@ and not net@ >How=20 > can I set up a simple portforwarding? The machine is the same, the=20 > network interface and the IP address is the same, I just want to > forward a privileged port to an unprivileged one so that the daemon > don't have to run as root. I know there's mac_portacl, but I have > some troubles with that, and I would avoid using that. An IPF or an > IPFW-based solution would be nice. man ipfw man(4) divert. =20 From owner-freebsd-net@FreeBSD.ORG Fri Sep 23 13:59:20 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D57A716A41F for ; Fri, 23 Sep 2005 13:59:20 +0000 (GMT) (envelope-from lourik@wtec.co.za) Received: from meerkat.wtec.co.za (meerkat.wtec.co.za [69.67.33.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7959143D4C for ; Fri, 23 Sep 2005 13:59:14 +0000 (GMT) (envelope-from lourik@wtec.co.za) Received: from lourik.wtec.co.za ([192.168.2.200]) (AUTH: PLAIN lourik@wtec.co.za) by meerkat.wtec.co.za with esmtp; Fri, 23 Sep 2005 16:02:30 +0200 From: Lourik Malan Organization: Woodlands Technologies Pty(LTD) To: freebsd-net@freebsd.org Date: Fri, 23 Sep 2005 13:59:00 +0000 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200509231359.01354.lourik@wtec.co.za> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Fwd: ipnat X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lourik@wtec.co.za List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2005 13:59:21 -0000 Hi There I need some help. I've always used Freebsd 4.x as my main firewall, now i've upgrade to 5.4 with the same config files. I can ping the net from the BSD-server, but not from the lan. All my config files is below I get the following when from a firewall that i'm pinging meerkat /kernel: ipfw: 2 Accept ICMP:8.0 172.20.154.77 69.67.33.50 in via rl1 meerkat /kernel: ipfw: 2 Accept ICMP:0.0 69.67.33.50 172.20.154.77 out via rl1 Please help. Thanks # This is my config rc.conf ifconfig_xl1_alias0=" inet 196.23.176.188 netmask 255.255.255.255" ifconfig_xl1_alias1=" inet 196.23.176.189 netmask 255.255.255.255" ifconfig_xl1_alias2=" inet 196.23.176.190 netmask 255.255.255.255" ifconfig_xl1_alias3=" inet 196.23.176.186 netmask 255.255.255.255" ifconfig_xl1_alias4=" inet 196.23.176.185 netmask 255.255.255.255" ifconfig_xl1_alias5=" inet 196.23.176.184 netmask 255.255.255.255" ifconfig_xl1_alias6=" inet 196.23.176.183 netmask 255.255.255.255" ifconfig_xl1=" inet 196.23.176.187 netmask 255.255.255.240" ifconfig_xl0=" inet 172.20.154.2 netmask 255.255.255.0" # This is my ipnat.rules bimap xl1 172.20.154.199/32 -> 196.23.176.188/32 bimap xl1 172.20.154.198/32 -> 196.23.176.189/32 bimap xl1 172.20.154.197/32 -> 196.23.176.190/32 bimap xl1 172.20.154.3/32 -> 196.23.176.186/32 map xl1 172.20.154.0/24 -> 196.23.176.187/32 RC.conf firewall_enable="YES" firewall_script="/etc/rc.firewall" firewall_type="OPEN" firewall_quiet="NO" firewall_logging="YES" firewall_flags="" ipfilter_enable="YES" ipfilter_program="/sbin/ipf" ipfilter_rules="/etc/ipf.rules" ipfilter_flags="" ipnat_enable="YES" ipnat_program="/sbin/ipnat" ipnat_rules="/etc/ipnat.rules" ipnat_flags="" ipmon_enable="YES" ipmon_program="/sbin/ipmon" ipmon_flags="-Ds" In my kernel options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT options DUMMYNET options HZ=1000 ipf.rules pass in all pass out all ------------------------------------------------------- -- Lourik Malan Woodlands Technologies Pty(LTD) 082 570 3191 From owner-freebsd-net@FreeBSD.ORG Fri Sep 23 17:08:03 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 508C016A41F for ; Fri, 23 Sep 2005 17:08:03 +0000 (GMT) (envelope-from vvelox@vvelox.net) Received: from S4.cableone.net (s4.cableone.net [24.116.0.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4EFB43D48 for ; Fri, 23 Sep 2005 17:08:02 +0000 (GMT) (envelope-from vvelox@vvelox.net) Received: from vixen42.vulpes (unverified [24.119.122.41]) by S4.cableone.net (CableOne SMTP Service S4) with ESMTP id 31710559 for multiple; Fri, 23 Sep 2005 10:19:24 -0700 Date: Fri, 23 Sep 2005 12:17:15 -0500 From: "Z.C.B." To: Dave+Seddon Message-ID: <20050923121715.4061f6b2@vixen42.vulpes> In-Reply-To: <1127448493.82079.TMDA@seddon.ca> References: <20050922205505.0bbd2ff4@vixen42.vulpes> <20050922230821.65570d8c@vixen42.vulpes> <1127448493.82079.TMDA@seddon.ca> X-Mailer: Sylpheed-Claws 1.9.14 (GTK+ 2.6.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IP-stats: Incoming Last 1, First 126, in=222, out=0, spam=0 X-External-IP: 24.119.122.41 X-Abuse-Info: Send abuse complaints to abuse@cableone.net Cc: freebsd-net@freebsd.org Subject: Re: wierd problems with openvpn [update] 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, 23 Sep 2005 17:08:03 -0000 It works perfectly fine with out pf. Not gotten around to debugging it yet. Threw it behind the router on a server and forwarded the port. On Fri, 23 Sep 2005 14:08:11 +1000 Dave+Seddon wrote: > So ditch pf and let us know. Or swap to ipf > > Z.C.B. writes: > > > I am positive it is something to do with pf. I copied the exact > > same config file from the vpn server over to another box and > > pointed the client at it and it worked perfectly fine. Any one > > see any thing odd in that pf setup or have any suggestions or the > > like? > > > > On Thu, 22 Sep 2005 20:55:05 -0500 > > Vulpes Velox wrote: > > > >> Just been messing around with openvpn and trying to get it up and > >> running using http://openvpn.net/static.html as a guide. It > >> works, but I run into a weird problem with data moving across > >> the vpn. I can send a ping across from the client to the server, > >> but the server never sends any thing back. I used tcpdump to > >> make sure the server is seeing it and it is. I see it going > >> there on both machines, but I never see a reply. > >> > >> I am running pf on the server... but it should not be doing any > >> thing... > >> > >> > >> server pf.conf... > >> ext_if="fxp1" > >> int_if="fxp0" > >> internal_net="192.168.0.0/8" > >> dcc = "{ 6115:6130 }" > >> bittorrent = "{ 6881:6889 }" > >> nat on $ext_if from $internal_net to any -> ($ext_if) > >> rdr on $ext_if proto tcp from any to any port $dcc -> 192.168.0.2 > >> rdr on $ext_if proto tcp from any to any port $bittorrent -> > >> 192.168.0.2 rdr on $ext_if proto udp from any to any port 27960 > >> -> 192.168.0.2 pass in all > >> pass out all > >> > >> > >> > >> server config... > >> dev tun > >> secret vulpes-static.key > >> ifconfig 10.8.0.1 10.8.0.2 > >> comp-lzo > >> > >> > >> > >> host config... > >> dev tun > >> secret vulpes-static.key > >> ifconfig 10.8.0.2 10.8.0.1 > >> remote inari > >> comp-lzo > >> _______________________________________________ > >> 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" > > From owner-freebsd-net@FreeBSD.ORG Fri Sep 23 17:51:38 2005 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BABFE16A42A for ; Fri, 23 Sep 2005 17:51:38 +0000 (GMT) (envelope-from cristjc@comcast.net) Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 683D243D45 for ; Fri, 23 Sep 2005 17:51:38 +0000 (GMT) (envelope-from cristjc@comcast.net) Received: from goku.cjclark.org (c-24-6-184-207.hsd1.ca.comcast.net[24.6.184.207]) by comcast.net (rwcrmhc14) with ESMTP id <2005092317513601400omme7e>; Fri, 23 Sep 2005 17:51:37 +0000 Received: from goku.cjclark.org (localhost. [127.0.0.1]) by goku.cjclark.org (8.13.3/8.12.8) with ESMTP id j8NHpTuM069441 for ; Fri, 23 Sep 2005 10:51:30 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by goku.cjclark.org (8.13.3/8.13.1/Submit) id j8NHpPPo069440 for net@freebsd.org; Fri, 23 Sep 2005 10:51:26 -0700 (PDT) (envelope-from cristjc@comcast.net) X-Authentication-Warning: goku.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Fri, 23 Sep 2005 10:51:25 -0700 From: "Crist J. Clark" To: net@freebsd.org Message-ID: <20050923175125.GA69254@goku.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-URL: http://people.freebsd.org/~cjc/ Cc: Subject: Fixed Dest Port for traceroute(8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2005 17:51:38 -0000 Gee. It would be nice if one could fix the outgoing port for UDP and TCP traceroutes. Sometimes firewalls, load balancers, and various other systems treat packets differently depending on the transport layer destination port. The current traceroute implementation allows one to specify a starting port, but increments the port with each packet sent out. It doesn't do this without reason. The value is essentially a sequence number that is used to identify out-of-order responses, but this screws up our ability to traceroute a specific port. Also, traceroute just needs more options. It's closing on ping(8). I have added a '-e' option. A firewall "evasion," fixed-port option. For TCP and UDP scans, the destination port is not changed. Doing this in TCP is pretty straightforward. The sequence number field was already being loaded with the source port (which in turn is the PID) and destination port. I stopped incrementing the destination port, but continiued to increment the dest port part of the sequence number. I added the sequence number to the out-of-order check. For UDP, that approach won't work. There isn't much space available in the header to store a counter, so I switched the conter to the source port rather than destination. I thought about abusing the UDP checksum. But that has the side effect that the destination will drop our last packet rather than return a port unreachable and has the potential to confuse NATing devices and other nastiness (although we somehow got away without TCP checksums at all for a long time). The counter is only switched when the fixed port option is given. Anyone mind if I see if my commit bit still works and merge this in? Index: traceroute.8 =================================================================== RCS file: /ncvs/freebsd/src/contrib/traceroute/traceroute.8,v retrieving revision 1.11 diff -u -r1.11 traceroute.8 --- traceroute.8 12 Apr 2005 15:16:32 -0000 1.11 +++ traceroute.8 23 Sep 2005 17:47:12 -0000 @@ -24,7 +24,7 @@ .na .B traceroute [ -.B \-dFISdnrvx +.B \-deFISdnrvx ] [ .B \-f .I first_ttl @@ -98,6 +98,11 @@ .PP Other options are: .TP +.B \-e +Firewall evasion mode. +Use fixed destination ports for UDP and TCP probes. +The destination port does NOT increment with each packet sent. +.TP .B \-f Set the initial time-to-live used in the first outgoing probe packet. .TP Index: traceroute.c =================================================================== RCS file: /ncvs/freebsd/src/contrib/traceroute/traceroute.c,v retrieving revision 1.27 diff -u -r1.27 traceroute.c --- traceroute.c 26 Aug 2005 18:08:24 -0000 1.27 +++ traceroute.c 23 Sep 2005 17:47:45 -0000 @@ -353,6 +353,7 @@ int doipcksum = 1; /* calculate ip checksums by default */ #endif int optlen; /* length of ip options */ +int fixedPort = 0; /* Use fixed destination port for TCP and UDP */ extern int optind; extern int opterr; @@ -521,13 +522,17 @@ prog = argv[0]; opterr = 0; - while ((op = getopt(argc, argv, "dFInrSvxf:g:i:M:m:P:p:q:s:t:w:z:")) != EOF) + while ((op = getopt(argc, argv, "edFInrSvxf:g:i:M:m:P:p:q:s:t:w:z:")) != EOF) switch (op) { case 'd': options |= SO_DEBUG; break; + case 'e': + fixedPort = 1; + break; + case 'f': case 'M': /* FreeBSD compat. */ first_ttl = str2val(optarg, "first ttl", 1, 255); @@ -1289,8 +1294,8 @@ { struct udphdr *const outudp = (struct udphdr *) outp; - outudp->uh_sport = htons(ident); - outudp->uh_dport = htons(port + outdata->seq); + outudp->uh_sport = htons(ident + (fixedPort ? outdata->seq : 0)); + outudp->uh_dport = htons(port + (fixedPort ? 0 : outdata->seq)); outudp->uh_ulen = htons((u_short)protlen); outudp->uh_sum = 0; if (doipcksum) { @@ -1306,8 +1311,8 @@ { struct udphdr *const udp = (struct udphdr *) data; - return (ntohs(udp->uh_sport) == ident - && ntohs(udp->uh_dport) == port + seq); + return (ntohs(udp->uh_sport) == ident + (fixedPort ? seq : 0) && + ntohs(udp->uh_dport) == port + (fixedPort ? 0 : seq)); } void @@ -1316,8 +1321,9 @@ struct tcphdr *const tcp = (struct tcphdr *) outp; tcp->th_sport = htons(ident); - tcp->th_dport = htons(port + outdata->seq); - tcp->th_seq = (tcp->th_sport << 16) | tcp->th_dport; + tcp->th_dport = htons(port + (fixedPort ? 0 : outdata->seq)); + tcp->th_seq = (tcp->th_sport << 16) | (tcp->th_dport + + (fixedPort ? outdata->seq : 0)); tcp->th_ack = 0; tcp->th_off = 5; tcp->th_flags = TH_SYN; @@ -1335,7 +1341,8 @@ struct tcphdr *const tcp = (struct tcphdr *) data; return (ntohs(tcp->th_sport) == ident - && ntohs(tcp->th_dport) == port + seq); + && ntohs(tcp->th_dport) == port + (fixedPort ? 0 : seq)) + && tcp->th_seq == (ident << 16) | (port + seq); } void -- Crist J. Clark | cjclark@alum.mit.edu From owner-freebsd-net@FreeBSD.ORG Fri Sep 23 21:30:16 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1286E16A440 for ; Fri, 23 Sep 2005 21:30:16 +0000 (GMT) (envelope-from quandary@dufton.com) Received: from chb63.neoplus.adsl.tpnet.pl (chb63.neoplus.adsl.tpnet.pl [83.30.255.63]) by mx1.FreeBSD.org (Postfix) with SMTP id B463343D49 for ; Fri, 23 Sep 2005 21:30:14 +0000 (GMT) (envelope-from quandary@dufton.com) Received: from 110.38.103.100 (EHLO Oman) by chb63.neoplus.adsl.tpnet.pl with SMTP; Fri, 23 Sep 2005 23:30:12 +0200 id 114201122442quadruples97597 for freebsd-net@freebsd.org; Fri, 23 Sep 2005 23:30:12 +0200 Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <6936962258.4544143892@chb63.neoplus.adsl.tpnet.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-net@freebsd.org From: Brian Date: Fri, 23 Sep 2005 23:30:11 +0200 X-Mailer: Apple Mail (2.728) Subject: Software distribution. 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, 23 Sep 2005 21:30:16 -0000 Need software? Click here. http://rcazfm.429msbsssnsum44zrm4hrm4m.restesibmb.com/?dgj Give me where to stand, and I will move the earth. Heaven's not beyond the clouds, it's just beyond the fear. The state has no business in the bedrooms of the nation. Pleasure and love are the pinions of great deeds. Whom did it benefit. (Cui Bono Fuerit) To freely bloom - that is my definition of success. From owner-freebsd-net@FreeBSD.ORG Sat Sep 24 15:06:01 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4ADC216A420 for ; Sat, 24 Sep 2005 15:06:01 +0000 (GMT) (envelope-from howells@kde.org) Received: from mail.devrandom.org.uk (host-84-9-223-82.bulldogdsl.com [84.9.223.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62B9A43D49 for ; Sat, 24 Sep 2005 15:05:58 +0000 (GMT) (envelope-from howells@kde.org) Received: from localhost (localhost [127.0.0.1]) by mail.devrandom.org.uk (Postfix) with ESMTP id 3292AFD023 for ; Sat, 24 Sep 2005 16:05:57 +0100 (BST) Received: from mail.devrandom.org.uk ([127.0.0.1]) by localhost (mail.devrandom.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70298-07 for ; Sat, 24 Sep 2005 16:05:52 +0100 (BST) Received: from [192.168.1.167] (unknown [192.168.1.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.devrandom.org.uk (Postfix) with ESMTP id B63AAFD021 for ; Sat, 24 Sep 2005 16:05:52 +0100 (BST) From: Chris Howells Organization: K Desktop Environment To: freebsd-net@freebsd.org Date: Sat, 24 Sep 2005 16:05:17 +0100 User-Agent: KMail/1.8.50 References: <200509221040.j8MAep8Q063279@lurza.secnetix.de> In-Reply-To: <200509221040.j8MAep8Q063279@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3048185.QlU0SCL8SJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509241605.26998.howells@kde.org> X-Virus-Scanned: amavisd-new at devrandom.org.uk Subject: Re: VIA VT6103 support (VIA EPIA PD) 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, 24 Sep 2005 15:06:01 -0000 --nextPart3048185.QlU0SCL8SJ Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 22 September 2005 11:40, Oliver Fromme wrote: > I know that both are supposed to be supported by FreeBSD. > However, searching the lists and PR database reveals that > a few people had problems with the VT6103 (and VT6102, it > seems), causing the interface to hang randomly when there > is a lot of traffic. I couldn't find any definite infor- > mation about whether those problems have been solved or > not. There is a BIOS bug on various Via boards that causes a lockup when large=20 amounts of DMA transfers happen, either via the ethernet interfaces or via= =20 IDE. It look a very long time for Via to admit that it happens and to start=20 attempting to issue a fix. The fix is a BIOS which is clearly marked as Beta. Personally I'd steer clear of such Via boards. =2D-=20 Cheers, Chris Howells -- chris@chrishowells.co.uk, howells@kde.org Web: http://www.chrishowells.co.uk, PGP ID: 0x33795A2C KDE/Qt/C++/PHP Developer: http://www.kde.org --nextPart3048185.QlU0SCL8SJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBDNWs2F8Iu1zN5WiwRAopdAKCKMMFNpQ26HVlyJhmkpF81rsu9IACfSa4u RKQmEdi32F1NO1KFcwufCw8= =xATo -----END PGP SIGNATURE----- --nextPart3048185.QlU0SCL8SJ-- From owner-freebsd-net@FreeBSD.ORG Sat Sep 24 15:58:39 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.ORG Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6E7216A41F for ; Sat, 24 Sep 2005 15:58:39 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1460043D53 for ; Sat, 24 Sep 2005 15:58:38 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (dsdybk@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j8OFwbep066355 for ; Sat, 24 Sep 2005 17:58:38 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j8OFwbRI066354; Sat, 24 Sep 2005 17:58:37 +0200 (CEST) (envelope-from olli) Date: Sat, 24 Sep 2005 17:58:37 +0200 (CEST) Message-Id: <200509241558.j8OFwbRI066354@lurza.secnetix.de> From: Oliver Fromme To: freebsd-net@FreeBSD.ORG In-Reply-To: <200509241605.26998.howells@kde.org> X-Newsgroups: list.freebsd-net User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: VIA VT6103 support (VIA EPIA PD) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-net@FreeBSD.ORG List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2005 15:58:39 -0000 Chris Howells wrote: > There is a BIOS bug on various Via boards that causes a lockup when large > amounts of DMA transfers happen, either via the ethernet interfaces or via > IDE. That sounds strange. Do you have a URL where I can get more information about that problem? > It look a very long time for Via to admit that it happens and to start > attempting to issue a fix. > > The fix is a BIOS which is clearly marked as Beta. > > Personally I'd steer clear of such Via boards. But how do I know which VIA boards are affected? Does the VIA EPIA PD have that problem? I cannot find any information about a "VIA BIOS bug". Are you sure you're not confusing things? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998 From owner-freebsd-net@FreeBSD.ORG Sat Sep 24 18:56:46 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0B3016A41F for ; Sat, 24 Sep 2005 18:56:46 +0000 (GMT) (envelope-from msommer@argotsoft.com) Received: from mx1a.swcp.com (mx1a.swcp.com [216.184.2.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6131543D4C for ; Sat, 24 Sep 2005 18:56:46 +0000 (GMT) (envelope-from msommer@argotsoft.com) Received: from taka.swcp.com (taka-216.swcp.com [216.184.2.3]) by mx1a.swcp.com (8.13.3/8.13.3/Debian-6) with ESMTP id j8OIujIP027906 for ; Sat, 24 Sep 2005 12:56:45 -0600 Received: from argotsoft.com (argotsoft.com [198.59.115.127]) by taka.swcp.com (8.13.3/8.13.1) with ESMTP id j8OIuReR031091 for ; Sat, 24 Sep 2005 12:56:30 -0600 (MDT) (envelope-from msommer@argotsoft.com) Received: from ATHABASCA (athabasca.argotsoft.com [192.168.3.104]) by argotsoft.com (8.12.3/8.12.3) with ESMTP id j8OIrmoD023917 for ; Sat, 24 Sep 2005 12:53:52 -0600 (MDT) Message-Id: <200509241853.j8OIrmoD023917@argotsoft.com> From: "Mark J. Sommer" To: Date: Sat, 24 Sep 2005 12:53:42 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_1127588033-23671-42" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200509241558.j8OFwbRI066354@lurza.secnetix.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXBJ0cPByCbVaXESTyVDcsoWpd2kgAELwJg X-Scanned-By: MIMEDefang 2.9 (www dot roaringpenguin dot com slash mimedefang) X-Virus-Scanned: ClamAV 0.87/1099/Fri Sep 23 14:29:28 2005 on av1 X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on kaimen.swcp.com X-Spam-Status: No, hits=-2.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Level: Subject: RE: VIA VT6103 support (VIA EPIA PD) 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, 24 Sep 2005 18:56:46 -0000 This is a multi-part message in MIME format... ------------=_1127588033-23671-42 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes, please post a URL or an e-mail address of someone at VIA that can provide more information. I'm looking to implement some thin clients based on these motherboards, so any info you can provide would be very much appreciated. Thanks -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Oliver Fromme Sent: 09/24/2005 9:59 AM To: freebsd-net@freebsd.org Subject: Re: VIA VT6103 support (VIA EPIA PD) Chris Howells wrote: > There is a BIOS bug on various Via boards that causes a lockup when large > amounts of DMA transfers happen, either via the ethernet interfaces or via > IDE. That sounds strange. Do you have a URL where I can get more information about that problem? > It look a very long time for Via to admit that it happens and to start > attempting to issue a fix. > > The fix is a BIOS which is clearly marked as Beta. > > Personally I'd steer clear of such Via boards. But how do I know which VIA boards are affected? Does the VIA EPIA PD have that problem? I cannot find any information about a "VIA BIOS bug". Are you sure you're not confusing things? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998 _______________________________________________ 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" SPAM: (no report template found) ------------=_1127588033-23671-42-- From owner-freebsd-net@FreeBSD.ORG Sat Sep 24 19:20:36 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AFFD16A41F for ; Sat, 24 Sep 2005 19:20:36 +0000 (GMT) (envelope-from msommer@argotsoft.com) Received: from mx1a.swcp.com (mx1a.swcp.com [216.184.2.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C6C243D48 for ; Sat, 24 Sep 2005 19:20:36 +0000 (GMT) (envelope-from msommer@argotsoft.com) Received: from taka.swcp.com (taka-216.swcp.com [216.184.2.3]) by mx1a.swcp.com (8.13.3/8.13.3/Debian-6) with ESMTP id j8OJKZii001927 for ; Sat, 24 Sep 2005 13:20:35 -0600 Received: from argotsoft.com (argotsoft.com [198.59.115.127]) by taka.swcp.com (8.13.3/8.13.1) with ESMTP id j8OJKOi9050527 for ; Sat, 24 Sep 2005 13:20:30 -0600 (MDT) (envelope-from msommer@argotsoft.com) Received: from ATHABASCA (athabasca.argotsoft.com [192.168.3.104]) by argotsoft.com (8.12.3/8.12.3) with ESMTP id j8OJJfoD024059 for ; Sat, 24 Sep 2005 13:19:45 -0600 (MDT) Message-Id: <200509241919.j8OJJfoD024059@argotsoft.com> From: "Mark J. Sommer" To: Date: Sat, 24 Sep 2005 13:19:27 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200509241853.j8OIrmoD023917@argotsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXBJ0cPByCbVaXESTyVDcsoWpd2kgAELwJgAAEd2uA= X-Scanned-By: MIMEDefang 2.9 (www dot roaringpenguin dot com slash mimedefang) X-Virus-Scanned: ClamAV 0.87/1099/Fri Sep 23 14:29:28 2005 on av1 X-Virus-Status: Clean X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on kaimen.swcp.com X-Spam-Status: No, hits=-2.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4 X-Spam-Level: Subject: RE: VIA VT6103 support (VIA EPIA PD) 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, 24 Sep 2005 19:20:36 -0000 Friend found a post regarding this. Says there is an update to the BIOS too. Please check out: http://forums.viaarena.com/messageview.aspx?catid=28&threadid=60131 And http://forums.viaarena.com/messageview.aspx?catid=28&threadid=67386&enterthr ead=y If anyone has this working properly with FreeBSD, I'd appreciate knowing. I hear the Ethernet on these are not great performers. -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Mark J. Sommer Sent: 09/24/2005 12:54 PM To: freebsd-net@freebsd.org Subject: RE: VIA VT6103 support (VIA EPIA PD) Yes, please post a URL or an e-mail address of someone at VIA that can provide more information. I'm looking to implement some thin clients based on these motherboards, so any info you can provide would be very much appreciated. Thanks -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Oliver Fromme Sent: 09/24/2005 9:59 AM To: freebsd-net@freebsd.org Subject: Re: VIA VT6103 support (VIA EPIA PD) Chris Howells wrote: > There is a BIOS bug on various Via boards that causes a lockup when large > amounts of DMA transfers happen, either via the ethernet interfaces or > via IDE. That sounds strange. Do you have a URL where I can get more information about that problem? > It look a very long time for Via to admit that it happens and to start > attempting to issue a fix. > > The fix is a BIOS which is clearly marked as Beta. > > Personally I'd steer clear of such Via boards. But how do I know which VIA boards are affected? Does the VIA EPIA PD have that problem? I cannot find any information about a "VIA BIOS bug". Are you sure you're not confusing things? Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998 _______________________________________________ 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" SPAM: (no report template found)