From owner-freebsd-net@FreeBSD.ORG Sun Mar 23 02:23:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CF421065670 for ; Sun, 23 Mar 2008 02:23:10 +0000 (UTC) (envelope-from daniel@dgnetwork.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [200.179.179.14]) by mx1.freebsd.org (Postfix) with SMTP id 93EF58FC1B for ; Sun, 23 Mar 2008 02:23:09 +0000 (UTC) (envelope-from daniel@dgnetwork.com.br) Received: (qmail 88037 invoked by uid 1008); 23 Mar 2008 02:23:07 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.6-unknown (2006-10-03) on srvmail3 X-Spam-Level: X-Spam-Status: No, score=-1.8 required=4.7 tests=AWL,BAYES_00 autolearn=ham version=3.1.6-unknown Received: from unknown (HELO ?10.0.1.10?) (daniel@dgnetwork.com.br@200.243.216.68) by mail.mastercabo.com.br with SMTP; 23 Mar 2008 02:23:03 -0000 Message-ID: <47E5BD04.5050806@dgnetwork.com.br> Date: Sat, 22 Mar 2008 23:14:28 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= Organization: DGNET Network Solutions User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: FreeBSD OS Detection and Uptime X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel@dgnetwork.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2008 02:23:10 -0000 Which methods used to prevent OS detection and uptime (nmap) ? http://nmap.org/misc/defeat-nmap-osdetect.html#BSD I tried, but not work. From owner-freebsd-net@FreeBSD.ORG Sun Mar 23 06:11:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50C811065673 for ; Sun, 23 Mar 2008 06:11:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by mx1.freebsd.org (Postfix) with ESMTP id 16ABC8FC1B for ; Sun, 23 Mar 2008 06:11:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so2444615wfa.7 for ; Sat, 22 Mar 2008 23:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=bC3qd98wiQYgAf7I+kPb+18hbhg1sOR04ZemRfO8gVo=; b=nKu48IdWpxBGJlgaL7tHG8s3Vz/+NI4MS0X8gyDxrcUtx2cfguefO+dpy9/6Z0p+fDnn/z2uXX2QOd6x9v1+Rd7Y1nb3ZsXvjJ1cp2wTovCPyYKxDX9stYeaJT7q1Sn3cTZ83Fc1qOm0f95WaeZ0U8pfq0Lc+N+is7MzrNbPZe4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=rLYTT90WZMr44rYCTTPDOOWij4msAHVcds713AqICrNCSzUwUOo01a2mCgsiGqULf4vpPakEAHRodmZczX4mfRQxpXwHYXA4jlZifMJlQwgmGBHYNtLJqENxpz5wJ75JxwhXlcNWqz/PmvB47j31ShTcN5CxhdGuk5BUt135Sms= Received: by 10.142.232.20 with SMTP id e20mr3542271wfh.198.1206252716820; Sat, 22 Mar 2008 23:11:56 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 24sm11906500wff.10.2008.03.22.23.11.52 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 22 Mar 2008 23:11:54 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m2N6BmIl079795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 23 Mar 2008 15:11:48 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m2N6BkYa079794; Sun, 23 Mar 2008 15:11:46 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sun, 23 Mar 2008 15:11:46 +0900 From: Pyun YongHyeon To: Artem Belevich Message-ID: <20080323061146.GA79693@cdnetworks.co.kr> References: <47E57C8F.4090602@citrin.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org, Anton Yuzhaninov Subject: Re: re TSO: data corruption X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2008 06:11:57 -0000 On Sat, Mar 22, 2008 at 04:01:50PM -0700, Artem Belevich wrote: > TSO does seem to be broken on Realtek adapters. I ran into it on > Windows, went googling and found that I'm not the only one suffering: > > http://blogs.zdnet.com/Ou/?p=663 > http://www.mail-archive.com/netdev@vger.kernel.org/msg56764.html > Long time ago, I've read this article but the article is not clear to me. I know RealTek chips have several bugs not mentioned in datasheet and Tx checksum offload is one of the most serious bug in the hardware. But I didn't encounter any TSO related issues on my box. It could also be related checksum offload and padding but I have no clear evidence yet. Today, I commited pending changes in my local tree. This will address VLAN and unstability issues on PCIe based hardwares. But the stock version still does not have one important fix that is under actively testing. To rule out other possible bugs in stock driver, please download the follodwing files and set tunable hw.re.msi_disable="1" in /boot/loader.conf and let me know the result. http://people.freebsd.org/~yongari/re/if_re.c http://people.freebsd.org/~yongari/re/if_rlreg.h The above version has changed a way to work-around checksum offload bug of the hardware. -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Sun Mar 23 10:22:15 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAC871065682 for ; Sun, 23 Mar 2008 10:22:15 +0000 (UTC) (envelope-from robertjenssen@ozemail.com.au) Received: from outbound.icp-qv1-irony-out4.iinet.net.au (outbound.icp-qv1-irony-out4.iinet.net.au [203.59.1.150]) by mx1.freebsd.org (Postfix) with ESMTP id 590148FC15 for ; Sun, 23 Mar 2008 10:22:13 +0000 (UTC) (envelope-from robertjenssen@ozemail.com.au) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgAAB/F5Ud8qznO/2dsb2JhbAAIpnw X-IronPort-AV: E=Sophos;i="4.25,542,1199631600"; d="scan'208";a="195878052" Received: from unknown (HELO [192.168.0.4]) ([124.171.57.206]) by outbound.icp-qv1-irony-out4.iinet.net.au with ESMTP; 23 Mar 2008 18:52:07 +0900 From: Robert Jenssen To: net@freebsd.org Date: Sun, 23 Mar 2008 20:52:06 +1100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803232052.07111.robertjenssen@ozemail.com.au> Cc: Subject: Lock order reversal in ral driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2008 10:22:15 -0000 Hi, Since upgrading to FreeBSD 7 I have been experiencing some frustrating problems with my RAL wifi card. In particular, it seems to me that dhclient fails when the ral device driver times out while scanning for my access point. At the same time my HP PDA with Spectec WiFi SDIO card has no problems finding my access point. Today I made a kernel with the following options: makeoptions DEBUG=-g options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_LOCKS options DEBUG_VFS_LOCKS options DIAGNOSTIC options SOCKBUF_DEBUG options DDB options KDB Upon rebooting the dmesg immediately showed a lock order reversal in the ral driver in ieee80211_scan.c and rt2560.c (see below). Does this correspond to my symptoms? Is there a wizard out there who understands what is happening? Thanks in advance, Rob Mar 23 18:29:49 kraken syslogd: kernel boot file is /boot/kernel/kernel Mar 23 18:29:49 kraken kernel: Copyright (c) 1992-2008 The FreeBSD Project. Mar 23 18:29:49 kraken kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 23 18:29:49 kraken kernel: The Regents of the University of California. All rights reserved. Mar 23 18:29:49 kraken kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Mar 23 18:29:49 kraken kernel: FreeBSD 7.0-STABLE #0: Sun Mar 23 17:39:25 EST 2008 Mar 23 18:29:49 kraken kernel: root@kraken.wollstonecraft:/usr/obj/usr/src/sys/KRAKEN_DEBUG Mar 23 18:29:49 kraken kernel: WARNING: WITNESS option enabled, expect reduced performance. Mar 23 18:29:49 kraken kernel: WARNING: DIAGNOSTIC option enabled, expect reduced performance. Mar 23 18:29:49 kraken kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Mar 23 18:29:49 kraken kernel: CPU: Intel(R) Celeron(R) CPU 2.80GHz (2856.49-MHz 686-class CPU) Mar 23 18:29:49 kraken kernel: Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Mar 23 18:29:49 kraken kernel: Features=0xbfebfbff Mar 23 18:29:49 kraken kernel: Features2=0x4400 Mar 23 18:29:49 kraken kernel: real memory = 1073676288 (1023 MB) Mar 23 18:29:49 kraken kernel: avail memory = 1040924672 (992 MB) Mar 23 18:29:49 kraken kernel: ACPI APIC Table: Mar 23 18:29:49 kraken kernel: WITNESS: spin lock intrcnt not in order list Mar 23 18:29:49 kraken kernel: ioapic0 irqs 0-23 on motherboard Mar 23 18:29:49 kraken kernel: kbd1 at kbdmux0 Mar 23 18:29:49 kraken kernel: acpi0: on motherboard Mar 23 18:29:49 kraken kernel: acpi0: [ITHREAD] Mar 23 18:29:49 kraken kernel: acpi0: Power Button (fixed) Mar 23 18:29:49 kraken kernel: acpi0: reservation of 0, a0000 (3) failed Mar 23 18:29:49 kraken kernel: acpi0: reservation of 100000, 3fef0000 (3) failed Mar 23 18:29:49 kraken kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Mar 23 18:29:49 kraken kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 Mar 23 18:29:49 kraken kernel: cpu0: on acpi0 Mar 23 18:29:49 kraken kernel: acpi_button0: on acpi0 Mar 23 18:29:49 kraken kernel: pcib0: port 0xcf8-0xcff on acpi0 Mar 23 18:29:49 kraken kernel: pci0: on pcib0 Mar 23 18:29:49 kraken kernel: agp0: on hostb0 Mar 23 18:29:49 kraken kernel: pcib1: at device 1.0 on pci0 Mar 23 18:29:49 kraken kernel: pci1: on pcib1 Mar 23 18:29:49 kraken kernel: vgapci0: port 0x9000-0x90ff mem 0xe0000000-0xe7ffffff,0xf1000000-0xf100ffff irq 16 at device 0.0 on pci1 Mar 23 18:29:49 kraken kernel: vgapci1: mem 0xe8000000-0xefffffff,0xf1010000-0xf101ffff at device 0.1 on pci1 Mar 23 18:29:49 kraken kernel: uhci0: port 0xbc00-0xbc1f irq 16 at device 29.0 on pci0 Mar 23 18:29:49 kraken kernel: uhci0: [GIANT-LOCKED] Mar 23 18:29:49 kraken kernel: uhci0: [ITHREAD] Mar 23 18:29:49 kraken kernel: usb0: on uhci0 Mar 23 18:29:49 kraken kernel: usb0: USB revision 1.0 Mar 23 18:29:49 kraken kernel: uhub0: on usb0 Mar 23 18:29:49 kraken kernel: uhub0: 2 ports with 2 removable, self powered Mar 23 18:29:49 kraken kernel: uhci1: port 0xb000-0xb01f irq 19 at device 29.1 on pci0 Mar 23 18:29:49 kraken kernel: uhci1: [GIANT-LOCKED] Mar 23 18:29:49 kraken kernel: uhci1: [ITHREAD] Mar 23 18:29:49 kraken kernel: usb1: on uhci1 Mar 23 18:29:49 kraken kernel: usb1: USB revision 1.0 Mar 23 18:29:49 kraken kernel: uhub1: on usb1 Mar 23 18:29:49 kraken kernel: uhub1: 2 ports with 2 removable, self powered Mar 23 18:29:49 kraken kernel: uhci2: port 0xb400-0xb41f irq 18 at device 29.2 on pci0 Mar 23 18:29:49 kraken kernel: uhci2: [GIANT-LOCKED] Mar 23 18:29:49 kraken kernel: uhci2: [ITHREAD] Mar 23 18:29:49 kraken kernel: usb2: on uhci2 Mar 23 18:29:49 kraken kernel: usb2: USB revision 1.0 Mar 23 18:29:49 kraken kernel: uhub2: on usb2 Mar 23 18:29:49 kraken kernel: uhub2: 2 ports with 2 removable, self powered Mar 23 18:29:49 kraken kernel: uhci3: port 0xb800-0xb81f irq 16 at device 29.3 on pci0 Mar 23 18:29:49 kraken kernel: uhci3: [GIANT-LOCKED] Mar 23 18:29:49 kraken kernel: uhci3: [ITHREAD] Mar 23 18:29:49 kraken kernel: usb3: on uhci3 Mar 23 18:29:49 kraken kernel: usb3: USB revision 1.0 Mar 23 18:29:49 kraken kernel: uhub3: on usb3 Mar 23 18:29:49 kraken kernel: uhub3: 2 ports with 2 removable, self powered Mar 23 18:29:49 kraken kernel: ehci0: mem 0xf2200000-0xf22003ff irq 23 at device 29.7 on pci0 Mar 23 18:29:49 kraken kernel: ehci0: [GIANT-LOCKED] Mar 23 18:29:49 kraken kernel: ehci0: [ITHREAD] Mar 23 18:29:49 kraken kernel: usb4: EHCI version 1.0 Mar 23 18:29:49 kraken kernel: usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 Mar 23 18:29:49 kraken kernel: usb4: on ehci0 Mar 23 18:29:49 kraken kernel: usb4: USB revision 2.0 Mar 23 18:29:49 kraken kernel: uhub4: on usb4 Mar 23 18:29:49 kraken kernel: uhub4: 8 ports with 8 removable, self powered Mar 23 18:29:49 kraken kernel: usb4: handing over low speed device on port 2 to usb0 Mar 23 18:29:49 kraken kernel: uhub4: port 2, device disappeared after reset Mar 23 18:29:49 kraken kernel: pcib2: at device 30.0 on pci0 Mar 23 18:29:49 kraken kernel: pci2: on pcib2 Mar 23 18:29:49 kraken kernel: fwohci0: mem 0xf2007000-0xf20077ff,0xf2000000-0xf2003fff irq 17 at device 1.0 on pci2 Mar 23 18:29:49 kraken kernel: fwohci0: [FILTER] Mar 23 18:29:49 kraken kernel: fwohci0: OHCI version 1.10 (ROM=1) Mar 23 18:29:49 kraken kernel: fwohci0: No. of Isochronous channels is 4. Mar 23 18:29:49 kraken kernel: fwohci0: EUI64 00:50:8d:00:00:e2:cc:9b Mar 23 18:29:49 kraken kernel: fwohci0: Phy 1394a available S400, 3 ports. Mar 23 18:29:49 kraken kernel: fwohci0: Link S400, max_rec 2048 bytes. Mar 23 18:29:49 kraken kernel: firewire0: on fwohci0 Mar 23 18:29:49 kraken kernel: fwip0: on firewire0 Mar 23 18:29:49 kraken kernel: fwip0: Firewire address: 00:50:8d:00:00:e2:cc:9b @ 0xfffe00000000, S400, maxrec 2048 Mar 23 18:29:49 kraken kernel: sbp0: on firewire0 Mar 23 18:29:49 kraken kernel: dcons_crom0: on firewire0 Mar 23 18:29:49 kraken kernel: dcons_crom0: bus_addr 0x138c000 Mar 23 18:29:49 kraken kernel: fwe0: on firewire0 Mar 23 18:29:49 kraken kernel: if_fwe0: Fake Ethernet address: 02:50:8d:e2:cc:9b Mar 23 18:29:49 kraken kernel: fwe0: Ethernet address: xx:xx:xx:xx:xx:xx Mar 23 18:29:49 kraken kernel: fwohci0: Initiate bus reset Mar 23 18:29:49 kraken kernel: fwohci0: BUS reset Mar 23 18:29:49 kraken kernel: fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode Mar 23 18:29:49 kraken kernel: rl0: port 0xa000-0xa0ff mem 0xf2006000-0xf20060ff irq 18 at device 2.0 on pci2 Mar 23 18:29:49 kraken kernel: miibus0: on rl0 Mar 23 18:29:49 kraken kernel: rlphy0: PHY 0 on miibus0 Mar 23 18:29:49 kraken kernel: rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Mar 23 18:29:49 kraken kernel: rl0: Ethernet address: xx:xx:xx:xx:xx:xx Mar 23 18:29:49 kraken kernel: rl0: [ITHREAD] Mar 23 18:29:49 kraken kernel: pci2: at device 4.0 (no driver attached) Mar 23 18:29:49 kraken kernel: ral0: mem 0xf2004000-0xf2005fff irq 22 at device 6.0 on pci2 Mar 23 18:29:49 kraken kernel: ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 Mar 23 18:29:49 kraken kernel: ral0: Ethernet address: xx:xx:xx:xx:xx:xx Mar 23 18:29:49 kraken kernel: ral0: [ITHREAD] Mar 23 18:29:49 kraken kernel: isab0: at device 31.0 on pci0 Mar 23 18:29:49 kraken kernel: isa0: on isab0 Mar 23 18:29:49 kraken kernel: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0 Mar 23 18:29:49 kraken kernel: ata0: on atapci0 Mar 23 18:29:49 kraken kernel: ata0: [ITHREAD] Mar 23 18:29:49 kraken kernel: ata1: on atapci0 Mar 23 18:29:49 kraken kernel: ata1: [ITHREAD] Mar 23 18:29:49 kraken kernel: atapci1: port 0xc000-0xc007,0xc400-0xc403,0xc800-0xc807,0xcc00-0xcc03,0xd000-0xd00f irq 18 at device 31.2 on pci0 Mar 23 18:29:49 kraken kernel: atapci1: [ITHREAD] Mar 23 18:29:49 kraken kernel: ata2: on atapci1 Mar 23 18:29:49 kraken kernel: ata2: [ITHREAD] Mar 23 18:29:49 kraken kernel: ata3: on atapci1 Mar 23 18:29:49 kraken kernel: ata3: [ITHREAD] Mar 23 18:29:49 kraken kernel: pci0: at device 31.3 (no driver attached) Mar 23 18:29:49 kraken kernel: pcm0: port 0xd800-0xd8ff,0xdc00-0xdc3f mem 0xf2201000-0xf22011ff,0xf2202000-0xf22020ff irq 17 at device 31.5 on pci0 Mar 23 18:29:49 kraken kernel: pcm0: [ITHREAD] Mar 23 18:29:49 kraken kernel: pcm0: Mar 23 18:29:49 kraken kernel: acpi_tz0: on acpi0 Mar 23 18:29:49 kraken kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Mar 23 18:29:49 kraken kernel: fdc0: [FILTER] Mar 23 18:29:49 kraken kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Mar 23 18:29:49 kraken kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Mar 23 18:29:49 kraken kernel: sio0: type 16550A Mar 23 18:29:49 kraken kernel: sio0: [FILTER] Mar 23 18:29:49 kraken kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Mar 23 18:29:49 kraken kernel: atkbd0: irq 1 on atkbdc0 Mar 23 18:29:49 kraken kernel: kbd0 at atkbd0 Mar 23 18:29:49 kraken kernel: atkbd0: [GIANT-LOCKED] Mar 23 18:29:49 kraken kernel: atkbd0: [ITHREAD] Mar 23 18:29:49 kraken kernel: pmtimer0 on isa0 Mar 23 18:29:49 kraken kernel: orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 Mar 23 18:29:49 kraken kernel: ppc0: at port 0x378-0x37f irq 7 on isa0 Mar 23 18:29:49 kraken kernel: ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode Mar 23 18:29:49 kraken kernel: ppbus0: on ppc0 Mar 23 18:29:49 kraken kernel: ppbus0: [ITHREAD] Mar 23 18:29:49 kraken kernel: plip0: on ppbus0 Mar 23 18:29:49 kraken kernel: lpt0: on ppbus0 Mar 23 18:29:49 kraken kernel: lpt0: Interrupt-driven port Mar 23 18:29:49 kraken kernel: ppi0: on ppbus0 Mar 23 18:29:49 kraken kernel: ppc0: [GIANT-LOCKED] Mar 23 18:29:49 kraken kernel: ppc0: [ITHREAD] Mar 23 18:29:49 kraken kernel: sc0: at flags 0x100 on isa0 Mar 23 18:29:49 kraken kernel: sc0: VGA <16 virtual consoles, flags=0x300> Mar 23 18:29:49 kraken kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Mar 23 18:29:49 kraken kernel: sio1: port may not be enabled Mar 23 18:29:49 kraken kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Mar 23 18:29:49 kraken kernel: ums0: on uhub0 Mar 23 18:29:49 kraken kernel: ums0: 3 buttons and Z dir. Mar 23 18:29:49 kraken kernel: Timecounter "TSC" frequency 2856488788 Hz quality 800 Mar 23 18:29:49 kraken kernel: Timecounters tick every 1.000 msec Mar 23 18:29:49 kraken kernel: ipfw2 (+ipv6) initialized, divert enabled, nat loadable, rule-based forwarding firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) Mar 23 18:29:49 kraken kernel: firewire0: bus manager 0 (me) Mar 23 18:29:49 kraken kernel: disabled, default to accept, logging limited to 5 packets/entry by default Mar 23 18:29:49 kraken kernel: acd0: DVDR at ata0-master UDMA33 Mar 23 18:29:49 kraken kernel: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 Mar 23 18:29:49 kraken kernel: acd1: CDROM at ata1-master UDMA33 Mar 23 18:29:49 kraken kernel: ad4: 152627MB at ata2-master SATA150 Mar 23 18:29:49 kraken kernel: ad6: 76319MB at ata3-master SATA150 Mar 23 18:29:49 kraken kernel: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 Mar 23 18:29:49 kraken kernel: cd0 at ata0 bus 0 target 0 lun 0 Mar 23 18:29:49 kraken kernel: cd0: Removable CD-ROM SCSI-0 device Mar 23 18:29:49 kraken kernel: cd0: 33.000MB/s transfers Mar 23 18:29:49 kraken kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present Mar 23 18:29:49 kraken kernel: cd1 at ata1 bus 0 target 0 lun 0 Mar 23 18:29:49 kraken kernel: cd1: Removable CD-ROM SCSI-0 device Mar 23 18:29:49 kraken kernel: cd1: 33.000MB/s transfers Mar 23 18:29:49 kraken kernel: cd1: Attempt to query device size failed: NOT READY, Medium not present Mar 23 18:29:49 kraken kernel: hwpmc: TSC/1/0x20 P4/18/0xfff Mar 23 18:29:49 kraken kernel: WARNING: WITNESS option enabled, expect reduced performance. Mar 23 18:29:49 kraken kernel: WARNING: DIAGNOSTIC option enabled, expect reduced performance. Mar 23 18:29:49 kraken kernel: Trying to mount root from ufs:/dev/ad4s2a Mar 23 18:29:49 kraken savecore: no dumps found Mar 23 18:30:05 kraken kernel: ipfw: limit 10 reached on entry 3240 Mar 23 18:30:36 kraken kernel: ipfw: limit 10 reached on entry 1300 Mar 23 18:30:36 kraken nmbd[879]: [2008/03/23 18:30:36, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_wins(335) Mar 23 18:30:36 kraken nmbd[879]: become_domain_master_browser_wins: Mar 23 18:30:36 kraken nmbd[879]: Attempting to become domain master browser on workgroup WORKGROUP, subnet UNICAST_SUBNET. Mar 23 18:30:36 kraken nmbd[879]: [2008/03/23 18:30:36, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_wins(349) Mar 23 18:30:36 kraken nmbd[879]: become_domain_master_browser_wins: querying WINS server from IP 192.168.0.4 for domain master browser name WORKGROUP<1b> on workgroup WORKGROUP Mar 23 18:30:36 kraken nmbd[879]: [2008/03/23 18:30:36, 0] nmbd/nmbd_become_dmb.c:become_domain_master_stage2(113) Mar 23 18:30:36 kraken nmbd[879]: ***** Mar 23 18:30:36 kraken nmbd[879]: Mar 23 18:30:36 kraken nmbd[879]: Samba server KRAKEN is now a domain master browser for workgroup WORKGROUP on subnet UNICAST_SUBNET Mar 23 18:30:36 kraken nmbd[879]: Mar 23 18:30:36 kraken nmbd[879]: ***** Mar 23 18:30:36 kraken nmbd[879]: [2008/03/23 18:30:36, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_bcast(290) Mar 23 18:30:36 kraken nmbd[879]: become_domain_master_browser_bcast: Mar 23 18:30:36 kraken nmbd[879]: Attempting to become domain master browser on workgroup WORKGROUP on subnet 192.168.0.4 Mar 23 18:30:36 kraken nmbd[879]: [2008/03/23 18:30:36, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_bcast(303) Mar 23 18:30:36 kraken nmbd[879]: become_domain_master_browser_bcast: querying subnet 192.168.0.4 for domain master browser on workgroup WORKGROUP Mar 23 18:30:44 kraken nmbd[879]: [2008/03/23 18:30:44, 0] nmbd/nmbd_become_dmb.c:become_domain_master_stage2(113) Mar 23 18:30:44 kraken nmbd[879]: ***** Mar 23 18:30:44 kraken nmbd[879]: Mar 23 18:30:44 kraken nmbd[879]: Samba server KRAKEN is now a domain master browser for workgroup WORKGROUP on subnet 192.168.0.4 Mar 23 18:30:44 kraken nmbd[879]: Mar 23 18:30:44 kraken nmbd[879]: ***** Mar 23 18:30:59 kraken nmbd[879]: [2008/03/23 18:30:59, 0] nmbd/nmbd_become_lmb.c:become_local_master_stage2(396) Mar 23 18:30:59 kraken nmbd[879]: ***** Mar 23 18:30:59 kraken nmbd[879]: Mar 23 18:30:59 kraken nmbd[879]: Samba name server KRAKEN is now a local master browser for workgroup WORKGROUP on subnet 192.168.0.4 Mar 23 18:30:59 kraken nmbd[879]: Mar 23 18:30:59 kraken nmbd[879]: ***** Mar 23 18:31:37 kraken winbindd[888]: [2008/03/23 18:31:37, 0] nsswitch/winbindd_cache.c:initialize_winbindd_cache(2223) Mar 23 18:31:37 kraken winbindd[888]: initialize_winbindd_cache: clearing cache and re-creating with version number 1 Mar 23 18:31:37 kraken lpd[908]: lpd startup: logging=0 Mar 23 18:31:37 kraken ntpd: logging to file /var/log/ntpd.log Mar 23 18:31:50 kraken kernel: rl0: link state changed to DOWN Mar 23 18:31:56 kraken kernel: Expensive timeout(9) function: 0xc05302a7 (0xc0988260) 0.004545697 s Mar 23 18:33:07 kraken kernel: lock order reversal: Mar 23 18:33:07 kraken kernel: 1st 0xc3cd900c ieee80211com (802.11 com lock) @ /usr/src/sys/net80211/ieee80211_scan.c:524 Mar 23 18:33:07 kraken kernel: 2nd 0xc3cda41c ral0 (network driver) @ /usr/src/sys/dev/ral/rt2560.c:2006 Mar 23 18:33:07 kraken kernel: KDB: stack backtrace: Mar 23 18:33:07 kraken kernel: db_trace_self_wrapper(c08867d1,e4119914,c060505a,c0888c56,c3cda41c,...) at db_trace_self_wrapper+0x26 Mar 23 18:33:07 kraken kernel: kdb_backtrace(c0888c56,c3cda41c,c3cd80c0,c086c50c,c08707e8,...) at kdb_backtrace+0x29 Mar 23 18:33:07 kraken kernel: witness_checkorder(c3cda41c,9,c08707e8,7d6,c0604871,...) at witness_checkorder+0x6b7 Mar 23 18:33:07 kraken kernel: _mtx_lock_flags(c3cda41c,0,c08707e8,7d6,c0894568,...) at _mtx_lock_flags+0xb0 Mar 23 18:33:07 kraken kernel: rt2560_start(c3cd7c00,c3cd9004,e4119a10,c068dfb2,c3cd7c00,...) at rt2560_start+0x3e Mar 23 18:33:07 kraken kernel: if_start(c3cd7c00,0,c0894568,184,e41199f4,...) at if_start+0x4f Mar 23 18:33:07 kraken kernel: ieee80211_send_nulldata(c40e7000,38,c0888342,6ce,c3cd900c) at ieee80211_send_nulldata+0x1ea Mar 23 18:33:07 kraken kernel: ieee80211_sta_pwrsave(c3cd9004,1,20c,6400,c3bfe000,...) at ieee80211_sta_pwrsave+0x1fe Mar 23 18:33:07 kraken kernel: scan_restart(c3bfe000,c3cd9004,c0895099,20c,2,...) at scan_restart+0x89 Mar 23 18:33:07 kraken kernel: ieee80211_bg_scan(c3cd9004,c3d10818,8,1,c092b858,...) at ieee80211_bg_scan+0x113 Mar 23 18:33:07 kraken kernel: ieee80211_recv_mgmt(c3cd9004,c3ce3400,c40e7000,80,32,...) at ieee80211_recv_mgmt+0xd9c Mar 23 18:33:07 kraken kernel: ieee80211_input(c3cd9004,c3ce3400,c40e7000,32,ffffffa1,...) at ieee80211_input+0x141d Mar 23 18:33:07 kraken kernel: rt2560_intr(c3cd9000,0,c088062e,471,c3af32e4,...) at rt2560_intr+0x824 Mar 23 18:33:07 kraken kernel: ithread_loop(c3bf0940,e4119d38,c08803bd,305,c3bdaab0,...) at ithread_loop+0x1a4 Mar 23 18:33:07 kraken kernel: fork_exit(c05b4780,c3bf0940,e4119d38) at fork_exit+0xb8 Mar 23 18:33:07 kraken kernel: fork_trampoline() at fork_trampoline+0x8 Mar 23 18:33:07 kraken kernel: --- trap 0, eip = 0, esp = 0xe4119d70, ebp = 0 --- Mar 23 18:34:38 kraken kernel: Expensive timeout(9) function: 0xc05302a7 (0xc0988260) 0.009589366 s Mar 23 18:34:43 kraken login: ROOT LOGIN (root) ON ttyv0 From owner-freebsd-net@FreeBSD.ORG Sun Mar 23 11:49:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A20071065672; Sun, 23 Mar 2008 11:49:03 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 71C3D8FC14; Sun, 23 Mar 2008 11:49:03 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2NBn3M6051827; Sun, 23 Mar 2008 11:49:03 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2NBn39j051823; Sun, 23 Mar 2008 11:49:03 GMT (envelope-from gavin) Date: Sun, 23 Mar 2008 11:49:03 GMT Message-Id: <200803231149.m2NBn39j051823@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/121983: [fxp] fxp0 MBUF and PAE 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, 23 Mar 2008 11:49:03 -0000 Old Synopsis: fxp0 MBUF and PAE New Synopsis: [fxp] fxp0 MBUF and PAE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Mar 23 11:45:57 UTC 2008 Responsible-Changed-Why: Over to -net. fxp doesn't seem to work correctly with PAE, even though it is fxp not excluded from the PAE kernel (ie so should work) http://www.freebsd.org/cgi/query-pr.cgi?pr=121983 From owner-freebsd-net@FreeBSD.ORG Sun Mar 23 13:04:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19736106566C for ; Sun, 23 Mar 2008 13:04:53 +0000 (UTC) (envelope-from freebsd@levsha.org.ua) Received: from expo.ukrweb.net (expo.ukrweb.net [193.125.78.116]) by mx1.freebsd.org (Postfix) with ESMTP id C204F8FC13 for ; Sun, 23 Mar 2008 13:04:52 +0000 (UTC) (envelope-from freebsd@levsha.org.ua) Received: from levsha by expo.ukrweb.net with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JdPPS-000Pzu-AL; Sun, 23 Mar 2008 14:34:46 +0200 Date: Sun, 23 Mar 2008 14:34:46 +0200 From: Mykola Dzham To: Alexandre Biancalana Message-ID: <20080323123446.GZ62100@expo.ukrweb.net> References: <8e10486b0803041857v6d20e3f0x115c6842ec7d899b@mail.gmail.com> <47CE9F22.4010107@FreeBSD.org> <8e10486b0803050740u7d36c784pd0b9d0d1b3e29c95@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8e10486b0803050740u7d36c784pd0b9d0d1b3e29c95@mail.gmail.com> X-Operating-System: FreeBSD/5.4-RELEASE-p6 (i386) User-Agent: Mutt/1.5.6i Cc: freebsd-net@freebsd.org Subject: Re: ALTQ Vlan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2008 13:04:53 -0000 Alexandre Biancalana wrote: > On 3/5/08, Sergey Matveychuk wrote: > > Alexandre Biancalana wrote: > > > Hi list, > > > > > > Is there any patches or plans to support altq on vlan interfaces ?? > > > > > > > > > The patch is quite trivial: > > http://people.yandex-team.ru/~sem/FreeBSD/vlan+altq.patch > > Is this working on 7 ? with pf ? > > > > > But may be a better way to shape traffic on parent interface for you? > > I did the patch because I couldn't do shaping on a parent interface for > > some reason. > > My problem is that I've only one physical interface on the server and > this interface provide vlans for local network and remote links (which > I want to shape the traffic) then I had problems because I want to > limit the speed only on remote links. You can setup atlq on parent interface and assign traffic to queue on vlan interface: altq on em0 cbq bandwidth 1Gb queue { def, vlan10 } queue def bandwidth 80% cbq ( default , borrow ) queue vlan10 bandwidth 20Mb cbq ... pass out on vlan10 queue vlan10 -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua From owner-freebsd-net@FreeBSD.ORG Sun Mar 23 15:00:54 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 715E41065677 for ; Sun, 23 Mar 2008 15:00:54 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by mx1.freebsd.org (Postfix) with ESMTP id E7FAE8FC20 for ; Sun, 23 Mar 2008 15:00:53 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so3263929fka.11 for ; Sun, 23 Mar 2008 08:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; bh=I+OesYSpS/2dwZG3sqL/h1cRTXnHriWfgSh17IaNBBc=; b=boXzepw48uSrnIRdlhT7Uj3iFMLx28KF73b0sRBlknTLDy5RphAXg5hO1WaGYDoEvak1quc4BNYRjMFcCNFZpc6WysnXVbXJvxwdnbuLLhbHLLpYzgvCIa3uZmbZFKI+8syLmE08t/VvWr/f5k/tgQYEumcLdBvjVwniO2r9p54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; b=oT8Zj5u9H/AkM59OiYtho40GoaYxQMa/TfPqnrvTIhcdXlYQTOppaswEiL/qv1hykt39VBJXpcGono+a9H6kYfzkcZhbwX/0zWnFDFJaregFpdGqShfeD/oAgQa2t2TCzcSoQWkPdtA5VXbAQ344Z34mwXrko58gTRppUR4D5SA= Received: by 10.78.107.8 with SMTP id f8mr17088864huc.23.1206284452036; Sun, 23 Mar 2008 08:00:52 -0700 (PDT) Received: from fnop.net ( [83.144.141.62]) by mx.google.com with ESMTPS id c22sm11255606ika.3.2008.03.23.08.00.50 (version=SSLv3 cipher=OTHER); Sun, 23 Mar 2008 08:00:51 -0700 (PDT) Date: Sun, 23 Mar 2008 15:00:38 +0000 From: Rui Paulo To: =?us-ascii?B?PT9JU08tODg1OS0xP1E/RGFuaWVsX0RpYXNfR29uPUU3YWx2ZXNf?= , ?=@fnop.net Message-ID: <20080323150038.GA17070@fnop.net> References: <47E5BD04.5050806@dgnetwork.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47E5BD04.5050806@dgnetwork.com.br> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: Rui Paulo Cc: freebsd-hackers@freebsd.org, freebsd-pf@freebsd.org, freebsd-net@freebsd.org Subject: Re: FreeBSD OS Detection and Uptime 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, 23 Mar 2008 15:00:54 -0000 On Sat, Mar 22, 2008 at 11:14:28PM -0300, =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves_ wrote: > Which methods used to prevent OS detection and uptime (nmap) ? > http://nmap.org/misc/defeat-nmap-osdetect.html#BSD > I tried, but not work. The TCP Drop SYN+FIN sysctl might help. % sysctl -d net.inet.tcp.drop_synfin net.inet.tcp.drop_synfin: Drop TCP packets with SYN+FIN set Regards. -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Sun Mar 23 22:23:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26954106564A for ; Sun, 23 Mar 2008 22:23:57 +0000 (UTC) (envelope-from jontheil@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id BCBE18FC18 for ; Sun, 23 Mar 2008 22:23:57 +0000 (UTC) (envelope-from jontheil@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so2970199waf.3 for ; Sun, 23 Mar 2008 15:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=RKEYX6Tok6fMkWOdjXUya7WFsWEGDSgeeDFUHE8cdqs=; b=cbpi5/HFkUDYM5dRAY9mZ4X3MtTE4CXx8R38GfXfUrSFbiF4SuelhQIVnLwzorXRdh38oud/T6bYmJFOyVvN84Y4HepH9cZtIZFeC5aiVO6hA/vWBnFZ7P4reCOBe0FVvLSMOKMHSgDhCK+/mRlN3eXHA1TNR3EZGdBQKhSGbhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Z5FqVQHsRHmWlyIpyJt9DSkEFMw6RLQTA/sUhOKVqxsOZFIUv+WVDh3KynAJaNNZ78UQZYyoP9rDAc+HC7Ha1flRlOW2uZ0KpCX5lwWamktOHKDDi5QQkBrg3u0+0bG60Ugj2qz9QjIoYxYCzhzx/rxVA1ed7INrMBpIV59PrVw= Received: by 10.114.77.1 with SMTP id z1mr10290890waa.123.1206311037440; Sun, 23 Mar 2008 15:23:57 -0700 (PDT) Received: by 10.114.168.6 with HTTP; Sun, 23 Mar 2008 15:23:57 -0700 (PDT) Message-ID: <8f82c35c0803231523i52e55906tfd3cf96b36fe70d7@mail.gmail.com> Date: Sun, 23 Mar 2008 23:23:57 +0100 From: "Jon Theil Nielsen" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: A general purpose LDAP solution? 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, 23 Mar 2008 22:23:58 -0000 Hi list! I have speculated a lot about implementation of (Open)LDAP on my sever. By I haven't yet found the right (and logical) way to do it. I'm running FreeBSD 7.0-Release with some different server applications - Samba PDC - Virtual mail server (Postfix, MySQL, Courier-IMAP) - VPN (currently with mpd4) - Apache-2.2.8 web server (with PHP and MySQL) I would like to implement LDAP for: - authentication of UNIX/login users - authentication of Samba users - authentication/authorization of virtual mail users For the first part, I got useful information from a previsous thread (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-02/msg01047.html) and for the second part, i guess there is sufficient howtos to make it work. My biggest question right now is if is possible to combine all three things in one data structure. And which in which order I should make the different implimentions. Excuse my total lack of understanding, but is it possible to have a structure with a superior unit such as OU= which could contain several virtual domains and the actual doamin for my PDC? -- Jon Theil Nielsen From owner-freebsd-net@FreeBSD.ORG Sun Mar 23 22:26:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E81F41065674 for ; Sun, 23 Mar 2008 22:26:52 +0000 (UTC) (envelope-from jontheil@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by mx1.freebsd.org (Postfix) with ESMTP id B72408FC1B for ; Sun, 23 Mar 2008 22:26:52 +0000 (UTC) (envelope-from jontheil@gmail.com) Received: by wf-out-1314.google.com with SMTP id 25so2790479wfa.7 for ; Sun, 23 Mar 2008 15:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=LIQf6TW21VPSQkLTB2FpFWt9kulqhpVHbCi/2L/Gyu8=; b=L+ijvTsl8vX2QH1hgaqyBQmUvrdg6LhfswAtr2Oakk4yroDZNtsgqMNh+iwfv8jGH1ffkuWb7DFtAKshu8DvfAp/T7eyWYuIYkAiIGzO8HiFgGPS2DdNZoSep8261BXqQNei2wnN3XzuqkfRFjrnCVrqd3hpPjZ2Jh/n43nPHM0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=haSv64gmOTDy5DQSC/uNXjs41z4JZLiZqM6h2h2jbKvE54EBGQCQHiGfAsknfWwMjxfDSpW/bhyBI67SNZ78nCyLXRDJfXQ+Ix3y19wZI3NDm2hkd4CpMlqt6ULxHSq4yQJcKcNpb7wJ0KmmGJx55SPX0F3mDJKIo0G53qjy9Mg= Received: by 10.114.136.1 with SMTP id j1mr10329230wad.85.1206311211747; Sun, 23 Mar 2008 15:26:51 -0700 (PDT) Received: by 10.114.168.6 with HTTP; Sun, 23 Mar 2008 15:26:51 -0700 (PDT) Message-ID: <8f82c35c0803231526n5a429cb5t1c81a7f98dfb19ea@mail.gmail.com> Date: Sun, 23 Mar 2008 23:26:51 +0100 From: "Jon Theil Nielsen" To: freebsd-net@freebsd.org In-Reply-To: <8f82c35c0803231523i52e55906tfd3cf96b36fe70d7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8f82c35c0803231523i52e55906tfd3cf96b36fe70d7@mail.gmail.com> Subject: Re: A general purpose LDAP solution? 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, 23 Mar 2008 22:26:53 -0000 2008/3/23, Jon Theil Nielsen : > Hi list! > > I have speculated a lot about implementation of (Open)LDAP on my > sever. By I haven't yet found the right (and logical) way to do it. > I'm running FreeBSD 7.0-Release with some different server applications > - Samba PDC > - Virtual mail server (Postfix, MySQL, Courier-IMAP) > - VPN (currently with mpd4) > - Apache-2.2.8 web server (with PHP and MySQL) > I would like to implement LDAP for: > - authentication of UNIX/login users > - authentication of Samba users > - authentication/authorization of virtual mail users > For the first part, I got useful information from a previsous thread > (http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-02/msg01047.html) > and for the second part, i guess there is sufficient howtos to make it > work. > My biggest question right now is if is possible to combine all three > things in one data structure. And which in which order I should make > the different implimentions. > Excuse my total lack of understanding, but is it possible to have a > structure with a superior unit such as OU= which > could contain several virtual domains and the actual doamin for my > PDC? > > -- > Jon Theil Nielsen Oh, i forgot one more thing: I would also like to be able to authenticate VPN users the same way. -- Jon Theil Nielsen From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 04:23:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 532631065678 for ; Mon, 24 Mar 2008 04:23:33 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 0EDB18FC15 for ; Mon, 24 Mar 2008 04:23:32 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so901574anc.13 for ; Sun, 23 Mar 2008 21:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5+BuFHoYqDkRhhWrvUXvcIk/EihLrk3dNUSluREaZJw=; b=anh3cwggdQvqichpQ6qCoPrH1PpuF9ifkZLhgecynhf2f/PXL+OCtFAarflLKOUaxJ+G5k4mTgFbCF3D72boDMcPzFpVHRZF4hr7RWrQB4YfekPEnAhqG/7R3XrG+IuGDWXq3Wli6pSSCVitSIzjgTexOn14HoJXBUHI7NGpSG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZU9sViD3E0mpsUOIU32yCcohaW78KS2/zjgdlKgiL7StudrWEekkVtpcIMSl4kf3qWPVA8V9bSQwc/duCapoKZtxcVMT1szUdsoRbWUu2BE4B37NUO6WfP5hukwTt2/6GjcL57iEeSwe5LQFx4IFPMd2zdh5kRcLDzOJE9ezin8= Received: by 10.100.164.10 with SMTP id m10mr16387268ane.14.1206332611815; Sun, 23 Mar 2008 21:23:31 -0700 (PDT) Received: by 10.70.48.17 with HTTP; Sun, 23 Mar 2008 21:23:31 -0700 (PDT) Message-ID: Date: Mon, 24 Mar 2008 00:23:31 -0400 From: Kage To: freebsd-net@freebsd.org In-Reply-To: <47E50936.1010405@restart.be> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47E50936.1010405@restart.be> Subject: Re: natd port forward times out, tcpdump yields nothing 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, 24 Mar 2008 04:23:33 -0000 Well, no, see it's hitting natd just fine as shown by my natd verbose logs, if you're assuming ipfw is blocking me from reaching natd. Are you talking about adding a firewall rule for each of my round-robin addresses, too? How would that do any good? On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert wrote: > > Kage wrote: > > Hey guys, > > > > This is a fun one that's stumped people in Freenode ##freebsd. > > Basically, I have this layout: > > > > irc.domain.com -> DNS A -> IRC Jail > > > > When someone connects to irc.domain.com on IRC ports (6667, 8067, > > etc.), it round-robins them using natd, otherwise it sends all other > > port requests to the IRC jail as per normal (such as port 80, which is > > my primary concern). As for having it setup to have ipfw divert to > > natd, that's done and works, as shown by natd verbose mode: > > > > In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 aliased to > > [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 > > > > (For reference) > > 207.210.114.45 = jail IP > > 72.20.28.202 = example target IP in the round-robin > > 72.65.73.23 = my IP > > > > Right now, my ipfw.rules file is as follows: > > > > [root@nub /etc]# cat ipfw.rules > > IPF="ipfw -q add" > > ipfw -f -q flush > > > > #loopback > > $IPF 10 allow all from any to any via lo0 > > $IPF 20 deny all from any to 127.0.0.0/8 > > $IPF 30 deny all from 127.0.0.0/8 to any > > $IPF 40 deny tcp from any to any frag > > > > # statefull > > $IPF 50 check-state > > $IPF 60 allow tcp from any to any established > > $IPF 70 allow all from any to any out keep-state > > $IPF 54999 allow icmp from any to any > > > > # Include the deny file > > . /etc/ipfw.deny > > > > [snip -- some allowed ports] > > # IRC (natd divert for IRC port-forwarding > > $IPF 50220 divert natd all from any to 207.210.114.45 6667 via rl0 > > $IPF 50230 divert natd all from any to 207.210.114.45 8067 via rl0 > > $IPF 50240 divert natd all from any to 207.210.114.45 8068 via rl0 > > $IPF 50250 divert natd all from any to 207.210.114.45 6697 via rl0 > > $IPF 50260 divert natd all from any to 207.210.114.45 7000 via rl0 > > > You must also divert the response trafic AFAIK eg: > > $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 via rl0 > > > > > # keep these two IRC ports normally open for BNC > > $IPF 50270 allow all from any to any 31337 in > > $IPF 50380 allow all from any to any 31337 out > > [snip -- more allowed ports] > > # deny and log everything > > $IPF 55000 deny log all from any to any > > > > ----- > > > > Here's a dump of ipfw show, with some stuff cut out for space purposes > > (they're just denied DDoS IPs) > > > > [root@nub /etc]# ipfw show > > 00010 61124 16056802 allow ip from any to any via lo0 > > 00020 0 0 deny ip from any to 127.0.0.0/8 > > 00030 0 0 deny ip from 127.0.0.0/8 to any > > 00040 0 0 deny tcp from any to any frag > > 00050 0 0 check-state > > 00060 670616 455926379 allow tcp from any to any established > > 00070 16213 14071853 allow ip from any to any out keep-state > > [snip] > > 50220 468 22464 divert 8668 ip from any to 207.210.114.45 > > dst-port 6667 via rl0 > > 50230 0 0 divert 8668 ip from any to 207.210.114.45 > > dst-port 8067 via rl0 > > 50240 0 0 divert 8668 ip from any to 207.210.114.45 > > dst-port 8068 via rl0 > > 50250 0 0 divert 8668 ip from any to 207.210.114.45 > > dst-port 6697 via rl0 > > 50260 0 0 divert 8668 ip from any to 207.210.114.45 > > dst-port 7000 via rl0 > > 50270 1 60 allow ip from any to any dst-port 31337 in > > 54999 66 3991 allow icmp from any to any > > 55000 4364 343609 deny log logamount 100 ip from any to any > > 65535 29 4176 allow ip from any to any > > > > My natd.conf is as follows: > > > > [root@nub /etc]# cat natd.conf > > # Nub.Core NATd > > verbose > > alias_address 207.210.114.45 > > log > > log_denied > > log_ipfw_denied > > pid_file /var/run/natd.pid > > > > > > ### IRC Redirect Ports > > # 6667 > > > If I understand man natd > > > > redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 207.210.114.45:6667 > > ^^^^^^^^^^^^^ > Trafic is comming from 72.65.73.23 - so the rule don't apply > > > > [root@nub /etc]# > > > > And, as stated above, I am showing connection diverts to natd. When I > > run the following three tcpdumps: > > > > tcpdump -s 0 -w me_to_nat.pcap -vvv -i rl0 src host 72.65.73.23 and > > dst host 207.210.114.45 and dst port 6667 > > tcpdump -s 0 -w nat_to_jail.pcap -vvv -i rl0 src host 72.20.28.202 and > > dst host 207.210.114.45 and dst port 6667 > > tcpdump -s 0 -w jail_to_nat.pcap -vvv -i rl0 src host 207.210.114.45 > > and dst host 72.20.28.202 and src port 6667 > > > > Only the "me_to_nat.pcap" gets any data. The rest are 0 bytes. Example: > > > > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 jail_to_nat.pcap > > -rw-r--r-- 1 root wheel 16384 Mar 21 15:24 me_to_nat.pcap > > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 nat_to_jail.pcap > > > > So, can anyone diagnose and fix this? Thanks. > > > > (P.S.: I'm aware of the DNS methods of doing round-robin, but please > > keep that from this discussion. I need to port-forward round-robin, > > not whole DNS) > > > > > _______________________________________________ > 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" > -- ~ Kage http://vitund.com http://hackthissite.org From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 05:42:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFD6B1065670 for ; Mon, 24 Mar 2008 05:42:44 +0000 (UTC) (envelope-from chengjin@FASTSOFT.COM) Received: from HQ-ES.FASTSOFT.COM (static-71-160-206-130.lsanca.dsl-w.verizon.net [71.160.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id AA0FD8FC12 for ; Mon, 24 Mar 2008 05:42:44 +0000 (UTC) (envelope-from chengjin@FASTSOFT.COM) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 23 Mar 2008 22:29:12 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: novice question: unable to kldunload netgraph.ko Thread-Index: AciNb/4xJRRQLUV/SNuCHYY0DE1LqA== From: "Cheng Jin" To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: novice question: unable to kldunload netgraph.ko 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, 24 Mar 2008 05:42:44 -0000 Hi, =20 I have started to play around with netgraph this weekend, and I am = finding a very strange problem of not being able to kldunload any of the = ng*.ko modules, as well as netgraph.ko itself. =20 I tried on two systems running 5.4-RELEASE and 7.0-RELEASE, and the = result is the same. On both systems, I compiled netgraph after the main = kernel compilation by specifying netgraph on the MODULES_OVERRIDE line = in /etc/make.conf. Not sure if I left some component that netgraph = depends on inside the kernel? =20 I have tried the following with regard to netgraph.ko on both systems. =20 1. plain kldload and following by kldunload. The error message is = device busy. =20 2. sitting in front of the console with no active network connections, i = brought down all ethernet interfaces, tried kldunload, same device busy = error. I tried on a freshly booted system, same problem. =20 3. in front of the console, brought down all ethernet interfaces, tried = kldload followed by kldunload. Same problem. =20 I think at some point, I didnt get the device-busy error message with = kldunload, but netgraph.ko wasnt unloaded either. =20 I tried googling around and looked through all the netgraph related man = pages and netgraph related examples, and it seems that I am the only one = having this problem so I wonder if there was something really simple = thing that I overlooked? =20 Thanks, =20 Cheng =20 --- =20 On the 5.4 system, kldstat shows the following once netgraph.ko is = loaded. It has three ethernet interfaces bge0, bge1, and em0 =20 Id Refs Address Size Name 1 4 0xc0400000 4dd4a8 kernel 2 1 0xc08de000 6d90 dummynet.ko 3 1 0xc2a79000 12000 netgraph.ko =20 On the 7.0 system with fxp0 and em0 =20 Id Refs Address Size Name 1 2 0xffffffff80100000 5e4560 kernel 2 1 0xffffffffc221c000 87d4 netgraph.ko =20 If I try to look at details with ngctl, it loads ng_socket.ko, which = only makes the unloading problem harder! Not sure why the ref count is = 1 almost right away. From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 10:10:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3EBB106564A for ; Mon, 24 Mar 2008 10:10:41 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (unknown [IPv6:2001:41d0:1:2ad2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 383318FC17 for ; Mon, 24 Mar 2008 10:10:41 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:1:2ad2::fffe:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id E39051BAC11; Mon, 24 Mar 2008 11:10:39 +0100 (CET) Received: from morzine.restart.bel (morzine6.restart.bel [IPv6:2001:41d0:1:2ad2::1:2]) (authenticated bits=0) by restart.be (8.14.2/8.14.2) with ESMTP id m2OAAa9A079860; Mon, 24 Mar 2008 11:10:36 +0100 (CET) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1206353439; bh=ixz5YX7dbg4ja0RbKk1VuHAO7M3bpg419O2TT00 kdHQ=; h=Message-ID:Date:From:MIME-Version:To:CC:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Fi6nY9DMQNEy bMxUxkqFguMvpqQeFd48ProCKjDIgkrZ4rIX8fef2o2I0Yo6Jt9gLvKXqKCtBOnLo0I nR8vhFA== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=zyd9dnjvWZtGg5kOFMZw04ALouFy4MEQDIPaEBsuOgDLGb4ZlXOzbafkjiH/j/ri/ ogpAQVfUusR6EIyxE2lmA== Message-ID: <47E77E1C.7090000@restart.be> Date: Mon, 24 Mar 2008 11:10:36 +0100 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.12 (X11/20080316) MIME-Version: 1.0 To: Kage References: <47E50936.1010405@restart.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on IPv6:2001:41d0:1:2ad2::1:1 Cc: freebsd-net@freebsd.org Subject: Re: natd port forward times out, tcpdump yields nothing 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, 24 Mar 2008 10:10:42 -0000 Kage wrote: > Well, no, see it's hitting natd just fine as shown by my natd verbose > logs, if you're assuming ipfw is blocking me from reaching natd. Are > you talking about adding a firewall rule for each of my round-robin > addresses, too? Yes > How would that do any good? All response paquet to a paquet diverted to natd must also be diverted to natd to be reverse translated. eg: incoming request from client (c) to server (s) redirected to server (S) c.c.c.c -> s.s.s.s nated as c.c.c.c -> S.S.S.S must have response paquetd reverse translated: S.S.S.S -> c.c.c.c nated as s.s.s.s -> c.c.c.c to be a valid response to client (c). > > On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert wrote: >> Kage wrote: >> > Hey guys, >> > >> > This is a fun one that's stumped people in Freenode ##freebsd. >> > Basically, I have this layout: >> > >> > irc.domain.com -> DNS A -> IRC Jail >> > >> > When someone connects to irc.domain.com on IRC ports (6667, 8067, >> > etc.), it round-robins them using natd, otherwise it sends all other >> > port requests to the IRC jail as per normal (such as port 80, which is >> > my primary concern). As for having it setup to have ipfw divert to >> > natd, that's done and works, as shown by natd verbose mode: >> > >> > In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 aliased to >> > [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 >> > >> > (For reference) >> > 207.210.114.45 = jail IP >> > 72.20.28.202 = example target IP in the round-robin >> > 72.65.73.23 = my IP >> > >> > Right now, my ipfw.rules file is as follows: >> > >> > [root@nub /etc]# cat ipfw.rules >> > IPF="ipfw -q add" >> > ipfw -f -q flush >> > >> > #loopback >> > $IPF 10 allow all from any to any via lo0 >> > $IPF 20 deny all from any to 127.0.0.0/8 >> > $IPF 30 deny all from 127.0.0.0/8 to any >> > $IPF 40 deny tcp from any to any frag >> > >> > # statefull >> > $IPF 50 check-state >> > $IPF 60 allow tcp from any to any established >> > $IPF 70 allow all from any to any out keep-state >> > $IPF 54999 allow icmp from any to any >> > >> > # Include the deny file >> > . /etc/ipfw.deny >> > >> > [snip -- some allowed ports] >> > # IRC (natd divert for IRC port-forwarding >> > $IPF 50220 divert natd all from any to 207.210.114.45 6667 via rl0 >> > $IPF 50230 divert natd all from any to 207.210.114.45 8067 via rl0 >> > $IPF 50240 divert natd all from any to 207.210.114.45 8068 via rl0 >> > $IPF 50250 divert natd all from any to 207.210.114.45 6697 via rl0 >> > $IPF 50260 divert natd all from any to 207.210.114.45 7000 via rl0 >> >> >> You must also divert the response trafic AFAIK eg: >> >> $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 via rl0 >> >> >> >> > # keep these two IRC ports normally open for BNC >> > $IPF 50270 allow all from any to any 31337 in >> > $IPF 50380 allow all from any to any 31337 out >> > [snip -- more allowed ports] >> > # deny and log everything >> > $IPF 55000 deny log all from any to any >> > >> > ----- >> > >> > Here's a dump of ipfw show, with some stuff cut out for space purposes >> > (they're just denied DDoS IPs) >> > >> > [root@nub /etc]# ipfw show >> > 00010 61124 16056802 allow ip from any to any via lo0 >> > 00020 0 0 deny ip from any to 127.0.0.0/8 >> > 00030 0 0 deny ip from 127.0.0.0/8 to any >> > 00040 0 0 deny tcp from any to any frag >> > 00050 0 0 check-state >> > 00060 670616 455926379 allow tcp from any to any established >> > 00070 16213 14071853 allow ip from any to any out keep-state >> > [snip] >> > 50220 468 22464 divert 8668 ip from any to 207.210.114.45 >> > dst-port 6667 via rl0 >> > 50230 0 0 divert 8668 ip from any to 207.210.114.45 >> > dst-port 8067 via rl0 >> > 50240 0 0 divert 8668 ip from any to 207.210.114.45 >> > dst-port 8068 via rl0 >> > 50250 0 0 divert 8668 ip from any to 207.210.114.45 >> > dst-port 6697 via rl0 >> > 50260 0 0 divert 8668 ip from any to 207.210.114.45 >> > dst-port 7000 via rl0 >> > 50270 1 60 allow ip from any to any dst-port 31337 in >> > 54999 66 3991 allow icmp from any to any >> > 55000 4364 343609 deny log logamount 100 ip from any to any >> > 65535 29 4176 allow ip from any to any >> > >> > My natd.conf is as follows: >> > >> > [root@nub /etc]# cat natd.conf >> > # Nub.Core NATd >> > verbose >> > alias_address 207.210.114.45 >> > log >> > log_denied >> > log_ipfw_denied >> > pid_file /var/run/natd.pid >> > >> > >> > ### IRC Redirect Ports >> > # 6667 >> >> >> If I understand man natd >> >> >>> redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 207.210.114.45:6667 >> ^^^^^^^^^^^^^ >> Trafic is comming from 72.65.73.23 - so the rule don't apply >> >> >>> [root@nub /etc]# >> > >> > And, as stated above, I am showing connection diverts to natd. When I >> > run the following three tcpdumps: >> > >> > tcpdump -s 0 -w me_to_nat.pcap -vvv -i rl0 src host 72.65.73.23 and >> > dst host 207.210.114.45 and dst port 6667 >> > tcpdump -s 0 -w nat_to_jail.pcap -vvv -i rl0 src host 72.20.28.202 and >> > dst host 207.210.114.45 and dst port 6667 >> > tcpdump -s 0 -w jail_to_nat.pcap -vvv -i rl0 src host 207.210.114.45 >> > and dst host 72.20.28.202 and src port 6667 >> > >> > Only the "me_to_nat.pcap" gets any data. The rest are 0 bytes. Example: >> > >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 jail_to_nat.pcap >> > -rw-r--r-- 1 root wheel 16384 Mar 21 15:24 me_to_nat.pcap >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 nat_to_jail.pcap >> > >> > So, can anyone diagnose and fix this? Thanks. >> > >> > (P.S.: I'm aware of the DNS methods of doing round-robin, but please >> > keep that from this discussion. I need to port-forward round-robin, >> > not whole DNS) >> > >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 11:01:27 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9313E1065675; Mon, 24 Mar 2008 11:01:27 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5D78FC1B; Mon, 24 Mar 2008 11:01:27 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2OB1R3L086748; Mon, 24 Mar 2008 11:01:27 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2OB1RgL086744; Mon, 24 Mar 2008 11:01:27 GMT (envelope-from remko) Date: Mon, 24 Mar 2008 11:01:27 GMT Message-Id: <200803241101.m2OB1RgL086744@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/122033: [ral] Lock order reversal in ral0 at bootup (regression) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 11:01:27 -0000 Synopsis: [ral] Lock order reversal in ral0 at bootup (regression) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Mar 24 11:01:07 UTC 2008 Responsible-Changed-Why: Send to -net team, this is a nic. http://www.freebsd.org/cgi/query-pr.cgi?pr=122033 From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 11:07:10 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F9E210656D5 for ; Mon, 24 Mar 2008 11:07:10 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7E3498FC18 for ; Mon, 24 Mar 2008 11:07:10 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2OB7Aac087869 for ; Mon, 24 Mar 2008 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2OB793m087865 for freebsd-net@FreeBSD.org; Mon, 24 Mar 2008 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Mar 2008 11:07:09 GMT Message-Id: <200803241107.m2OB793m087865@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 11:07:10 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/81147 net [net] [patch] em0 reinitialization while adding aliase s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument (regress o kern/92090 net [bge] bge0: watchdog timeout -- resetting f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast f kern/116172 net [tun] [panic] Network / ipv6 recursive mutex panic o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash (regression) o kern/118880 net [ipv6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card (regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time f kern/120725 net [bce] On board second lan port 'bce1' with Broadcom Ne f kern/120966 net [rum]: kernel panic with if_rum and WPA encryption o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121555 net Fatal trap 12: current process = 12 (swi1: net) o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/122033 net [ral] Lock order reversal in ral0 at bootup (regressio 45 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 o kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o bin/79228 net [patch] extend /sbin/arp to be able to create blackhol o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/95267 net packet drops periodically appear o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112179 net [sis] [patch] sis driver for natsemi DP83815D autonego o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o bin/117339 net [patch] route(8): loading routing management commands o kern/118727 net [ng] [patch] [request] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118975 net [bge] [patch] Broadcom 5906 not handled by FreeBSD o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120958 net no response to ICMP traffic on interface configured wi o kern/121242 net [ate] [patch] Promiscuous mode of if_ate (arm) doesn't o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net 35 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 12:45:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92DE41065673 for ; Mon, 24 Mar 2008 12:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6048FC26 for ; Mon, 24 Mar 2008 12:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id F1D8F41C75C; Mon, 24 Mar 2008 13:45:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id vmLVUgcgbH74; Mon, 24 Mar 2008 13:45:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 9CE0B41C75B; Mon, 24 Mar 2008 13:45:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 9AA0744487F; Mon, 24 Mar 2008 12:41:09 +0000 (UTC) Date: Mon, 24 Mar 2008 12:41:09 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: blue In-Reply-To: <46B044E9.50404@zyxel.com.tw> Message-ID: <20080324103345.K50685@maildrop.int.zabbadoz.net> References: <46B044E9.50404@zyxel.com.tw> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: IPsec AH tunneling pakcet mis-handling? 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, 24 Mar 2008 12:45:07 -0000 On Wed, 1 Aug 2007, blue wrote: Hi, > Dear all: > > I do not know the purpose of the following codes in the very beginning in > ip6_input(): > > #ifdef IPSEC > /* > * should the inner packet be considered authentic? > * see comment in ah4_input(). > */ > if (m) { > m->m_flags &= ~M_AUTHIPHDR; > m->m_flags &= ~M_AUTHIPDGM; > } > #endif > > Consider the case: a packet is encrypted as AH tunneled, and FreeBSD is the > end point of the tunnel. After it tore off the outer IPv6 header, the mbuf > will be inserted to NETISR again. Then ip6_forward() will be called again to > process the packet. However, in ipsec6_in_reject(), the packet's source and > destination will match the SP entry. Since ip6_input() has truned off the > flag M_AUTHIPHDR and M_AUTHIPDGM, the packet will be dropped. > > I don't think with the codes AH tunnel could work properly. I was pointed at this. I am a bit unsure about your setup as you are talking about "AH tunneled" and "encrypted" while at the end it's "AH tunnel" only. So, are you using IPsec tunnel mode with ESP and AH or just AH, or ...? Can you describe the setup this would be a problem in detail and maybe file a PR so this won't be lost again. We've got other ESP+AH+IPv6 problems pending like PR kern/121373 and I could look into both at the same time I guess. PS: I am assuming this was with (Fast) IPsec, not KAME IPsec implementation? The date was too close to the change, so I thought it might be better asking;-) Thanks /bz -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 13:22:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E254E106564A for ; Mon, 24 Mar 2008 13:22:22 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9069F8FC14 for ; Mon, 24 Mar 2008 13:22:22 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from ZyTWBE03.ZyXEL.com ([172.23.5.49]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Mar 2008 21:10:17 +0800 Received: from zytwfe01.zyxel.com ([172.23.5.5]) by ZyTWBE03.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Mar 2008 21:10:17 +0800 Received: from [172.23.17.24] ([172.23.17.24]) by zytwfe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Mar 2008 21:10:17 +0800 Message-ID: <47E7A7C5.2090509@zyxel.com.tw> Date: Mon, 24 Mar 2008 21:08:21 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <46B044E9.50404@zyxel.com.tw> <20080324103345.K50685@maildrop.int.zabbadoz.net> In-Reply-To: <20080324103345.K50685@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Mar 2008 13:10:17.0101 (UTC) FILETIME=[678B6BD0:01C88DB0] Cc: freebsd-net@freebsd.org Subject: Re: IPsec AH tunneling pakcet mis-handling? 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, 24 Mar 2008 13:22:23 -0000 Sorry, maybe my words make you confused. What I meant is "AH tunnel" only, and the code base is FAST_IPSEC, which is currently IPSEC in FreeBSD-7.0. BR, Yi-Wen Bjoern A. Zeeb wrote: > On Wed, 1 Aug 2007, blue wrote: > > Hi, > > >> Dear all: >> >> I do not know the purpose of the following codes in the very >> beginning in ip6_input(): >> >> #ifdef IPSEC >> /* >> * should the inner packet be considered authentic? >> * see comment in ah4_input(). >> */ >> if (m) { >> m->m_flags &= ~M_AUTHIPHDR; >> m->m_flags &= ~M_AUTHIPDGM; >> } >> #endif >> >> Consider the case: a packet is encrypted as AH tunneled, and FreeBSD >> is the end point of the tunnel. After it tore off the outer IPv6 >> header, the mbuf will be inserted to NETISR again. Then ip6_forward() >> will be called again to process the packet. However, in >> ipsec6_in_reject(), the packet's source and destination will match >> the SP entry. Since ip6_input() has truned off the flag M_AUTHIPHDR >> and M_AUTHIPDGM, the packet will be dropped. >> >> I don't think with the codes AH tunnel could work properly. > > > I was pointed at this. > > I am a bit unsure about your setup as you are talking about "AH > tunneled" and "encrypted" while at the end it's "AH tunnel" only. > So, are you using IPsec tunnel mode with ESP and AH or just AH, or ...? > > Can you describe the setup this would be a problem in detail and maybe > file a PR so this won't be lost again. > > We've got other ESP+AH+IPv6 problems pending like PR kern/121373 and I > could look into both at the same time I guess. > > PS: I am assuming this was with (Fast) IPsec, not KAME IPsec > implementation? The date was too close to the change, so I thought it > might be better asking;-) > > Thanks > /bz > From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 14:15:52 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4E881065670; Mon, 24 Mar 2008 14:15:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7753A8FC13; Mon, 24 Mar 2008 14:15:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4E55746C0D; Mon, 24 Mar 2008 10:15:51 -0400 (EDT) Date: Mon, 24 Mar 2008 14:15:51 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Christian S.J. Peron" In-Reply-To: <20080324140623.GA14941@sub.vaned.net> Message-ID: <20080324141334.T7797@fledge.watson.org> References: <20080317133029.GA19369@sub.vaned.net> <20080317134335.A3253@fledge.watson.org> <20080324140623.GA14941@sub.vaned.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, freebsd-current@freebsd.org, net@freebsd.org Subject: Re: HEADS UP: zerocopy bpf commits impending 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, 24 Mar 2008 14:15:53 -0000 On Mon, 24 Mar 2008, Christian S.J. Peron wrote: > I just want everyone to know that I have completed the zerocopy bpf commit. > Please be on the "lookout" for any strange bpf related issues. > > For people that want to test the new zerocopy bpf implementation, a patch > can be found here: > > http://people.freebsd.org/~csjp/pcap.1206364304.diff > > Any comments, patches etc can be sent to Robert Watson (rwatson@) or myself. FYI, right now there is a known issue in which only one of the two BPF buffers can be owned by user processes at a time. As a result, when acking one buffer, it's almost always the case that userspace will enter select() even though another buffer is essentially ready, leading to a system call being generated for each buffer even though that's undesirable. I'm working on some changing allowing both buffers to be owned by userspace at a time, but it will be a couple of weeks before that enters CVS. I believe that the current libpcap patches should keep working with that fine, although of course, we'll see. :-) The bpf.4 documentation is very careful to warn that applications should not assume that there are any invariants about the number of buffers assigned to userspace at a time. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 14:24:28 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2919106566C for ; Mon, 24 Mar 2008 14:24:28 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id A6BA08FC21 for ; Mon, 24 Mar 2008 14:24:28 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id E6F6B2E1; Mon, 24 Mar 2008 09:06:23 -0500 (CDT) Date: Mon, 24 Mar 2008 09:06:23 -0500 From: "Christian S.J. Peron" To: Robert Watson Message-ID: <20080324140623.GA14941@sub.vaned.net> References: <20080317133029.GA19369@sub.vaned.net> <20080317134335.A3253@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080317134335.A3253@fledge.watson.org> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org, freebsd-current@freebsd.org, "Christian S.J. Peron" , net@freebsd.org Subject: Re: HEADS UP: zerocopy bpf commits impending 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, 24 Mar 2008 14:24:28 -0000 I just want everyone to know that I have completed the zerocopy bpf commit. Please be on the "lookout" for any strange bpf related issues. For people that want to test the new zerocopy bpf implementation, a patch can be found here: http://people.freebsd.org/~csjp/pcap.1206364304.diff Any comments, patches etc can be sent to Robert Watson (rwatson@) or myself. Thanks! From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 14:53:37 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7066106566B; Mon, 24 Mar 2008 14:53:37 +0000 (UTC) (envelope-from petri@helenius.fi) Received: from silver.he.iki.fi (helenius.fi [83.150.107.219]) by mx1.freebsd.org (Postfix) with ESMTP id 5C5158FC18; Mon, 24 Mar 2008 14:53:37 +0000 (UTC) (envelope-from petri@helenius.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id 69359DF49; Mon, 24 Mar 2008 16:31:00 +0200 (EET) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymvqJQKR1Yfl; Mon, 24 Mar 2008 16:30:53 +0200 (EET) Received: from [83.150.107.194] (d194.helenius.fi [83.150.107.194]) by silver.he.iki.fi (Postfix) with ESMTP; Mon, 24 Mar 2008 16:30:53 +0200 (EET) Message-ID: <47E7BB1C.4020703@helenius.fi> Date: Mon, 24 Mar 2008 16:30:52 +0200 From: Petri Helenius User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Robert Watson References: <20080317133029.GA19369@sub.vaned.net> <20080317134335.A3253@fledge.watson.org> <20080324140623.GA14941@sub.vaned.net> <20080324141334.T7797@fledge.watson.org> In-Reply-To: <20080324141334.T7797@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, freebsd-current@freebsd.org, net@freebsd.org Subject: Re: HEADS UP: zerocopy bpf commits impending 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, 24 Mar 2008 14:53:38 -0000 Pardon the basic question, but is the current patchset "zero copy" or "one copy"? The paper I saw a link to described a mechanism to eliminate one of the two copies the traditional bpf approach makes but I haven't taken a look into the actual code. Pete From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 15:26:37 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17BE2106566B; Mon, 24 Mar 2008 15:26:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id B22198FC21; Mon, 24 Mar 2008 15:26:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 9388746B0C; Mon, 24 Mar 2008 11:26:35 -0400 (EDT) Date: Mon, 24 Mar 2008 15:26:35 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Petri Helenius In-Reply-To: <47E7BB1C.4020703@helenius.fi> Message-ID: <20080324151814.Y12107@fledge.watson.org> References: <20080317133029.GA19369@sub.vaned.net> <20080317134335.A3253@fledge.watson.org> <20080324140623.GA14941@sub.vaned.net> <20080324141334.T7797@fledge.watson.org> <47E7BB1C.4020703@helenius.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, freebsd-current@freebsd.org, net@freebsd.org Subject: Re: HEADS UP: zerocopy bpf commits impending 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, 24 Mar 2008 15:26:37 -0000 On Mon, 24 Mar 2008, Petri Helenius wrote: > Pardon the basic question, but is the current patchset "zero copy" or "one > copy"? The paper I saw a link to described a mechanism to eliminate one of > the two copies the traditional bpf approach makes but I haven't taken a look > into the actual code. The short answer is "one-copy". This eliminates the copy between the kernel and user space, but not the possibility of in-kernel copying. In practice, that in-kernel copying is frequently desirable as: (1) It allows packing of headers into a buffer when a small snaplen is used, which greatly reduces memory overhead when capturing, for example, just TCP headers and not payloads. (2) It allows us to more easily maintain independence between separate BPF sessions, and in particular, to avoid leaking memory between kernel, userspace, and different BPF consumers. If doing full capture of all packet data to userspace, the approach we took would improve performance, but would still involve one full copy of packet data in kernel. Further work would be required to eliminate that copy. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 16:04:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 485721065676 for ; Mon, 24 Mar 2008 16:04:36 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by mx1.freebsd.org (Postfix) with ESMTP id B35528FC30 for ; Mon, 24 Mar 2008 16:04:34 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: by ti-out-0910.google.com with SMTP id j2so678116tid.3 for ; Mon, 24 Mar 2008 09:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=oVzNHRVF3M02oYdv+ebbtMa037W6DuJLjdmEwDtmG3w=; b=LS/Cj/b89MfljaAMwmInVaUe8ZdmsUQvVlkirog3OY0vSMEFAtGpY5kV8n8sD3xfzxPHYIj4mgIcprwxBqQWwi4ar89zeGggTCz0pRv7FnJ+sxrxdLtKjduN1S4og8OK4ovTLLSZQakvovBp11MM8u9FuMuANo4YuBlE3pF3xh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VE4CiWbe8wfU5KWecfaSCTZ1xqIR1a4wVO06M6izNV1BYdbKT8DWz6cGXqnHFJIVxsGTFX+7HdIaiFkVY/Z2CtnDup0eiE/VKYcxEsFVuQsPfI2UWiNo+maLmltsVR1ZFmx/+dbS3JJpwuEj2B6R4LXTcn8uSubs3q3RKG5o4YY= Received: by 10.110.62.14 with SMTP id k14mr1586010tia.5.1206374672845; Mon, 24 Mar 2008 09:04:32 -0700 (PDT) Received: by 10.70.48.17 with HTTP; Mon, 24 Mar 2008 09:04:32 -0700 (PDT) Message-ID: Date: Mon, 24 Mar 2008 12:04:32 -0400 From: Kage To: "Henri Hennebert" , freebsd-net@freebsd.org In-Reply-To: <47E77E1C.7090000@restart.be> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47E50936.1010405@restart.be> <47E77E1C.7090000@restart.be> Cc: Subject: Re: natd port forward times out, tcpdump yields nothing 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, 24 Mar 2008 16:04:36 -0000 Still not working, but I DO have natd aliasing properly. Here's my natd output (remember which IP is mine, the IRC jail, and the example round-robin IP): [root@nub /etc]# natd -f /etc/natd.conf In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 72...23 (me) is hitting the natd on the jail IP (207...45), which is getting correctly aliased to 72...202 (example round-robin IP). So it appears the natd is working properly. Here's my natd configuration as it exists now: # Nub.Core NATd verbose alias_address 207.210.114.45 log log_denied log_ipfw_denied pid_file /var/run/natd.pid ### IRC Redirect Ports # 6667 redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 And for more record, here's my ipfw.rules file up until the divert: [root@nub /etc]# cat ipfw.rules IPF="ipfw -q add" ipfw -f -q flush #loopback $IPF 10 allow all from any to any via lo0 $IPF 20 deny all from any to 127.0.0.0/8 $IPF 30 deny all from 127.0.0.0/8 to any $IPF 40 deny tcp from any to any frag # statefull $IPF 50 check-state $IPF 60 allow tcp from any to any established $IPF 70 allow all from any to any out keep-state $IPF 54999 allow icmp from any to any [snip -- Some allowed ports (port 80, 443, etc.), and some denied IPs] # IRC (natd divert for IRC port-forwarding $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 6667 via rl0 $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0 Any attempt to connect to the IRC jail IP thus far, though, still fails with a "connection timed out." Thanks for your help thus far. Any additional ideas? On Mon, Mar 24, 2008 at 6:10 AM, Henri Hennebert wrote: > Kage wrote: > > Well, no, see it's hitting natd just fine as shown by my natd verbose > > logs, if you're assuming ipfw is blocking me from reaching natd. Are > > you talking about adding a firewall rule for each of my round-robin > > addresses, too? > > Yes > > > > How would that do any good? > > All response paquet to a paquet diverted to natd must also be diverted > to natd to be reverse translated. eg: > > incoming request from client (c) to server (s) redirected to server (S) > > c.c.c.c -> s.s.s.s nated as c.c.c.c -> S.S.S.S > > must have response paquetd reverse translated: > > S.S.S.S -> c.c.c.c nated as s.s.s.s -> c.c.c.c > > to be a valid response to client (c). > > > > > > > On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert wrote: > >> Kage wrote: > >> > Hey guys, > >> > > >> > This is a fun one that's stumped people in Freenode ##freebsd. > >> > Basically, I have this layout: > >> > > >> > irc.domain.com -> DNS A -> IRC Jail > >> > > >> > When someone connects to irc.domain.com on IRC ports (6667, 8067, > >> > etc.), it round-robins them using natd, otherwise it sends all other > >> > port requests to the IRC jail as per normal (such as port 80, which is > >> > my primary concern). As for having it setup to have ipfw divert to > >> > natd, that's done and works, as shown by natd verbose mode: > >> > > >> > In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 aliased to > >> > [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 > >> > > >> > (For reference) > >> > 207.210.114.45 = jail IP > >> > 72.20.28.202 = example target IP in the round-robin > >> > 72.65.73.23 = my IP > >> > > >> > Right now, my ipfw.rules file is as follows: > >> > > >> > [root@nub /etc]# cat ipfw.rules > >> > IPF="ipfw -q add" > >> > ipfw -f -q flush > >> > > >> > #loopback > >> > $IPF 10 allow all from any to any via lo0 > >> > $IPF 20 deny all from any to 127.0.0.0/8 > >> > $IPF 30 deny all from 127.0.0.0/8 to any > >> > $IPF 40 deny tcp from any to any frag > >> > > >> > # statefull > >> > $IPF 50 check-state > >> > $IPF 60 allow tcp from any to any established > >> > $IPF 70 allow all from any to any out keep-state > >> > $IPF 54999 allow icmp from any to any > >> > > >> > # Include the deny file > >> > . /etc/ipfw.deny > >> > > >> > [snip -- some allowed ports] > >> > # IRC (natd divert for IRC port-forwarding > >> > $IPF 50220 divert natd all from any to 207.210.114.45 6667 via rl0 > >> > $IPF 50230 divert natd all from any to 207.210.114.45 8067 via rl0 > >> > $IPF 50240 divert natd all from any to 207.210.114.45 8068 via rl0 > >> > $IPF 50250 divert natd all from any to 207.210.114.45 6697 via rl0 > >> > $IPF 50260 divert natd all from any to 207.210.114.45 7000 via rl0 > >> > >> > >> You must also divert the response trafic AFAIK eg: > >> > >> $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 via rl0 > >> > >> > >> > >> > # keep these two IRC ports normally open for BNC > >> > $IPF 50270 allow all from any to any 31337 in > >> > $IPF 50380 allow all from any to any 31337 out > >> > [snip -- more allowed ports] > >> > # deny and log everything > >> > $IPF 55000 deny log all from any to any > >> > > >> > ----- > >> > > >> > Here's a dump of ipfw show, with some stuff cut out for space purposes > >> > (they're just denied DDoS IPs) > >> > > >> > [root@nub /etc]# ipfw show > >> > 00010 61124 16056802 allow ip from any to any via lo0 > >> > 00020 0 0 deny ip from any to 127.0.0.0/8 > >> > 00030 0 0 deny ip from 127.0.0.0/8 to any > >> > 00040 0 0 deny tcp from any to any frag > >> > 00050 0 0 check-state > >> > 00060 670616 455926379 allow tcp from any to any established > >> > 00070 16213 14071853 allow ip from any to any out keep-state > >> > [snip] > >> > 50220 468 22464 divert 8668 ip from any to 207.210.114.45 > >> > dst-port 6667 via rl0 > >> > 50230 0 0 divert 8668 ip from any to 207.210.114.45 > >> > dst-port 8067 via rl0 > >> > 50240 0 0 divert 8668 ip from any to 207.210.114.45 > >> > dst-port 8068 via rl0 > >> > 50250 0 0 divert 8668 ip from any to 207.210.114.45 > >> > dst-port 6697 via rl0 > >> > 50260 0 0 divert 8668 ip from any to 207.210.114.45 > >> > dst-port 7000 via rl0 > >> > 50270 1 60 allow ip from any to any dst-port 31337 in > >> > 54999 66 3991 allow icmp from any to any > >> > 55000 4364 343609 deny log logamount 100 ip from any to any > >> > 65535 29 4176 allow ip from any to any > >> > > >> > My natd.conf is as follows: > >> > > >> > [root@nub /etc]# cat natd.conf > >> > # Nub.Core NATd > >> > verbose > >> > alias_address 207.210.114.45 > >> > log > >> > log_denied > >> > log_ipfw_denied > >> > pid_file /var/run/natd.pid > >> > > >> > > >> > ### IRC Redirect Ports > >> > # 6667 > >> > >> > >> If I understand man natd > >> > >> > >>> redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 207.210.114.45:6667 > >> ^^^^^^^^^^^^^ > >> Trafic is comming from 72.65.73.23 - so the rule don't apply > >> > >> > >>> [root@nub /etc]# > >> > > >> > And, as stated above, I am showing connection diverts to natd. When I > >> > run the following three tcpdumps: > >> > > >> > tcpdump -s 0 -w me_to_nat.pcap -vvv -i rl0 src host 72.65.73.23 and > >> > dst host 207.210.114.45 and dst port 6667 > >> > tcpdump -s 0 -w nat_to_jail.pcap -vvv -i rl0 src host 72.20.28.202 and > >> > dst host 207.210.114.45 and dst port 6667 > >> > tcpdump -s 0 -w jail_to_nat.pcap -vvv -i rl0 src host 207.210.114.45 > >> > and dst host 72.20.28.202 and src port 6667 > >> > > >> > Only the "me_to_nat.pcap" gets any data. The rest are 0 bytes. Example: > >> > > >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 jail_to_nat.pcap > >> > -rw-r--r-- 1 root wheel 16384 Mar 21 15:24 me_to_nat.pcap > >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 nat_to_jail.pcap > >> > > >> > So, can anyone diagnose and fix this? Thanks. > >> > > >> > (P.S.: I'm aware of the DNS methods of doing round-robin, but please > >> > keep that from this discussion. I need to port-forward round-robin, > >> > not whole DNS) > >> > > >> > >> > >> _______________________________________________ > >> 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" > >> > > > > > > > > -- ~ Kage http://vitund.com http://hackthissite.org From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 17:24:34 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 680BD1065671 for ; Mon, 24 Mar 2008 17:24:34 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by mx1.freebsd.org (Postfix) with ESMTP id 1F2DE8FC21 for ; Mon, 24 Mar 2008 17:24:34 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so3439674waf.3 for ; Mon, 24 Mar 2008 10:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=mKW+853S/9Vv5He/4fPrRNT3zKlYK245TSi4CjTTBWU=; b=YORNVaxtqe+3j3eiyvBdoNqYOcGZAbCWVEgSE9AlAtkjwYxwPjOavARRbm6+VuqxRL4O1JFfqMYfsI+/vvqSCclLGI1s+LoNd2W37HuEl3bS6Mx1DohbeKuTlz1P0BKSe6Gi/xMeIrs8XeuVAXiqCuy3HJcTk5/llGnu39e/eE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kTsU6UXm242ARCjrBWVoXFDKldmI9TgU2GmXyDHletNVxiM+oogBlsyMy8EZ0i2SeUfLDYuJvTsNp0qd2HRbObM9jYZ6XlyOtuWAuVNv/44PiC9/MHZyRpvQFEsmvcfuaycdaaZjg0rmWn++ztpxx/a5lOpA2GSIASfcRNWqS2M= Received: by 10.114.132.5 with SMTP id f5mr5753338wad.125.1206377788664; Mon, 24 Mar 2008 09:56:28 -0700 (PDT) Received: by 10.114.155.19 with HTTP; Mon, 24 Mar 2008 09:56:28 -0700 (PDT) Message-ID: Date: Mon, 24 Mar 2008 09:56:28 -0700 From: "Freddie Cash" To: net@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200803191334.54510.fjwcash@gmail.com> <47E17BF9.1030403@elischer.org> <200803191355.54288.fjwcash@gmail.com> Cc: Subject: Re: "established" on { tcp or udp } rules 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, 24 Mar 2008 17:24:34 -0000 On Thu, Mar 20, 2008 at 2:03 AM, Vadim Goncharov wrote: > This is behaviour of ipfw2 - options are independently ANDed. Thus, man page > explicitly says: > > established > Matches TCP packets that have the RST or ACK bits set. > > So, it is obvious that udp packet will not match and thus entire rule will not > match. Yeah, it's just weird that it lets you write a rule that will never match. I'll have to fire up FreeBSD 4.11 (and possibly earlier with just ipfw1) in a VM and check things there. I'm sure back in the 4.x days that ipfw would error out if you wrote a UDP rule with TCP options at the end, as that is what got me in the habit of writing separate UDP and TCP rules. Now that I found the { udp or tcp } syntax, I was rewriting some rules on a test firewall and noticed that it would accept TCP option even if udp was listed. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 18:30:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61EEB106566C for ; Mon, 24 Mar 2008 18:30:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id EC1888FC35 for ; Mon, 24 Mar 2008 18:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id A8C4B41C749; Mon, 24 Mar 2008 19:30:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id fXvbBk+lfj+E; Mon, 24 Mar 2008 19:30:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 4E68E41C75B; Mon, 24 Mar 2008 19:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5A3CD44487F; Mon, 24 Mar 2008 18:25:44 +0000 (UTC) Date: Mon, 24 Mar 2008 18:25:43 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: blue In-Reply-To: <47E7A7C5.2090509@zyxel.com.tw> Message-ID: <20080324182452.B50685@maildrop.int.zabbadoz.net> References: <46B044E9.50404@zyxel.com.tw> <20080324103345.K50685@maildrop.int.zabbadoz.net> <47E7A7C5.2090509@zyxel.com.tw> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: IPsec AH tunneling pakcet mis-handling? 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, 24 Mar 2008 18:30:08 -0000 On Mon, 24 Mar 2008, blue wrote: Hi, > Sorry, maybe my words make you confused. > > What I meant is "AH tunnel" only, and the code base is FAST_IPSEC, which is > currently IPSEC in FreeBSD-7.0. thanks for the clarification. Can you open a PR with all this information so a) it woon't be lost and b) you'll get feedback. Get it assigned to bz@ Thanks > BR, > Yi-Wen > > Bjoern A. Zeeb wrote: > >> On Wed, 1 Aug 2007, blue wrote: >> >> Hi, >> >> >>> Dear all: >>> >>> I do not know the purpose of the following codes in the very beginning in >>> ip6_input(): >>> >>> #ifdef IPSEC >>> /* >>> * should the inner packet be considered authentic? >>> * see comment in ah4_input(). >>> */ >>> if (m) { >>> m->m_flags &= ~M_AUTHIPHDR; >>> m->m_flags &= ~M_AUTHIPDGM; >>> } >>> #endif >>> >>> Consider the case: a packet is encrypted as AH tunneled, and FreeBSD is >>> the end point of the tunnel. After it tore off the outer IPv6 header, the >>> mbuf will be inserted to NETISR again. Then ip6_forward() will be called >>> again to process the packet. However, in ipsec6_in_reject(), the packet's >>> source and destination will match the SP entry. Since ip6_input() has >>> truned off the flag M_AUTHIPHDR and M_AUTHIPDGM, the packet will be >>> dropped. >>> >>> I don't think with the codes AH tunnel could work properly. >> >> >> I was pointed at this. >> >> I am a bit unsure about your setup as you are talking about "AH >> tunneled" and "encrypted" while at the end it's "AH tunnel" only. >> So, are you using IPsec tunnel mode with ESP and AH or just AH, or ...? >> >> Can you describe the setup this would be a problem in detail and maybe >> file a PR so this won't be lost again. >> >> We've got other ESP+AH+IPv6 problems pending like PR kern/121373 and I >> could look into both at the same time I guess. >> >> PS: I am assuming this was with (Fast) IPsec, not KAME IPsec >> implementation? The date was too close to the change, so I thought it >> might be better asking;-) >> >> Thanks >> /bz >> > -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 18:40:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 679FF1065676 for ; Mon, 24 Mar 2008 18:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 17D468FC2B for ; Mon, 24 Mar 2008 18:40:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2OIe36t034723 for ; Mon, 24 Mar 2008 18:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2OIe3AN034722; Mon, 24 Mar 2008 18:40:03 GMT (envelope-from gnats) Date: Mon, 24 Mar 2008 18:40:03 GMT Message-Id: <200803241840.m2OIe3AN034722@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Norbert Papke Cc: Subject: Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Norbert Papke List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 18:40:04 -0000 The following reply was made to PR kern/116077; it has been noted by GNATS. From: Norbert Papke To: bug-followup@freebsd.org, rse@freebsd.org Cc: Subject: Re: kern/116077: 6.2-STABLE panic during use of multi-cast networking client Date: Mon, 24 Mar 2008 10:29:51 -0700 I have applied the commit and retested by 1) restarting multi-cast clients and 2) rebooting the system. I have not been able to reproduce the failure. The commit fixes the problem for me. Thanks! -- Norbert Papke. From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 18:43:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D79A61065670 for ; Mon, 24 Mar 2008 18:43:22 +0000 (UTC) (envelope-from wcglist@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by mx1.freebsd.org (Postfix) with ESMTP id 630F18FC14 for ; Mon, 24 Mar 2008 18:43:22 +0000 (UTC) (envelope-from wcglist@gmail.com) Received: by el-out-1112.google.com with SMTP id v27so1265452ele.12 for ; Mon, 24 Mar 2008 11:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=DclCvxUFafhUUbjkgkYpzQNRPFb5jPFddoOjXl3Pryg=; b=d94DrfhrkF/pXBCnDxJKmacx6Ylr3UrRGKV1Zo38feIRIlTIEJBRBbWbg//EL/5lIZNf3rzDrPJ6HJeoFECObTg7HOmluzKR9MWbbiBQi4goT8E9Y6izaP+TjBWT9YK4YasW5oGM1VnfLjhZHF98zm98BKD2acHQymL94jN3TkU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=f7IAKt30FB1PUfSnBiGH47XAbMpv8YKzuZPWPq/Odalzf9+aDQXDD2zDpBZSyZBRRu32XMWYn2VBUVyO8QSXvMRPgb4S8otLmRX7YtzlfNfMmxqLSVoN/WvxVnBG20iY5IRBMfmXNGki3nx5QQtjh1SRuYJo3ld4Tm3naH4fMEY= Received: by 10.141.20.7 with SMTP id x7mr2449348rvi.255.1206384200569; Mon, 24 Mar 2008 11:43:20 -0700 (PDT) Received: by 10.141.123.18 with HTTP; Mon, 24 Mar 2008 11:43:20 -0700 (PDT) Message-ID: Date: Mon, 24 Mar 2008 15:43:20 -0300 From: Wesley To: freebsd-net@freebsd.org In-Reply-To: <47E25F45.8010805@moneybookers.com> MIME-Version: 1.0 References: <47E25F45.8010805@moneybookers.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: route-to not working 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, 24 Mar 2008 18:43:23 -0000 Stephan, I tried to use your example, but the packet is replying to wrong interface.... Do you think that it's a bug? Best regards, Wesley On Thu, Mar 20, 2008 at 9:57 AM, Stefan Lambrev < stefan.lambrev@moneybookers.com> wrote: > Greetings, > > > Wesley wrote: > > Dear people, > > > > I have 2 links on a box, and I don't want to load balance it but, only > to > > reply requests in the same interface that it comes. > > > > I tried to use the route-to, but it not seems to work. > > > > Could you please, give-me a help? > > > I do not see where you use "reply-to" in you configuration > > But here is working example which you can improve off course. > > #dual home > pass in on $ext_if1 reply-to ($ext_if1 $gw1) from any to $external_addr1 > keep state > pass out on $ext_if2 route-to ($ext_if1 $gw1) from $external_addr1 to any > pass in on $ext_if2 reply-to ($ext_if2 $gw2) from any to $external_addr2 > keep state > pass out on $ext_if1 route-to ($ext_if2 $gw1) from $external_addr2 to any > > #dual home ssh only > pass out on $ext_if2 route-to ($ext_if1 $gw1) from $external_addr1 to any > pass out on $ext_if1 route-to ($ext_if2 $gw1) from $external_addr2 to any > pass in on $ext_if1 reply-to ($ext_if1 $gw1) proto tcp from any to > $external_addr1 port 22 keep state > pass in on $ext_if2 reply-to ($ext_if2 $gw2) proto tcp from any to > $external_addr2 port 22 keep state > > It's my configuration: > > > > set skip on lo0 > > scrub on xl0 reassemble tcp no-df random-id > > scrub on xl1 reassemble tcp no-df random-id > > scrub on dc0 reassemble tcp no-df random-id > > nat on xl0 from 172.16.0.0/24 to any -> (xl0) static-port > > rdr on dc0 inet proto tcp to port 80 -> 127.0.0.1 port 3128 round-robin > > sticky-address > > antispoof quick for {xl0,dc0,xl1} > > block proto tcp from 172.16.0.0/24 to any port 3128 > > # Internal Traffic > > pass in quick on dc0 from any to any > > pass out quick on dc0 from any to any > > # Outgoing > > pass out on xl0 proto tcp all flags S/SA modulate state > > pass out on xl0 proto { udp, icmp } all keep state > > pass out on xl1 proto tcp all flags S/SA modulate state > > pass out on xl1 proto { udp, icmp } all keep state > > # Pass basic services > > pass in quick on xl1 proto tcp from any to any port { 22, 21, 1194 } > keep > > state > > pass in quick on xl0 proto tcp from any to any port { 22, 21, 1194 } > keep > > state > > pass in on xl0 proto udp from any to any port 53 > > pass in on xl1 proto udp from any to any port 53 > > # Pass VPN > > pass in quick on xl1 proto udp from any to port 1194 keep state > > pass quick on tun0 > > # Source nat route > > pass out log on xl0 route-to ( xl1 200.232.164.1 ) from xl1 to any > > pass out on xl1 route-to ( xl0 201.83.16.1 ) from xl0 to any > > # Close > > block return-rst in log quick on xl0 inet proto tcp from any to any > > block return-rst in log quick on xl1 inet proto tcp from any to any > > block return-icmp in log quick on xl0 proto udp from any to any > > block return-icmp in log quick on xl1 proto udp from any to any > > block in quick on xl0 all > > block in quick on xl1 all > > > > Best Regards, > > > > Wesley Gentine > > _______________________________________________ > > 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" > > > > -- > > Best Wishes, > Stefan Lambrev > ICQ# 24134177 > > From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 19:07:15 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 060CF1065677 for ; Mon, 24 Mar 2008 19:07:15 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id AB0698FC25 for ; Mon, 24 Mar 2008 19:07:14 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id m2OISUcr040464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Mar 2008 11:28:32 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <47E7F2CE.503@freebsd.org> Date: Mon, 24 Mar 2008 11:28:30 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Robert Jenssen References: <200803232052.07111.robertjenssen@ozemail.com.au> In-Reply-To: <200803232052.07111.robertjenssen@ozemail.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: net@freebsd.org Subject: Re: Lock order reversal in ral driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2008 19:07:15 -0000 Robert Jenssen wrote: > Hi, > > Since upgrading to FreeBSD 7 I have been experiencing some frustrating > problems with my RAL wifi card. In particular, it seems to me that dhclient > fails when the ral device driver times out while scanning for my access > point. At the same time my HP PDA with Spectec WiFi SDIO card has no problems > finding my access point. > > Today I made a kernel with the following options: > > makeoptions DEBUG=-g > options INVARIANTS > options INVARIANT_SUPPORT > options WITNESS > options DEBUG_LOCKS > options DEBUG_VFS_LOCKS > options DIAGNOSTIC > options SOCKBUF_DEBUG > options DDB > options KDB > > Upon rebooting the dmesg immediately showed a lock order reversal in the ral > driver in ieee80211_scan.c and rt2560.c (see below). Does this correspond to > my symptoms? Is there a wizard out there who understands what is happening? > <...stuff snipped...> The LOR is unrelated to any issues you are seeing and can be safely ignored. Try providing a description of your setup and a log that indicates the problem. For the latter look at wlandebug(8). Sam From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 20:24:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AD931065670 for ; Mon, 24 Mar 2008 20:24:39 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (unknown [IPv6:2001:41d0:1:2ad2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5174E8FC18 for ; Mon, 24 Mar 2008 20:24:38 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:1:2ad2::fffe:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 0C07D1BAC11; Mon, 24 Mar 2008 21:24:36 +0100 (CET) Received: from morzine.restart.bel (morzine6.restart.bel [IPv6:2001:41d0:1:2ad2::1:2]) (authenticated bits=0) by restart.be (8.14.2/8.14.2) with ESMTP id m2OKOXwW081723; Mon, 24 Mar 2008 21:24:33 +0100 (CET) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1206390276; bh=Axnn7a9cd5HRJ8v5W3IXlRqM+BRQUR2nw6ewIxA dilA=; h=Message-ID:Date:From:MIME-Version:To:CC:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=xpPZ+mFNs7Qh 0+TTkz02ihjS4otSmElEo8GhuuecNyo9bEcXVgJHL1rq87093879vxSZhOqeFUR2I7T eM+Kesg== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=q+jnB724RktPHX/qZ1eAOxhg1/Xd8g3lo6DjR3N6KH45UpPCBd4DVQmRcevM+IRhT w75f7AgU7wQ30ZTZCzgVg== Message-ID: <47E80E01.4060605@restart.be> Date: Mon, 24 Mar 2008 21:24:33 +0100 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.12 (X11/20080316) MIME-Version: 1.0 To: Kage References: <47E50936.1010405@restart.be> <47E77E1C.7090000@restart.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on IPv6:2001:41d0:1:2ad2::1:1 Cc: freebsd-net@freebsd.org Subject: Re: natd port forward times out, tcpdump yields nothing 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, 24 Mar 2008 20:24:39 -0000 Kage wrote: > Still not working, but I DO have natd aliasing properly. Here's my > natd output (remember which IP is mine, the IRC jail, and the example > round-robin IP): > > [root@nub /etc]# natd -f /etc/natd.conf > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 > > 72...23 (me) is hitting the natd on the jail IP (207...45), which is > getting correctly aliased to 72...202 (example round-robin IP). So it > appears the natd is working properly. In the client -> server direction only for now -- see bellow. > Here's my natd configuration as > it exists now: > > # Nub.Core NATd > verbose > alias_address 207.210.114.45 > log > log_denied > log_ipfw_denied > pid_file /var/run/natd.pid > > ### IRC Redirect Ports > # 6667 > redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 > > And for more record, here's my ipfw.rules file up until the divert: > > [root@nub /etc]# cat ipfw.rules > IPF="ipfw -q add" > ipfw -f -q flush > > #loopback > $IPF 10 allow all from any to any via lo0 > $IPF 20 deny all from any to 127.0.0.0/8 > $IPF 30 deny all from 127.0.0.0/8 to any > $IPF 40 deny tcp from any to any frag > > # statefull > $IPF 50 check-state > $IPF 60 allow tcp from any to any established > $IPF 70 allow all from any to any out keep-state > $IPF 54999 allow icmp from any to any > > [snip -- Some allowed ports (port 80, 443, etc.), and some denied IPs] > > # IRC (natd divert for IRC port-forwarding > $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 6667 via rl0 ^^^^ The destination port must not be given (ie any destination port corresponding to any source port greater than 1023 for the request) - in this test the source port is 2897, in the next one it may be anything > 1023. Moreover `any' in place of 207.210.114.45 would be nice to allow others to chat. So the rule should be: $IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0 Henri > $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0 > > Any attempt to connect to the IRC jail IP thus far, though, still > fails with a "connection timed out." > > Thanks for your help thus far. Any additional ideas? > > On Mon, Mar 24, 2008 at 6:10 AM, Henri Hennebert wrote: >> Kage wrote: >> > Well, no, see it's hitting natd just fine as shown by my natd verbose >> > logs, if you're assuming ipfw is blocking me from reaching natd. Are >> > you talking about adding a firewall rule for each of my round-robin >> > addresses, too? >> >> Yes >> >> >> > How would that do any good? >> >> All response paquet to a paquet diverted to natd must also be diverted >> to natd to be reverse translated. eg: >> >> incoming request from client (c) to server (s) redirected to server (S) >> >> c.c.c.c -> s.s.s.s nated as c.c.c.c -> S.S.S.S >> >> must have response paquetd reverse translated: >> >> S.S.S.S -> c.c.c.c nated as s.s.s.s -> c.c.c.c >> >> to be a valid response to client (c). >> >> >> >> > >> > On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert wrote: >> >> Kage wrote: >> >> > Hey guys, >> >> > >> >> > This is a fun one that's stumped people in Freenode ##freebsd. >> >> > Basically, I have this layout: >> >> > >> >> > irc.domain.com -> DNS A -> IRC Jail >> >> > >> >> > When someone connects to irc.domain.com on IRC ports (6667, 8067, >> >> > etc.), it round-robins them using natd, otherwise it sends all other >> >> > port requests to the IRC jail as per normal (such as port 80, which is >> >> > my primary concern). As for having it setup to have ipfw divert to >> >> > natd, that's done and works, as shown by natd verbose mode: >> >> > >> >> > In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 aliased to >> >> > [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 >> >> > >> >> > (For reference) >> >> > 207.210.114.45 = jail IP >> >> > 72.20.28.202 = example target IP in the round-robin >> >> > 72.65.73.23 = my IP >> >> > >> >> > Right now, my ipfw.rules file is as follows: >> >> > >> >> > [root@nub /etc]# cat ipfw.rules >> >> > IPF="ipfw -q add" >> >> > ipfw -f -q flush >> >> > >> >> > #loopback >> >> > $IPF 10 allow all from any to any via lo0 >> >> > $IPF 20 deny all from any to 127.0.0.0/8 >> >> > $IPF 30 deny all from 127.0.0.0/8 to any >> >> > $IPF 40 deny tcp from any to any frag >> >> > >> >> > # statefull >> >> > $IPF 50 check-state >> >> > $IPF 60 allow tcp from any to any established >> >> > $IPF 70 allow all from any to any out keep-state >> >> > $IPF 54999 allow icmp from any to any >> >> > >> >> > # Include the deny file >> >> > . /etc/ipfw.deny >> >> > >> >> > [snip -- some allowed ports] >> >> > # IRC (natd divert for IRC port-forwarding >> >> > $IPF 50220 divert natd all from any to 207.210.114.45 6667 via rl0 >> >> > $IPF 50230 divert natd all from any to 207.210.114.45 8067 via rl0 >> >> > $IPF 50240 divert natd all from any to 207.210.114.45 8068 via rl0 >> >> > $IPF 50250 divert natd all from any to 207.210.114.45 6697 via rl0 >> >> > $IPF 50260 divert natd all from any to 207.210.114.45 7000 via rl0 >> >> >> >> >> >> You must also divert the response trafic AFAIK eg: >> >> >> >> $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 via rl0 >> >> >> >> >> >> >> >> > # keep these two IRC ports normally open for BNC >> >> > $IPF 50270 allow all from any to any 31337 in >> >> > $IPF 50380 allow all from any to any 31337 out >> >> > [snip -- more allowed ports] >> >> > # deny and log everything >> >> > $IPF 55000 deny log all from any to any >> >> > >> >> > ----- >> >> > >> >> > Here's a dump of ipfw show, with some stuff cut out for space purposes >> >> > (they're just denied DDoS IPs) >> >> > >> >> > [root@nub /etc]# ipfw show >> >> > 00010 61124 16056802 allow ip from any to any via lo0 >> >> > 00020 0 0 deny ip from any to 127.0.0.0/8 >> >> > 00030 0 0 deny ip from 127.0.0.0/8 to any >> >> > 00040 0 0 deny tcp from any to any frag >> >> > 00050 0 0 check-state >> >> > 00060 670616 455926379 allow tcp from any to any established >> >> > 00070 16213 14071853 allow ip from any to any out keep-state >> >> > [snip] >> >> > 50220 468 22464 divert 8668 ip from any to 207.210.114.45 >> >> > dst-port 6667 via rl0 >> >> > 50230 0 0 divert 8668 ip from any to 207.210.114.45 >> >> > dst-port 8067 via rl0 >> >> > 50240 0 0 divert 8668 ip from any to 207.210.114.45 >> >> > dst-port 8068 via rl0 >> >> > 50250 0 0 divert 8668 ip from any to 207.210.114.45 >> >> > dst-port 6697 via rl0 >> >> > 50260 0 0 divert 8668 ip from any to 207.210.114.45 >> >> > dst-port 7000 via rl0 >> >> > 50270 1 60 allow ip from any to any dst-port 31337 in >> >> > 54999 66 3991 allow icmp from any to any >> >> > 55000 4364 343609 deny log logamount 100 ip from any to any >> >> > 65535 29 4176 allow ip from any to any >> >> > >> >> > My natd.conf is as follows: >> >> > >> >> > [root@nub /etc]# cat natd.conf >> >> > # Nub.Core NATd >> >> > verbose >> >> > alias_address 207.210.114.45 >> >> > log >> >> > log_denied >> >> > log_ipfw_denied >> >> > pid_file /var/run/natd.pid >> >> > >> >> > >> >> > ### IRC Redirect Ports >> >> > # 6667 >> >> >> >> >> >> If I understand man natd >> >> >> >> >> >>> redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 207.210.114.45:6667 >> >> ^^^^^^^^^^^^^ >> >> Trafic is comming from 72.65.73.23 - so the rule don't apply >> >> >> >> >> >>> [root@nub /etc]# >> >> > >> >> > And, as stated above, I am showing connection diverts to natd. When I >> >> > run the following three tcpdumps: >> >> > >> >> > tcpdump -s 0 -w me_to_nat.pcap -vvv -i rl0 src host 72.65.73.23 and >> >> > dst host 207.210.114.45 and dst port 6667 >> >> > tcpdump -s 0 -w nat_to_jail.pcap -vvv -i rl0 src host 72.20.28.202 and >> >> > dst host 207.210.114.45 and dst port 6667 >> >> > tcpdump -s 0 -w jail_to_nat.pcap -vvv -i rl0 src host 207.210.114.45 >> >> > and dst host 72.20.28.202 and src port 6667 >> >> > >> >> > Only the "me_to_nat.pcap" gets any data. The rest are 0 bytes. Example: >> >> > >> >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 jail_to_nat.pcap >> >> > -rw-r--r-- 1 root wheel 16384 Mar 21 15:24 me_to_nat.pcap >> >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 nat_to_jail.pcap >> >> > >> >> > So, can anyone diagnose and fix this? Thanks. >> >> > >> >> > (P.S.: I'm aware of the DNS methods of doing round-robin, but please >> >> > keep that from this discussion. I need to port-forward round-robin, >> >> > not whole DNS) >> >> > >> >> >> >> >> >> _______________________________________________ >> >> freebsd-net@freebsd.org mailing list >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> > >> > >> > >> >> > > > From owner-freebsd-net@FreeBSD.ORG Mon Mar 24 20:53:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 368011065679 for ; Mon, 24 Mar 2008 20:53:21 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by mx1.freebsd.org (Postfix) with ESMTP id 822628FC26 for ; Mon, 24 Mar 2008 20:53:20 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: by ti-out-0910.google.com with SMTP id j2so800495tid.3 for ; Mon, 24 Mar 2008 13:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=4LYHDLieorPLgol76SMGfFBf2+pVOCEF4/PwsvDo7F4=; b=h3l0gV8HxZzqxK+7Wfg0pb3M7uFMOp2wfB2e+7Yh240T1I0VmDaTCrs1OLJeBmvNiU7hSZhrwh3EhfOLqDmv3XiqP5YfAywz5D+3ewL+36oRhQcGBqosApUtyjZ23BrcKK6LtE0I8GewUQACzrmxlabrvJy6/S4PnijCOSOtW48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WUwVIzqkETWGOGCwP+U7sxVWeRO78PTUOtipCcBO+qn7X/88CQxnA88fBWNL4BOGsfahEoOrRRm0Ifc8IRPbuudp8u9KriP11NCQx6AZJpNYqu51rpnbdENCim7nkU36977wcJ1uYPL2s/Rq0m0Yu5l6ehITSdMeBJ+t0sgQklo= Received: by 10.110.46.14 with SMTP id t14mr2227646tit.16.1206391999474; Mon, 24 Mar 2008 13:53:19 -0700 (PDT) Received: by 10.70.48.17 with HTTP; Mon, 24 Mar 2008 13:53:19 -0700 (PDT) Message-ID: Date: Mon, 24 Mar 2008 16:53:19 -0400 From: Kage To: freebsd-net@freebsd.org In-Reply-To: <47E80E01.4060605@restart.be> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47E50936.1010405@restart.be> <47E77E1C.7090000@restart.be> <47E80E01.4060605@restart.be> Subject: Re: natd port forward times out, tcpdump yields nothing 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, 24 Mar 2008 20:53:21 -0000 I changed my rules, and it's still not working: $IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0 $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0 It's still timing connections out. On Mon, Mar 24, 2008 at 4:24 PM, Henri Hennebert wrote: > Kage wrote: > > Still not working, but I DO have natd aliasing properly. Here's my > > natd output (remember which IP is mine, the IRC jail, and the example > > round-robin IP): > > > > [root@nub /etc]# natd -f /etc/natd.conf > > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to > > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 > > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to > > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 > > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to > > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 > > > > 72...23 (me) is hitting the natd on the jail IP (207...45), which is > > getting correctly aliased to 72...202 (example round-robin IP). So it > > appears the natd is working properly. > > In the client -> server direction only for now -- see bellow. > > > > > Here's my natd configuration as > > it exists now: > > > > # Nub.Core NATd > > verbose > > alias_address 207.210.114.45 > > log > > log_denied > > log_ipfw_denied > > pid_file /var/run/natd.pid > > > > ### IRC Redirect Ports > > # 6667 > > redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 > > > > And for more record, here's my ipfw.rules file up until the divert: > > > > [root@nub /etc]# cat ipfw.rules > > IPF="ipfw -q add" > > ipfw -f -q flush > > > > #loopback > > $IPF 10 allow all from any to any via lo0 > > $IPF 20 deny all from any to 127.0.0.0/8 > > $IPF 30 deny all from 127.0.0.0/8 to any > > $IPF 40 deny tcp from any to any frag > > > > # statefull > > $IPF 50 check-state > > $IPF 60 allow tcp from any to any established > > $IPF 70 allow all from any to any out keep-state > > $IPF 54999 allow icmp from any to any > > > > [snip -- Some allowed ports (port 80, 443, etc.), and some denied IPs] > > > > # IRC (natd divert for IRC port-forwarding > > $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 6667 via rl0 > ^^^^ > The destination port must not be given (ie any destination port > corresponding to any source port greater than 1023 for the request) - in > this test the source port is 2897, in the next one it may be anything > > 1023. Moreover `any' in place of 207.210.114.45 would be nice to allow > others to chat. So the rule should be: > > $IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0 > > Henri > > > > > $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0 > > > > Any attempt to connect to the IRC jail IP thus far, though, still > > fails with a "connection timed out." > > > > Thanks for your help thus far. Any additional ideas? > > > > On Mon, Mar 24, 2008 at 6:10 AM, Henri Hennebert wrote: > >> Kage wrote: > >> > Well, no, see it's hitting natd just fine as shown by my natd verbose > >> > logs, if you're assuming ipfw is blocking me from reaching natd. Are > >> > you talking about adding a firewall rule for each of my round-robin > >> > addresses, too? > >> > >> Yes > >> > >> > >> > How would that do any good? > >> > >> All response paquet to a paquet diverted to natd must also be diverted > >> to natd to be reverse translated. eg: > >> > >> incoming request from client (c) to server (s) redirected to server (S) > >> > >> c.c.c.c -> s.s.s.s nated as c.c.c.c -> S.S.S.S > >> > >> must have response paquetd reverse translated: > >> > >> S.S.S.S -> c.c.c.c nated as s.s.s.s -> c.c.c.c > >> > >> to be a valid response to client (c). > >> > >> > >> > >> > > >> > On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert wrote: > >> >> Kage wrote: > >> >> > Hey guys, > >> >> > > >> >> > This is a fun one that's stumped people in Freenode ##freebsd. > >> >> > Basically, I have this layout: > >> >> > > >> >> > irc.domain.com -> DNS A -> IRC Jail > >> >> > > >> >> > When someone connects to irc.domain.com on IRC ports (6667, 8067, > >> >> > etc.), it round-robins them using natd, otherwise it sends all other > >> >> > port requests to the IRC jail as per normal (such as port 80, which is > >> >> > my primary concern). As for having it setup to have ipfw divert to > >> >> > natd, that's done and works, as shown by natd verbose mode: > >> >> > > >> >> > In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 aliased to > >> >> > [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 > >> >> > > >> >> > (For reference) > >> >> > 207.210.114.45 = jail IP > >> >> > 72.20.28.202 = example target IP in the round-robin > >> >> > 72.65.73.23 = my IP > >> >> > > >> >> > Right now, my ipfw.rules file is as follows: > >> >> > > >> >> > [root@nub /etc]# cat ipfw.rules > >> >> > IPF="ipfw -q add" > >> >> > ipfw -f -q flush > >> >> > > >> >> > #loopback > >> >> > $IPF 10 allow all from any to any via lo0 > >> >> > $IPF 20 deny all from any to 127.0.0.0/8 > >> >> > $IPF 30 deny all from 127.0.0.0/8 to any > >> >> > $IPF 40 deny tcp from any to any frag > >> >> > > >> >> > # statefull > >> >> > $IPF 50 check-state > >> >> > $IPF 60 allow tcp from any to any established > >> >> > $IPF 70 allow all from any to any out keep-state > >> >> > $IPF 54999 allow icmp from any to any > >> >> > > >> >> > # Include the deny file > >> >> > . /etc/ipfw.deny > >> >> > > >> >> > [snip -- some allowed ports] > >> >> > # IRC (natd divert for IRC port-forwarding > >> >> > $IPF 50220 divert natd all from any to 207.210.114.45 6667 via rl0 > >> >> > $IPF 50230 divert natd all from any to 207.210.114.45 8067 via rl0 > >> >> > $IPF 50240 divert natd all from any to 207.210.114.45 8068 via rl0 > >> >> > $IPF 50250 divert natd all from any to 207.210.114.45 6697 via rl0 > >> >> > $IPF 50260 divert natd all from any to 207.210.114.45 7000 via rl0 > >> >> > >> >> > >> >> You must also divert the response trafic AFAIK eg: > >> >> > >> >> $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 via rl0 > >> >> > >> >> > >> >> > >> >> > # keep these two IRC ports normally open for BNC > >> >> > $IPF 50270 allow all from any to any 31337 in > >> >> > $IPF 50380 allow all from any to any 31337 out > >> >> > [snip -- more allowed ports] > >> >> > # deny and log everything > >> >> > $IPF 55000 deny log all from any to any > >> >> > > >> >> > ----- > >> >> > > >> >> > Here's a dump of ipfw show, with some stuff cut out for space purposes > >> >> > (they're just denied DDoS IPs) > >> >> > > >> >> > [root@nub /etc]# ipfw show > >> >> > 00010 61124 16056802 allow ip from any to any via lo0 > >> >> > 00020 0 0 deny ip from any to 127.0.0.0/8 > >> >> > 00030 0 0 deny ip from 127.0.0.0/8 to any > >> >> > 00040 0 0 deny tcp from any to any frag > >> >> > 00050 0 0 check-state > >> >> > 00060 670616 455926379 allow tcp from any to any established > >> >> > 00070 16213 14071853 allow ip from any to any out keep-state > >> >> > [snip] > >> >> > 50220 468 22464 divert 8668 ip from any to 207.210.114.45 > >> >> > dst-port 6667 via rl0 > >> >> > 50230 0 0 divert 8668 ip from any to 207.210.114.45 > >> >> > dst-port 8067 via rl0 > >> >> > 50240 0 0 divert 8668 ip from any to 207.210.114.45 > >> >> > dst-port 8068 via rl0 > >> >> > 50250 0 0 divert 8668 ip from any to 207.210.114.45 > >> >> > dst-port 6697 via rl0 > >> >> > 50260 0 0 divert 8668 ip from any to 207.210.114.45 > >> >> > dst-port 7000 via rl0 > >> >> > 50270 1 60 allow ip from any to any dst-port 31337 in > >> >> > 54999 66 3991 allow icmp from any to any > >> >> > 55000 4364 343609 deny log logamount 100 ip from any to any > >> >> > 65535 29 4176 allow ip from any to any > >> >> > > >> >> > My natd.conf is as follows: > >> >> > > >> >> > [root@nub /etc]# cat natd.conf > >> >> > # Nub.Core NATd > >> >> > verbose > >> >> > alias_address 207.210.114.45 > >> >> > log > >> >> > log_denied > >> >> > log_ipfw_denied > >> >> > pid_file /var/run/natd.pid > >> >> > > >> >> > > >> >> > ### IRC Redirect Ports > >> >> > # 6667 > >> >> > >> >> > >> >> If I understand man natd > >> >> > >> >> > >> >>> redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 207.210.114.45:6667 > >> >> ^^^^^^^^^^^^^ > >> >> Trafic is comming from 72.65.73.23 - so the rule don't apply > >> >> > >> >> > >> >>> [root@nub /etc]# > >> >> > > >> >> > And, as stated above, I am showing connection diverts to natd. When I > >> >> > run the following three tcpdumps: > >> >> > > >> >> > tcpdump -s 0 -w me_to_nat.pcap -vvv -i rl0 src host 72.65.73.23 and > >> >> > dst host 207.210.114.45 and dst port 6667 > >> >> > tcpdump -s 0 -w nat_to_jail.pcap -vvv -i rl0 src host 72.20.28.202 and > >> >> > dst host 207.210.114.45 and dst port 6667 > >> >> > tcpdump -s 0 -w jail_to_nat.pcap -vvv -i rl0 src host 207.210.114.45 > >> >> > and dst host 72.20.28.202 and src port 6667 > >> >> > > >> >> > Only the "me_to_nat.pcap" gets any data. The rest are 0 bytes. Example: > >> >> > > >> >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 jail_to_nat.pcap > >> >> > -rw-r--r-- 1 root wheel 16384 Mar 21 15:24 me_to_nat.pcap > >> >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 nat_to_jail.pcap > >> >> > > >> >> > So, can anyone diagnose and fix this? Thanks. > >> >> > > >> >> > (P.S.: I'm aware of the DNS methods of doing round-robin, but please > >> >> > keep that from this discussion. I need to port-forward round-robin, > >> >> > not whole DNS) > >> >> > > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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" > >> >> > >> > > >> > > >> > > >> > >> > > > > > > > > -- ~ Kage http://vitund.com http://hackthissite.org From owner-freebsd-net@FreeBSD.ORG Tue Mar 25 06:16:46 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 586401065671; Tue, 25 Mar 2008 06:16:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 191FB8FC14; Tue, 25 Mar 2008 06:16:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2P6Gk2X018652; Tue, 25 Mar 2008 06:16:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2P6GkVS018648; Tue, 25 Mar 2008 06:16:46 GMT (envelope-from linimon) Date: Tue, 25 Mar 2008 06:16:46 GMT Message-Id: <200803250616.m2P6GkVS018648@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/122058: [em] [panic] Panic on em1: taskq 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, 25 Mar 2008 06:16:46 -0000 Old Synopsis: Panic on em1: taskq New Synopsis: [em] [panic] Panic on em1: taskq Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 25 06:16:30 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122058 From owner-freebsd-net@FreeBSD.ORG Tue Mar 25 15:23:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE11D106564A for ; Tue, 25 Mar 2008 15:23:21 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (unknown [IPv6:2001:41d0:1:2ad2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 132DC8FC23 for ; Tue, 25 Mar 2008 15:23:21 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:1:2ad2::fffe:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id C557C1BAC11 for ; Tue, 25 Mar 2008 16:23:18 +0100 (CET) Received: from morzine.restart.bel (morzine6.restart.bel [IPv6:2001:41d0:1:2ad2::1:2]) (authenticated bits=0) by restart.be (8.14.2/8.14.2) with ESMTP id m2PFNBUr085414 for ; Tue, 25 Mar 2008 16:23:11 +0100 (CET) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1206458596; bh=ZJ+OwaLDEi2ZJsNWGh2VeIJi7a7fy+psWMBjLsU HMjI=; h=Message-ID:Date:From:MIME-Version:To:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=uaPQ/SyZJK+O vyfhM76+//aSEeJh2iBqpYjg5tXP64PvjqiCxW62XfDdkWvqwcfAU5Dpp4ATfCEMTD9 ZzBAHYA== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=JQ+EQintT87qdztpUusiJLBwDKVxumGqNZ/DzoTBqCbbO+9ruqo/BBk4r1q/yVMdl Ki0v1kj80OF6mkPYyqh0A== Message-ID: <47E918DF.7060005@restart.be> Date: Tue, 25 Mar 2008 16:23:11 +0100 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.12 (X11/20080316) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <47E50936.1010405@restart.be> <47E77E1C.7090000@restart.be> <47E80E01.4060605@restart.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on IPv6:2001:41d0:1:2ad2::1:1 Subject: Re: natd port forward times out, tcpdump yields nothing 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, 25 Mar 2008 15:23:22 -0000 Kage wrote: > I changed my rules, and it's still not working: > > $IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0 > $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0 > > It's still timing connections out. Does the server hosting natd is the default route for 72.20.28.202 ? Henri > > On Mon, Mar 24, 2008 at 4:24 PM, Henri Hennebert wrote: >> Kage wrote: >> > Still not working, but I DO have natd aliasing properly. Here's my >> > natd output (remember which IP is mine, the IRC jail, and the example >> > round-robin IP): >> > >> > [root@nub /etc]# natd -f /etc/natd.conf >> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to >> > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 >> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to >> > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 >> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to >> > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 >> > >> > 72...23 (me) is hitting the natd on the jail IP (207...45), which is >> > getting correctly aliased to 72...202 (example round-robin IP). So it >> > appears the natd is working properly. >> >> In the client -> server direction only for now -- see bellow. >> >> >> >> > Here's my natd configuration as >> > it exists now: >> > >> > # Nub.Core NATd >> > verbose >> > alias_address 207.210.114.45 >> > log >> > log_denied >> > log_ipfw_denied >> > pid_file /var/run/natd.pid >> > >> > ### IRC Redirect Ports >> > # 6667 >> > redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 >> > >> > And for more record, here's my ipfw.rules file up until the divert: >> > >> > [root@nub /etc]# cat ipfw.rules >> > IPF="ipfw -q add" >> > ipfw -f -q flush >> > >> > #loopback >> > $IPF 10 allow all from any to any via lo0 >> > $IPF 20 deny all from any to 127.0.0.0/8 >> > $IPF 30 deny all from 127.0.0.0/8 to any >> > $IPF 40 deny tcp from any to any frag >> > >> > # statefull >> > $IPF 50 check-state >> > $IPF 60 allow tcp from any to any established >> > $IPF 70 allow all from any to any out keep-state >> > $IPF 54999 allow icmp from any to any >> > >> > [snip -- Some allowed ports (port 80, 443, etc.), and some denied IPs] >> > >> > # IRC (natd divert for IRC port-forwarding >> > $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 6667 via rl0 >> ^^^^ >> The destination port must not be given (ie any destination port >> corresponding to any source port greater than 1023 for the request) - in >> this test the source port is 2897, in the next one it may be anything > >> 1023. Moreover `any' in place of 207.210.114.45 would be nice to allow >> others to chat. So the rule should be: >> >> $IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0 >> >> Henri >> >> >> >> > $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0 >> > >> > Any attempt to connect to the IRC jail IP thus far, though, still >> > fails with a "connection timed out." >> > >> > Thanks for your help thus far. Any additional ideas? >> > >> > On Mon, Mar 24, 2008 at 6:10 AM, Henri Hennebert wrote: >> >> Kage wrote: >> >> > Well, no, see it's hitting natd just fine as shown by my natd verbose >> >> > logs, if you're assuming ipfw is blocking me from reaching natd. Are >> >> > you talking about adding a firewall rule for each of my round-robin >> >> > addresses, too? >> >> >> >> Yes >> >> >> >> >> >> > How would that do any good? >> >> >> >> All response paquet to a paquet diverted to natd must also be diverted >> >> to natd to be reverse translated. eg: >> >> >> >> incoming request from client (c) to server (s) redirected to server (S) >> >> >> >> c.c.c.c -> s.s.s.s nated as c.c.c.c -> S.S.S.S >> >> >> >> must have response paquetd reverse translated: >> >> >> >> S.S.S.S -> c.c.c.c nated as s.s.s.s -> c.c.c.c >> >> >> >> to be a valid response to client (c). >> >> >> >> >> >> >> >> > >> >> > On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert wrote: >> >> >> Kage wrote: >> >> >> > Hey guys, >> >> >> > >> >> >> > This is a fun one that's stumped people in Freenode ##freebsd. >> >> >> > Basically, I have this layout: >> >> >> > >> >> >> > irc.domain.com -> DNS A -> IRC Jail >> >> >> > >> >> >> > When someone connects to irc.domain.com on IRC ports (6667, 8067, >> >> >> > etc.), it round-robins them using natd, otherwise it sends all other >> >> >> > port requests to the IRC jail as per normal (such as port 80, which is >> >> >> > my primary concern). As for having it setup to have ipfw divert to >> >> >> > natd, that's done and works, as shown by natd verbose mode: >> >> >> > >> >> >> > In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 aliased to >> >> >> > [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 >> >> >> > >> >> >> > (For reference) >> >> >> > 207.210.114.45 = jail IP >> >> >> > 72.20.28.202 = example target IP in the round-robin >> >> >> > 72.65.73.23 = my IP >> >> >> > >> >> >> > Right now, my ipfw.rules file is as follows: >> >> >> > >> >> >> > [root@nub /etc]# cat ipfw.rules >> >> >> > IPF="ipfw -q add" >> >> >> > ipfw -f -q flush >> >> >> > >> >> >> > #loopbackpg_dumpall >all.dmp >> >> >> > $IPF 10 allow all from any to any via lo0 >> >> >> > $IPF 20 deny all from any to 127.0.0.0/8 >> >> >> > $IPF 30 deny all from 127.0.0.0/8 to any >> >> >> > $IPF 40 deny tcp from any to any frag >> >> >> > >> >> >> > # statefull >> >> >> > $IPF 50 check-state >> >> >> > $IPF 60 allow tcp from any to any established >> >> >> > $IPF 70 allow all from any to any out keep-state >> >> >> > $IPF 54999 allow icmp from any to any >> >> >> > >> >> >> > # Include the deny file >> >> >> > . /etc/ipfw.deny >> >> >> > >> >> >> > [snip -- some allowed ports] >> >> >> > # IRC (natd divert for IRC port-forwarding >> >> >> > $IPF 50220 divert natd all from any to 207.210.114.45 6667 via rl0 >> >> >> > $IPF 50230 divert natd all from any to 207.210.114.45 8067 via rl0 >> >> >> > $IPF 50240 divert natd all from any to 207.210.114.45 8068 via rl0 >> >> >> > $IPF 50250 divert natd all from any to 207.210.114.45 6697 via rl0 >> >> >> > $IPF 50260 divert natd all from any to 207.210.114.45 7000 via rl0 >> >> >> >> >> >> >> >> >> You must also divert the response trafic AFAIK eg: >> >> >> >> >> >> $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 via rl0 >> >> >> >> >> >> >> >> >> >> >> >> > # keep these two IRC ports normally open for BNC >> >> >> > $IPF 50270 allow all from any to any 31337 in >> >> >> > $IPF 50380 allow all from any to any 31337 out >> >> >> > [snip -- more allowed ports] >> >> >> > # deny and log everything >> >> >> > $IPF 55000 deny log all from any to any >> >> >> > >> >> >> > ----- >> >> >> > >> >> >> > Here's a dump of ipfw show, with some stuff cut out for space purposes >> >> >> > (they're just denied DDoS IPs) >> >> >> > >> >> >> > [root@nub /etc]# ipfw show >> >> >> > 00010 61124 16056802 allow ip from any to any via lo0 >> >> >> > 00020 0 0 deny ip from any to 127.0.0.0/8 >> >> >> > 00030 0 0 deny ip from 127.0.0.0/8 to any >> >> >> > 00040 0 0 deny tcp from any to any frag >> >> >> > 00050 0 0 check-state >> >> >> > 00060 670616 455926379 allow tcp from any to any established >> >> >> > 00070 16213 14071853 allow ip from any to any out keep-state >> >> >> > [snip] >> >> >> > 50220 468 22464 divert 8668 ip from any to 207.210.114.45 >> >> >> > dst-port 6667 via rl0 >> >> >> > 50230 0 0 divert 8668 ip from any to 207.210.114.45 >> >> >> > dst-port 8067 via rl0 >> >> >> > 50240 0 0 divert 8668 ip from any to 207.210.114.45 >> >> >> > dst-port 8068 via rl0 >> >> >> > 50250 0 0 divert 8668 ip from any to 207.210.114.45 >> >> >> > dst-port 6697 via rl0 >> >> >> > 50260 0 0 divert 8668 ip from any to 207.210.114.45 >> >> >> > dst-port 7000 via rl0 >> >> >> > 50270 1 60 allow ip from any to any dst-port 31337 in >> >> >> > 54999 66 3991 allow icmp from any to any >> >> >> > 55000 4364 343609 deny log logamount 100 ip from any to any >> >> >> > 65535 29 4176 allow ip from any to any >> >> >> > >> >> >> > My natd.conf is as follows: >> >> >> > >> >> >> > [root@nub /etc]# cat natd.conf >> >> >> > # Nub.Core NATd >> >> >> > verbose >> >> >> > alias_address 207.210.114.45 >> >> >> > log >> >> >> > log_denied >> >> >> > log_ipfw_denied >> >> >> > pid_file /var/run/natd.pid >> >> >> > >> >> >> > >> >> >> > ### IRC Redirect Ports >> >> >> > # 6667 >> >> >> >> >> >> >> >> >> If I understand man natd >> >> >> >> >> >> >> >> >>> redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 207.210.114.45:6667 >> >> >> ^^^^^^^^^^^^^ >> >> >> Trafic is comming from 72.65.73.23 - so the rule don't apply >> >> >> >> >> >> >> >> >>> [root@nub /etc]# >> >> >> > >> >> >> > And, as stated above, I am showing connection diverts to natd. When I >> >> >> > run the following three tcpdumps: >> >> >> > >> >> >> > tcpdump -s 0 -w me_to_nat.pcap -vvv -i rl0 src host 72.65.73.23 and >> >> >> > dst host 207.210.114.45 and dst port 6667 >> >> >> > tcpdump -s 0 -w nat_to_jail.pcap -vvv -i rl0 src host 72.20.28.202 and >> >> >> > dst host 207.210.114.45 and dst port 6667 >> >> >> > tcpdump -s 0 -w jail_to_nat.pcap -vvv -i rl0 src host 207.210.114.45 >> >> >> > and dst host 72.20.28.202 and src port 6667 >> >> >> > >> >> >> > Only the "me_to_nat.pcap" gets any data. The rest are 0 bytes. Example: >> >> >> > >> >> >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 jail_to_nat.pcap >> >> >> > -rw-r--r-- 1 root wheel 16384 Mar 21 15:24 me_to_nat.pcap >> >> >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 nat_to_jail.pcap >> >> >> > >> >> >> > So, can anyone diagnose and fix this? Thanks. >> >> >> > >> >> >> > (P.S.: I'm aware of the DNS methods of doing round-robin, but please >> >> >> > keep that from this discussion. I need to port-forward round-robin, >> >> >> > not whole DNS) >> >> >> > >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> freebsd-net@freebsd.org mailing list >> >> >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> >> >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> >> >> >> > >> >> > >> >> > >> >> >> >> >> > >> > >> > >> >> > > > From owner-freebsd-net@FreeBSD.ORG Tue Mar 25 15:40:03 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9A3E1065670 for ; Tue, 25 Mar 2008 15:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B4CDA8FC17 for ; Tue, 25 Mar 2008 15:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2PFe3TZ064769 for ; Tue, 25 Mar 2008 15:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2PFe3ru064765; Tue, 25 Mar 2008 15:40:03 GMT (envelope-from gnats) Date: Tue, 25 Mar 2008 15:40:03 GMT Message-Id: <200803251540.m2PFe3ru064765@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Julien Cc: Subject: Re: kern/122058: [em] [panic] Panic on em1: taskq X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Julien List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 15:40:03 -0000 The following reply was made to PR kern/122058; it has been noted by GNATS. From: Julien To: bug-followup@FreeBSD.org, mich@kievnet.com Cc: Subject: Re: kern/122058: [em] [panic] Panic on em1: taskq Date: Tue, 25 Mar 2008 18:33:18 +0100 Hello, FYI, I filled a PR today where the kdbm output looks the same : http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122067 Regards, Julien -- Julien Cigar Belgian Biodiversity Platform http://www.biodiversity.be Université Libre de Bruxelles (ULB) Campus de la Plaine CP 257 Bâtiment NO, Bureau 4 N4 115C (Niveau 4) Boulevard du Triomphe, entrée ULB 2 B-1050 Bruxelles Mail: jcigar@ulb.ac.be @biobel: http://biobel.biodiversity.be/person/show/471 Tel : 02 650 57 52 From owner-freebsd-net@FreeBSD.ORG Tue Mar 25 19:26:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A353A1065670 for ; Tue, 25 Mar 2008 19:26:37 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3BEDE8FC1E for ; Tue, 25 Mar 2008 19:26:36 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JeEn5-00063w-2U for freebsd-net@freebsd.org; Tue, 25 Mar 2008 19:26:35 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Mar 2008 19:26:35 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Mar 2008 19:26:35 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Vadim Goncharov Date: Tue, 25 Mar 2008 19:26:26 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 40 Message-ID: References: <200803191334.54510.fjwcash@gmail.com> <47E17BF9.1030403@elischer.org> <200803191355.54288.fjwcash@gmail.com> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: Freddie Cash User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: "established" on { tcp or udp } rules X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 19:26:37 -0000 Hi Freddie Cash! On Mon, 24 Mar 2008 09:56:28 -0700; Freddie Cash wrote about 'Re: "established" on { tcp or udp } rules': >> This is behaviour of ipfw2 - options are independently ANDed. Thus, man page >> explicitly says: >> >> established >> Matches TCP packets that have the RST or ACK bits set. >> >> So, it is obvious that udp packet will not match and thus entire rule will not >> match. > Yeah, it's just weird that it lets you write a rule that will never match. It's not. I don't want a compiler standing in my way. > I'll have to fire up FreeBSD 4.11 (and possibly earlier with just > ipfw1) in a VM and check things there. I'm sure back in the 4.x days > that ipfw would error out if you wrote a UDP rule with TCP options at > the end, as that is what got me in the habit of writing separate UDP > and TCP rules. > Now that I found the { udp or tcp } syntax, I was rewriting some rules > on a test firewall and noticed that it would accept TCP option even if > udp was listed. In 4.11 days and ipfw1 you were limited in what you could check at once, so that check/complain was ok. New ipfw2 syntax allows to write perfectly valid rules with tcp/udp mixed in: ipfw add allow { proto udp or established } out That's an optimized short-catcher in the beginning of ruleset. Machine is hard to teach to properly recognize whether that rule is valid mix or not, so it just must not comlain. Of course, then it is user responsibilty to check. As always, Unix assumes you know what you do - if you rm a file, you can't undelete it. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-net@FreeBSD.ORG Tue Mar 25 19:41:55 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 251201065671; Tue, 25 Mar 2008 19:41:55 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 06B2B8FC1B; Tue, 25 Mar 2008 19:41:55 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2PJfsot083872; Tue, 25 Mar 2008 19:41:54 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2PJfs74083868; Tue, 25 Mar 2008 19:41:54 GMT (envelope-from remko) Date: Tue, 25 Mar 2008 19:41:54 GMT Message-Id: <200803251941.m2PJfs74083868@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/122082: NULL pointer dereference in in_pcbdrop 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, 25 Mar 2008 19:41:55 -0000 Synopsis: NULL pointer dereference in in_pcbdrop Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Tue Mar 25 19:41:45 UTC 2008 Responsible-Changed-Why: Might be networking related. http://www.freebsd.org/cgi/query-pr.cgi?pr=122082 From owner-freebsd-net@FreeBSD.ORG Tue Mar 25 19:42:24 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B1E8106566B; Tue, 25 Mar 2008 19:42:24 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0098FC14; Tue, 25 Mar 2008 19:42:24 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2PJgOpC083936; Tue, 25 Mar 2008 19:42:24 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2PJgOs4083932; Tue, 25 Mar 2008 19:42:24 GMT (envelope-from remko) Date: Tue, 25 Mar 2008 19:42:24 GMT Message-Id: <200803251942.m2PJgOs4083932@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/122068: [ppp] ppp can not set the correct interface with pptpd 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, 25 Mar 2008 19:42:24 -0000 Synopsis: [ppp] ppp can not set the correct interface with pptpd Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Tue Mar 25 19:42:10 UTC 2008 Responsible-Changed-Why: over to maintainer group (-net) http://www.freebsd.org/cgi/query-pr.cgi?pr=122068 From owner-freebsd-net@FreeBSD.ORG Tue Mar 25 19:44:12 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1110106566B; Tue, 25 Mar 2008 19:44:12 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 923F58FC20; Tue, 25 Mar 2008 19:44:12 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2PJiCrL084071; Tue, 25 Mar 2008 19:44:12 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2PJiCIN084067; Tue, 25 Mar 2008 19:44:12 GMT (envelope-from remko) Date: Tue, 25 Mar 2008 19:44:12 GMT Message-Id: <200803251944.m2PJiCIN084067@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/122065: [gre] gre over ipsec not working 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, 25 Mar 2008 19:44:12 -0000 Synopsis: [gre] gre over ipsec not working Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Tue Mar 25 19:44:03 UTC 2008 Responsible-Changed-Why: Over to networking team http://www.freebsd.org/cgi/query-pr.cgi?pr=122065 From owner-freebsd-net@FreeBSD.ORG Tue Mar 25 21:00:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38EBA106564A for ; Tue, 25 Mar 2008 21:00:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 21D6C8FC20 for ; Tue, 25 Mar 2008 21:00:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2PL041f091460 for ; Tue, 25 Mar 2008 21:00:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2PL04Va091459; Tue, 25 Mar 2008 21:00:04 GMT (envelope-from gnats) Date: Tue, 25 Mar 2008 21:00:04 GMT Message-Id: <200803252100.m2PL04Va091459@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Bjoern A. Zeeb" Cc: Subject: Re: kern/122065: [gre] gre over ipsec not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Bjoern A. Zeeb" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2008 21:00:04 -0000 The following reply was made to PR kern/122065; it has been noted by GNATS. From: "Bjoern A. Zeeb" To: bug-followup@FreeBSD.org, alephis@gmail.com Cc: Subject: Re: kern/122065: [gre] gre over ipsec not working Date: Tue, 25 Mar 2008 20:45:18 +0000 (UTC) Hi, the report is not too specific. Could you provide more details like - policies on Windows - confirm with tcpdump that no packets are going out on the real interface? - can you still see the packets on enc0? - any possible firewall setups? - ... In case you do not want to share all that in public you can mail me directly thought with "private IPs" this shouldn't be a problem. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT Software is harder than hardware so better get it right the first time. From owner-freebsd-net@FreeBSD.ORG Tue Mar 25 23:24:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83BD6106564A for ; Tue, 25 Mar 2008 23:24:31 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.239]) by mx1.freebsd.org (Postfix) with ESMTP id 139508FC13 for ; Tue, 25 Mar 2008 23:24:30 +0000 (UTC) (envelope-from kagekonjou@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so4330808wxd.7 for ; Tue, 25 Mar 2008 16:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=OO46di0k1jV9efMBSXmRapf6/DSDr7LrUxM7GIVEMc8=; b=gGIBiuDAUqeUAG/aiQZUZjMoR8a3U1AvaDTMQ+5nSOfZKbMgZDs/EozfG1idavSa+WUvwLwXiAC/rIy5TVBtqZ8Zlfzrzx08C4nckQ5pDFcnDFgy6edc/wppwxwgSmVT4PGEHTFoo6LiOErdJ1TtcfTG/Lr/Ms1UHDOaCYjfsYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SGlhpIsQkDZmeXTLIhkJ+TrGPnUThGoYu+CXiplL8JxN5fFhKTYY69/aH9gkvsSNsSiGbzJRIByvTTq4GHxfkXlCmnqzY6U8s7C0mnifM/SR+8OcSZIT/nqQ6KMLF8XbjVvkVn+cw2CZV4/qOjNKyH3tcpkd+Lhbz1zVBI8YPMk= Received: by 10.70.57.18 with SMTP id f18mr11123451wxa.89.1206487470251; Tue, 25 Mar 2008 16:24:30 -0700 (PDT) Received: by 10.70.48.17 with HTTP; Tue, 25 Mar 2008 16:24:30 -0700 (PDT) Message-ID: Date: Tue, 25 Mar 2008 19:24:30 -0400 From: Kage To: "Henri Hennebert" In-Reply-To: <47E918DF.7060005@restart.be> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47E50936.1010405@restart.be> <47E77E1C.7090000@restart.be> <47E80E01.4060605@restart.be> <47E918DF.7060005@restart.be> Cc: freebsd-net@freebsd.org Subject: Re: natd port forward times out, tcpdump yields nothing 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, 25 Mar 2008 23:24:31 -0000 I'm sorry, I did not understand what you just asked. On Tue, Mar 25, 2008 at 11:23 AM, Henri Hennebert wrote: > Kage wrote: > > I changed my rules, and it's still not working: > > > > $IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0 > > $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0 > > > > It's still timing connections out. > > > Does the server hosting natd is the default route for 72.20.28.202 ? > > Henri > > > > > > On Mon, Mar 24, 2008 at 4:24 PM, Henri Hennebert wrote: > >> Kage wrote: > >> > Still not working, but I DO have natd aliasing properly. Here's my > >> > natd output (remember which IP is mine, the IRC jail, and the example > >> > round-robin IP): > >> > > >> > [root@nub /etc]# natd -f /etc/natd.conf > >> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to > >> > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 > >> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to > >> > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 > >> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to > >> > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 > >> > > >> > 72...23 (me) is hitting the natd on the jail IP (207...45), which is > >> > getting correctly aliased to 72...202 (example round-robin IP). So it > >> > appears the natd is working properly. > >> > >> In the client -> server direction only for now -- see bellow. > >> > >> > >> > >> > Here's my natd configuration as > >> > it exists now: > >> > > >> > # Nub.Core NATd > >> > verbose > >> > alias_address 207.210.114.45 > >> > log > >> > log_denied > >> > log_ipfw_denied > >> > pid_file /var/run/natd.pid > >> > > >> > ### IRC Redirect Ports > >> > # 6667 > >> > redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 > >> > > >> > And for more record, here's my ipfw.rules file up until the divert: > >> > > >> > [root@nub /etc]# cat ipfw.rules > >> > IPF="ipfw -q add" > >> > ipfw -f -q flush > >> > > >> > #loopback > >> > $IPF 10 allow all from any to any via lo0 > >> > $IPF 20 deny all from any to 127.0.0.0/8 > >> > $IPF 30 deny all from 127.0.0.0/8 to any > >> > $IPF 40 deny tcp from any to any frag > >> > > >> > # statefull > >> > $IPF 50 check-state > >> > $IPF 60 allow tcp from any to any established > >> > $IPF 70 allow all from any to any out keep-state > >> > $IPF 54999 allow icmp from any to any > >> > > >> > [snip -- Some allowed ports (port 80, 443, etc.), and some denied IPs] > >> > > >> > # IRC (natd divert for IRC port-forwarding > >> > $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 6667 via rl0 > >> ^^^^ > >> The destination port must not be given (ie any destination port > >> corresponding to any source port greater than 1023 for the request) - in > >> this test the source port is 2897, in the next one it may be anything > > >> 1023. Moreover `any' in place of 207.210.114.45 would be nice to allow > >> others to chat. So the rule should be: > >> > >> $IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0 > >> > >> Henri > >> > >> > >> > >> > $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0 > >> > > >> > Any attempt to connect to the IRC jail IP thus far, though, still > >> > fails with a "connection timed out." > >> > > >> > Thanks for your help thus far. Any additional ideas? > >> > > >> > On Mon, Mar 24, 2008 at 6:10 AM, Henri Hennebert wrote: > >> >> Kage wrote: > >> >> > Well, no, see it's hitting natd just fine as shown by my natd verbose > >> >> > logs, if you're assuming ipfw is blocking me from reaching natd. Are > >> >> > you talking about adding a firewall rule for each of my round-robin > >> >> > addresses, too? > >> >> > >> >> Yes > >> >> > >> >> > >> >> > How would that do any good? > >> >> > >> >> All response paquet to a paquet diverted to natd must also be diverted > >> >> to natd to be reverse translated. eg: > >> >> > >> >> incoming request from client (c) to server (s) redirected to server (S) > >> >> > >> >> c.c.c.c -> s.s.s.s nated as c.c.c.c -> S.S.S.S > >> >> > >> >> must have response paquetd reverse translated: > >> >> > >> >> S.S.S.S -> c.c.c.c nated as s.s.s.s -> c.c.c.c > >> >> > >> >> to be a valid response to client (c). > >> >> > >> >> > >> >> > >> >> > > >> >> > On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert wrote: > >> >> >> Kage wrote: > >> >> >> > Hey guys, > >> >> >> > > >> >> >> > This is a fun one that's stumped people in Freenode ##freebsd. > >> >> >> > Basically, I have this layout: > >> >> >> > > >> >> >> > irc.domain.com -> DNS A -> IRC Jail > >> >> >> > > >> >> >> > When someone connects to irc.domain.com on IRC ports (6667, 8067, > >> >> >> > etc.), it round-robins them using natd, otherwise it sends all other > >> >> >> > port requests to the IRC jail as per normal (such as port 80, which is > >> >> >> > my primary concern). As for having it setup to have ipfw divert to > >> >> >> > natd, that's done and works, as shown by natd verbose mode: > >> >> >> > > >> >> >> > In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 aliased to > >> >> >> > [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 > >> >> >> > > >> >> >> > (For reference) > >> >> >> > 207.210.114.45 = jail IP > >> >> >> > 72.20.28.202 = example target IP in the round-robin > >> >> >> > 72.65.73.23 = my IP > >> >> >> > > >> >> >> > Right now, my ipfw.rules file is as follows: > >> >> >> > > >> >> >> > [root@nub /etc]# cat ipfw.rules > >> >> >> > IPF="ipfw -q add" > >> >> >> > ipfw -f -q flush > >> >> >> > > >> >> >> > #loopbackpg_dumpall >all.dmp > > > >> >> >> > $IPF 10 allow all from any to any via lo0 > >> >> >> > $IPF 20 deny all from any to 127.0.0.0/8 > >> >> >> > $IPF 30 deny all from 127.0.0.0/8 to any > >> >> >> > $IPF 40 deny tcp from any to any frag > >> >> >> > > >> >> >> > # statefull > >> >> >> > $IPF 50 check-state > >> >> >> > $IPF 60 allow tcp from any to any established > >> >> >> > $IPF 70 allow all from any to any out keep-state > >> >> >> > $IPF 54999 allow icmp from any to any > >> >> >> > > >> >> >> > # Include the deny file > >> >> >> > . /etc/ipfw.deny > >> >> >> > > >> >> >> > [snip -- some allowed ports] > >> >> >> > # IRC (natd divert for IRC port-forwarding > >> >> >> > $IPF 50220 divert natd all from any to 207.210.114.45 6667 via rl0 > >> >> >> > $IPF 50230 divert natd all from any to 207.210.114.45 8067 via rl0 > >> >> >> > $IPF 50240 divert natd all from any to 207.210.114.45 8068 via rl0 > >> >> >> > $IPF 50250 divert natd all from any to 207.210.114.45 6697 via rl0 > >> >> >> > $IPF 50260 divert natd all from any to 207.210.114.45 7000 via rl0 > >> >> >> > >> >> >> > >> >> >> You must also divert the response trafic AFAIK eg: > >> >> >> > >> >> >> $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 via rl0 > >> >> >> > >> >> >> > >> >> >> > >> >> >> > # keep these two IRC ports normally open for BNC > >> >> >> > $IPF 50270 allow all from any to any 31337 in > >> >> >> > $IPF 50380 allow all from any to any 31337 out > >> >> >> > [snip -- more allowed ports] > >> >> >> > # deny and log everything > >> >> >> > $IPF 55000 deny log all from any to any > >> >> >> > > >> >> >> > ----- > >> >> >> > > >> >> >> > Here's a dump of ipfw show, with some stuff cut out for space purposes > >> >> >> > (they're just denied DDoS IPs) > >> >> >> > > >> >> >> > [root@nub /etc]# ipfw show > >> >> >> > 00010 61124 16056802 allow ip from any to any via lo0 > >> >> >> > 00020 0 0 deny ip from any to 127.0.0.0/8 > >> >> >> > 00030 0 0 deny ip from 127.0.0.0/8 to any > >> >> >> > 00040 0 0 deny tcp from any to any frag > >> >> >> > 00050 0 0 check-state > >> >> >> > 00060 670616 455926379 allow tcp from any to any established > >> >> >> > 00070 16213 14071853 allow ip from any to any out keep-state > >> >> >> > [snip] > >> >> >> > 50220 468 22464 divert 8668 ip from any to 207.210.114.45 > >> >> >> > dst-port 6667 via rl0 > >> >> >> > 50230 0 0 divert 8668 ip from any to 207.210.114.45 > >> >> >> > dst-port 8067 via rl0 > >> >> >> > 50240 0 0 divert 8668 ip from any to 207.210.114.45 > >> >> >> > dst-port 8068 via rl0 > >> >> >> > 50250 0 0 divert 8668 ip from any to 207.210.114.45 > >> >> >> > dst-port 6697 via rl0 > >> >> >> > 50260 0 0 divert 8668 ip from any to 207.210.114.45 > >> >> >> > dst-port 7000 via rl0 > >> >> >> > 50270 1 60 allow ip from any to any dst-port 31337 in > >> >> >> > 54999 66 3991 allow icmp from any to any > >> >> >> > 55000 4364 343609 deny log logamount 100 ip from any to any > >> >> >> > 65535 29 4176 allow ip from any to any > >> >> >> > > >> >> >> > My natd.conf is as follows: > >> >> >> > > >> >> >> > [root@nub /etc]# cat natd.conf > >> >> >> > # Nub.Core NATd > >> >> >> > verbose > >> >> >> > alias_address 207.210.114.45 > >> >> >> > log > >> >> >> > log_denied > >> >> >> > log_ipfw_denied > >> >> >> > pid_file /var/run/natd.pid > >> >> >> > > >> >> >> > > >> >> >> > ### IRC Redirect Ports > >> >> >> > # 6667 > >> >> >> > >> >> >> > >> >> >> If I understand man natd > >> >> >> > >> >> >> > >> >> >>> redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 207.210.114.45:6667 > >> >> >> ^^^^^^^^^^^^^ > >> >> >> Trafic is comming from 72.65.73.23 - so the rule don't apply > >> >> >> > >> >> >> > >> >> >>> [root@nub /etc]# > >> >> >> > > >> >> >> > And, as stated above, I am showing connection diverts to natd. When I > >> >> >> > run the following three tcpdumps: > >> >> >> > > >> >> >> > tcpdump -s 0 -w me_to_nat.pcap -vvv -i rl0 src host 72.65.73.23 and > >> >> >> > dst host 207.210.114.45 and dst port 6667 > >> >> >> > tcpdump -s 0 -w nat_to_jail.pcap -vvv -i rl0 src host 72.20.28.202 and > >> >> >> > dst host 207.210.114.45 and dst port 6667 > >> >> >> > tcpdump -s 0 -w jail_to_nat.pcap -vvv -i rl0 src host 207.210.114.45 > >> >> >> > and dst host 72.20.28.202 and src port 6667 > >> >> >> > > >> >> >> > Only the "me_to_nat.pcap" gets any data. The rest are 0 bytes. Example: > >> >> >> > > >> >> >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 jail_to_nat.pcap > >> >> >> > -rw-r--r-- 1 root wheel 16384 Mar 21 15:24 me_to_nat.pcap > >> >> >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 nat_to_jail.pcap > >> >> >> > > >> >> >> > So, can anyone diagnose and fix this? Thanks. > >> >> >> > > >> >> >> > (P.S.: I'm aware of the DNS methods of doing round-robin, but please > >> >> >> > keep that from this discussion. I need to port-forward round-robin, > >> >> >> > not whole DNS) > >> >> >> > > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> 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" > -- ~ Kage http://vitund.com http://hackthissite.org From owner-freebsd-net@FreeBSD.ORG Wed Mar 26 02:14:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85AC9106564A for ; Wed, 26 Mar 2008 02:14:27 +0000 (UTC) (envelope-from sazzad@ou.edu) Received: from IT-CYCLONE.sooner.net.ou.edu (e2007asmtp.zero.ou.edu [129.15.0.236]) by mx1.freebsd.org (Postfix) with ESMTP id 4D5B68FC19 for ; Wed, 26 Mar 2008 02:14:27 +0000 (UTC) (envelope-from sazzad@ou.edu) Received: from XMAIL5.sooner.net.ou.edu ([10.254.254.57]) by IT-CYCLONE.sooner.net.ou.edu ([10.254.254.40]) with mapi; Tue, 25 Mar 2008 21:04:19 -0500 From: "Rahman, Md Sazzadur" To: "freebsd-net@freebsd.org" Date: Tue, 25 Mar 2008 21:04:13 -0500 Thread-Topic: A query regarding SCTP congestion control Thread-Index: AciO5bA0wNdh5UW3R1+tzcT98vqsbw== Message-ID: <7059EA19D7837E44A3BA7DAB464944B37FDA715193@XMAIL5.sooner.net.ou.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: A query regarding SCTP congestion control 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, 26 Mar 2008 02:14:27 -0000 Hi, I would like to get the values of SCTP congestion control algorithm variabl= es (cwnd, ssthresh, flightsize and pba) from any SCTP based application in= runtime for research purpose. Does any API exist in SCTP for that? Do I n= eed to dig the SCTP code in kernel to get the values? I will appreciate any help in this regard. Best Regards, Md Sazzadur Rahman Graduate Student, School of Computer Science, University of Oklahoma, Norman, Oklahoma, USA From owner-freebsd-net@FreeBSD.ORG Wed Mar 26 02:34:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31E01106566B for ; Wed, 26 Mar 2008 02:34:13 +0000 (UTC) (envelope-from rahman.sazzadur@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 009288FC14 for ; Wed, 26 Mar 2008 02:34:12 +0000 (UTC) (envelope-from rahman.sazzadur@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so3993845waf.3 for ; Tue, 25 Mar 2008 19:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=t1vVrnvDhUD8UMZC1DObXWgKO0DrnomeIpyihqnTx/4=; b=UbOxJwsy7k3YmyTpQEgu8Df3wRAp3iE/KqKiQV8dX3n0d44TQajJL34Q+CLVneGCPEXKzqKL3Me/LMrQAC9FFNLxhxXjiVYwVSrvCl8OUGJvo9RMOZCcoXY6jBA6YH5IbLhxPKfI5GaAfoOn6HJUW2ULYkbCk+3OJJpn3F4926c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:mime-version:content-type; b=oR1sakEwp7FhlFaYotWDK8z33J6U8U/ibIMDeDpi3xK3QmelnWn/POWch/tf9f4NfqcvWRoku4fOkU3FMljQh7kLwc3rZSirx+5cJk3NoattHO1S666qfCDSysmIeiz9TtjJdVmPLXkutpQE5DcANtbzER4CjrbqjBCUnbnmmcE= Received: by 10.114.103.1 with SMTP id a1mr14574205wac.59.1206497389869; Tue, 25 Mar 2008 19:09:49 -0700 (PDT) Received: by 10.114.151.3 with HTTP; Tue, 25 Mar 2008 19:09:49 -0700 (PDT) Message-ID: <82bdb5ec0803251909i8cd92a0w9812b548798667e1@mail.gmail.com> Date: Tue, 25 Mar 2008 21:09:49 -0500 From: "sazzadur rahman" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: A query regarding SCTP congestion control 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, 26 Mar 2008 02:34:13 -0000 Hi, I would like to get the values of SCTP congestion control algorithm variables (*cwnd, ssthresh, flightsize *and* pba)* from any SCTP based application in runtime for research purpose. Does any API exist in SCTP for that? Do I need to dig the SCTP code in kernel to get the values? I will appreciate any help in this regard. Best Regards, Md Sazzadur Rahman Graduate Student, School of Computer Science, University of Oklahoma, Norman, Oklahoma, USA From owner-freebsd-net@FreeBSD.ORG Wed Mar 26 05:38:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2F7F1065672 for ; Wed, 26 Mar 2008 05:38:43 +0000 (UTC) (envelope-from Iverson.Hsieh@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id 63AF38FC21 for ; Wed, 26 Mar 2008 05:38:43 +0000 (UTC) (envelope-from Iverson.Hsieh@zyxel.com.tw) Received: from ZyTWBE03.ZyXEL.com ([172.23.5.49]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 13:38:42 +0800 Received: from zytwbe01.zyxel.com ([172.23.5.10]) by ZyTWBE03.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 13:38:42 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Mar 2008 13:38:39 +0800 Message-ID: <587CD04060DD6A4EA8BCDDBECC758C140BD16F@zytwbe01.ZyXEL.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A problem in ndp and rtadvd. Thread-Index: AciPA6TEtABDBWJiTuW2PnqDwc7eAg== From: =?big5?B?SXZlcnNvbiBIc2llaCAtwcKp066m?= To: X-OriginalArrivalTime: 26 Mar 2008 05:38:42.0313 (UTC) FILETIME=[A69E5F90:01C88F03] Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: A problem in ndp and rtadvd. 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, 26 Mar 2008 05:38:43 -0000 Dear all: I use command, date, to set current time. I find this causes the two=20 problems. I test the following two cases in freebsd 5.5-STABLE and=20 in freebsd 7.0-BETA2, and I find the result is the same. =20 1.in neighbor discovery protocol(ndp) The following is my command sequence. =20 $ ndp -a Neighbor Linklayer Address = Netif Expire S Flags 2001:b121:4::cccc 0:50:8d:48:57:9a = fxp0 permanent R 2001:b121:4:0:41f7:42ee:d08c:ca8c 0:90:cc:c2:aa:61 fxp0 26s = R 9999:9999::1 0:5:1c:15:a:8b = rl0 permanent R fe80::205:1cff:fe15:a8b%rl0 0:5:1c:15:a:8b rl0 = permanent R fe80::250:8dff:fe48:579a%fxp0 0:50:8d:48:57:9a fxp0 = permanent R fe80::290:ccff:fec2:aa61%fxp0 0:90:cc:c2:aa:61 fxp0 30s = R fe80::1%lo0 (incomplete) = lo0 permanent R =20 $ date Fri Mar 21 16:14:18 UTC 2008 =20 $ sudo date 0703211614 Password: Wed Mar 21 16:14:00 UTC 2007 =20 $ ndp -a Neighbor Linklayer Address = Netif Expire S Flags 2001:b121:4::cccc 0:50:8d:48:57:9a = fxp0 permanent R 2001:b121:4:0:41f7:42ee:d08c:ca8c 0:90:cc:c2:aa:61 fxp0 = 366d0h0m4 R 9999:9999::1 0:5:1c:15:a:8b = rl0 permanent R fe80::205:1cff:fe15:a8b%rl0 0:5:1c:15:a:8b rl0 = permanent R fe80::250:8dff:fe48:579a%fxp0 0:50:8d:48:57:9a fxp0 = permanent R fe80::290:ccff:fec2:aa61%fxp0 0:90:cc:c2:aa:61 fxp0 = 366d0h0m4 R fe80::1%lo0 (incomplete) = lo0 permanent R =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 I adjust system current time to one year ago by using 'date' command. = we can find ndp expiration time, in Expire column, also extended one year. Is this = OK? =20 2.in router advertisement daemon(rtadvd) I also adjust system current time to test rtadvd. Before I adjust = system current time, rtadvd can send unsolicited RA periodically. rtadvd can = send unsolicited RA about from 200 seconds to 600 seconds each time. But = after I=20 adjust system current time to one year ago, rtadvd does not send = unsolicited=20 RA any more. Is the behavior correct? =20 From owner-freebsd-net@FreeBSD.ORG Wed Mar 26 07:47:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DEEB106566B for ; Wed, 26 Mar 2008 07:47:31 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (unknown [IPv6:2001:41d0:1:2ad2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 55A128FC32 for ; Wed, 26 Mar 2008 07:47:30 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:1:2ad2::fffe:0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id CB6871BAC11; Wed, 26 Mar 2008 08:47:28 +0100 (CET) Received: from morzine.restart.bel (morzine6.restart.bel [IPv6:2001:41d0:1:2ad2::1:2]) (authenticated bits=0) by restart.be (8.14.2/8.14.2) with ESMTP id m2Q7lMop088828; Wed, 26 Mar 2008 08:47:22 +0100 (CET) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1206517648; bh=gVVPXHl1tCp32vOWV1rCcdEfwT5md5rxs+auq4j iTGA=; h=Message-ID:Date:From:MIME-Version:To:CC:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=YqezNfhG1Ath gB4w0tCpoCU6k9FEXXgOGjkbwvpPOwwm+H1QaoHEQ6mfwfsDAnw8lzxkaU7fbuNjpJt 5ZOS2KA== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=ECjZycS9rDCs7fgAlo+MRuKtkCD+mdYKEJEgAwdkcDN5FQfkob6/8Fz7YxGg2aPct 3yRzulRZEfX/xG0IbcGjg== Message-ID: <47E9FF8A.8000405@restart.be> Date: Wed, 26 Mar 2008 08:47:22 +0100 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.12 (X11/20080316) MIME-Version: 1.0 To: Kage References: <47E50936.1010405@restart.be> <47E77E1C.7090000@restart.be> <47E80E01.4060605@restart.be> <47E918DF.7060005@restart.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on IPv6:2001:41d0:1:2ad2::1:1 Cc: freebsd-net@freebsd.org Subject: Re: natd port forward times out, tcpdump yields nothing 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, 26 Mar 2008 07:47:31 -0000 Kage wrote: > I'm sorry, I did not understand what you just asked. When the request hit the real server [72.20.28.202], the response from this server must go back to the natd server so the reverse translation can take place. You can check by running tcpdump on [207.210.114.45] and see if the response came back from [72.20.28.202]. > > On Tue, Mar 25, 2008 at 11:23 AM, Henri Hennebert wrote: >> Kage wrote: >> > I changed my rules, and it's still not working: >> > >> > $IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0 >> > $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0 >> > >> > It's still timing connections out. >> >> >> Does the server hosting natd is the default route for 72.20.28.202 ? >> >> Henri >> > >> >> >>> On Mon, Mar 24, 2008 at 4:24 PM, Henri Hennebert wrote: >> >> Kage wrote: >> >> > Still not working, but I DO have natd aliasing properly. Here's my >> >> > natd output (remember which IP is mine, the IRC jail, and the example >> >> > round-robin IP): >> >> > >> >> > [root@nub /etc]# natd -f /etc/natd.conf >> >> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to >> >> > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 >> >> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to >> >> > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 >> >> > In {default}[TCP] [TCP] 72.65.73.23:2897 -> 207.210.114.45:6667 aliased to >> >> > [TCP] 72.65.73.23:2897 -> 72.20.28.202:6667 >> >> > >> >> > 72...23 (me) is hitting the natd on the jail IP (207...45), which is >> >> > getting correctly aliased to 72...202 (example round-robin IP). So it >> >> > appears the natd is working properly. >> >> >> >> In the client -> server direction only for now -- see bellow. >> >> >> >> >> >> >> >> > Here's my natd configuration as >> >> > it exists now: >> >> > >> >> > # Nub.Core NATd >> >> > verbose >> >> > alias_address 207.210.114.45 >> >> > log >> >> > log_denied >> >> > log_ipfw_denied >> >> > pid_file /var/run/natd.pid >> >> > >> >> > ### IRC Redirect Ports >> >> > # 6667 >> >> > redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 >> >> > >> >> > And for more record, here's my ipfw.rules file up until the divert: >> >> > >> >> > [root@nub /etc]# cat ipfw.rules >> >> > IPF="ipfw -q add" >> >> > ipfw -f -q flush >> >> > >> >> > #loopback >> >> > $IPF 10 allow all from any to any via lo0 >> >> > $IPF 20 deny all from any to 127.0.0.0/8 >> >> > $IPF 30 deny all from 127.0.0.0/8 to any >> >> > $IPF 40 deny tcp from any to any frag >> >> > >> >> > # statefull >> >> > $IPF 50 check-state >> >> > $IPF 60 allow tcp from any to any established >> >> > $IPF 70 allow all from any to any out keep-state >> >> > $IPF 54999 allow icmp from any to any >> >> > >> >> > [snip -- Some allowed ports (port 80, 443, etc.), and some denied IPs] >> >> > >> >> > # IRC (natd divert for IRC port-forwarding >> >> > $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 6667 via rl0 >> >> ^^^^ >> >> The destination port must not be given (ie any destination port >> >> corresponding to any source port greater than 1023 for the request) - in >> >> this test the source port is 2897, in the next one it may be anything > >> >> 1023. Moreover `any' in place of 207.210.114.45 would be nice to allow >> >> others to chat. So the rule should be: >> >> >> >> $IPF 50220 divert natd all from 72.20.28.202 6667 to any via rl0 >> >> >> >> Henri >> >> >> >> >> >> >> >> > $IPF 50221 divert natd all from any to 207.210.114.45 6667 via rl0 >> >> > >> >> > Any attempt to connect to the IRC jail IP thus far, though, still >> >> > fails with a "connection timed out." >> >> > >> >> > Thanks for your help thus far. Any additional ideas? >> >> > >> >> > On Mon, Mar 24, 2008 at 6:10 AM, Henri Hennebert wrote: >> >> >> Kage wrote: >> >> >> > Well, no, see it's hitting natd just fine as shown by my natd verbose >> >> >> > logs, if you're assuming ipfw is blocking me from reaching natd. Are >> >> >> > you talking about adding a firewall rule for each of my round-robin >> >> >> > addresses, too? >> >> >> >> >> >> Yes >> >> >> >> >> >> >> >> >> > How would that do any good? >> >> >> >> >> >> All response paquet to a paquet diverted to natd must also be diverted >> >> >> to natd to be reverse translated. eg: >> >> >> >> >> >> incoming request from client (c) to server (s) redirected to server (S) >> >> >> >> >> >> c.c.c.c -> s.s.s.s nated as c.c.c.c -> S.S.S.S >> >> >> >> >> >> must have response paquetd reverse translated: >> >> >> >> >> >> S.S.S.S -> c.c.c.c nated as s.s.s.s -> c.c.c.c >> >> >> >> >> >> to be a valid response to client (c). >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > On Sat, Mar 22, 2008 at 9:27 AM, Henri Hennebert wrote: >> >> >> >> Kage wrote: >> >> >> >> > Hey guys, >> >> >> >> > >> >> >> >> > This is a fun one that's stumped people in Freenode ##freebsd. >> >> >> >> > Basically, I have this layout: >> >> >> >> > >> >> >> >> > irc.domain.com -> DNS A -> IRC Jail >> >> >> >> > >> >> >> >> > When someone connects to irc.domain.com on IRC ports (6667, 8067, >> >> >> >> > etc.), it round-robins them using natd, otherwise it sends all other >> >> >> >> > port requests to the IRC jail as per normal (such as port 80, which is >> >> >> >> > my primary concern). As for having it setup to have ipfw divert to >> >> >> >> > natd, that's done and works, as shown by natd verbose mode: >> >> >> >> > >> >> >> >> > In {default}[TCP] [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 aliased to >> >> >> >> > [TCP] 72.65.73.23:2980 -> 207.210.114.45:6667 >> >> >> >> > >> >> >> >> > (For reference) >> >> >> >> > 207.210.114.45 = jail IP >> >> >> >> > 72.20.28.202 = example target IP in the round-robin >> >> >> >> > 72.65.73.23 = my IP >> >> >> >> > >> >> >> >> > Right now, my ipfw.rules file is as follows: >> >> >> >> > >> >> >> >> > [root@nub /etc]# cat ipfw.rules >> >> >> >> > IPF="ipfw -q add" >> >> >> >> > ipfw -f -q flush >> >> >> >> > >> >> >> >> > #loopbackpg_dumpall >all.dmp >> >> >>>> >> >> > $IPF 10 allow all from any to any via lo0 >> >> >> >> > $IPF 20 deny all from any to 127.0.0.0/8 >> >> >> >> > $IPF 30 deny all from 127.0.0.0/8 to any >> >> >> >> > $IPF 40 deny tcp from any to any frag >> >> >> >> > >> >> >> >> > # statefull >> >> >> >> > $IPF 50 check-state >> >> >> >> > $IPF 60 allow tcp from any to any established >> >> >> >> > $IPF 70 allow all from any to any out keep-state >> >> >> >> > $IPF 54999 allow icmp from any to any >> >> >> >> > >> >> >> >> > # Include the deny file >> >> >> >> > . /etc/ipfw.deny >> >> >> >> > >> >> >> >> > [snip -- some allowed ports] >> >> >> >> > # IRC (natd divert for IRC port-forwarding >> >> >> >> > $IPF 50220 divert natd all from any to 207.210.114.45 6667 via rl0 >> >> >> >> > $IPF 50230 divert natd all from any to 207.210.114.45 8067 via rl0 >> >> >> >> > $IPF 50240 divert natd all from any to 207.210.114.45 8068 via rl0 >> >> >> >> > $IPF 50250 divert natd all from any to 207.210.114.45 6697 via rl0 >> >> >> >> > $IPF 50260 divert natd all from any to 207.210.114.45 7000 via rl0 >> >> >> >> >> >> >> >> >> >> >> >> You must also divert the response trafic AFAIK eg: >> >> >> >> >> >> >> >> $IPF 50220 divert natd all from 72.20.28.202 6667 to 207.210.114.45 via rl0 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > # keep these two IRC ports normally open for BNC >> >> >> >> > $IPF 50270 allow all from any to any 31337 in >> >> >> >> > $IPF 50380 allow all from any to any 31337 out >> >> >> >> > [snip -- more allowed ports] >> >> >> >> > # deny and log everything >> >> >> >> > $IPF 55000 deny log all from any to any >> >> >> >> > >> >> >> >> > ----- >> >> >> >> > >> >> >> >> > Here's a dump of ipfw show, with some stuff cut out for space purposes >> >> >> >> > (they're just denied DDoS IPs) >> >> >> >> > >> >> >> >> > [root@nub /etc]# ipfw show >> >> >> >> > 00010 61124 16056802 allow ip from any to any via lo0 >> >> >> >> > 00020 0 0 deny ip from any to 127.0.0.0/8 >> >> >> >> > 00030 0 0 deny ip from 127.0.0.0/8 to any >> >> >> >> > 00040 0 0 deny tcp from any to any frag >> >> >> >> > 00050 0 0 check-state >> >> >> >> > 00060 670616 455926379 allow tcp from any to any established >> >> >> >> > 00070 16213 14071853 allow ip from any to any out keep-state >> >> >> >> > [snip] >> >> >> >> > 50220 468 22464 divert 8668 ip from any to 207.210.114.45 >> >> >> >> > dst-port 6667 via rl0 >> >> >> >> > 50230 0 0 divert 8668 ip from any to 207.210.114.45 >> >> >> >> > dst-port 8067 via rl0 >> >> >> >> > 50240 0 0 divert 8668 ip from any to 207.210.114.45 >> >> >> >> > dst-port 8068 via rl0 >> >> >> >> > 50250 0 0 divert 8668 ip from any to 207.210.114.45 >> >> >> >> > dst-port 6697 via rl0 >> >> >> >> > 50260 0 0 divert 8668 ip from any to 207.210.114.45 >> >> >> >> > dst-port 7000 via rl0 >> >> >> >> > 50270 1 60 allow ip from any to any dst-port 31337 in >> >> >> >> > 54999 66 3991 allow icmp from any to any >> >> >> >> > 55000 4364 343609 deny log logamount 100 ip from any to any >> >> >> >> > 65535 29 4176 allow ip from any to any >> >> >> >> > >> >> >> >> > My natd.conf is as follows: >> >> >> >> > >> >> >> >> > [root@nub /etc]# cat natd.conf >> >> >> >> > # Nub.Core NATd >> >> >> >> > verbose >> >> >> >> > alias_address 207.210.114.45 >> >> >> >> > log >> >> >> >> > log_denied >> >> >> >> > log_ipfw_denied >> >> >> >> > pid_file /var/run/natd.pid >> >> >> >> > >> >> >> >> > >> >> >> >> > ### IRC Redirect Ports >> >> >> >> > # 6667 >> >> >> >> >> >> >> >> >> >> >> >> If I understand man natd >> >> >> >> >> >> >> >> >> >> >> >>> redirect_port tcp 72.20.28.202:6667 207.210.114.45:6667 207.210.114.45:6667 >> >> >> >> ^^^^^^^^^^^^^ >> >> >> >> Trafic is comming from 72.65.73.23 - so the rule don't apply >> >> >> >> >> >> >> >> >> >> >> >>> [root@nub /etc]# >> >> >> >> > >> >> >> >> > And, as stated above, I am showing connection diverts to natd. When I >> >> >> >> > run the following three tcpdumps: >> >> >> >> > >> >> >> >> > tcpdump -s 0 -w me_to_nat.pcap -vvv -i rl0 src host 72.65.73.23 and >> >> >> >> > dst host 207.210.114.45 and dst port 6667 >> >> >> >> > tcpdump -s 0 -w nat_to_jail.pcap -vvv -i rl0 src host 72.20.28.202 and >> >> >> >> > dst host 207.210.114.45 and dst port 6667 >> >> >> >> > tcpdump -s 0 -w jail_to_nat.pcap -vvv -i rl0 src host 207.210.114.45 >> >> >> >> > and dst host 72.20.28.202 and src port 6667 >> >> >> >> > >> >> >> >> > Only the "me_to_nat.pcap" gets any data. The rest are 0 bytes. Example: >> >> >> >> > >> >> >> >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 jail_to_nat.pcap >> >> >> >> > -rw-r--r-- 1 root wheel 16384 Mar 21 15:24 me_to_nat.pcap >> >> >> >> > -rw-r--r-- 1 root wheel 0 Mar 21 14:57 nat_to_jail.pcap >> >> >> >> > >> >> >> >> > So, can anyone diagnose and fix this? Thanks. >> >> >> >> > >> >> >> >> > (P.S.: I'm aware of the DNS methods of doing round-robin, but please >> >> >> >> > keep that from this discussion. I need to port-forward round-robin, >> >> >> >> > not whole DNS) >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> 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 Wed Mar 26 08:28:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26E5F106566B for ; Wed, 26 Mar 2008 08:28:16 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D72978FC12 for ; Wed, 26 Mar 2008 08:28:15 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JeQzU-0007FM-GD for freebsd-net@freebsd.org; Wed, 26 Mar 2008 08:28:12 +0000 Received: from 195.208.174.178 ([195.208.174.178]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Mar 2008 08:28:12 +0000 Received: from vadim_nuclight by 195.208.174.178 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Mar 2008 08:28:12 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Vadim Goncharov Date: Wed, 26 Mar 2008 08:28:02 +0000 (UTC) Organization: Nuclear Lightning @ Tomsk, TPU AVTF Hostel Lines: 17 Message-ID: References: <82bdb5ec0803251909i8cd92a0w9812b548798667e1@mail.gmail.com> X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 195.208.174.178 X-Comment-To: sazzadur rahman User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: A query regarding SCTP congestion control X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2008 08:28:16 -0000 Hi sazzadur rahman! On Tue, 25 Mar 2008 21:09:49 -0500; sazzadur rahman wrote about 'A query regarding SCTP congestion control': > I would like to get the values of SCTP congestion control algorithm > variables (*cwnd, ssthresh, flightsize *and* pba)* from any SCTP based > application in runtime for research purpose. Does any API exist in SCTP for > that? Do I need to dig the SCTP code in kernel to get the values? > I will appreciate any help in this regard. Yes, SCTP has the API for retrieving association parameters, but only inside the application using that association. If it is your own-written application - no problem. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From owner-freebsd-net@FreeBSD.ORG Wed Mar 26 11:06:27 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 101051065671 for ; Wed, 26 Mar 2008 11:06:26 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id CA0FD8FC4B for ; Wed, 26 Mar 2008 11:06:26 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id C55EBDCABE; Wed, 26 Mar 2008 07:06:25 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 26 Mar 2008 07:06:25 -0400 X-Sasl-enc: p49qKRG49axIjpu5WRon7rr0fTg7Q2+ODw96JhYe+nED 1206529585 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 2C1ADA0BB; Wed, 26 Mar 2008 07:06:25 -0400 (EDT) Message-ID: <47EA2E30.9010806@incunabulum.net> Date: Wed, 26 Mar 2008 11:06:24 +0000 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: FreeBSD-Net mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dhartmei@FreeBSD.org Subject: CALL FOR FEEDBACK: IGMP and PF interoperability 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, 26 Mar 2008 11:06:27 -0000 It has come to my attention that the default configuration of PF in FreeBSD will block legitimate outgoing IGMP messages. PF is currently not the default firewall in FreeBSD. Anyone using multicast in any way, even for link-scope multicasts (224.x.x.x/24), will be affected by this issue if they use PF as their firewall. This issue was described in this thread: http://lists.freebsd.org/pipermail/freebsd-pf/2006-June/002259.html The documentation does state that allow-opts needs to be specified explicitly -- there is no fine grained control for the IPv4 options actually filtered, however, and currently the IP Router Alert option is handled in the main path in all BSD derived systems. Please let me know if you have encountered this issue, so that we can get started on a workaround. cheers BMS From owner-freebsd-net@FreeBSD.ORG Thu Mar 27 06:50:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 648BD106566B for ; Thu, 27 Mar 2008 06:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 54CBB8FC1D for ; Thu, 27 Mar 2008 06:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2R6o4Fx022651 for ; Thu, 27 Mar 2008 06:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2R6o48b022650; Thu, 27 Mar 2008 06:50:04 GMT (envelope-from gnats) Date: Thu, 27 Mar 2008 06:50:04 GMT Message-Id: <200803270650.m2R6o48b022650@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Alexander Efimov" Cc: Subject: Re: kern/122065: [gre] gre over ipsec not working X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Efimov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 06:50:04 -0000 The following reply was made to PR kern/122065; it has been noted by GNATS. From: "Alexander Efimov" To: bug-followup@FreeBSD.org, alephis@gmail.com Cc: Subject: Re: kern/122065: [gre] gre over ipsec not working Date: Thu, 27 Mar 2008 12:17:43 +0600 ------=_Part_19935_27991802.1206598664906 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline - policies on Windows the same to require ipsec on 192.168.250.0/24 both directions connection type: all network connectins with "accept usecured communication, but always respond using ipsec" turned off certificate type of authentication - confirm with tcpdump that no packets are going out on the real interface? I've got only esp packets, currently can't make tcpdump work with -E - can you still see the packets on enc0? not sure I understand what you mean. - any possible firewall setups? no server and host currently resides in same lan ------=_Part_19935_27991802.1206598664906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline - policies on Windows

the same to require ipsec on 192.168.250.0/24 both directions
connection type: all network connectins
with  "accept usecured communication, but always respond using ipsec" turned off
certificate type of authentication 

- confirm with tcpdump that no packets are going out on the real
interface?

I've got only esp packets, currently can't make tcpdump work with -E 

- can you still see the packets on enc0?
not sure I understand what you mean.

- any possible firewall setups?
no server and host currently resides in same lan 
------=_Part_19935_27991802.1206598664906-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 27 11:43:57 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8141A1065673 for ; Thu, 27 Mar 2008 11:43:57 +0000 (UTC) (envelope-from gizmen@blurp.pl) Received: from albion.azs.pwr.wroc.pl (albion.azs.pwr.wroc.pl [156.17.17.145]) by mx1.freebsd.org (Postfix) with ESMTP id 3D06C8FC26 for ; Thu, 27 Mar 2008 11:43:56 +0000 (UTC) (envelope-from gizmen@blurp.pl) Received: from [10.8.1.58] (unknown [213.172.177.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by albion.azs.pwr.wroc.pl (Postfix) with ESMTP id E781811610 for ; Thu, 27 Mar 2008 12:43:55 +0100 (CET) From: Bartosz Giza Organization: BLURP.pl To: freebsd-net@freebsd.org Date: Thu, 27 Mar 2008 12:43:53 +0100 User-Agent: KMail/1.9.7 References: <200803251942.m2PJgOs4083932@freefall.freebsd.org> In-Reply-To: <200803251942.m2PJgOs4083932@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803271243.53888.gizmen@blurp.pl> Subject: Re: kern/122068: [ppp] ppp can not set the correct interface with pptpd 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, 27 Mar 2008 11:43:57 -0000 Tuesday 25 of March 2008 20:42:24 remko@freebsd.org napisa=C5=82(a): > Synopsis: [ppp] ppp can not set the correct interface with pptpd > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: remko > Responsible-Changed-When: Tue Mar 25 19:42:10 UTC 2008 > Responsible-Changed-Why: > over to maintainer group (-net) > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D122068 I am having similar problem with ppp and pppoe. I am trying to implement pppoe with ppp for windows workstations and proble= m=20 is with routing. When first client connects via pppoe tun0 is created and everything is fine= =2E=20 But when second clinet connects tun1 is created but routing to his ip is se= t=20 up via tun0. When i manually delete this routing and set it again but via=20 tun1 tunnel works fine. I have spent last two weeks trying to find what is going on. And today i found this post and i think that my problem is realated to abov= e=20 bug.=20 Could someone tell me is there any work around(patches?) for my problem exc= ept=20 of downgrading to 6.x line (i am using 7.0-rel). Or maybe there is different ppp program which should work fine. Thanks for any help From owner-freebsd-net@FreeBSD.ORG Thu Mar 27 23:41:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 104D6106564A for ; Thu, 27 Mar 2008 23:41:37 +0000 (UTC) (envelope-from daniel@dgnetwork.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [200.179.179.14]) by mx1.freebsd.org (Postfix) with SMTP id 090408FC15 for ; Thu, 27 Mar 2008 23:41:35 +0000 (UTC) (envelope-from daniel@dgnetwork.com.br) Received: (qmail 26739 invoked by uid 1008); 27 Mar 2008 23:41:33 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.6-unknown (2006-10-03) on srvmail2 X-Spam-Level: X-Spam-Status: No, score=-1.9 required=4.7 tests=AWL,BAYES_00 autolearn=ham version=3.1.6-unknown Received: from unknown (HELO ?10.0.1.10?) (daniel@dgnetwork.com.br@200.243.216.68) by mail.mastercabo.com.br with SMTP; 27 Mar 2008 23:41:29 -0000 Message-ID: <47EC303B.1040201@dgnetwork.com.br> Date: Thu, 27 Mar 2008 20:39:39 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= Organization: DGNET Network Solutions User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Understanding Flags, Refs, Use, Expire in Routing Table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel@dgnetwork.com.br List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2008 23:41:37 -0000 I would like an explanation on each field it command "netstat - rn", example: Flags,Refs,Use,Expire In Flags: UGS, UC, UHLW, UH Somebody can explain me ? Thanks, Daniel From owner-freebsd-net@FreeBSD.ORG Fri Mar 28 01:13:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4544B1065672 for ; Fri, 28 Mar 2008 01:13:31 +0000 (UTC) (envelope-from rock_on_the_web@comcen.com.au) Received: from angel.comcen.com.au (angel.comcen.com.au [203.23.236.69]) by mx1.freebsd.org (Postfix) with ESMTP id D25E98FC1C for ; Fri, 28 Mar 2008 01:13:30 +0000 (UTC) (envelope-from rock_on_the_web@comcen.com.au) Received: from [192.168.0.199] (202-172-126-254.cpe.qld-1.comcen.com.au [202.172.126.254]) by angel.comcen.com.au (8.13.4/8.12.9) with ESMTP id m2S10Yd2040240 for ; Fri, 28 Mar 2008 12:00:36 +1100 (EST) From: Da Rock To: freebsd-net@freebsd.org Content-Type: text/plain Date: Fri, 28 Mar 2008 11:00:23 +1000 Message-Id: <1206666023.4155.21.camel@laptop2.herveybayaustralia.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-3.fc8) Content-Transfer-Encoding: 7bit X-comcen-MailScanner-Information: Please contact the ISP for more information X-comcen-MailScanner: Found to be clean X-comcen-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-16.43, required 4, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.37, BAYES_00 -15.00) X-comcen-MailScanner-From: rock_on_the_web@comcen.com.au Subject: DDNS, ISC-DHCPD, and Bind... not working because of strange error messages 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, 28 Mar 2008 01:13:31 -0000 (Sorry for cross posting- I originally sent this to the questions list but got no response, and on further reflection [considering the content] If figured that the most experience in these matters would exist here. If you don't mind, I'll stick around and watch this list so that I might learn something too :) ) I did actually manage to get this to work, and I can't exactly work out what changed to cause this error. I set this up at the end of last year, and it worked- kind of. The failure was my own by not using a proper FQDN, but it worked unofficially anyway. Records were updating etc: all happy. Anyway, I finally got the FQDN worked out (split horizon dns- external and internal views), but I find that the ddns is not working: and not because of the changes I made. I looked back and found the problem going on for month. My messages file has these entries, and no amount of googling has brought me any closer to finding out what they could mean, or why my clients aren't updating: Mar 27 16:18:54 {$HOSTNAME} dhcpd: pool.ntp.org: no A record associated with address I've edited the hostname to protect the innocent. What I can't figure out is why would dhcpd be looking at pool.ntp.org? I ran a dig on pool.ntp.org on the off chance it was busted- but of course it was not. And this record pops up everytime I renew my ip addresses. Weird... Little help anyone? Cheers From owner-freebsd-net@FreeBSD.ORG Fri Mar 28 10:50:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D4E4106564A for ; Fri, 28 Mar 2008 10:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 547748FC15 for ; Fri, 28 Mar 2008 10:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2SAo3TI043096 for ; Fri, 28 Mar 2008 10:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2SAo36k043095; Fri, 28 Mar 2008 10:50:03 GMT (envelope-from gnats) Date: Fri, 28 Mar 2008 10:50:03 GMT Message-Id: <200803281050.m2SAo36k043095@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Jonas Wolz" Cc: Subject: Re: kern/119225: [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card (regression) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jonas Wolz List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 10:50:04 -0000 The following reply was made to PR kern/119225; it has been noted by GNATS. From: "Jonas Wolz" To: bug-followup@freebsd.org, jyrki.k@post.cz Cc: Subject: Re: kern/119225: [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card (regression) Date: Fri, 28 Mar 2008 11:45:53 +0100 I recently did some more experimenting and found an workaround that works for me ("ifconfig scan" still doesn' work): When I use an old ISC dhclient binary from FreeBSD 5 which ignores the "no carrier" status and sends the DHCP requests anyway, I get an IP address from the router and ifconfig shows "status: associated" afterwards. (and the network works just fine) Manually setting the IP address seems not work, however (but this might be also my router...). From owner-freebsd-net@FreeBSD.ORG Fri Mar 28 15:56:05 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D405E106566C; Fri, 28 Mar 2008 15:56:05 +0000 (UTC) (envelope-from jessy@sicha.net) Received: from viefep26-int.chello.at (viefep26-int.chello.at [62.179.121.46]) by mx1.freebsd.org (Postfix) with ESMTP id 0FCEF8FC2C; Fri, 28 Mar 2008 15:56:04 +0000 (UTC) (envelope-from jessy@sicha.net) Received: from du.sicha.net ([84.113.235.172]) by viefep19-int.chello.at (InterMail vM.7.08.02.02 201-2186-121-104-20070414) with ESMTP id <20080328154028.JPUO5883.viefep19-int.chello.at@du.sicha.net>; Fri, 28 Mar 2008 16:40:28 +0100 X-Virus-Scanned: amavisd-new at sicha.net Message-Id: From: Robert Jesacher To: daniel@dgnetwork.com.br In-Reply-To: <47EC303B.1040201@dgnetwork.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 28 Mar 2008 16:39:31 +0100 References: <47EC303B.1040201@dgnetwork.com.br> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Understanding Flags, Refs, Use, Expire in Routing Table 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, 28 Mar 2008 15:56:06 -0000 Hi Daniel, you find mostl of you questions answered in "man netstat" (the =20 relevant passage is posted below) The missing part is the expiry, which IMHO are the seconds, the ARP =20 entry is valid (after this time a new arp request would be issued) I hope this is the information you needed. br, Robert +++++++++++++++ The routing table display indicates the available routes and their sta- tus. Each route consists of a destination host or network, and =20= a gateway to use in forwarding packets. The flags field shows a =20 collection of information about the route stored as binary choices. The =20 individual flags are discussed in more detail in the route(8) and route(4) =20= manual pages. The mapping between letters and flags is: 1 RTF_PROTO1 Protocol specific routing flag #1 2 RTF_PROTO2 Protocol specific routing flag #2 3 RTF_PROTO3 Protocol specific routing flag #3 B RTF_BLACKHOLE Just discard pkts (during updates) b RTF_BROADCAST The route represents a broadcast address C RTF_CLONING Generate new routes on use c RTF_PRCLONING Protocol-specified generate new routes on =20= use D RTF_DYNAMIC Created dynamically (by redirect) G RTF_GATEWAY Destination requires forwarding by =20 intermediary H RTF_HOST Host entry (net otherwise) L RTF_LLINFO Valid protocol to link address translation M RTF_MODIFIED Modified dynamically (by redirect) R RTF_REJECT Host or net unreachable S RTF_STATIC Manually added U RTF_UP Route usable W RTF_WASCLONED Route was generated as a result of cloning X RTF_XRESOLVE External daemon translates proto to link =20 address Direct routes are created for each interface attached to the =20 local host; the gateway field for such entries shows the address of the =20 outgoing interface. The refcnt field gives the current number of active =20= uses of the route. Connection oriented protocols normally hold on to a =20= single route for the duration of a connection while connectionless =20 protocols obtain a route while sending to the same destination. The use =20 field pro- vides a count of the number of packets sent using that route. =20 The inter- face entry indicates the network interface utilized for the route. +++++++++++++++++++++ On 28.03.2008, at 00:39, Daniel Dias Gon=E7alves wrote: > I would like an explanation on each field it command "netstat - rn", =20= > example: > Flags,Refs,Use,Expire > In Flags: UGS, UC, UHLW, UH > Somebody can explain me ? > > Thanks, > Daniel > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to = "freebsd-questions-unsubscribe@freebsd.org=20 > " From owner-freebsd-net@FreeBSD.ORG Fri Mar 28 16:48:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0AF31065673; Fri, 28 Mar 2008 16:48:31 +0000 (UTC) (envelope-from SRS0=2e2a31498d13a62da0deeb64394e9e30cbee5c10=654=es.net=oberman@es.net) Received: from postal1.es.net (postal3.es.net [IPv6:2001:400:14:3::8]) by mx1.freebsd.org (Postfix) with ESMTP id 3296D8FC1B; Fri, 28 Mar 2008 16:48:31 +0000 (UTC) (envelope-from SRS0=2e2a31498d13a62da0deeb64394e9e30cbee5c10=654=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id ITY88829; Fri, 28 Mar 2008 09:48:29 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id F14814500F; Fri, 28 Mar 2008 09:48:28 -0700 (PDT) To: Robert Jesacher In-Reply-To: Your message of "Fri, 28 Mar 2008 16:39:31 BST." Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1206722908_12662P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 28 Mar 2008 09:48:28 -0700 From: "Kevin Oberman" Message-Id: <20080328164828.F14814500F@ptavv.es.net> X-Sender-IP: 198.128.4.29 X-Sender-Domain: es.net X-Recipent: ; ; ; ; X-Sender: X-To_Name: Robert Jesacher X-To_Domain: sicha.net X-To: Robert Jesacher X-To_Email: jessy@sicha.net X-To_Alias: jessy Cc: daniel@dgnetwork.com.br, freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Understanding Flags, Refs, Use, Expire in Routing Table 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, 28 Mar 2008 16:48:31 -0000 --==_Exmh_1206722908_12662P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > From: Robert Jesacher > Date: Fri, 28 Mar 2008 16:39:31 +0100 > Sender: owner-freebsd-net@freebsd.org > > Hi Daniel, > > you find mostl of you questions answered in "man netstat" (the > relevant passage is posted below) > The missing part is the expiry, which IMHO are the seconds, the ARP > entry is valid (after this time a new arp request would be issued) > > I hope this is the information you needed. It makes following a thread really hard. It's all (mostly) Microsoft's fault! > Why? > > I wish people would stop top-posting! The Expire entry is the result of FreeBSD's unfortunate co-mingling network layer routing information with layer 2 ARP information. The only entries with "Expire" values are actually ARP entries. (Note the MAC address os "Gateway".) Expire is in seconds remaining until the entry expires and is no longer used. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1206722908_12662P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFH7SFckn3rs5h7N1ERAmxvAJ0Wco42LPxwEvC5wS9RxPloo4ZbjQCdGPvO G66KESVv8jmacHSbmgCnSig= =A77z -----END PGP SIGNATURE----- --==_Exmh_1206722908_12662P-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 28 17:02:31 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37FEF106566B for ; Fri, 28 Mar 2008 17:02:31 +0000 (UTC) (envelope-from sinister@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id DDBAF8FC1D for ; Fri, 28 Mar 2008 17:02:30 +0000 (UTC) (envelope-from sinister@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so501494pyb.10 for ; Fri, 28 Mar 2008 10:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:from:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; bh=L+XE7LSZOwyGYU3beUlVm8fWaFFUrjqjsE4wH76H5jo=; b=Xa3yXthbnDPT1IItCa8taun2OH6G9x0HqObIu2M7r5skVgTrPJo85kE4DYq8wKNaXPNSbyPpQtaD9u7n739JDoeXLRIxm27anOjB+G1COH2b8xb/zfT1wKLFPORMkknhM5hoewgZSzvnXCb6pR6mACNp/FgaagN1mhDOEmIrFGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:from:to:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=GRG+OwxbRA/nsYDYkyEbFCXt/Y/CQzduF5DDzch4k87kUv7W2D/UZUoLGHkeJh0G2G61VWWVHzdF0cA5C6Z3FraJqAN/p9tZ+zWM64w95vI9jn8fV1OcDcGzX/F3Vzp+KjCgEYD47MXVsYZ3ZQNUcIHH+6I6+pT7x3GWEYOV0fw= Received: by 10.35.28.12 with SMTP id f12mr5824953pyj.45.1206723749842; Fri, 28 Mar 2008 10:02:29 -0700 (PDT) Received: from dts ( [216.8.139.47]) by mx.google.com with ESMTPS id y78sm6353805pyg.17.2008.03.28.10.02.28 (version=SSLv3 cipher=RC4-MD5); Fri, 28 Mar 2008 10:02:28 -0700 (PDT) Message-ID: <019c01c890f5$95155690$0200a8c0@dts> From: "Sin" To: Date: Fri, 28 Mar 2008 13:03:00 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: netstat -s bridge question 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, 28 Mar 2008 17:02:31 -0000 I've noticed there's a new way to bridge NIC's on BSD. But the new way = doesn't show bridging stats in " netstat -s " here's netstat -s from 6.2 RELEASE. -- Bridging statistics (bdg) -- Name In Out Forward Drop Bcast Mcast Local = Unknown sk0:1 23889560 19694957 32228 0 3969 304695 23548555 = 113 sk1:1 373597 1245545 23588 0 4127 3 345340 = 539 sk2:1 98950 939430 0 0 39 275 98636 = 0 rl0:1 0 759073 0 0 0 0 0 = 0 ed1:1 20892045 25355369 5670 0 0 21 20886350 = 4 ed2:1 368726 1101166 11086 0 519 306 356813 = 2 Anyone know how to get a stat like this with the newer method in 6.3/7.0 = ? From owner-freebsd-net@FreeBSD.ORG Fri Mar 28 17:31:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8800106564A; Fri, 28 Mar 2008 17:31:55 +0000 (UTC) (envelope-from ap00@mail.ru) Received: from mx0.awanti.com (mx0.awanti.com [91.190.112.18]) by mx1.freebsd.org (Postfix) with ESMTP id A2DE38FC15; Fri, 28 Mar 2008 17:31:55 +0000 (UTC) (envelope-from ap00@mail.ru) Received: by mx0.awanti.com (Postfix, from userid 100) id F1AF74C022; Fri, 28 Mar 2008 20:13:18 +0300 (MSK) X-Spam-Flag: NO X-Spam-Checker-Version: SpamAssassin 3.1.9 on mx0.awanti.com X-Spam-Status: No, score=-2.3 required=6.5 tests=AWL,BAYES_00 autolearn=ham version=3.1.9 Received: from pstation (unknown [10.28.4.14]) by mx0.awanti.com (Postfix) with ESMTP id 467204C019; Fri, 28 Mar 2008 20:13:17 +0300 (MSK) Date: Fri, 28 Mar 2008 20:14:58 +0300 From: Anthony Pankov X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) Message-ID: <1333421734.20080328201458@mail.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: performance@freebsd.org Subject: packet delay because of blackhole X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anthony Pankov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 17:31:56 -0000 Just for somebody convince. While analyzing client<->server HTTPS conversation one second delay in packet exchange was discovered (strongly reproducible): Sample: N time 6 0.002303 10.28.4.14 10.28.4.50 SSL Client Hello 7 0.106710 10.28.4.50 10.28.4.14 TCP 443 > 1447 [ACK] Seq=1 Ack=103 Win=65535 Len=0 8 1.045712 10.28.4.50 10.28.4.14 TLSv1 Server Hello, Certificate, Server Hello Done Another sample: 10 0.011722 10.28.4.14 10.28.4.50 TLSv1 Application Data 11 0.115933 10.28.4.50 10.28.4.14 TCP 443 > 1442 [ACK] Seq=839 Ack=519 Win=65466 Len=0 12 1.054037 10.28.4.50 10.28.4.14 TLSv1 Application Data The reason for delay is sysctl tcp.blackhole value grater than 0, much to surprise. So, turning tcp.blackhole to 0 eliminate any delay (strongly reproducible). System: FreeBSD 6_2_stable -- Best regards, Anthony mailto:ap00@mail.ru From owner-freebsd-net@FreeBSD.ORG Fri Mar 28 17:37:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2DD2106566B for ; Fri, 28 Mar 2008 17:37:06 +0000 (UTC) (envelope-from jerrymc@gizmo.acns.msu.edu) Received: from gizmo.acns.msu.edu (gizmo.acns.msu.edu [35.8.1.43]) by mx1.freebsd.org (Postfix) with ESMTP id 6D5A28FC1A for ; Fri, 28 Mar 2008 17:37:06 +0000 (UTC) (envelope-from jerrymc@gizmo.acns.msu.edu) Received: from gizmo.acns.msu.edu (localhost [127.0.0.1]) by gizmo.acns.msu.edu (8.13.6/8.13.6) with ESMTP id m2SH9Lao008711; Fri, 28 Mar 2008 13:09:21 -0400 (EDT) (envelope-from jerrymc@gizmo.acns.msu.edu) Received: (from jerrymc@localhost) by gizmo.acns.msu.edu (8.13.6/8.13.6/Submit) id m2SH9KeI008710; Fri, 28 Mar 2008 13:09:20 -0400 (EDT) (envelope-from jerrymc) Date: Fri, 28 Mar 2008 13:09:20 -0400 From: Jerry McAllister To: Kevin Oberman Message-ID: <20080328170920.GE8233@gizmo.acns.msu.edu> References: <20080328164828.F14814500F@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080328164828.F14814500F@ptavv.es.net> User-Agent: Mutt/1.4.2.2i Cc: Robert Jesacher , daniel@dgnetwork.com.br, freebsd-questions@freebsd.org, freebsd-net@freebsd.org Subject: Re: Understanding Flags, Refs, Use, Expire in Routing Table 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, 28 Mar 2008 17:37:06 -0000 On Fri, Mar 28, 2008 at 09:48:28AM -0700, Kevin Oberman wrote: > > From: Robert Jesacher > > Date: Fri, 28 Mar 2008 16:39:31 +0100 > > Sender: owner-freebsd-net@freebsd.org > > > > Hi Daniel, > > > > you find mostl of you questions answered in "man netstat" (the > > relevant passage is posted below) > > The missing part is the expiry, which IMHO are the seconds, the ARP > > entry is valid (after this time a new arp request would be issued) > > > > I hope this is the information you needed. > Isn't everything?! > It makes following a thread really hard. It's all (mostly) Microsoft's fault! > > Why? > > > I wish people would stop top-posting! > > The Expire entry is the result of FreeBSD's unfortunate co-mingling > network layer routing information with layer 2 ARP information. The only > entries with "Expire" values are actually ARP entries. (Note the MAC > address os "Gateway".) > > Expire is in seconds remaining until the entry expires and is no longer > used. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-net@FreeBSD.ORG Fri Mar 28 18:30:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D579106566B for ; Fri, 28 Mar 2008 18:30:25 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from n126.sc0.he.tucows.com (smtpout1100.sc0.he.tucows.com [64.97.144.100]) by mx1.freebsd.org (Postfix) with ESMTP id 6342C8FC1E for ; Fri, 28 Mar 2008 18:30:25 +0000 (UTC) (envelope-from eagletree@hughes.net) Received: from sc0-out02.emaildefenseservice.com (64.97.131.2) by n126.sc0.he.tucows.com (7.2.069.1) id 47AEF770006E1D4E for freebsd-net@freebsd.org; Fri, 28 Mar 2008 18:30:24 +0000 X-SpamScore: 2 X-Spamcatcher-Summary: 2, 0, 0, e3bcfac6d81a7b40, e4301484d0a2b177, eagletree@hughes.net, -, RULES_HIT:355:379:541:564:945:966:973:988:989:1260:1261:1277:1311:1313:1314:1345:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1766:1792:2196:2198:2199:2200:2393:2559:2562:2693:3354:3622:3636:3865:3866:3867:3868:3869:3870:3871:3872:3874:4250:4385:4774:5007:6117:6119:7652, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none, TSO:0 X-Spamcatcher-Explanation: Received: from [192.168.0.3] (dpc6744118153.direcpc.com [67.44.118.153]) (Authenticated sender: eagletree@hughes.net) by sc0-out02.emaildefenseservice.com (Postfix) with ESMTP for ; Fri, 28 Mar 2008 18:30:18 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v753) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <921F19D4-0900-4975-B7D9-C0D6BCA1460D@hughes.net> Content-Transfer-Encoding: 7bit From: Chris Date: Fri, 28 Mar 2008 11:20:12 -0700 To: freebsd-net@freebsd.org X-Mailer: Apple Mail (2.753) Subject: if_bridge performance issue? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: snagit@cbpratt.prohosting.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 18:30:25 -0000 Hello, I was wondering if I'm seeing a normal issue with if_bridge and having an IP assigned to one of the interfaces within a bridge. I see a confusing performance problem when attempting to move data via sftp "to" the machine versus "through" the machine. The difference is quite pronounced. When I sftp through the bridge to another FreeBSD machine behind it (A very old and slow Compaq running FreeBSD 6.2), I get acceptable performance averaging 1.5MB Per Second. When I send to the IP on the interface of the bridge (coming in through the same em NIC), I get ~320KB Per Second. The bridge system uses modern SATA Drives so I'm pretty sure it's not disk speed slowing the bridge system. I've monitored IPFW to try and find a bottleneck in the rules for the local interface. It turns out it's just the opposite in that when passing through the system, many additional rules are traversed while the rules for the local interface immediately are passed on a dynamic rule. In fact the bridged traffic is passing through snort_inline via divert, the local interface traffic is not. I'm not sure I actually care that this performance difference is occurring since very little traffic will go to the bridge system, but it does make me wonder if I've done something odd to cause it. Is there any reason why the local interface on an if_bridge bridge computer would show worse performance for the same operations that pass through the bridge to other systems. The config is: Bridge System FreeBSD 7.0 Release, if_bridge and ipfw compiled into the Kernel Dual CPU Intel Supermicro with SATA drives Dual port em NICs (have tried multiples now) Test Server behind Bridge FreeBSD 6.2 Release, runs just apache and sshd 900mhz Athlon with IDE Drives Single port em NIC Test Client Dual Macintosh G5 tower running 10.4 OS-X Results SFTP to Bridge System File Size: 46 MB, Duration of transfer: ~2.25 Minutes, Reported Performance: 324KBPS SFTP to Test Server File Size: 46 MB, Duration of transfer: ~34 Seconds, Reported Performance: 1.4MBPS rc.conf relevant entries: ifconfig_em1="inet 192.168.0.221 netmask 255.255.255.0 media 100baseTX mediaopt full-duplex polling" ifconfig_em0="media 100baseTX mediaopt full-duplex polling" # em0 LAN, em1 T1 WAN cloned_interfaces="bridge0" ifconfig_bridge0="addm em0 up addm em1 up" (note, both tests are incoming through em1.) From owner-freebsd-net@FreeBSD.ORG Fri Mar 28 18:56:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77603106567A for ; Fri, 28 Mar 2008 18:56:35 +0000 (UTC) (envelope-from SRS0=RvP3vR=UO=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout14.yourhostingaccount.com (mailout14.yourhostingaccount.com [65.254.253.117]) by mx1.freebsd.org (Postfix) with ESMTP id 43F2E8FC3D for ; Fri, 28 Mar 2008 18:56:35 +0000 (UTC) (envelope-from SRS0=RvP3vR=UO=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailscan17.yourhostingaccount.com ([10.1.15.17] helo=mailscan17.yourhostingaccount.com) by mailout14.yourhostingaccount.com with esmtp (Exim) id 1JfJHE-0000Ip-SY for freebsd-net@freebsd.org; Fri, 28 Mar 2008 14:26:08 -0400 Received: from impout03.yourhostingaccount.com ([10.1.55.3] helo=impout03.yourhostingaccount.com) by mailscan17.yourhostingaccount.com with esmtp (Exim) id 1JfJHE-0000PZ-DN for freebsd-net@freebsd.org; Fri, 28 Mar 2008 14:26:08 -0400 Received: from authsmtp10.yourhostingaccount.com ([10.1.18.10]) by impout03.yourhostingaccount.com with NO UCE id 6iS81Z0020D2B7u0000000; Fri, 28 Mar 2008 14:26:08 -0400 X-EN-OrigOutIP: 10.1.18.10 X-EN-IMPSID: 6iS81Z0020D2B7u0000000 Received: from c-68-51-74-1.hsd1.il.comcast.net ([68.51.74.1] helo=vixen42) by authsmtp10.yourhostingaccount.com with esmtpa (Exim) id 1JfJHD-00028F-Ng for freebsd-net@freebsd.org; Fri, 28 Mar 2008 14:26:08 -0400 Date: Fri, 28 Mar 2008 13:27:07 -0500 From: "Zane C.B." To: FreeBSD-Net mailing list Message-ID: <20080328132707.7d12c609@vixen42> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i386-portbld-freebsd6.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-EN-UserInfo: 0d1ca1697cdb7a831d4877828571b7ab:1570f0de6936c69fef9e164fffc541bc X-EN-AuthUser: vvelox2 Sender: "Zane C.B." X-EN-OrigIP: 68.51.74.1 X-EN-OrigHost: c-68-51-74-1.hsd1.il.comcast.net Subject: oddness with wpa_cli save_config 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, 28 Mar 2008 18:56:35 -0000 Just sat down and begin playing around with wpa_cli. I have one network network setup already in '/etc/wpa_supplicant.conf'. This is working with out issue. Now I try the following from wpa_cli and just the the message back "FAIL". > add_network test 1 > set_network 1 ssid "test" OK > save_config FAIL =46rom my understanding that should be fine as ssid is the only required thing for a network. Not truely useful, but should still work. -rw-r----- 1 root wheel 322B Nov 25 22:35 /etc/wpa_supplicant.conf USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 321 0.0 0.1 3048 2416 ?? Ss 1:16PM 0:00.15 /usr/sbin/wpa_supplicant -B -q -i ath0 -c /etc/wpa_supplicant.conf -D bsd -P /var/run/wpa_supplicant/ath0.pid Any suggestions? From owner-freebsd-net@FreeBSD.ORG Fri Mar 28 19:15:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AED5106564A for ; Fri, 28 Mar 2008 19:15:37 +0000 (UTC) (envelope-from SRS0=RvP3vR=UO=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout17.yourhostingaccount.com (mailout17.yourhostingaccount.com [65.254.253.138]) by mx1.freebsd.org (Postfix) with ESMTP id E3E898FC1C for ; Fri, 28 Mar 2008 19:15:36 +0000 (UTC) (envelope-from SRS0=RvP3vR=UO=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailscan10.yourhostingaccount.com ([10.1.15.10] helo=mailscan10.yourhostingaccount.com) by mailout17.yourhostingaccount.com with esmtp (Exim) id 1JfK35-0005om-UN for freebsd-net@freebsd.org; Fri, 28 Mar 2008 15:15:35 -0400 Received: from impout03.yourhostingaccount.com ([10.1.55.3] helo=impout03.yourhostingaccount.com) by mailscan10.yourhostingaccount.com with esmtp (Exim) id 1JfK35-0000ow-PP for freebsd-net@freebsd.org; Fri, 28 Mar 2008 15:15:35 -0400 Received: from authsmtp10.yourhostingaccount.com ([10.1.18.10]) by impout03.yourhostingaccount.com with NO UCE id 6jFb1Z0020D2B7u0000000; Fri, 28 Mar 2008 15:15:35 -0400 X-EN-OrigOutIP: 10.1.18.10 X-EN-IMPSID: 6jFb1Z0020D2B7u0000000 Received: from c-68-51-74-1.hsd1.il.comcast.net ([68.51.74.1] helo=vixen42) by authsmtp10.yourhostingaccount.com with esmtpa (Exim) id 1JfK34-00037c-MP for freebsd-net@freebsd.org; Fri, 28 Mar 2008 15:15:34 -0400 Date: Fri, 28 Mar 2008 14:16:35 -0500 From: "Zane C.B." To: FreeBSD-Net mailing list Message-ID: <20080328141635.4558c7e6@vixen42> In-Reply-To: <20080328132707.7d12c609@vixen42> References: <20080328132707.7d12c609@vixen42> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i386-portbld-freebsd6.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EN-UserInfo: 0d1ca1697cdb7a831d4877828571b7ab:1570f0de6936c69fef9e164fffc541bc X-EN-AuthUser: vvelox2 Sender: "Zane C.B." X-EN-OrigIP: 68.51.74.1 X-EN-OrigHost: c-68-51-74-1.hsd1.il.comcast.net Subject: Re: oddness with wpa_cli save_config (FIXED) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 19:15:37 -0000 On Fri, 28 Mar 2008 13:27:07 -0500 "Zane C.B." wrote: > Just sat down and begin playing around with wpa_cli. > > I have one network network setup already in > '/etc/wpa_supplicant.conf'. This is working with out issue. Now I > try the following from wpa_cli and just the the message back "FAIL". > > > add_network test > 1 > > set_network 1 ssid "test" > OK > > save_config > FAIL > > > From my understanding that should be fine as ssid is the only > required thing for a network. Not truely useful, but should still > work. > > > -rw-r----- 1 root wheel 322B Nov 25 > 22:35 /etc/wpa_supplicant.conf > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME > COMMAND > root 321 0.0 0.1 3048 2416 ?? Ss 1:16PM > 0:00.15 /usr/sbin/wpa_supplicant -B -q -i ath0 > -c /etc/wpa_supplicant.conf -D bsd > -P /var/run/wpa_supplicant/ath0.pid > > > Any suggestions? > _______________________________________________ > 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" It turns out 'update_config=1' needed added to the config. From owner-freebsd-net@FreeBSD.ORG Fri Mar 28 19:31:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1C551065677 for ; Fri, 28 Mar 2008 19:31:47 +0000 (UTC) (envelope-from SRS0=RvP3vR=UO=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailout03.yourhostingaccount.com (mailout03.yourhostingaccount.com [65.254.253.27]) by mx1.freebsd.org (Postfix) with ESMTP id 9D9528FC14 for ; Fri, 28 Mar 2008 19:31:47 +0000 (UTC) (envelope-from SRS0=RvP3vR=UO=vvelox.net=v.velox@yourhostingaccount.com) Received: from mailscan02.yourhostingaccount.com ([10.1.15.2] helo=mailscan02.yourhostingaccount.com) by mailout03.yourhostingaccount.com with esmtp (Exim) id 1JfKIk-0006mm-E4 for freebsd-net@freebsd.org; Fri, 28 Mar 2008 15:31:46 -0400 Received: from impout02.yourhostingaccount.com ([10.1.55.2] helo=impout02.yourhostingaccount.com) by mailscan02.yourhostingaccount.com with esmtp (Exim) id 1JfKIk-0004RF-3s for freebsd-net@freebsd.org; Fri, 28 Mar 2008 15:31:46 -0400 Received: from authsmtp09.yourhostingaccount.com ([10.1.18.9]) by impout02.yourhostingaccount.com with NO UCE id 6jXm1Z0020BkWne0000000; Fri, 28 Mar 2008 15:31:46 -0400 X-EN-OrigOutIP: 10.1.18.9 X-EN-IMPSID: 6jXm1Z0020BkWne0000000 Received: from c-68-51-74-1.hsd1.il.comcast.net ([68.51.74.1] helo=vixen42) by authsmtp09.yourhostingaccount.com with esmtpa (Exim) id 1JfKIj-0006rC-A2 for freebsd-net@freebsd.org; Fri, 28 Mar 2008 15:31:45 -0400 Date: Fri, 28 Mar 2008 14:32:46 -0500 From: "Zane C.B." To: FreeBSD-Net mailing list Message-ID: <20080328143246.1b5be472@vixen42> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; i386-portbld-freebsd6.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EN-UserInfo: 0d1ca1697cdb7a831d4877828571b7ab:1570f0de6936c69fef9e164fffc541bc X-EN-AuthUser: vvelox2 Sender: "Zane C.B." X-EN-OrigIP: 68.51.74.1 X-EN-OrigHost: c-68-51-74-1.hsd1.il.comcast.net Subject: getting SSID that are ifconfig list scan unfriently (spaces and unprintable characters) 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, 28 Mar 2008 19:31:47 -0000 Just sitting down beginning to write a perl module for getting wireless info under FreeBSD. With out knowing C, is there any way to get SSID info for networks that contain something that makes ifconfig list scan unfriendly to parse? Like spaces and unprintable characters. From owner-freebsd-net@FreeBSD.ORG Sat Mar 29 13:42:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18E941065711 for ; Sat, 29 Mar 2008 13:42:50 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [91.103.162.4]) by mx1.freebsd.org (Postfix) with ESMTP id C89B08FC1F for ; Sat, 29 Mar 2008 13:42:49 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from localhost (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id C91C419E023 for ; Sat, 29 Mar 2008 14:23:02 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 3289D19E019 for ; Sat, 29 Mar 2008 14:23:00 +0100 (CET) Message-ID: <47EE42C8.3070100@quip.cz> Date: Sat, 29 Mar 2008 14:23:20 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cz, cs, en, en-us MIME-Version: 1.0 To: FreeBSD-Net mailing list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: 7.0 - ifconfig create is not working as expected? 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, 29 Mar 2008 13:42:50 -0000 Hi, I was using following command in FreeBSD 6.2: # ifconfig lo1 create inet 172.16.16.2 netmask 255.255.255.0 In FreeBSD 7.0 I got an error: # ifconfig lo1 create inet 172.16.16.2 netmask 255.255.255.0 ifconfig: inet: bad value But it is working splitted in to two commands: # ifconfig lo1 create # ifconfig lo1 inet 172.16.16.2 netmask 255.255.255.0 Is this expected behavior or should I file a PR? Miroslav Lachman From owner-freebsd-net@FreeBSD.ORG Sat Mar 29 20:43:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B35B1106566B for ; Sat, 29 Mar 2008 20:43:42 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4E1158FC18 for ; Sat, 29 Mar 2008 20:43:42 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.2/8.14.2) with ESMTP id m2TKhj3X066939; Sat, 29 Mar 2008 15:43:45 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.2/8.14.2/Submit) id m2TKhih2066938; Sat, 29 Mar 2008 15:43:44 -0500 (CDT) (envelope-from brooks) Date: Sat, 29 Mar 2008 15:43:44 -0500 From: Brooks Davis To: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20080329204344.GA66910@lor.one-eyed-alien.net> References: <47EE42C8.3070100@quip.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <47EE42C8.3070100@quip.cz> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Sat, 29 Mar 2008 15:43:45 -0500 (CDT) Cc: FreeBSD-Net mailing list Subject: Re: 7.0 - ifconfig create is not working as expected? 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, 29 Mar 2008 20:43:42 -0000 --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 29, 2008 at 02:23:20PM +0100, Miroslav Lachman wrote: > Hi, >=20 > I was using following command in FreeBSD 6.2: >=20 > # ifconfig lo1 create inet 172.16.16.2 netmask 255.255.255.0 >=20 > In FreeBSD 7.0 I got an error: >=20 > # ifconfig lo1 create inet 172.16.16.2 netmask 255.255.255.0 > ifconfig: inet: bad value >=20 > But it is working splitted in to two commands: > # ifconfig lo1 create > # ifconfig lo1 inet 172.16.16.2 netmask 255.255.255.0 >=20 > Is this expected behavior or should I file a PR? This expected. There's some argument it's wrong, but filing a PR is unlikely to cause it to change any time soon. -- Brooks --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFH7qn+XY6L6fI4GtQRAqVsAJ9oQcEU4sggO2lDRDPQyeL0x0BIzgCgu3jH PLdwxJqMAJ9xvQnzKLffNgg= =j5/G -----END PGP SIGNATURE----- --huq684BweRXVnRxX--