From owner-freebsd-net@FreeBSD.ORG Sun Aug 7 17:10:31 2011 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 6399B106564A for ; Sun, 7 Aug 2011 17:10:31 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1EED98FC15 for ; Sun, 7 Aug 2011 17:10:30 +0000 (UTC) Received: by ywm39 with SMTP id 39so2878965ywm.13 for ; Sun, 07 Aug 2011 10:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Qugqg/5+lZvSk6bqVLU2/lAs5RKpYfQ4igR8ctqLLuc=; b=YvSDCOTDgVRrAKiCp8Yf+Odval2Km+hfbev09RhyNgehozwN9V2+I5hNrhbtR3H+hZ OvfsuaiPLGDFv2fDPT/NAKJrNGGHA56sVAfhLJuQNVI/hrCMmFTGAhJE5hjgEDoJY/9x 55j1kS38oTXOdGQ9KHr0Y9WYnDt5ifrPS5GPM= MIME-Version: 1.0 Received: by 10.150.103.1 with SMTP id a1mr5004133ybc.244.1312735227533; Sun, 07 Aug 2011 09:40:27 -0700 (PDT) Received: by 10.150.200.3 with HTTP; Sun, 7 Aug 2011 09:40:27 -0700 (PDT) In-Reply-To: References: Date: Sun, 7 Aug 2011 20:40:27 +0400 Message-ID: From: Sergey Kandaurov To: Tom Vijlbrief Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net , freebsd-current@freebsd.org Subject: Re: BETA1 IPv6 crash 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, 07 Aug 2011 17:10:31 -0000 On 7 August 2011 17:11, Tom Vijlbrief wrote: > I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the > new installer. > > Major issue I noticed was the missing /home. > > It took me quite some time to get IPv6 working in the guest (a Linux > configuration issue), but now that it works > BETA1 panics in about 50% of the boot attempts: > > testbsd dumped core - see /var/crash/vmcore.0 > > Sun Aug =A07 08:25:28 CEST 2011 > > FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16 > UTC 2011 =A0 =A0 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > i386 > > panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ > /usr/src/sys/netinet6/mld6.c:1676 > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. =A0Type "show warranty" for deta= ils. > This GDB was configured as "i386-marcel-freebsd"... [..] > panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ > /usr/src/sys/netinet6/mld6.c:1676 > > cpuid =3D 0 > KDB: enter: panic > Uptime: 28s > Physical memory: 491 MB > Dumping 45 MB: 30 14 > > #0 =A0doadump (textdump=3D1) at pcpu.h:244 > 244 =A0 =A0 pcpu.h: No such file or directory. > =A0 =A0 =A0 =A0in pcpu.h > (kgdb) #0 =A0doadump (textdump=3D1) at pcpu.h:244 > #1 =A00xc0a04965 in kern_reboot (howto=3D260) > =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:430 > #2 =A00xc0a04291 in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:595 > #3 =A00xc09f4a4a in _mtx_lock_sleep (m=3D0xc35f3a28, tid=3D3278693824, op= ts=3D0, > =A0 =A0file=3D0xc0f1ab65 "/usr/src/sys/netinet6/mld6.c", line=3D1676) > =A0 =A0at /usr/src/sys/kern/kern_mutex.c:341 > #4 =A00xc09f4c67 in _mtx_lock_flags (m=3D0xc35f3a28, opts=3D0, > =A0 =A0file=3D0xc0f1ab65 "/usr/src/sys/netinet6/mld6.c", line=3D1676) > =A0 =A0at /usr/src/sys/kern/kern_mutex.c:203 > #5 =A00xc0bbf007 in mld_set_version (mli=3D0xc3589a00, version=3DVariable > "version" is not available. > ) > =A0 =A0at /usr/src/sys/netinet6/mld6.c:1676 > #6 =A00xc0bc0c00 in mld_input (m=3D0xc3951e00, off=3D48, icmp6len=3D24) > =A0 =A0at /usr/src/sys/netinet6/mld6.c:690 > #7 =A00xc0ba5696 in icmp6_input (mp=3D0xc3313a54, offp=3D0xc3313a68, prot= o=3D58) > =A0 =A0at /usr/src/sys/netinet6/icmp6.c:654 > #8 =A00xc0bba23a in ip6_input (m=3D0xc3951e00) > =A0 =A0at /usr/src/sys/netinet6/ip6_input.c:964 > #9 =A00xc0ac9b1c in netisr_dispatch_src (proto=3D10, source=3D0, m=3D0xc3= 951e00) > =A0 =A0at /usr/src/sys/net/netisr.c:1013 > #10 0xc0ac9da0 in netisr_dispatch (proto=3D10, m=3D0xc3951e00) > =A0 =A0at /usr/src/sys/net/netisr.c:1104 > #11 0xc0abecf1 in ether_demux (ifp=3D0xc35f3800, m=3D0xc3951e00) > =A0 =A0at /usr/src/sys/net/if_ethersubr.c:936 > #12 0xc0abf1b3 in ether_nh_input (m=3D0xc3951e00) > =A0 =A0at /usr/src/sys/net/if_ethersubr.c:755 > #13 0xc0ac9b1c in netisr_dispatch_src (proto=3D9, source=3D0, m=3D0xc3951= e00) > =A0 =A0at /usr/src/sys/net/netisr.c:1013 > #14 0xc0ac9da0 in netisr_dispatch (proto=3D9, m=3D0xc3951e00) > =A0 =A0at /usr/src/sys/net/netisr.c:1104 > #15 0xc0abe7f5 in ether_input (ifp=3D0xc35f3800, m=3D0xc3951e00) > =A0 =A0at /usr/src/sys/net/if_ethersubr.c:796 > #16 0xc0672bc9 in lem_handle_rxtx (context=3D0xc3732000, pending=3D1) > =A0 =A0at /usr/src/sys/dev/e1000/if_lem.c:3554 > #17 0xc0a468ab in taskqueue_run_locked (queue=3D0xc359ca80) > =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:306 > #18 0xc0a47307 in taskqueue_thread_loop (arg=3D0xc37365ec) > =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:495 > #19 0xc09d7af8 in fork_exit (callout=3D0xc0a472a0 = , > =A0 =A0arg=3D0xc37365ec, frame=3D0xc3313d28) at /usr/src/sys/kern/kern_fo= rk.c:941 > #20 0xc0d1d714 in fork_trampoline () at /usr/src/sys/i386/i386/exception.= s:275 > (kgdb) > This is the same as in PR kern/158426. Can you try the patch from PR followup and report us whether it helps? Full link to PR with patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/158426 --=20 wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 00:46:49 2011 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 27E09106564A; Mon, 8 Aug 2011 00:46:49 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by mx1.freebsd.org (Postfix) with ESMTP id B39EE8FC0C; Mon, 8 Aug 2011 00:46:48 +0000 (UTC) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p780kGkQ009240; Mon, 8 Aug 2011 10:46:17 +1000 Message-ID: <4E3F31D8.6050208@swin.edu.au> Date: Mon, 08 Aug 2011 10:46:16 +1000 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: "J.R. Oldroyd" References: <4E3B86C4.7050005@swin.edu.au> <4E3B9346.9000101@FreeBSD.org> <20110805123050.1aa49e0c@shibato.opal.com> In-Reply-To: <20110805123050.1aa49e0c@shibato.opal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Doug Barton , freebsd-current@freebsd.org Subject: Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related 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, 08 Aug 2011 00:46:49 -0000 On 05/08/2011 20:30, J.R. Oldroyd wrote: > On Thu, 04 Aug 2011 23:52:54 -0700, Doug Barton wrote: >> >> On 08/04/2011 22:59, Mattia Rossi wrote: >>> I've finally patched my 8.2 IPv6 gateway with the RDNSS/DNSSL patches >>> The script anyhow overwrites my previous manual entries in >>> /etc/resolv.conf which I need for my manual IPv4 setup... >>> >> Check 'man resolvconf.conf' for information on name_servers_append. It >> would probably be nice if there was a _prepend equivalent. >> > > Mattia, when you say you have the patches, which ones? > > To be clear, the RDNSS/DNSSL support that was committed to head was > very heavily modified from that which I proposed and which is on my > web site. In particular, the resolvconf(8) tool that I offered was > not used at all; the version in head is the openresolv tool by Roy > Marples. Doug's response is in regard to the resolvconf version > in head. I'm using the patches from your website on my 8.2 box, which is the IPv6 gateway and runs rtadvd. The problem with the resolv.conf is happening on my client though, which is a box running HEAD, so I'll try to follow Doug's advice, thanks. > > FWIW, the resolvconf version from my site will use the most recent > nameservers received by from either dhclient-script or rtadvd but you > can also add "static" entries using standard resolv.conf syntax in the > /var/db/resolv.db file; see the man page with that version. I'll remember to read the manpages more thoroughly :-) > > I will update my RDNSS/DNSSL web page now to add a warning that my > patches have been superseded and that folk should use the committed > versions where possible. > Is there any chance that you could create a patch for 8.2 based on the commits in HEAD? That would be great! Thanks, Mat From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 06:42:45 2011 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 0466B1065677; Mon, 8 Aug 2011 06:42:45 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 914D28FC1B; Mon, 8 Aug 2011 06:42:44 +0000 (UTC) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p786g6i3028147; Mon, 8 Aug 2011 16:42:27 +1000 Message-ID: <4E3F853E.4030201@swin.edu.au> Date: Mon, 08 Aug 2011 16:42:06 +1000 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Doug Barton References: <4E3B86C4.7050005@swin.edu.au> <4E3B9346.9000101@FreeBSD.org> In-Reply-To: <4E3B9346.9000101@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, fbsd@opal.com Subject: Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related 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, 08 Aug 2011 06:42:45 -0000 On 05/08/2011 16:52, Doug Barton wrote: > On 08/04/2011 22:59, Mattia Rossi wrote: >> Hi all, >> >> I've finally patched my 8.2 IPv6 gateway with the RDNSS/DNSSL patches >> and I'm distributing DNS servers that way now. Works fine, my box >> running CURRENT picks up the DNS servers and search domains and writes >> them into /etc/resolv.conf using the resolvconf script. >> >> The script anyhow overwrites my previous manual entries in >> /etc/resolv.conf which I need for my manual IPv4 setup... >> >> I think it's an easily fixable bug - haven't looked into it that close >> atm., but given that the resolvconf script is going to be >> rewritten/enhanced anyways, that's something to keep in mind. >> I think that manual entries should always be preferred. > > Check 'man resolvconf.conf' for information on name_servers_append. It > would probably be nice if there was a _prepend equivalent. > Okay, finally got around to read that manpage (which I didn't realise that it existed). So For RDNSS/DNSSL we have now the following manpages related to resolv.conf: resolvconf(8), resolv.conf(5) (aka. resolver(5)) and resolvconf.conf(5)... Lot's of resolvconfs :-) Anyhow, the manpage is really not clear about name_servers_append, and it's not working as expected either: 1) If I put in a comma separated list of nameservers, I'll find that comma separated list in /etc/resolv.conf under a single "nameserver" tag. That doesn't work, as it's not a valid entry. Each nameserver needs to have a "nameserver " entry. 2) If I use multiple name_servers_append entries in /etc/resolvconf.conf, then only the last entry is used. I don't want only one DNS server there though, I want all three of them, as I already had the problem that one or the other didn't work properly. 3) If I read the description for name_servers in resolvconf.conf(5), I understand that this tag prepends the nameserver to my list. This is not what happens. Still not sure what actually happens there... How do I get my 3 manual DNS entries properly into my resolv.conf ? Mat From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 07:55:47 2011 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 EAF541065670 for ; Mon, 8 Aug 2011 07:55:47 +0000 (UTC) (envelope-from mcins1@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 74DEB8FC14 for ; Mon, 8 Aug 2011 07:55:46 +0000 (UTC) Received: by wwi36 with SMTP id 36so3208637wwi.31 for ; Mon, 08 Aug 2011 00:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rMqnMaC1aByxjY1qU+E8YcBd5u+DCI7KOo4CG5BiI7A=; b=ULZgg7roDfr3mdK9HqvVNQHZxORO5SKpTn25++QikdqZ40EQWjAOK6yhb7tUJzr+uQ iH+mK5WUSpcHjP9T6JNPJJllVYpob7UW5z1v+FSSc9GnoVN/CCLs9jrCSFEEpYm9ZtKX wYNkG+w+/1CbHVg6PUDPSSPkpqiMcGT8zYYjI= Received: by 10.217.7.3 with SMTP id z3mr1319874wes.34.1312790146153; Mon, 08 Aug 2011 00:55:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.85.77 with HTTP; Mon, 8 Aug 2011 00:55:26 -0700 (PDT) In-Reply-To: <4E3C2886.9070100@freebsd.org> References: <4E3C2886.9070100@freebsd.org> From: Matthew Cini Sarreo Date: Mon, 8 Aug 2011 09:55:26 +0200 Message-ID: To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ESP Raw Socket: Returned IP packet incorrect 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, 08 Aug 2011 07:55:48 -0000 I have tested the provided patch and can confirm that the IP header length for raw sockets now properly includes the length of the IP header and not just the data. Thanks & Regards, Matt On 5 August 2011 19:29, Andre Oppermann wrote: > On 11.07.2011 17:26, Matthew Cini Sarreo wrote: > >> Hello all; >> >> I have recently encountered a problem when using raw sockets on FreeBSD 8 >> (8.0-RELEASE) when using ESP raw sockets. >> >> I have created a raw esp socket using: >> socket(AF_INET, SOCK_RAW, 50); >> which works fine. However, when there is a packet on the socket, >> recvfrom() >> returns a packet where the length bytes in the IP header are incorrect; >> they >> are swapped (MSB is placed in the LSB and vice-versa) >> >> tcpdump shows the following: >> >> tcpdump: listening on le0, link-type EN10MB (Ethernet), capture size 96 >> bytes >> 15:00:53.993810 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ESP >> (50), length 120) >> 10.0.251.228> 10.0.252.231: ESP(spi=0xa0534f17,seq=0x3), length 100 >> 0x0000: 4500 0078 0000 4000 4032 2d88 0a00 fbe4 >> 0x0010: 0a00 fce7 a053 4f17 0000 0003 6885 8abd >> 0x0020: 2222 5ded 44dc 842f 3081 8fa3 bde4 2265 >> 0x0030: 7438 2bf4 049c 664b 7dc4 44ef 1f6f 5e7d >> 0x0040: b8c1 482f 8c3b f488 a19a 3d9a d5fe ed9d >> 0x0050: b1c2 >> >> >> However, recvfrom() returns the following buffer: >> 4500 6400 0000 0040 4032 2D88 0A00 FBE4 >> 0A00 FCE7 A053 4F17 0000 0003 6885 8ABD >> 2222 5DED 44DC 842F 3081 8FA3 BDE4 2265 >> 7438 2BF4 049C 664B 7DC4 44EF 1F6F 5E7D >> B8C1 482F 8C3B F488 A19A 3D9A D5FE ED9D >> B1C2 >> >> As it is easy to see, the length is not correct (bytes 2 and 3 are 0x6400 >> instead of 0x0064) and it does not correspond to the value returned by >> recvfrom(). >> >> Is this a known issue? Am I missing some options for raw sockets that are >> required for FreeBSD? I have attempted this on a socket to a TUN interface >> (not with an ESP socket) and the buffer had the proper length; it seems to >> only happen with ESP. This code runs fine on multiple Linux distributions >> and on Windows; it was only noticed with FreeBSD. Could it be that there >> is >> some other ESP application running and interfering (I have not installed >> any; don't know if there are by default and I'm quite new to any of the >> BSDs)? >> > > The problem is with all raw sockets. Contrary to the statement in ip(4) > "Incoming packets are received with IP header and options intact" and other > popular OSes the ip_len field in the IP header has the IP header length > already deducted (line 770 in ip_input.c). For normal in-kernel > implemented > protocols this is fine but raw sockets it is clearly wrong. The fix is > pretty easy and just adds the header length back in raw_input() in > raw_ip.c. > > Please test this patch: > http://people.freebsd.org/~**andre/raw_ip-header-length-**20110805.diff > > -- > Andre > From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 08:40:12 2011 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 83526106564A for ; Mon, 8 Aug 2011 08:40:12 +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 72B028FC0A for ; Mon, 8 Aug 2011 08:40:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p788eCMc037836 for ; Mon, 8 Aug 2011 08:40:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p788eCeX037833; Mon, 8 Aug 2011 08:40:12 GMT (envelope-from gnats) Date: Mon, 8 Aug 2011 08:40:12 GMT Message-Id: <201108080840.p788eCeX037833@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Marius Strobl Cc: Subject: Re: kern/158156: [bce] bce driver shows "no carrier" on IBM blade (HS22 with BCM5709) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marius Strobl List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 08:40:12 -0000 The following reply was made to PR kern/158156; it has been noted by GNATS. From: Marius Strobl To: bug-followup@FreeBSD.org, jsc@ntu.edu.tw Cc: Subject: Re: kern/158156: [bce] bce driver shows "no carrier" on IBM blade (HS22 with BCM5709) Date: Mon, 8 Aug 2011 10:30:27 +0200 --7LkOrbQMr4cezO2T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Could you please test whether the attached patch fixes this? --7LkOrbQMr4cezO2T Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="mii_physubr_reset_default_may_power_down.diff" Index: mii_physubr.c =================================================================== --- mii_physubr.c (revision 224216) +++ mii_physubr.c (working copy) @@ -273,8 +273,8 @@ mii_phy_reset(struct mii_softc *sc) DELAY(1000); } - /* NB: a PHY may default to isolation. */ - reg &= ~BMCR_ISO; + /* NB: a PHY may default to being powered down and isolated. */ + reg &= ~(BMCR_PDOWN | BMCR_ISO); if ((sc->mii_flags & MIIF_NOISOLATE) == 0 && ((ife == NULL && sc->mii_inst != 0) || (ife != NULL && IFM_INST(ife->ifm_media) != sc->mii_inst))) --7LkOrbQMr4cezO2T-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 11:07:11 2011 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 3B7DD106564A for ; Mon, 8 Aug 2011 11:07:11 +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 2954F8FC1E for ; Mon, 8 Aug 2011 11:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p78B7BB4078616 for ; Mon, 8 Aug 2011 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p78B79RV078614 for freebsd-net@FreeBSD.org; Mon, 8 Aug 2011 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Aug 2011 11:07:09 GMT Message-Id: <201108081107.p78B79RV078614@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, 08 Aug 2011 11:07:11 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/159353 net [netinet] [patch] conditional call of ifa_del_loopback o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/158426 net [e1000] [panic] _mtx_lock_sleep: recursed on non-recur o kern/158156 net [bce] bce driver shows "no carrier" on IBM blade (HS22 f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [patch] routed(8): if.c in routed fails to compile if o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 378 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 11:55:18 2011 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 D88771065675; Mon, 8 Aug 2011 11:55:18 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 921608FC0A; Mon, 8 Aug 2011 11:55:18 +0000 (UTC) Received: from pool-141-154-233-28.bos.east.verizon.net ([141.154.233.28] helo=homobox.opal.com) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QqOQP-000IHx-No; Mon, 08 Aug 2011 11:55:17 +0000 Received: from opal.com (localhost [IPv6:::1]) (authenticated bits=0) by homobox.opal.com (8.14.4/8.14.4) with ESMTP id p78BtEmn015731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Aug 2011 07:55:15 -0400 (EDT) (envelope-from fbsd@opal.com) Received: from shibato.opal.com ([2001:470:8cb8:3:221:63ff:fe5a:c9a7] helo=shibato.opal.com) with IPv6:587 by opal.com; 8 Aug 2011 07:55:14 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 141.154.233.28 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19DeTurjJ9dVrXAzpILL4Kw Date: Mon, 8 Aug 2011 07:55:11 -0400 From: "J.R. Oldroyd" To: Mattia Rossi Message-ID: <20110808075511.290a3b6d@shibato.opal.com> In-Reply-To: <4E3F31D8.6050208@swin.edu.au> References: <4E3B86C4.7050005@swin.edu.au> <4E3B9346.9000101@FreeBSD.org> <20110805123050.1aa49e0c@shibato.opal.com> <4E3F31D8.6050208@swin.edu.au> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; amd64-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/Fyh=e7=X5h0vWXJ/f3jN8GV"; protocol="application/pgp-signature" Cc: freebsd-net@freebsd.org, Doug Barton , freebsd-current@freebsd.org Subject: Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related 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, 08 Aug 2011 11:55:18 -0000 --Sig_/Fyh=e7=X5h0vWXJ/f3jN8GV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 08 Aug 2011 10:46:16 +1000, Mattia Rossi wrote: >=20 > I'm using the patches from your website on my 8.2 box, which is the IPv6= =20 > gateway and runs rtadvd. The problem with the resolv.conf is happening=20 > on my client though, which is a box running HEAD, so I'll try to follow=20 > Doug's advice, thanks. >=20 Yes, you'll need the openresolv config in this case. Keep in mind that the resolver only queries at most MAXNS nameservers where MAXNS is usually 3. Using the openresolv name_servers_append, you need to make sure that your static servers are listed within the first MAXNS entries. If you have more than MAXNS dynamic servers, your statically configured ones will be ignored. I would just point out though that, in general, you shouldn't need static nameservers just because you have a manual IPv4 configuration. Nameservers will return both IPv4 and IPv6 addresses regardless of whether they were queried over 4 or 6. Of course, if you have an internal nameserver that has private info not available from the dynamically learned nameservers, then you will need a static config. =20 > Is there any chance that you could create a patch for 8.2 based on the=20 > commits in HEAD? > That would be great! >=20 Better would be to ask hrs@ to MFC his commits to 8-stable. -jr --Sig_/Fyh=e7=X5h0vWXJ/f3jN8GV Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAk4/zp8ACgkQls33urr0k4mkowCgorqSAl6cinbewG0IakiTwG1m d4UAn0eOvGiO6UfNmAiBWtM5oDsFdDCu =6E01 -----END PGP SIGNATURE----- --Sig_/Fyh=e7=X5h0vWXJ/f3jN8GV-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 15:12:08 2011 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 78C721065673 for ; Mon, 8 Aug 2011 15:12:07 +0000 (UTC) (envelope-from ferdinand.goldmann@jku.at) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mx1.freebsd.org (Postfix) with ESMTP id 453928FC14 for ; Mon, 8 Aug 2011 15:12:07 +0000 (UTC) Received: from From: Ferdinand Goldmann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Aug 2011 16:54:10 +0200 Message-Id: To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: Problem using CARP + HAST ... 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, 08 Aug 2011 15:12:09 -0000 Hi! I am trying to create a common resource pool for a certain application = using CARP/HAST as described in [1]. However while testing my setup I ran into = a problem which I don't know how to fix or work around: If I shut down only the carp interface on the master (ifconfig carp0 = down), the slave will take note of this, make his carp interface the master and mount the HAST storage using a script called by devd. Everything fine so = far. BUT: If, however, I completely shut down the masters network connection = (using "shut" on the switchport), the carp interface on the slave will still switch to = master.=20 But the script for making the HAST storage primary will just hang = forever: root 46841 0.0 0.6 3628 1524 ?? S 4:21PM 0:00.08 /bin/sh = /opt/bin/carp-hast-switch master root 47043 0.0 2.6 42228 6580 ?? S 4:22PM 0:00.03 hastd: = hast0 (secondary) (hastd) Seemingly, this is because the hastd daemons on master and slave are = unable to=20 communicate. So the script waits forever for the secondary device to go = away... : # Wait for any "hastd secondary" processes to stop for disk in ${resources}; do while $( pgrep -lf "hastd: ${disk} \(secondary\)" > /dev/null = 2>&1 ); do sleep 1 done Im a bit puzzled. Is there a way for hastd to make himself the master in = case of a timeout or such? Because in normal operation, whenever the carp interface fails, = the underlying=20 infrastructure will most likely be down as well. Even if I'd connect the two machines over an extra port for hastd, this problem would still occur if I pull the plug on the master. I = suppose the slave making himself the master will lead to a split-brain condition ... = but is there any way for hastd to handle this automagically? Because otherwise, it = won't be much good for a scenario like the above. :-/ Can anybody shed light on this please? TIA & best regards, Ferdinand [1] http://www.freebsd.org/doc/en/books/handbook/disks-hast.html= From owner-freebsd-net@FreeBSD.ORG Mon Aug 8 18:37:25 2011 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 7C0031065672 for ; Mon, 8 Aug 2011 18:37:25 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id 38F998FC0A for ; Mon, 8 Aug 2011 18:37:25 +0000 (UTC) Received: by qwc9 with SMTP id 9so1256495qwc.13 for ; Mon, 08 Aug 2011 11:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LA0enBQrcYrPi6zNPnAJSSukNNa3h22mxJ/UdfYu7IE=; b=XhuxbOmZOKbiYR4rzxBENlrWWCAA1pqzr3Puv4ICCzWG0hDSnDuJVzP+eTO9mWMH0l 4Jxil9fjgQFxH1nyN5hgk71/y44q064mFMwbNrw45WvntoqfQmEOS7l8rDtQ+Qt3NqDO vKKgiLbhfDsHYu6wvqaBYxwxTMfPusEAk51eM= MIME-Version: 1.0 Received: by 10.229.11.6 with SMTP id r6mr3997186qcr.140.1312826814035; Mon, 08 Aug 2011 11:06:54 -0700 (PDT) Sender: tvijlbrief@gmail.com Received: by 10.229.141.204 with HTTP; Mon, 8 Aug 2011 11:06:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Aug 2011 20:06:54 +0200 X-Google-Sender-Auth: Ecrr8jdmuW980lyMAyXkqO3qKyQ Message-ID: From: Tom Vijlbrief To: Sergey Kandaurov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Net , freebsd-current@freebsd.org Subject: Re: BETA1 IPv6 crash 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, 08 Aug 2011 18:37:25 -0000 2011/8/7 Sergey Kandaurov : > On 7 August 2011 17:11, Tom Vijlbrief wrote: >> I installed BETA1 in a fresh ubuntu 11.04 KVM virtual machine with the >> new installer. >> >> Major issue I noticed was the missing /home. >> >> It took me quite some time to get IPv6 working in the guest (a Linux >> configuration issue), but now that it works >> BETA1 panics in about 50% of the boot attempts: >> >> testbsd dumped core - see /var/crash/vmcore.0 >> >> Sun Aug =A07 08:25:28 CEST 2011 >> >> FreeBSD testbsd 9.0-BETA1 FreeBSD 9.0-BETA1 #0: Thu Jul 28 16:34:16 >> UTC 2011 =A0 =A0 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERI= C >> i386 >> >> panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ >> /usr/src/sys/netinet6/mld6.c:1676 >> >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you= are >> welcome to change it and/or distribute copies of it under certain condit= ions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. =A0Type "show warranty" for det= ails. >> This GDB was configured as "i386-marcel-freebsd"... > [..] >> panic: _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ >> /usr/src/sys/netinet6/mld6.c:1676 >> >> cpuid =3D 0 >> KDB: enter: panic >> Uptime: 28s >> Physical memory: 491 MB >> Dumping 45 MB: 30 14 >> >> #0 =A0doadump (textdump=3D1) at pcpu.h:244 >> 244 =A0 =A0 pcpu.h: No such file or directory. >> =A0 =A0 =A0 =A0in pcpu.h >> (kgdb) #0 =A0doadump (textdump=3D1) at pcpu.h:244 >> #1 =A00xc0a04965 in kern_reboot (howto=3D260) >> =A0 =A0at /usr/src/sys/kern/kern_shutdown.c:430 >> #2 =A00xc0a04291 in panic (fmt=3DVariable "fmt" is not available. >> ) at /usr/src/sys/kern/kern_shutdown.c:595 >> #3 =A00xc09f4a4a in _mtx_lock_sleep (m=3D0xc35f3a28, tid=3D3278693824, o= pts=3D0, >> =A0 =A0file=3D0xc0f1ab65 "/usr/src/sys/netinet6/mld6.c", line=3D1676) >> =A0 =A0at /usr/src/sys/kern/kern_mutex.c:341 >> #4 =A00xc09f4c67 in _mtx_lock_flags (m=3D0xc35f3a28, opts=3D0, >> =A0 =A0file=3D0xc0f1ab65 "/usr/src/sys/netinet6/mld6.c", line=3D1676) >> =A0 =A0at /usr/src/sys/kern/kern_mutex.c:203 >> #5 =A00xc0bbf007 in mld_set_version (mli=3D0xc3589a00, version=3DVariabl= e >> "version" is not available. >> ) >> =A0 =A0at /usr/src/sys/netinet6/mld6.c:1676 >> #6 =A00xc0bc0c00 in mld_input (m=3D0xc3951e00, off=3D48, icmp6len=3D24) >> =A0 =A0at /usr/src/sys/netinet6/mld6.c:690 >> #7 =A00xc0ba5696 in icmp6_input (mp=3D0xc3313a54, offp=3D0xc3313a68, pro= to=3D58) >> =A0 =A0at /usr/src/sys/netinet6/icmp6.c:654 >> #8 =A00xc0bba23a in ip6_input (m=3D0xc3951e00) >> =A0 =A0at /usr/src/sys/netinet6/ip6_input.c:964 >> #9 =A00xc0ac9b1c in netisr_dispatch_src (proto=3D10, source=3D0, m=3D0xc= 3951e00) >> =A0 =A0at /usr/src/sys/net/netisr.c:1013 >> #10 0xc0ac9da0 in netisr_dispatch (proto=3D10, m=3D0xc3951e00) >> =A0 =A0at /usr/src/sys/net/netisr.c:1104 >> #11 0xc0abecf1 in ether_demux (ifp=3D0xc35f3800, m=3D0xc3951e00) >> =A0 =A0at /usr/src/sys/net/if_ethersubr.c:936 >> #12 0xc0abf1b3 in ether_nh_input (m=3D0xc3951e00) >> =A0 =A0at /usr/src/sys/net/if_ethersubr.c:755 >> #13 0xc0ac9b1c in netisr_dispatch_src (proto=3D9, source=3D0, m=3D0xc395= 1e00) >> =A0 =A0at /usr/src/sys/net/netisr.c:1013 >> #14 0xc0ac9da0 in netisr_dispatch (proto=3D9, m=3D0xc3951e00) >> =A0 =A0at /usr/src/sys/net/netisr.c:1104 >> #15 0xc0abe7f5 in ether_input (ifp=3D0xc35f3800, m=3D0xc3951e00) >> =A0 =A0at /usr/src/sys/net/if_ethersubr.c:796 >> #16 0xc0672bc9 in lem_handle_rxtx (context=3D0xc3732000, pending=3D1) >> =A0 =A0at /usr/src/sys/dev/e1000/if_lem.c:3554 >> #17 0xc0a468ab in taskqueue_run_locked (queue=3D0xc359ca80) >> =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:306 >> #18 0xc0a47307 in taskqueue_thread_loop (arg=3D0xc37365ec) >> =A0 =A0at /usr/src/sys/kern/subr_taskqueue.c:495 >> #19 0xc09d7af8 in fork_exit (callout=3D0xc0a472a0 , >> =A0 =A0arg=3D0xc37365ec, frame=3D0xc3313d28) at /usr/src/sys/kern/kern_f= ork.c:941 >> #20 0xc0d1d714 in fork_trampoline () at /usr/src/sys/i386/i386/exception= .s:275 >> (kgdb) >> > > This is the same as in PR kern/158426. > Can you try the patch from PR followup and report us whether it helps? > Full link to PR with patch: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/158426 > > -- > wbr, > pluknet > > I applied the patch and tried about 15 reboots and all went fine.... From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 11:30:15 2011 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 868C41065672 for ; Tue, 9 Aug 2011 11:30:15 +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 5C2188FC1C for ; Tue, 9 Aug 2011 11:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p79BUFbS071075 for ; Tue, 9 Aug 2011 11:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p79BUFcT071072; Tue, 9 Aug 2011 11:30:15 GMT (envelope-from gnats) Date: Tue, 9 Aug 2011 11:30:15 GMT Message-Id: <201108091130.p79BUFcT071072@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Svatopluk Kraus Cc: Subject: Re: kern/159353: [netinet] [patch] conditional call of ifa_del_loopback_route() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Svatopluk Kraus List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 11:30:15 -0000 The following reply was made to PR kern/159353; it has been noted by GNATS. From: Svatopluk Kraus To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/159353: [netinet] [patch] conditional call of ifa_del_loopback_route() Date: Tue, 9 Aug 2011 12:55:42 +0200 This PR can be closed because (IMHO) more complex patch (I'm just trying to work on) is needed. From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 12:00:38 2011 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 8ED9F10657F5 for ; Tue, 9 Aug 2011 12:00:38 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id 0C21F8FC0C for ; Tue, 9 Aug 2011 12:00:37 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 17826 invoked from network); 9 Aug 2011 14:00:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1312891230; bh=T3Um7JaPn8ZxZcwkzZwqiZSsToiEf5x2ZFveIR/tZCU=; h=From:To:Subject; b=R5/uob/twApYiw3IJ4uR2xCEoh+/JlGDuY7WqBEUBI0X6Bp7g7HGSxU9rUto5GbZo FFcJ1FcZwTNIYb5Mrwd749lyCBZmOTaU6KSAy1HadQKT2myYw2QJtH30go+09OIiYf frHXgP3bMp3gYxOsrEmWGmsHIixrYmzKy8qDC5uA= Received: from cwx170.internetdsl.tpnet.pl (HELO [10.0.0.15]) (marek_sal@[83.19.131.170]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 9 Aug 2011 14:00:30 +0200 Message-ID: <4E412116.1070305@wp.pl> Date: Tue, 09 Aug 2011 13:59:18 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [YYMU] Subject: ipfw - accessing DMZ from LAN 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, 09 Aug 2011 12:00:38 -0000 Hi all, I have set up a new router for my network, with separated DMZ zone for my internet servers. I'd like computers from my LAN to be able to connect to DMZ zone. My ISP provided me some public IP's, so right now configuration looks like this: Router with 4 NICs: #public ISP ifconfig_vr3="inet xx.yy.zz.171 netmask 255.255.255.248" ifconfig_vr3_alias0="inet xx.yy.zz.170 netmask 255.255.255.255" ifconfig_vr3_alias1="inet xx.yy.zz.172 netmask 255.255.255.255" ifconfig_vr3_alias2="inet xx.yy.zz.173 netmask 255.255.255.255" The first IP, with suffix .171 I want to be used as real router's IP, and public IP for computers in my LAN. All 3 aliases I want to be redirected to DMZ (one public IP for each server in DMZ) #DMZ ifconfig_vr2="inet 192.168.0.1 netmask 255.255.255.0" #LAN ifconfig_vr0="inet 10.0.0.1 netmask 255.255.255.0" I've set up in natd.conf: use_sockets yes same_ports yes interface vr3 dynamic yes unregistered_only yes redirect_address 192.168.0.10 xx.yy.zz.170 #DMZ host 1 redirect_address 192.168.0.20 xx.yy.zz.172 #DMZ host 2 redirect_address 192.168.0.30 xx.yy.zz.173 #DMZ host 3 Right now everything works from the Internet - if I do ssh to xx.yy.zz.170, I really can connect to host 192.168.0.10 etc. The problem is that when I want to connect from my 10.0.0.0/24 network (and even from router) to any DMZ host, using it's public address (any of xx.yy.zz.{170,172,173} ), I can't connect and in fact I am connecting to the router.. So I am unable to access my web, mta, ftp servers that are located in DMZ My ipfw firewall script looks as follows: #!/bin/sh cmd="ipfw -q" DMZ="192.168.0.0/24" LAN="10.0.0.0/24" kldstat -q -m dummynet || kldload dummynet $cmd flush $cmd add 80 divert natd ip from any to any via vr3 $cmd add 90 allow ip from any to any via lo0 $cmd add 100 allow ip from any to me $cmd add 101 allow ip from me to any $cmd add 500 deny ip from $DMZ to $LAN $cmd add 510 deny ip from $LAN to $DMZ $cmd add 10000 allow ip from any to any I know I've blcoked traffic between DMZ and LAN, but I wanted them to contact via public IPs.. but now I'm not sure if it's possible... Can you give me some hints on how to properly configure my router? Regards, -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 12:01:27 2011 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 6616D1065693 for ; Tue, 9 Aug 2011 12:01:27 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id DBC8A8FC1F for ; Tue, 9 Aug 2011 12:01:26 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 21503 invoked from network); 9 Aug 2011 13:58:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1312891100; bh=T3Um7JaPn8ZxZcwkzZwqiZSsToiEf5x2ZFveIR/tZCU=; h=From:To:Subject; b=SRQIxnx6VhqgZWZ+lMVYy7f/AiZax2KMfvTuwHEQ23JJpv6tGiOfp8I7P1UpVTq1u rqvaO0Uu2+8yKcxsuFk6SizKUTfzGU6TnCZ3GNODZ2Hh1PIdjTlUAKN2Jt3Aejcy8f rQTxsr026QP49GRTtdEehtW5YDpD67cTtWh5buYw= Received: from cwx170.internetdsl.tpnet.pl (HELO [10.0.0.15]) (marek_sal@[83.19.131.170]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 9 Aug 2011 13:58:20 +0200 Message-ID: <4E412093.8000105@wp.pl> Date: Tue, 09 Aug 2011 13:57:07 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [ETNE] Subject: ipfw - accessing DMZ from LAN 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, 09 Aug 2011 12:01:27 -0000 Hi all, I have set up a new router for my network, with separated DMZ zone for my internet servers. I'd like computers from my LAN to be able to connect to DMZ zone. My ISP provided me some public IP's, so right now configuration looks like this: Router with 4 NICs: #public ISP ifconfig_vr3="inet xx.yy.zz.171 netmask 255.255.255.248" ifconfig_vr3_alias0="inet xx.yy.zz.170 netmask 255.255.255.255" ifconfig_vr3_alias1="inet xx.yy.zz.172 netmask 255.255.255.255" ifconfig_vr3_alias2="inet xx.yy.zz.173 netmask 255.255.255.255" The first IP, with suffix .171 I want to be used as real router's IP, and public IP for computers in my LAN. All 3 aliases I want to be redirected to DMZ (one public IP for each server in DMZ) #DMZ ifconfig_vr2="inet 192.168.0.1 netmask 255.255.255.0" #LAN ifconfig_vr0="inet 10.0.0.1 netmask 255.255.255.0" I've set up in natd.conf: use_sockets yes same_ports yes interface vr3 dynamic yes unregistered_only yes redirect_address 192.168.0.10 xx.yy.zz.170 #DMZ host 1 redirect_address 192.168.0.20 xx.yy.zz.172 #DMZ host 2 redirect_address 192.168.0.30 xx.yy.zz.173 #DMZ host 3 Right now everything works from the Internet - if I do ssh to xx.yy.zz.170, I really can connect to host 192.168.0.10 etc. The problem is that when I want to connect from my 10.0.0.0/24 network (and even from router) to any DMZ host, using it's public address (any of xx.yy.zz.{170,172,173} ), I can't connect and in fact I am connecting to the router.. So I am unable to access my web, mta, ftp servers that are located in DMZ My ipfw firewall script looks as follows: #!/bin/sh cmd="ipfw -q" DMZ="192.168.0.0/24" LAN="10.0.0.0/24" kldstat -q -m dummynet || kldload dummynet $cmd flush $cmd add 80 divert natd ip from any to any via vr3 $cmd add 90 allow ip from any to any via lo0 $cmd add 100 allow ip from any to me $cmd add 101 allow ip from me to any $cmd add 500 deny ip from $DMZ to $LAN $cmd add 510 deny ip from $LAN to $DMZ $cmd add 10000 allow ip from any to any I know I've blcoked traffic between DMZ and LAN, but I wanted them to contact via public IPs.. but now I'm not sure if it's possible... Can you give me some hints on how to properly configure my router? Regards, -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 13:09:52 2011 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 51631106564A for ; Tue, 9 Aug 2011 13:09:52 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0E88FC08 for ; Tue, 9 Aug 2011 13:09:52 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.151.76.210] by asmtp024.mac.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTPSA id <0LPN00IZ0WJS6B40@asmtp024.mac.com> for freebsd-net@freebsd.org; Tue, 09 Aug 2011 06:09:30 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-08-09_05:2011-08-09, 2011-08-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1108090093 From: Chuck Swiger In-reply-to: <4E412093.8000105@wp.pl> Date: Tue, 09 Aug 2011 06:09:28 -0700 Message-id: References: <4E412093.8000105@wp.pl> To: Marek Salwerowicz X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: ipfw - accessing DMZ from LAN 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, 09 Aug 2011 13:09:52 -0000 On Aug 9, 2011, at 4:57 AM, Marek Salwerowicz wrote: > Right now everything works from the Internet - if I do ssh to xx.yy.zz.170, I really can connect to host 192.168.0.10 etc. > > The problem is that when I want to connect from my 10.0.0.0/24 network (and even from router) to any DMZ host, using it's public address (any of xx.yy.zz.{170,172,173} ), I can't connect and in fact I am connecting to the router.. So I am unable to access my web, mta, ftp servers that are located in DMZ It's not working because you configured natd to work against traffic flowing via vr3, but traffic from your LAN is coming via vr0. While you can change natd to run against all traffic, it's much better to avoid re-writing purely internal traffic by setting up a DNS view for your machines in the DMZ which uses internal IPs rather than the public IPs. Or, if you insist upon your DMZ hosts being on externally routable IPs, then go ahead and configure them with externally routable IPs rather than using natd's redirect_address, and only do NAT for internal traffic via vr0 instead. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 13:16:29 2011 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 03C3B106566B for ; Tue, 9 Aug 2011 13:16:29 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id 734038FC17 for ; Tue, 9 Aug 2011 13:16:28 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 29271 invoked from network); 9 Aug 2011 15:16:13 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1312895773; bh=8NuTmjj5pGCut/wzLRm/6GFWULkEfG0OTX6ReEzOZd4=; h=From:To:CC:Subject; b=vig6idigo/DGTMyHArt0nLU4TiQplxACV6prarbLB6Kj6OS1iEswDEqnmSjnWlhg5 Z9SpDwzqJkpUOujMMmDDkGVBwORkaf965lTV8zQ1bK+6ymc+vqgLMidsq0X+b7n4NM 4ZO85LSUCCXwFgMMYgYr8xBBI+89o61PT4+/jQvE= Received: from cwx170.internetdsl.tpnet.pl (HELO [10.0.0.15]) (marek_sal@[83.19.131.170]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 9 Aug 2011 15:16:13 +0200 Message-ID: <4E4132D5.8020700@wp.pl> Date: Tue, 09 Aug 2011 15:15:01 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Chuck Swiger References: <4E412093.8000105@wp.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [EZNU] Cc: freebsd-net@freebsd.org Subject: Re: ipfw - accessing DMZ from LAN 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, 09 Aug 2011 13:16:29 -0000 W dniu 2011-08-09 15:09, Chuck Swiger pisze: > On Aug 9, 2011, at 4:57 AM, Marek Salwerowicz wrote: >> Right now everything works from the Internet - if I do ssh to xx.yy.zz.170, I really can connect to host 192.168.0.10 etc. >> >> The problem is that when I want to connect from my 10.0.0.0/24 network (and even from router) to any DMZ host, using it's public address (any of xx.yy.zz.{170,172,173} ), I can't connect and in fact I am connecting to the router.. So I am unable to access my web, mta, ftp servers that are located in DMZ > It's not working because you configured natd to work against traffic flowing via vr3, but traffic from your LAN is coming via vr0. While you can change natd to run against all traffic, it's much better to avoid re-writing purely internal traffic by setting up a DNS view for your machines in the DMZ which uses internal IPs rather than the public IPs. So should I allow trafic from LAN to DMZ and setup my local DNS to connect to hosts in DMZ using private IPs ? > > Or, if you insist upon your DMZ hosts being on externally routable IPs, then go ahead and configure them with externally routable IPs rather than using natd's redirect_address, and only do NAT for internal traffic via vr0 instead. > > Am I able to configure them with externally IPs only and having eg. bandwidth control using only one router? My current setup is that I have separately router, web server and mail server but If I want to limit bandwidth, I have to do it on proper machine instead of configuring only one device. Regards, -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 13:27:13 2011 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 C1777106564A for ; Tue, 9 Aug 2011 13:27:13 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout025.mac.com (asmtpout025.mac.com [17.148.16.100]) by mx1.freebsd.org (Postfix) with ESMTP id A8A548FC15 for ; Tue, 9 Aug 2011 13:27:13 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.151.76.210] by asmtp025.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LPN00GS3XCCI950@asmtp025.mac.com> for freebsd-net@freebsd.org; Tue, 09 Aug 2011 06:26:37 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-08-09_05:2011-08-09, 2011-08-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1108090097 From: Chuck Swiger In-reply-to: <4E4132D5.8020700@wp.pl> Date: Tue, 09 Aug 2011 06:26:35 -0700 Message-id: <502BD41A-AF5F-43D7-AB34-0CDEA1F57D4B@mac.com> References: <4E412093.8000105@wp.pl> <4E4132D5.8020700@wp.pl> To: Marek Salwerowicz X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: ipfw - accessing DMZ from LAN 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, 09 Aug 2011 13:27:13 -0000 On Aug 9, 2011, at 6:15 AM, Marek Salwerowicz wrote: >> It's not working because you configured natd to work against traffic flowing via vr3, but traffic from your LAN is coming via vr0. While you can change natd to run against all traffic, it's much better to avoid re-writing purely internal traffic by setting up a DNS view for your machines in the DMZ which uses internal IPs rather than the public IPs. > > So should I allow trafic from LAN to DMZ and setup my local DNS to connect to hosts in DMZ using private IPs ? Yes, that ought to work fine. In fact, in the classic screened-subnet design from which the notion of DMZ hosts originated, you only permitted traffic from LAN to DMZ, and blocked all traffic from outside to LAN. This meant that all LAN hosts needed to go through proxies or other services living in the DMZ-- internal hosts never talk to strangers, so to speak. :) >> Or, if you insist upon your DMZ hosts being on externally routable IPs, then go ahead and configure them with externally routable IPs rather than using natd's redirect_address, and only do NAT for internal traffic via vr0 instead. > > Am I able to configure them with externally IPs only and having eg. bandwidth control using only one router? > > My current setup is that I have separately router, web server and mail server but If I want to limit bandwidth, I have to do it on proper machine instead of configuring only one device. dummynet (or Altq, or whatever else you might be using) works fine with pure routing config, yes-- you don't have to NAT traffic to do bandwidth control on the router. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 13:46:38 2011 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 A79EE1065673 for ; Tue, 9 Aug 2011 13:46:38 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx3.wp.pl (mx3.wp.pl [212.77.101.7]) by mx1.freebsd.org (Postfix) with ESMTP id 21D5F8FC13 for ; Tue, 9 Aug 2011 13:46:37 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 11994 invoked from network); 9 Aug 2011 15:46:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1312897587; bh=tfiAwBPZxRkbUI4al+NPHGpo7ZsFSLRbrNU+zpZbp2E=; h=From:To:CC:Subject; b=eoxkg27gkCdpmIFA9cVn83aSrmvUdisdFnq9tMfWCkoWCel/IEkMp/8p5J+2S/u/k uv0WF1y8GnJeawdHndiPHBHE1q9GxYwTt9hiNCRqhECXlBhUW9NLFDBmTbHQP0Vk4w JOgQRaPD7g0Z/ShNFtHtXNPdMEqiNciCRylnPrN0= Received: from cwx170.internetdsl.tpnet.pl (HELO [10.0.0.15]) (marek_sal@[83.19.131.170]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 9 Aug 2011 15:46:27 +0200 Message-ID: <4E4139EB.7060904@wp.pl> Date: Tue, 09 Aug 2011 15:45:15 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Chuck Swiger References: <4E412093.8000105@wp.pl> <4E4132D5.8020700@wp.pl> <502BD41A-AF5F-43D7-AB34-0CDEA1F57D4B@mac.com> In-Reply-To: <502BD41A-AF5F-43D7-AB34-0CDEA1F57D4B@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [McO0] Cc: freebsd-net@freebsd.org Subject: Re: ipfw - accessing DMZ from LAN 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, 09 Aug 2011 13:46:38 -0000 W dniu 2011-08-09 15:26, Chuck Swiger pisze: > dummynet (or Altq, or whatever else you might be using) works fine with pure routing config, yes-- you don't have to NAT traffic to do bandwidth control on the router. > How it should be done? Leave the aliases at my external interface, and then 'bridge' DMZ interface with external and set up public IPs on my DMZ hosts? Regards, -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 14:19:10 2011 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 B1BF1106564A for ; Tue, 9 Aug 2011 14:19:10 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id 983408FC12 for ; Tue, 9 Aug 2011 14:19:10 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.151.76.210] by asmtp019.mac.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LPN002H9ZREW190@asmtp019.mac.com> for freebsd-net@freebsd.org; Tue, 09 Aug 2011 07:18:51 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813,1.0.211,0.0.0000 definitions=2011-08-09_05:2011-08-09, 2011-08-08, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1108090113 From: Chuck Swiger In-reply-to: <4E4139EB.7060904@wp.pl> Date: Tue, 09 Aug 2011 07:18:49 -0700 Message-id: References: <4E412093.8000105@wp.pl> <4E4132D5.8020700@wp.pl> <502BD41A-AF5F-43D7-AB34-0CDEA1F57D4B@mac.com> <4E4139EB.7060904@wp.pl> To: Marek Salwerowicz X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: ipfw - accessing DMZ from LAN 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, 09 Aug 2011 14:19:10 -0000 On Aug 9, 2011, at 6:45 AM, Marek Salwerowicz wrote: > W dniu 2011-08-09 15:26, Chuck Swiger pisze: >> dummynet (or Altq, or whatever else you might be using) works fine with pure routing config, yes-- you don't have to NAT traffic to do bandwidth control on the router. > > How it should be done? > Leave the aliases at my external interface, and then 'bridge' DMZ interface with external and set up public IPs on my DMZ hosts? You don't need to do NAT aliasing if you make your DMZ hosts directly routable-- you just need to do firewall and bandwidth shaping. If your provider is cooperative, then their end and your external NIC (vr3?) can switch to communicate over an unroutable /30 subnet, and your FreeBSD box's DMZ NIC (vr2) is reconfigured with the public router IP they are now vending. If they aren't willing to make such changes, then yes, you could bridge between vr3 and vr2 instead; you need to set the net.link.ether.bridge_ipfw=1 sysctl for IPFW to act on bridged traffic. There are more complicated solutions which could also work, but there doesn't seem to be a need for them. IMO, it's cleaner and more efficient to explicitly route between networks off of a firewall than it is to permit subnet-local broadcast traffic to pass thru the firewall. Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Aug 9 16:29:18 2011 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 0BE0E106566B for ; Tue, 9 Aug 2011 16:29:18 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id BA38C8FC0C for ; Tue, 9 Aug 2011 16:29:17 +0000 (UTC) Received: by vxh11 with SMTP id 11so183110vxh.13 for ; Tue, 09 Aug 2011 09:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gr5A6/QsNV0UooJ6Vv8320yIT1YxiZcRg10Rr+cxh3M=; b=lOvKNbn/t3E8ki1Rd/6e7xLervGTDPGW1iXCNV+wdusR+ozhFKJdRqTl45mMBFM/kd JYK4h1O0WPCBxMX7k5D9A5KEPTVt57lMxcRrQWikqxOoFWXvtcisRZXd8/MFDDcswMKx WD6w+icJpDUvOjCict6HboHra8jbFMTeJxWSU= MIME-Version: 1.0 Received: by 10.52.21.234 with SMTP id y10mr7980359vde.77.1312905863656; Tue, 09 Aug 2011 09:04:23 -0700 (PDT) Received: by 10.220.186.134 with HTTP; Tue, 9 Aug 2011 09:04:23 -0700 (PDT) In-Reply-To: <4E412116.1070305@wp.pl> References: <4E412116.1070305@wp.pl> Date: Tue, 9 Aug 2011 09:04:23 -0700 Message-ID: From: Freddie Cash To: Marek Salwerowicz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ipfw - accessing DMZ from LAN 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, 09 Aug 2011 16:29:18 -0000 On Tue, Aug 9, 2011 at 4:59 AM, Marek Salwerowicz wrote: > I have set up a new router for my network, with separated DMZ zone for my > internet servers. I'd like computers from my LAN to be able to connect to > DMZ zone. > > My ISP provided me some public IP's, so right now configuration looks like > this: > > Router with 4 NICs: > #public ISP > ifconfig_vr3="inet xx.yy.zz.171 netmask 255.255.255.248" > ifconfig_vr3_alias0="inet xx.yy.zz.170 netmask 255.255.255.255" > ifconfig_vr3_alias1="inet xx.yy.zz.172 netmask 255.255.255.255" > ifconfig_vr3_alias2="inet xx.yy.zz.173 netmask 255.255.255.255" > > The first IP, with suffix .171 I want to be used as real router's IP, and > public IP for computers in my LAN. > All 3 aliases I want to be redirected to DMZ (one public IP for each server > in DMZ) > > #DMZ > ifconfig_vr2="inet 192.168.0.1 netmask 255.255.255.0" > > #LAN > ifconfig_vr0="inet 10.0.0.1 netmask 255.255.255.0" > > I've set up in natd.conf: > > use_sockets yes > same_ports yes > interface vr3 > dynamic yes > unregistered_only yes > redirect_address 192.168.0.10 xx.yy.zz.170 #DMZ host 1 > redirect_address 192.168.0.20 xx.yy.zz.172 #DMZ host 2 > redirect_address 192.168.0.30 xx.yy.zz.173 #DMZ host 3 > > Right now everything works from the Internet - if I do ssh to xx.yy.zz.170, > I really can connect to host 192.168.0.10 etc. > > The problem is that when I want to connect from my 10.0.0.0/24 network > (and even from router) to any DMZ host, using it's public address (any of > xx.yy.zz.{170,172,173} ), I can't connect and in fact I am connecting to the > router.. > So I am unable to access my web, mta, ftp servers that are located in DMZ > > My ipfw firewall script looks as follows: > > #!/bin/sh > > cmd="ipfw -q" > > DMZ="192.168.0.0/24" > LAN="10.0.0.0/24" > > kldstat -q -m dummynet || kldload dummynet > $cmd flush > > $cmd add 80 divert natd ip from any to any via vr3 > $cmd add 90 allow ip from any to any via lo0 > > $cmd add 100 allow ip from any to me > $cmd add 101 allow ip from me to any > > $cmd add 500 deny ip from $DMZ to $LAN > $cmd add 510 deny ip from $LAN to $DMZ > > > $cmd add 10000 allow ip from any to any > > I know I've blcoked traffic between DMZ and LAN, but I wanted them to > contact via public IPs.. but now I'm not sure if it's possible... > > Can you give me some hints on how to properly configure my router? > There are two ways to do this, depending on whether or not you want to "leak" you private LAN IPs into the DMz. The simplest method, where LAN clients connect to the public IP of the DMZ servers, and where the DMZ servers see the private IPs of the clients, is like so: # Configure the natd process to NAT from x.x.x.170 to 192.168.0.10 using some port natd -port $port -same_ports -use_sockets -alias_address x.x.x.170 -redirect_address x.x.x.170 192.168.0.10 # NAT the traffic coming from the LAN to x.x.x.170 ipfw add divert $port ip from $LAN to x.x.x.170 in recv vr0 ipfw add allow ip from $LAN to 192.168.0.10 in recv vr0 ipfw add allow ip from $LAN to 192.168.0.10 out xmit vr2 ipfw add allow ip from 192.168.0.10 to $LAN in recv vr2 ipfw add divert ip from 192.168.0.10 to $LAN out xmit vr0 ipfw add allow ip from x.x.x.170 to $LAN out xmit vr0 Repeat the above for each of the servers in the DMZ, using separate natd processes for each, with separate divert port numbers. The general flow of the rules above is (src --> dest) 10.0.0.x --> x.x.x.170 10.0.0.x --> 192.168.0.10 192.168.0.10 --> 10.0.0.x x.x.x.170 --> 10.0.0.x The more correct method is to double-NAT the traffic, such that the LAN clients connect to public IPs, and the DMZ servers see connections from public IPs. It's more complicated to wrap your head around the first time, but it prevents private IPs from "leaking" between the LAN, the Internet, and the DMZ. (It took me 10 years of using IPFW to figure this one out.) # Configure the general natd process for the LAN natd -port $port2 -same_ports -use_sockets -alias_address x.x.x.171 # Configure the natd process to NAT from x.x.x.170 to 192.168.0.10 using some port natd -port $port1 -same_ports -use_sockets -alias_address x.x.x.170 -redirect_address x.x.x.170 192.168.0.10 # NAT the traffic coming from the LAN to x.x.x.170 ipfw add divert $port1 ip from $LAN to x.x.x.170 in recv vr0 ipfw add allow ip from $LAN to 192.168.0.10 in recv vr0 # NAT the traffic going to x.x.x.170 from the LAN ipfw add divert $port2 ip from $LAN to 192.168.0.10 out xmit vr2 ipfw add allow ip from x.x.x.171 to 192.168.0.10 out xmit vr2 # NAT the traffic coming from x.x.x.170 to the LAN ipfw add divert $port1 ip from 192.168.0.10 to x.x.x.171 in recv vr2 ipfw add allow ip from 192.168.0.10 to $LAN in recv vr2 # NAT the traffic going to the LAN from x.x.x.170 ipfw add divert ip from 192.168.0.10 to $LAN out xmit vr0 ipfw add allow ip from x.x.x.170 t0 $LAN out xmit vr0 The general flow of the rules above is (src --> dest) 10.0.0.x --> x.x.x.170 10.0.0.x --> 192.168.0.10 (after first NAT) x.x.x.171 --> 192.168.0.10 (after second NAT) 192.168.0.10 --> x.x.x.171 192.168.0.10 --> 10.0.0.x (after first NAT) x.x.x.170 --> 10.0.0.x (after second NAT) Notice how vr3 is never used in any of the rules above, as the packets never touch the public interface of the router. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 00:28:18 2011 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 01CB7106566B; Wed, 10 Aug 2011 00:28:18 +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 CDC3B8FC18; Wed, 10 Aug 2011 00:28:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p7A0SHVu096101; Wed, 10 Aug 2011 00:28:17 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p7A0SHGM096097; Wed, 10 Aug 2011 00:28:17 GMT (envelope-from linimon) Date: Wed, 10 Aug 2011 00:28:17 GMT Message-Id: <201108100028.p7A0SHGM096097@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/159601: [netinet] [patch] in_scrubprefix() - loopback route refcount malfunction 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, 10 Aug 2011 00:28:18 -0000 Old Synopsis: [patch] in_scrubprefix() - loopback route refcount malfunction New Synopsis: [netinet] [patch] in_scrubprefix() - loopback route refcount malfunction Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Aug 10 00:27:54 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=159601 From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 05:48:54 2011 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 6BFAC1065675 for ; Wed, 10 Aug 2011 05:48:54 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id F32908FC15 for ; Wed, 10 Aug 2011 05:48:53 +0000 (UTC) Received: by fxe4 with SMTP id 4so868312fxe.13 for ; Tue, 09 Aug 2011 22:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=gkh296zNw0lxvM8wkgJCTaTnCpfyG2EhN8smyNvJkMU=; b=Hs0drSXUnfMIQQ4fB0WlnSg71ta//O5NS+6H8qlNsuCU/pB7ONGb4JfEP3z/IJyTfI vnweKnVLkzrzzWJEE30mMKsOoKYonpGQqKDAXPAYi1OqObYrGK7QZ2Q7OXS1MU5+9pnY mG71YSsCq2HdvxvZvQqdkfdldFWV5AX6CAvqA= Received: by 10.223.55.79 with SMTP id t15mr10709788fag.23.1312955332787; Tue, 09 Aug 2011 22:48:52 -0700 (PDT) Received: from localhost ([94.27.39.186]) by mx.google.com with ESMTPS id o18sm483791fal.23.2011.08.09.22.48.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 22:48:50 -0700 (PDT) From: Mikolaj Golub To: Ferdinand Goldmann Organization: TOA Ukraine References: Sender: Mikolaj Golub Date: Wed, 10 Aug 2011 08:48:48 +0300 In-Reply-To: (Ferdinand Goldmann's message of "Mon, 8 Aug 2011 16:54:10 +0200") Message-ID: <86mxfhyfy7.fsf@in138.ua3> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org Subject: Re: Problem using CARP + HAST ... 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, 10 Aug 2011 05:48:54 -0000 On Mon, 8 Aug 2011 16:54:10 +0200 Ferdinand Goldmann wrote: FG> Hi! FG> I am trying to create a common resource pool for a certain application using FG> CARP/HAST as described in [1]. However while testing my setup I ran into a FG> problem which I don't know how to fix or work around: FG> If I shut down only the carp interface on the master (ifconfig carp0 down), FG> the slave will take note of this, make his carp interface the master and FG> mount the HAST storage using a script called by devd. Everything fine so far. BUT: FG> If, however, I completely shut down the masters network connection (using "shut" on FG> the switchport), the carp interface on the slave will still switch to master. FG> But the script for making the HAST storage primary will just hang forever: FG> root 46841 0.0 0.6 3628 1524 ?? S 4:21PM 0:00.08 /bin/sh /opt/bin/carp-hast-switch master FG> root 47043 0.0 2.6 42228 6580 ?? S 4:22PM 0:00.03 hastd: hast0 (secondary) (hastd) FG> Seemingly, this is because the hastd daemons on master and slave are unable to FG> communicate. So the script waits forever for the secondary device to go away... : FG> # Wait for any "hastd secondary" processes to stop FG> for disk in ${resources}; do FG> while $( pgrep -lf "hastd: ${disk} \(secondary\)" > /dev/null 2>&1 ); do FG> sleep 1 FG> done What freebsd are you running on? I suppose it is release, because on STABLE this issue should be fixed -- the secondary terminates after timeout. FG> Im a bit puzzled. Is there a way for hastd to make himself the master in case of a timeout FG> or such? Because in normal operation, whenever the carp interface fails, the underlying FG> infrastructure will most likely be down as well. On release you can just modify the script not to wait forever for hastd secondary to stop -- it will be terminated when the role is switched to primary. But anyway my advise is to use STABLE :-). -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 06:52:49 2011 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 2F1C9106566C for ; Wed, 10 Aug 2011 06:52:49 +0000 (UTC) (envelope-from marek_sal@wp.pl) Received: from mx4.wp.pl (mx4.wp.pl [212.77.101.8]) by mx1.freebsd.org (Postfix) with ESMTP id A1B0D8FC1A for ; Wed, 10 Aug 2011 06:52:47 +0000 (UTC) Received: (wp-smtpd smtp.wp.pl 10463 invoked from network); 10 Aug 2011 08:52:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wp.pl; s=1024a; t=1312959166; bh=aPGOgZuNuPzBjhvfE/NESfJn6sNkeyrivneh/Ne0+do=; h=From:To:Subject; b=qOqLH9Er5+umQukxVk6TUqxs9Au//6Ls4Qh8eAQtf5if+FvMLZDYa3QsyZAXc9795 qrt+h1//3aqzNJEmCULmwfMvbM7/DOR39u0S/91BHvWakypmDFsUFbODn7bwW7YkSG 7N2PBoxdtp2PKN6jghpm/L3G0F0ep3h21ZBhVlXw= Received: from cwx170.internetdsl.tpnet.pl (HELO [10.0.0.15]) (marek_sal@[83.19.131.170]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with SMTP for ; 10 Aug 2011 08:52:46 +0200 Message-ID: <4E422A74.3090601@wp.pl> Date: Wed, 10 Aug 2011 08:51:32 +0200 From: Marek Salwerowicz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Freddie Cash , freebsd-net@freebsd.org References: <4E412116.1070305@wp.pl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 [wVPE] Cc: Subject: Re: ipfw - accessing DMZ from LAN 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, 10 Aug 2011 06:52:49 -0000 W dniu 2011-08-09 18:04, Freddie Cash pisze: > On Tue, Aug 9, 2011 at 4:59 AM, Marek Salwerowicz wrote: > >> I have set up a new router for my network, with separated DMZ zone for my >> internet servers. I'd like computers from my LAN to be able to connect to >> DMZ zone. >> >> My ISP provided me some public IP's, so right now configuration looks like >> this: >> >> Router with 4 NICs: >> #public ISP >> ifconfig_vr3="inet xx.yy.zz.171 netmask 255.255.255.248" >> ifconfig_vr3_alias0="inet xx.yy.zz.170 netmask 255.255.255.255" >> ifconfig_vr3_alias1="inet xx.yy.zz.172 netmask 255.255.255.255" >> ifconfig_vr3_alias2="inet xx.yy.zz.173 netmask 255.255.255.255" >> >> The first IP, with suffix .171 I want to be used as real router's IP, and >> public IP for computers in my LAN. >> All 3 aliases I want to be redirected to DMZ (one public IP for each server >> in DMZ) >> >> #DMZ >> ifconfig_vr2="inet 192.168.0.1 netmask 255.255.255.0" >> >> #LAN >> ifconfig_vr0="inet 10.0.0.1 netmask 255.255.255.0" >> >> I've set up in natd.conf: >> >> use_sockets yes >> same_ports yes >> interface vr3 >> dynamic yes >> unregistered_only yes >> redirect_address 192.168.0.10 xx.yy.zz.170 #DMZ host 1 >> redirect_address 192.168.0.20 xx.yy.zz.172 #DMZ host 2 >> redirect_address 192.168.0.30 xx.yy.zz.173 #DMZ host 3 >> >> Right now everything works from the Internet - if I do ssh to xx.yy.zz.170, >> I really can connect to host 192.168.0.10 etc. >> >> The problem is that when I want to connect from my 10.0.0.0/24 network >> (and even from router) to any DMZ host, using it's public address (any of >> xx.yy.zz.{170,172,173} ), I can't connect and in fact I am connecting to the >> router.. >> So I am unable to access my web, mta, ftp servers that are located in DMZ >> >> My ipfw firewall script looks as follows: >> >> #!/bin/sh >> >> cmd="ipfw -q" >> >> DMZ="192.168.0.0/24" >> LAN="10.0.0.0/24" >> >> kldstat -q -m dummynet || kldload dummynet >> $cmd flush >> >> $cmd add 80 divert natd ip from any to any via vr3 >> $cmd add 90 allow ip from any to any via lo0 >> >> $cmd add 100 allow ip from any to me >> $cmd add 101 allow ip from me to any >> >> $cmd add 500 deny ip from $DMZ to $LAN >> $cmd add 510 deny ip from $LAN to $DMZ >> >> >> $cmd add 10000 allow ip from any to any >> >> I know I've blcoked traffic between DMZ and LAN, but I wanted them to >> contact via public IPs.. but now I'm not sure if it's possible... >> >> Can you give me some hints on how to properly configure my router? >> > There are two ways to do this, depending on whether or not you want to > "leak" you private LAN IPs into the DMz. > > The simplest method, where LAN clients connect to the public IP of the DMZ > servers, and where the DMZ servers see the private IPs of the clients, is > like so: > > # Configure the natd process to NAT from x.x.x.170 to 192.168.0.10 using > some port > natd -port $port -same_ports -use_sockets -alias_address x.x.x.170 > -redirect_address x.x.x.170 192.168.0.10 > > # NAT the traffic coming from the LAN to x.x.x.170 > ipfw add divert $port ip from $LAN to x.x.x.170 in recv vr0 > ipfw add allow ip from $LAN to 192.168.0.10 in recv vr0 > > ipfw add allow ip from $LAN to 192.168.0.10 out xmit vr2 > ipfw add allow ip from 192.168.0.10 to $LAN in recv vr2 > > ipfw add divert ip from 192.168.0.10 to $LAN out xmit vr0 > ipfw add allow ip from x.x.x.170 to $LAN out xmit vr0 > > Repeat the above for each of the servers in the DMZ, using separate natd > processes for each, with separate divert port numbers. > > The general flow of the rules above is (src --> dest) > 10.0.0.x --> x.x.x.170 > 10.0.0.x --> 192.168.0.10 > > 192.168.0.10 --> 10.0.0.x > x.x.x.170 --> 10.0.0.x > > > The more correct method is to double-NAT the traffic, such that the LAN > clients connect to public IPs, and the DMZ servers see connections from > public IPs. It's more complicated to wrap your head around the first time, > but it prevents private IPs from "leaking" between the LAN, the Internet, > and the DMZ. (It took me 10 years of using IPFW to figure this one out.) > > # Configure the general natd process for the LAN > natd -port $port2 -same_ports -use_sockets -alias_address x.x.x.171 > > # Configure the natd process to NAT from x.x.x.170 to 192.168.0.10 using > some port > natd -port $port1 -same_ports -use_sockets -alias_address x.x.x.170 > -redirect_address x.x.x.170 192.168.0.10 > > # NAT the traffic coming from the LAN to x.x.x.170 > ipfw add divert $port1 ip from $LAN to x.x.x.170 in recv vr0 > ipfw add allow ip from $LAN to 192.168.0.10 in recv vr0 > > # NAT the traffic going to x.x.x.170 from the LAN > ipfw add divert $port2 ip from $LAN to 192.168.0.10 out xmit vr2 > ipfw add allow ip from x.x.x.171 to 192.168.0.10 out xmit vr2 > > # NAT the traffic coming from x.x.x.170 to the LAN > ipfw add divert $port1 ip from 192.168.0.10 to x.x.x.171 in recv vr2 > ipfw add allow ip from 192.168.0.10 to $LAN in recv vr2 > > # NAT the traffic going to the LAN from x.x.x.170 > ipfw add divert ip from 192.168.0.10 to $LAN out xmit vr0 > ipfw add allow ip from x.x.x.170 t0 $LAN out xmit vr0 > > The general flow of the rules above is (src --> dest) > 10.0.0.x --> x.x.x.170 > 10.0.0.x --> 192.168.0.10 (after first NAT) > x.x.x.171 --> 192.168.0.10 (after second NAT) > > 192.168.0.10 --> x.x.x.171 > 192.168.0.10 --> 10.0.0.x (after first NAT) > x.x.x.170 --> 10.0.0.x (after second NAT) > > Notice how vr3 is never used in any of the rules above, as the packets never > touch the public interface of the router. > Thanks for that hints. Do you mean $port viariables as particular port numbers? So for each service in DMZ I want to be available I have to create such set of rules? Regards, -- Marek Salwerowicz From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 07:29:47 2011 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 16A41106564A; Wed, 10 Aug 2011 07:29:47 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id B28A28FC32; Wed, 10 Aug 2011 07:29:46 +0000 (UTC) Received: from asuka.mahoroba.org (ume@ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (user=ume mech=CRAM-MD5 bits=0) by mail.mahoroba.org (8.14.5/8.14.5) with ESMTP/inet6 id p7A7TXh1021511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Aug 2011 16:29:39 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 10 Aug 2011 16:29:33 +0900 Message-ID: From: Hajimu UMEMOTO To: Mattia Rossi In-Reply-To: <4E3F853E.4030201@swin.edu.au> References: <4E3B86C4.7050005@swin.edu.au> <4E3B9346.9000101@FreeBSD.org> <4E3F853E.4030201@swin.edu.au> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (amd64-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Wed, 10 Aug 2011 16:29:39 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.2 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-3.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org, Doug Barton , fbsd@opal.com, freebsd-current@freebsd.org Subject: Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related 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, 10 Aug 2011 07:29:47 -0000 Hi, >>>>> On Mon, 08 Aug 2011 16:42:06 +1000 >>>>> Mattia Rossi said: mrossi> Anyhow, the manpage is really not clear about name_servers_append, and mrossi> it's not working as expected either: mrossi> 1) If I put in a comma separated list of nameservers, I'll find that mrossi> comma separated list in /etc/resolv.conf under a single "nameserver" mrossi> tag. That doesn't work, as it's not a valid entry. Each nameserver mrossi> needs to have a "nameserver " entry. name_servers and name_servers_append is a space separated list of nameserver. mrossi> 2) If I use multiple name_servers_append entries in mrossi> /etc/resolvconf.conf, then only the last entry is used. I don't want mrossi> only one DNS server there though, I want all three of them, as I mrossi> already had the problem that one or the other didn't work properly. You can specify multiple nameservers in name_servers and/or name_servers_append. mrossi> 3) If I read the description for name_servers in resolvconf.conf(5), I mrossi> understand that this tag prepends the nameserver to my list. This is mrossi> not what happens. Still not sure what actually happens there... It is strange to me. If you specify name_servers, it should be prepended to the nameserver list. I've just tried name_servers, and it did the job as expected, here. mrossi> How do I get my 3 manual DNS entries properly into my resolv.conf ? Please specify your 3 servers as space separated list in name_servers or name_servers_append. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 12:07:12 2011 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 2A34F106566B; Wed, 10 Aug 2011 12:07:12 +0000 (UTC) (envelope-from ferdinand.goldmann@jku.at) Received: from emailsecure.uni-linz.ac.at (emailsecure.uni-linz.ac.at [140.78.3.66]) by mx1.freebsd.org (Postfix) with ESMTP id E8AE08FC0C; Wed, 10 Aug 2011 12:07:11 +0000 (UTC) Received: from Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ferdinand Goldmann In-Reply-To: <86mxfhyfy7.fsf@in138.ua3> Date: Wed, 10 Aug 2011 14:07:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <577E10A2-9193-4E36-A7DC-AAC1AA816104@jku.at> References: <86mxfhyfy7.fsf@in138.ua3> To: Mikolaj Golub X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: Problem using CARP + HAST ... 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, 10 Aug 2011 12:07:12 -0000 On 10.08.2011, at 7:48, Mikolaj Golub wrote: > What freebsd are you running on? I suppose it is release, because on = STABLE > this issue should be fixed -- the secondary terminates after timeout. I was running 8.2-RELEASE-p2 and now just upgraded to 8.2-STABLE. This = really seems to have helped: The slave now times out without intervention, allowing = himself to become the new master. Once the (old) master is online again, it will = take over from the slave.=20 The split-brain problem then of course has to be resolved manually as = described in the manual. But as I am using mostly static data and - most likely - no changes will = occur as long as the slave is master, this is not a big deal. Thanks for your advice & best regards, Ferdinand= From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 14:04:54 2011 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 2289E106564A for ; Wed, 10 Aug 2011 14:04:54 +0000 (UTC) (envelope-from tomas@tutus.se) Received: from fw-y.tutus.se (static-213-115-50-13.sme.bredbandsbolaget.se [213.115.50.13]) by mx1.freebsd.org (Postfix) with ESMTP id 90C508FC16 for ; Wed, 10 Aug 2011 14:04:52 +0000 (UTC) Received: from [193.181.0.161] (193.181.0.161 [193.181.0.161]) by fw.tutus.se (omb_smtp 1.8.1) with ESMTP; (cipher=DHE-RSA-AES256-SHA from= verify=NO) Wed, 10 Aug 2011 15:44:24 +0200 (CEST) Message-ID: <4E428B34.7020205@tutus.se> Date: Wed, 10 Aug 2011 15:44:20 +0200 From: Tomas Svensson User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: em driver support for Intel 82579LM still buggy in FreeBSD 9.0-BETA1 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, 10 Aug 2011 14:04:54 -0000 Hi, I sent a pr (kern/157418) that the em driver seems to be buggy for Intel 82579LM Gigabit Network Connection which passed unnoticed. I now tried it in FreeBSD 9.0-BETA1 and the problem is still present. Does anyone else have this problem or have any ideas on how to fix it? I assume that the initialization code for this chip is buggy, since the driver locks up depending on if you build it with debug symbols or not. The kernel also reports 'acquiring duplicate lock of same type: "network driver"' only for this chip. -Tomas From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 14:22:02 2011 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 8F966106566B for ; Wed, 10 Aug 2011 14:22:02 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 42D0C8FC15 for ; Wed, 10 Aug 2011 14:22:02 +0000 (UTC) Received: by vxh11 with SMTP id 11so1182046vxh.13 for ; Wed, 10 Aug 2011 07:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Enn8VNh/yP6MJhGtuxvzh/HUHJgU4HnRXmEds2QouDA=; b=YnP4qudnioJfolp5VE26jQVf2G455uUFANXsHBPplpo49tTS/k9XU6F/hGJb/SHkNo 2Ibw0AkQ9hbCuBHx+x7htxvVwhDxH/h4qRS7rdoglc6aNjeiXnqs+8HAjH63saJ6vPQr 0SAuFKzADMmkXbnns+Eaq9hbcP5e3Slgh+LYo= MIME-Version: 1.0 Received: by 10.52.71.142 with SMTP id v14mr1812869vdu.211.1312986121678; Wed, 10 Aug 2011 07:22:01 -0700 (PDT) Received: by 10.220.186.134 with HTTP; Wed, 10 Aug 2011 07:22:01 -0700 (PDT) In-Reply-To: <4E422A74.3090601@wp.pl> References: <4E412116.1070305@wp.pl> <4E422A74.3090601@wp.pl> Date: Wed, 10 Aug 2011 07:22:01 -0700 Message-ID: From: Freddie Cash To: Marek Salwerowicz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ipfw - accessing DMZ from LAN 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, 10 Aug 2011 14:22:02 -0000 On Tue, Aug 9, 2011 at 11:51 PM, Marek Salwerowicz wrote: > W dniu 2011-08-09 18:04, Freddie Cash pisze: > > On Tue, Aug 9, 2011 at 4:59 AM, Marek Salwerowicz >> wrote: >> >> I have set up a new router for my network, with separated DMZ zone for my >>> internet servers. I'd like computers from my LAN to be able to connect to >>> DMZ zone. >>> >>> My ISP provided me some public IP's, so right now configuration looks >>> like >>> this: >>> >>> Router with 4 NICs: >>> #public ISP >>> ifconfig_vr3="inet xx.yy.zz.171 netmask 255.255.255.248" >>> ifconfig_vr3_alias0="inet xx.yy.zz.170 netmask 255.255.255.255" >>> ifconfig_vr3_alias1="inet xx.yy.zz.172 netmask 255.255.255.255" >>> ifconfig_vr3_alias2="inet xx.yy.zz.173 netmask 255.255.255.255" >>> >>> The first IP, with suffix .171 I want to be used as real router's IP, and >>> public IP for computers in my LAN. >>> All 3 aliases I want to be redirected to DMZ (one public IP for each >>> server >>> in DMZ) >>> >>> #DMZ >>> ifconfig_vr2="inet 192.168.0.1 netmask 255.255.255.0" >>> >>> #LAN >>> ifconfig_vr0="inet 10.0.0.1 netmask 255.255.255.0" >>> >>> I've set up in natd.conf: >>> >>> use_sockets yes >>> same_ports yes >>> interface vr3 >>> dynamic yes >>> unregistered_only yes >>> redirect_address 192.168.0.10 xx.yy.zz.170 #DMZ host 1 >>> redirect_address 192.168.0.20 xx.yy.zz.172 #DMZ host 2 >>> redirect_address 192.168.0.30 xx.yy.zz.173 #DMZ host 3 >>> >>> Right now everything works from the Internet - if I do ssh to >>> xx.yy.zz.170, >>> I really can connect to host 192.168.0.10 etc. >>> >>> The problem is that when I want to connect from my 10.0.0.0/24 network >>> (and even from router) to any DMZ host, using it's public address (any of >>> xx.yy.zz.{170,172,173} ), I can't connect and in fact I am connecting to >>> the >>> router.. >>> So I am unable to access my web, mta, ftp servers that are located in DMZ >>> >>> My ipfw firewall script looks as follows: >>> >>> #!/bin/sh >>> >>> cmd="ipfw -q" >>> >>> DMZ="192.168.0.0/24" >>> LAN="10.0.0.0/24" >>> >>> kldstat -q -m dummynet || kldload dummynet >>> $cmd flush >>> >>> $cmd add 80 divert natd ip from any to any via vr3 >>> $cmd add 90 allow ip from any to any via lo0 >>> >>> $cmd add 100 allow ip from any to me >>> $cmd add 101 allow ip from me to any >>> >>> $cmd add 500 deny ip from $DMZ to $LAN >>> $cmd add 510 deny ip from $LAN to $DMZ >>> >>> >>> $cmd add 10000 allow ip from any to any >>> >>> I know I've blcoked traffic between DMZ and LAN, but I wanted them to >>> contact via public IPs.. but now I'm not sure if it's possible... >>> >>> Can you give me some hints on how to properly configure my router? >>> >>> There are two ways to do this, depending on whether or not you want to >> "leak" you private LAN IPs into the DMz. >> >> The simplest method, where LAN clients connect to the public IP of the DMZ >> servers, and where the DMZ servers see the private IPs of the clients, is >> like so: >> >> # Configure the natd process to NAT from x.x.x.170 to 192.168.0.10 using >> some port >> natd -port $port -same_ports -use_sockets -alias_address x.x.x.170 >> -redirect_address x.x.x.170 192.168.0.10 >> >> # NAT the traffic coming from the LAN to x.x.x.170 >> ipfw add divert $port ip from $LAN to x.x.x.170 in recv vr0 >> ipfw add allow ip from $LAN to 192.168.0.10 in recv vr0 >> >> ipfw add allow ip from $LAN to 192.168.0.10 out xmit vr2 >> ipfw add allow ip from 192.168.0.10 to $LAN in recv vr2 >> >> ipfw add divert ip from 192.168.0.10 to $LAN out xmit vr0 >> ipfw add allow ip from x.x.x.170 to $LAN out xmit vr0 >> >> Repeat the above for each of the servers in the DMZ, using separate natd >> processes for each, with separate divert port numbers. >> >> The general flow of the rules above is (src --> dest) >> 10.0.0.x --> x.x.x.170 >> 10.0.0.x --> 192.168.0.10 >> >> 192.168.0.10 --> 10.0.0.x >> x.x.x.170 --> 10.0.0.x >> >> >> The more correct method is to double-NAT the traffic, such that the LAN >> clients connect to public IPs, and the DMZ servers see connections from >> public IPs. It's more complicated to wrap your head around the first >> time, >> but it prevents private IPs from "leaking" between the LAN, the Internet, >> and the DMZ. (It took me 10 years of using IPFW to figure this one out.) >> >> # Configure the general natd process for the LAN >> natd -port $port2 -same_ports -use_sockets -alias_address x.x.x.171 >> >> # Configure the natd process to NAT from x.x.x.170 to 192.168.0.10 using >> some port >> natd -port $port1 -same_ports -use_sockets -alias_address x.x.x.170 >> -redirect_address x.x.x.170 192.168.0.10 >> >> # NAT the traffic coming from the LAN to x.x.x.170 >> ipfw add divert $port1 ip from $LAN to x.x.x.170 in recv vr0 >> ipfw add allow ip from $LAN to 192.168.0.10 in recv vr0 >> >> # NAT the traffic going to x.x.x.170 from the LAN >> ipfw add divert $port2 ip from $LAN to 192.168.0.10 out xmit vr2 >> ipfw add allow ip from x.x.x.171 to 192.168.0.10 out xmit vr2 >> >> # NAT the traffic coming from x.x.x.170 to the LAN >> ipfw add divert $port1 ip from 192.168.0.10 to x.x.x.171 in recv vr2 >> ipfw add allow ip from 192.168.0.10 to $LAN in recv vr2 >> >> # NAT the traffic going to the LAN from x.x.x.170 >> ipfw add divert ip from 192.168.0.10 to $LAN out xmit vr0 >> ipfw add allow ip from x.x.x.170 t0 $LAN out xmit vr0 >> >> The general flow of the rules above is (src --> dest) >> 10.0.0.x --> x.x.x.170 >> 10.0.0.x --> 192.168.0.10 (after first NAT) >> x.x.x.171 --> 192.168.0.10 (after second NAT) >> >> 192.168.0.10 --> x.x.x.171 >> 192.168.0.10 --> 10.0.0.x (after first NAT) >> x.x.x.170 --> 10.0.0.x (after second NAT) >> >> Notice how vr3 is never used in any of the rules above, as the packets >> never >> touch the public interface of the router. >> >> Thanks for that hints. > > Do you mean $port viariables as particular port numbers? > Each instance of natd needs it's own divert port number. Which number you choose is up to you. The default port, if you don't set one, is 8668. On our firewalls, we tend to use 7000+the last octet of the IP (so 7170 for x.x.x.170). But (AFAIK) there are no rules or limitations on the port number (other than under 65536). > So for each service in DMZ I want to be available I have to create such set > of rules? Depends how specific you want the rules to be. You can keep it generic like the above, and just have the 8 rules for each server in the DMZ. Or, you can make the rules very specific, and have sets of 8 for each protocol (TCP/UDP/ICMP/etc) and each port. > -- > Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 16:05:28 2011 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 F09511065673 for ; Wed, 10 Aug 2011 16:05:28 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 752C58FC14 for ; Wed, 10 Aug 2011 16:05:28 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p7AG5RQp006675 for ; Wed, 10 Aug 2011 20:05:27 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p7AG5QXa006674 for net@FreeBSD.org; Wed, 10 Aug 2011 20:05:26 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 10 Aug 2011 20:05:26 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Message-ID: <20110810160526.GO43567@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: new CARP implementation 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, 10 Aug 2011 16:05:29 -0000 Hello networkers, I'd like to present for review and early testing (for brave ones) a new CARP implementation. The reason for this rewrite was that CARP protocol actually doesn't bring a new interface, but is a property of interface address. Rewriting it in this way helps to remove several hacks from incoming packet processing[1], simplifies some code, makes CARP addresses more sane from viewpoint of routing daemons such as quagga/zebra. It also brings support for a single redundant address on the subnet, the thing that is called "carpdev feature" in OpenBSD, long awaited in FreeBSD. More info and the patch itself is available here: http://people.freebsd.org/~glebius/newcarp/README I'm glad to here comments. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 16:23:47 2011 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 ABD031065670 for ; Wed, 10 Aug 2011 16:23:47 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 62A3E8FC0C for ; Wed, 10 Aug 2011 16:23:47 +0000 (UTC) Received: by vws18 with SMTP id 18so1341586vws.13 for ; Wed, 10 Aug 2011 09:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P3jskfcc0PBMROaenWQws3kdGj4vva35zOt6TYrq/lY=; b=F7TXCbEuxy5HRAbBNnr6FPEAMcHym653ycroVhhR5SKtlw5PtdvuCa3eGwMgI6O0CK 96BusbCloL5feJRUVUtVhCe8u2DnMMqGfX6bF88fMj0EvKFRk30V9k+fpFGhvgsERSaP hpsEj3apGw8vv6lUwXStce6GUelMRMq2cbpMY= MIME-Version: 1.0 Received: by 10.52.183.37 with SMTP id ej5mr1691096vdc.423.1312993426516; Wed, 10 Aug 2011 09:23:46 -0700 (PDT) Received: by 10.52.107.105 with HTTP; Wed, 10 Aug 2011 09:23:46 -0700 (PDT) In-Reply-To: <4E428B34.7020205@tutus.se> References: <4E428B34.7020205@tutus.se> Date: Wed, 10 Aug 2011 09:23:46 -0700 Message-ID: From: Jack Vogel To: Tomas Svensson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: em driver support for Intel 82579LM still buggy in FreeBSD 9.0-BETA1 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, 10 Aug 2011 16:23:47 -0000 I have limited access to this hardware, I am told I will tomorrow, and will repro and test a fix that I have in mind, so stay tuned. I just noticed this bug is at a low priority, it should be higher than that. Jack On Wed, Aug 10, 2011 at 6:44 AM, Tomas Svensson wrote: > Hi, > > I sent a pr (kern/157418) that the em driver seems to be buggy for Intel > 82579LM Gigabit Network Connection which passed unnoticed. I now tried > it in FreeBSD 9.0-BETA1 and the problem is still present. > > Does anyone else have this problem or have any ideas on how to fix it? I > assume that the initialization code for this chip is buggy, since the > driver locks up depending on if you build it with debug symbols or not. > The kernel also reports 'acquiring duplicate lock of same type: "network > driver"' only for this chip. > > -Tomas > _______________________________________________ > 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 Aug 10 17:04:13 2011 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 A93481065672; Wed, 10 Aug 2011 17:04:13 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 516258FC17; Wed, 10 Aug 2011 17:04:13 +0000 (UTC) Received: by vxh11 with SMTP id 11so1362198vxh.13 for ; Wed, 10 Aug 2011 10:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q249DMjNanS9Y18+f/fzCwQU+HTf6KJAmkBNXFAU2lM=; b=k7d/VdcKX4xIZ9CJIP5m37No1Yn3AylxDzqngvc2Yow41u0+tCxwM3PCZ7tRMnnWrx X6sRP41XUARa3ARz96FTLLBGZ/HX6h+kXgP40yYf58rxiRZxS6B5WSq7MWQgRkF9tECo gzPNRVWDSzQpYV1nYOVp3nogFWaK4/24Rx8Pg= MIME-Version: 1.0 Received: by 10.220.57.11 with SMTP id a11mr2641607vch.4.1312994284852; Wed, 10 Aug 2011 09:38:04 -0700 (PDT) Received: by 10.220.186.134 with HTTP; Wed, 10 Aug 2011 09:38:04 -0700 (PDT) In-Reply-To: <20110810160526.GO43567@FreeBSD.org> References: <20110810160526.GO43567@FreeBSD.org> Date: Wed, 10 Aug 2011 09:38:04 -0700 Message-ID: From: Freddie Cash To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: new CARP implementation 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, 10 Aug 2011 17:04:13 -0000 2011/8/10 Gleb Smirnoff > I'd like to present for review and early testing (for brave ones) > a new CARP implementation. The reason for this rewrite was that CARP > protocol actually doesn't bring a new interface, but is a property of > interface address. Rewriting it in this way helps to remove several > hacks from incoming packet processing[1], simplifies some code, makes > CARP addresses more sane from viewpoint of routing daemons such as > quagga/zebra. It also brings support for a single redundant address > on the subnet, the thing that is called "carpdev feature" in OpenBSD, > long awaited in FreeBSD. > > More info and the patch itself is available here: > > http://people.freebsd.org/~glebius/newcarp/README > > I'm glad to here comments. > > Whoohoo! Thanks for working on this! :) I really like that you no longer need to "waste" IPs in order to share a virtual IP. This is the reason I've been experimenting with freevrrpd on FreeBSD, which isn't anywhere near as elegant as carp(4). However, I'm not sure I understand the reasoning for removing the carpX pseudo-interface. It's really nice having the symmetry between carpX, vlanX, brX, and other pseudo-interfaces, and keeping the configuration details separate from the underlying physical interface. This now makes creating/configuring CARP different from creating/configuring vLANs. :( -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Aug 10 23:23:05 2011 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 0D7B5106564A; Wed, 10 Aug 2011 23:23:05 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by mx1.freebsd.org (Postfix) with ESMTP id 972B38FC19; Wed, 10 Aug 2011 23:23:04 +0000 (UTC) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p7ANMaTA027691; Thu, 11 Aug 2011 09:22:51 +1000 Message-ID: <4E4312BC.9060106@swin.edu.au> Date: Thu, 11 Aug 2011 09:22:36 +1000 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110707 Thunderbird/5.0 MIME-Version: 1.0 To: Hajimu UMEMOTO References: <4E3B86C4.7050005@swin.edu.au> <4E3B9346.9000101@FreeBSD.org> <4E3F853E.4030201@swin.edu.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org, Doug Barton , fbsd@opal.com Subject: Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related 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, 10 Aug 2011 23:23:05 -0000 On 10/08/2011 17:29, Hajimu UMEMOTO wrote: > Hi, > >>>>>> On Mon, 08 Aug 2011 16:42:06 +1000 >>>>>> Mattia Rossi said: > > mrossi> Anyhow, the manpage is really not clear about name_servers_append, and > mrossi> it's not working as expected either: > > mrossi> 1) If I put in a comma separated list of nameservers, I'll find that > mrossi> comma separated list in /etc/resolv.conf under a single "nameserver" > mrossi> tag. That doesn't work, as it's not a valid entry. Each nameserver > mrossi> needs to have a "nameserver" entry. > > name_servers and name_servers_append is a space separated list of > nameserver. Ahh, okay, that works. Might be worth mentioning in the manpage though. Maybe an example wouldn't be too bad either > > mrossi> 2) If I use multiple name_servers_append entries in > mrossi> /etc/resolvconf.conf, then only the last entry is used. I don't want > mrossi> only one DNS server there though, I want all three of them, as I > mrossi> already had the problem that one or the other didn't work properly. > > You can specify multiple nameservers in name_servers and/or > name_servers_append. Of course, once 1) is solved 2) is redundant. > > mrossi> 3) If I read the description for name_servers in resolvconf.conf(5), I > mrossi> understand that this tag prepends the nameserver to my list. This is > mrossi> not what happens. Still not sure what actually happens there... > > It is strange to me. If you specify name_servers, it should be > prepended to the nameserver list. I've just tried name_servers, and > it did the job as expected, here. Hmm, not sure what happened last time here, but I've tried it now with a single nameserver, a space separated list of nameservers and a mix of name_servers and name_servers_append entries and it worked perfectly. It also eliminated duplicate entries in name_servers and name_servers_append, preferring the one in name_servers. Again, maybe worthwhile mentioning in the manpage. > > mrossi> How do I get my 3 manual DNS entries properly into my resolv.conf ? > > Please specify your 3 servers as space separated list in name_servers > or name_servers_append. > Yes, got it. All good! Thanks to all! Mat From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 01:13:35 2011 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 8094B106566C; Thu, 11 Aug 2011 01:13:35 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 1A3B98FC16; Thu, 11 Aug 2011 01:13:35 +0000 (UTC) Received: from lstewart-laptop.caia.swin.edu.au (unknown [74.125.56.18]) by lauren.room52.net (Postfix) with ESMTPSA id D53B57E824; Thu, 11 Aug 2011 11:13:32 +1000 (EST) Message-ID: <4E432CB2.3030700@freebsd.org> Date: Thu, 11 Aug 2011 11:13:22 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110727 Thunderbird/5.0 MIME-Version: 1.0 To: Steven Hartland References: <1F95A4C2D54E4F369830143CBDB5FF86@multiplay.co.uk><4E37C0F2.4080004@freebsd.org> <2B063B6D95AA4C27B004C50D96393F91@multiplay.co.uk> <4E3AA66A.6060605@freebsd.org> <20229216858044E4881642284F245750@multiplay.co.uk> In-Reply-To: <20229216858044E4881642284F245750@multiplay.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-net@freebsd.org, Andre Oppermann , slw@zxy.spb.ru Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? 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, 11 Aug 2011 01:13:35 -0000 On 08/05/11 00:19, Steven Hartland wrote: > ----- Original Message ----- From: "Lawrence Stewart" > [snip] >>> So I suppose the question is should maxsegments be larger by >>> default due to the recent changes e.g. >>> - V_tcp_reass_maxseg = nmbclusters / 16; >>> + V_tcp_reass_maxseg = nmbclusters / 8; >>> >>> or is the correct fix something more involved? >> >> I'm not sure if bumping the value is appropriate - we have always >> expected users to tune their network stack to perform well when used >> in "unusual" scenarios - a large BDP fibre path still being in the >> "unusual" category. > > TBH I wouldn't classify a latency of 7ms @ 100Mbps unusal in the slightest > in this day and age. Are the TCP sessions experiencing the problem terminating on either side of that link i.e. is the RTT of the connection 7ms? Or does the fibre link form one part of the path connections are traversing? Based on your symptoms, I believe the latter is the case (the BDP of a 7ms 100Mbps fiber link is a lot smaller than your pre-tweaked reass max queue limit and therefore shouldn't have caused stalls), in which case it's not the characteristics of your fiber link that matter in their own right, but the characteristics of the complete path from sender to receiver. >> The real fix which is somewhere down on my todo list is to make all >> these memory constraints elastic and respond to VM pressure, thus >> negating the need for a hard limit at all. This would solve many if >> not most of the TCP tuning problems we currently have with one foul >> swoop and would greatly reduce the need for tuning in many situations >> that currently are in the "needs manual tuning" basket. > > This would indeed be a great improvement. > >> Andre and Steven, I'm a bit too sleepy to properly review your >> combined proposed changes right now and will follow up in the next few >> days instead. > > No problem, we've increased nmbclusters on all our machines and there now > performing fine in the problem scenario so no rush, look forward to your > feedback when you've had some sleep :) Steven, as far as my reading of the code informs me, your additional sanity checking is unnecessary - the segment only gets added to the reassembly list where the calls to LIST_INSERT_* are, and the uma_zfree() in the "if (p != NULL)" block shouldn't ever be called if the incoming segment is equal to rcv_nxt. However, I would like to see some additional sanity checking added to Andre's base patch in the form of some KASSERTs. There are a number of hidden assumptions in the current code and I think explicitly noting them with KASSERTs would be useful. I'm also paranoid about leaking a stack allocated tseg_qent across calls to tcp_reass() as that would be a horrendous bug to diagnose. Here's my tweaked version of Andre's patch: http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass.c-logdebug%2bmissingsegment-20110811-lstewart.diff It has only been compile tested at this point. BTW, when a patch is eventually committed, the logging changes should be done separately to the KASSERT/backup stack allocated tseg_qent change. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 01:30:41 2011 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 5DB26106566C; Thu, 11 Aug 2011 01:30:41 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 1F3898FC08; Thu, 11 Aug 2011 01:30:40 +0000 (UTC) Received: from lstewart-laptop.caia.swin.edu.au (unknown [74.125.56.18]) by lauren.room52.net (Postfix) with ESMTPSA id D0DE47E824; Thu, 11 Aug 2011 11:30:39 +1000 (EST) Message-ID: <4E4330B5.5030100@freebsd.org> Date: Thu, 11 Aug 2011 11:30:29 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110727 Thunderbird/5.0 MIME-Version: 1.0 To: Slawa Olhovchenkov References: <1F95A4C2D54E4F369830143CBDB5FF86@multiplay.co.uk> <4E37C0F2.4080004@freebsd.org> <2B063B6D95AA4C27B004C50D96393F91@multiplay.co.uk> <4E3AA66A.6060605@freebsd.org> <20110805065743.GC94016@zxy.spb.ru> In-Reply-To: <20110805065743.GC94016@zxy.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: Steven Hartland , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? 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, 11 Aug 2011 01:30:41 -0000 On 08/05/11 16:57, Slawa Olhovchenkov wrote: > On Fri, Aug 05, 2011 at 12:02:18AM +1000, Lawrence Stewart wrote: [snip] >> >> The real fix which is somewhere down on my todo list is to make all >> these memory constraints elastic and respond to VM pressure, thus >> negating the need for a hard limit at all. This would solve many if not >> most of the TCP tuning problems we currently have with one foul swoop >> and would greatly reduce the need for tuning in many situations that >> currently are in the "needs manual tuning" basket. > > Autotunig w/o limits is bad idea. This is way to DoS. Depends how it is implemented. With appropriate backpressure mechanisms put in place, it could be perfectly safe. I envisage reassembly segments being at the bottom of the heap in terms of importance, so if a machine were to come under memory pressure, they would be the first thing to be reclaimed. TCP would continue to operate if they got pulled out from under the connection as the protocol doesn't consider segments held in reassembly to have been delivered, so would recover via retransmission. > May be solved this trouble by preallocation "hidden" element in tqe > for segment received in valid order and ready for send to application? > T.e. when creating reassembled queue for tcp connection we allocation > queue element (with room for data payload), used only when data ready > for application. Allocation in queue for not breaking ABI (don't > change struct tcpcb). I'm not sure I quite follow what you're suggesting here, but I think Andre's proposed patch achieves the same goal and is arguably cleaner? Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 07:50:09 2011 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 1C98D106566C; Thu, 11 Aug 2011 07:50:09 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id B0BF98FC08; Thu, 11 Aug 2011 07:50:08 +0000 (UTC) Received: from asuka.mahoroba.org (ume@ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (user=ume mech=CRAM-MD5 bits=0) by mail.mahoroba.org (8.14.5/8.14.5) with ESMTP/inet6 id p7B7o122030424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Aug 2011 16:50:02 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 11 Aug 2011 16:50:01 +0900 Message-ID: From: Hajimu UMEMOTO To: Mattia Rossi In-Reply-To: <20110808075511.290a3b6d@shibato.opal.com> References: <4E3B86C4.7050005@swin.edu.au> <4E3B9346.9000101@FreeBSD.org> <20110805123050.1aa49e0c@shibato.opal.com> <4E3F31D8.6050208@swin.edu.au> <20110808075511.290a3b6d@shibato.opal.com> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (amd64-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Thu, 11 Aug 2011 16:50:02 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.2 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-3.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org, Doug Barton , "J.R. Oldroyd" , freebsd-current@freebsd.org Subject: Re: resolvconf script overwrites entries in resolv.conf - RDNSS/DNSSL related 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, 11 Aug 2011 07:50:09 -0000 Hi, >>>>> On Mon, 8 Aug 2011 07:55:11 -0400 >>>>> "J.R. Oldroyd" said: > Is there any chance that you could create a patch for 8.2 based on the > commits in HEAD? > That would be great! > fbsd> Better would be to ask hrs@ to MFC his commits to 8-stable. hrs@ posted MFC candidate patch for review. Please refer the thread started from: http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029070.html The patches you will find in the thread are: http://people.freebsd.org/~hrs/rfc6106_stable8_20110612-1.diff http://people.freebsd.org/~ume/resolvconf-releng_8.diff You may be interested in the thread from the following as well: http://lists.freebsd.org/pipermail/freebsd-net/2011-June/029091.html Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 08:25:33 2011 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 568A8106564A for ; Thu, 11 Aug 2011 08:25:33 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id D083D8FC0A for ; Thu, 11 Aug 2011 08:25:32 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p7B8PV4f012975; Thu, 11 Aug 2011 12:25:31 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p7B8PVRv012974; Thu, 11 Aug 2011 12:25:31 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 11 Aug 2011 12:25:31 +0400 From: Gleb Smirnoff To: Freddie Cash Message-ID: <20110811082531.GR43567@glebius.int.ru> References: <20110810160526.GO43567@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: Re: new CARP implementation 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, 11 Aug 2011 08:25:33 -0000 On Wed, Aug 10, 2011 at 09:38:04AM -0700, Freddie Cash wrote: F> However, I'm not sure I understand the reasoning for removing the carpX F> pseudo-interface. It's really nice having the symmetry between carpX, F> vlanX, brX, and other pseudo-interfaces, and keeping the configuration F> details separate from the underlying physical interface. F> F> This now makes creating/configuring CARP different from creating/configuring F> VLANs. :( This is done because VLANs _are_ interfaces, they are tunnels within ethernet interfaces, splitting one interface into a bunch. Bridges are interfaces, as well as LACP trunks (lagg(4)), since they group a number of interfaces into one. CARP addresses _are not_ interfaces, they are addresses. IMHO, implementing them as virtual interface subtly attached to a real one, was a layering violation. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 08:46:39 2011 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 5792A106566B; Thu, 11 Aug 2011 08:46:39 +0000 (UTC) (envelope-from prvs=1204ca57bc=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 61D178FC0A; Thu, 11 Aug 2011 08:46:38 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 11 Aug 2011 09:34:48 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 11 Aug 2011 09:34:48 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014557659.msg; Thu, 11 Aug 2011 09:34:48 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1204ca57bc=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <9768045A23B54578BA47E5AD52BC872F@multiplay.co.uk> From: "Steven Hartland" To: "Lawrence Stewart" References: <1F95A4C2D54E4F369830143CBDB5FF86@multiplay.co.uk><4E37C0F2.4080004@freebsd.org> <2B063B6D95AA4C27B004C50D96393F91@multiplay.co.uk> <4E3AA66A.6060605@freebsd.org> <20229216858044E4881642284F245750@multiplay.co.uk> <4E432CB2.3030700@freebsd.org> Date: Thu, 11 Aug 2011 09:35:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-net@freebsd.org, Andre Oppermann , slw@zxy.spb.ru Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? 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, 11 Aug 2011 08:46:39 -0000 ----- Original Message ----- From: "Lawrence Stewart" To: "Steven Hartland" Cc: "Andre Oppermann" ; ; Sent: Thursday, August 11, 2011 2:13 AM Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? > On 08/05/11 00:19, Steven Hartland wrote: >> ----- Original Message ----- From: "Lawrence Stewart" >> > [snip] >>>> So I suppose the question is should maxsegments be larger by >>>> default due to the recent changes e.g. >>>> - V_tcp_reass_maxseg = nmbclusters / 16; >>>> + V_tcp_reass_maxseg = nmbclusters / 8; >>>> >>>> or is the correct fix something more involved? >>> >>> I'm not sure if bumping the value is appropriate - we have always >>> expected users to tune their network stack to perform well when used >>> in "unusual" scenarios - a large BDP fibre path still being in the >>> "unusual" category. >> >> TBH I wouldn't classify a latency of 7ms @ 100Mbps unusal in the slightest >> in this day and age. > > Are the TCP sessions experiencing the problem terminating on either side > of that link i.e. is the RTT of the connection 7ms? Or does the fibre > link form one part of the path connections are traversing? RTT is 7ms > Based on your symptoms, I believe the latter is the case (the BDP of a > 7ms 100Mbps fiber link is a lot smaller than your pre-tweaked reass max > queue limit and therefore shouldn't have caused stalls), in which case > it's not the characteristics of your fiber link that matter in their own > right, but the characteristics of the complete path from sender to receiver. We didnt tweek any settings during the initial testing, the change of V_tcp_reass_maxseg was just a suggestion. > Steven, as far as my reading of the code informs me, your additional > sanity checking is unnecessary - the segment only gets added to the > reassembly list where the calls to LIST_INSERT_* are, and the > uma_zfree() in the "if (p != NULL)" block shouldn't ever be called if > the incoming segment is equal to rcv_nxt. > > However, I would like to see some additional sanity checking added to > Andre's base patch in the form of some KASSERTs. There are a number of > hidden assumptions in the current code and I think explicitly noting > them with KASSERTs would be useful. I'm also paranoid about leaking a > stack allocated tseg_qent across calls to tcp_reass() as that would be a > horrendous bug to diagnose. > > Here's my tweaked version of Andre's patch: > http://people.freebsd.org/~lstewart/patches/misctcp/tcp_reass.c-logdebug%2bmissingsegment-20110811-lstewart.diff > > It has only been compile tested at this point. > > BTW, when a patch is eventually committed, the logging changes should be > done separately to the KASSERT/backup stack allocated tseg_qent change. Thanks will look to give this a test soon. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 12:31:04 2011 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 2FF35106567A; Thu, 11 Aug 2011 12:31:04 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 860A08FC1C; Thu, 11 Aug 2011 12:31:03 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QrUPe-000B0c-4d; Thu, 11 Aug 2011 16:31:02 +0400 Date: Thu, 11 Aug 2011 16:31:02 +0400 From: Slawa Olhovchenkov To: Lawrence Stewart Message-ID: <20110811123102.GQ94016@zxy.spb.ru> References: <1F95A4C2D54E4F369830143CBDB5FF86@multiplay.co.uk> <4E37C0F2.4080004@freebsd.org> <2B063B6D95AA4C27B004C50D96393F91@multiplay.co.uk> <4E3AA66A.6060605@freebsd.org> <20110805065743.GC94016@zxy.spb.ru> <4E4330B5.5030100@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E4330B5.5030100@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Steven Hartland , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? 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, 11 Aug 2011 12:31:04 -0000 On Thu, Aug 11, 2011 at 11:30:29AM +1000, Lawrence Stewart wrote: > On 08/05/11 16:57, Slawa Olhovchenkov wrote: > > On Fri, Aug 05, 2011 at 12:02:18AM +1000, Lawrence Stewart wrote: > [snip] > >> > >> The real fix which is somewhere down on my todo list is to make all > >> these memory constraints elastic and respond to VM pressure, thus > >> negating the need for a hard limit at all. This would solve many if not > >> most of the TCP tuning problems we currently have with one foul swoop > >> and would greatly reduce the need for tuning in many situations that > >> currently are in the "needs manual tuning" basket. > > > > Autotunig w/o limits is bad idea. This is way to DoS. > > Depends how it is implemented. With appropriate backpressure mechanisms > put in place, it could be perfectly safe. I envisage reassembly segments > being at the bottom of the heap in terms of importance, so if a machine > were to come under memory pressure, they would be the first thing to be > reclaimed. TCP would continue to operate if they got pulled out from > under the connection as the protocol doesn't consider segments held in > reassembly to have been delivered, so would recover via retransmission. Yes, TCP would continue to operate. But attacker don't allow to put system under memory pressure. > > May be solved this trouble by preallocation "hidden" element in tqe > > for segment received in valid order and ready for send to application? > > T.e. when creating reassembled queue for tcp connection we allocation > > queue element (with room for data payload), used only when data ready > > for application. Allocation in queue for not breaking ABI (don't > > change struct tcpcb). > > I'm not sure I quite follow what you're suggesting here, but I think > Andre's proposed patch achieves the same goal and is arguably cleaner? Ande allocation on stack. My idea is different (sorry for bad english). 1. application open socket. 2. kernel allocated internal tcp structure for this socket. 2.1 additional step: kernel beforehand allocation one tseg_qent and place it in t_segq. this queue entry will be used only when we receive first good segment in right place. for example: [lost segment 100] (segment 101) (segment 102) ... (segment 100). segments 101, 102 and etc processed as usaly. segment 100 placed in reserved and previously allocated queue entry. after receive segment 100 we can send data to application (to user space). after send data queue entry from 2.1 not freed, this permanently allocated entry. From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 13:33:50 2011 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 7C12B106564A; Thu, 11 Aug 2011 13:33:50 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id BCC418FC16; Thu, 11 Aug 2011 13:33:49 +0000 (UTC) Received: from lstewart-laptop.caia.swin.edu.au (203-158-52-243.dyn.iinet.net.au [203.158.52.243]) by lauren.room52.net (Postfix) with ESMTPSA id 4C2F47E824; Thu, 11 Aug 2011 23:33:48 +1000 (EST) Message-ID: <4E43DA31.7000605@freebsd.org> Date: Thu, 11 Aug 2011 23:33:37 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110727 Thunderbird/5.0 MIME-Version: 1.0 To: Slawa Olhovchenkov References: <1F95A4C2D54E4F369830143CBDB5FF86@multiplay.co.uk> <4E37C0F2.4080004@freebsd.org> <2B063B6D95AA4C27B004C50D96393F91@multiplay.co.uk> <4E3AA66A.6060605@freebsd.org> <20110805065743.GC94016@zxy.spb.ru> <4E4330B5.5030100@freebsd.org> <20110811123102.GQ94016@zxy.spb.ru> In-Reply-To: <20110811123102.GQ94016@zxy.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: Steven Hartland , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? 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, 11 Aug 2011 13:33:50 -0000 On 08/11/11 22:31, Slawa Olhovchenkov wrote: > On Thu, Aug 11, 2011 at 11:30:29AM +1000, Lawrence Stewart wrote: > >> On 08/05/11 16:57, Slawa Olhovchenkov wrote: >>> On Fri, Aug 05, 2011 at 12:02:18AM +1000, Lawrence Stewart wrote: >> [snip] >>>> >>>> The real fix which is somewhere down on my todo list is to make all >>>> these memory constraints elastic and respond to VM pressure, thus >>>> negating the need for a hard limit at all. This would solve many if not >>>> most of the TCP tuning problems we currently have with one foul swoop >>>> and would greatly reduce the need for tuning in many situations that >>>> currently are in the "needs manual tuning" basket. >>> >>> Autotunig w/o limits is bad idea. This is way to DoS. >> >> Depends how it is implemented. With appropriate backpressure mechanisms >> put in place, it could be perfectly safe. I envisage reassembly segments >> being at the bottom of the heap in terms of importance, so if a machine >> were to come under memory pressure, they would be the first thing to be >> reclaimed. TCP would continue to operate if they got pulled out from >> under the connection as the protocol doesn't consider segments held in >> reassembly to have been delivered, so would recover via retransmission. > > Yes, TCP would continue to operate. But attacker don't allow to put > system under memory pressure. Without a concrete patch to discuss, let's just agree to disagree for the time being. FreeBSD does a fairly good job autoscaling and reacting to pressure with the VM subsystem for example. I don't see why we can't become good at doing it with the netstack. Manual tuning sucks and can be just as dangerous if you tune things up to get performance, which opens you up to the same problems. >>> May be solved this trouble by preallocation "hidden" element in tqe >>> for segment received in valid order and ready for send to application? >>> T.e. when creating reassembled queue for tcp connection we allocation >>> queue element (with room for data payload), used only when data ready >>> for application. Allocation in queue for not breaking ABI (don't >>> change struct tcpcb). >> >> I'm not sure I quite follow what you're suggesting here, but I think >> Andre's proposed patch achieves the same goal and is arguably cleaner? > > Ande allocation on stack. My idea is different (sorry for bad english). > > 1. application open socket. > 2. kernel allocated internal tcp structure for this socket. > 2.1 additional step: kernel beforehand allocation one tseg_qent and > place it in t_segq. this queue entry will be used only when we receive > first good segment in right place. > > for example: > > [lost segment 100] (segment 101) (segment 102) ... (segment 100). > > segments 101, 102 and etc processed as usaly. > segment 100 placed in reserved and previously allocated queue entry. > > after receive segment 100 we can send data to application (to user > space). after send data queue entry from 2.1 not freed, this > permanently allocated entry. Ok I understand. Why is your proposal better than stack allocated though? I can think of a number of reasons why it's worse... Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 13:54:56 2011 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 ACE43106566C; Thu, 11 Aug 2011 13:54:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0DC9B8FC17; Thu, 11 Aug 2011 13:54:55 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1QrVio-000IOJ-6Q; Thu, 11 Aug 2011 17:54:54 +0400 Date: Thu, 11 Aug 2011 17:54:54 +0400 From: Slawa Olhovchenkov To: Lawrence Stewart Message-ID: <20110811135454.GR94016@zxy.spb.ru> References: <1F95A4C2D54E4F369830143CBDB5FF86@multiplay.co.uk> <4E37C0F2.4080004@freebsd.org> <2B063B6D95AA4C27B004C50D96393F91@multiplay.co.uk> <4E3AA66A.6060605@freebsd.org> <20110805065743.GC94016@zxy.spb.ru> <4E4330B5.5030100@freebsd.org> <20110811123102.GQ94016@zxy.spb.ru> <4E43DA31.7000605@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E43DA31.7000605@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Steven Hartland , Andre Oppermann , freebsd-net@freebsd.org Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? 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, 11 Aug 2011 13:54:56 -0000 On Thu, Aug 11, 2011 at 11:33:37PM +1000, Lawrence Stewart wrote: > >>> Autotunig w/o limits is bad idea. This is way to DoS. > >> > >> Depends how it is implemented. With appropriate backpressure mechanisms > >> put in place, it could be perfectly safe. I envisage reassembly segments > >> being at the bottom of the heap in terms of importance, so if a machine > >> were to come under memory pressure, they would be the first thing to be > >> reclaimed. TCP would continue to operate if they got pulled out from > >> under the connection as the protocol doesn't consider segments held in > >> reassembly to have been delivered, so would recover via retransmission. > > > > Yes, TCP would continue to operate. But attacker don't allow to put > > system under memory pressure. > > Without a concrete patch to discuss, let's just agree to disagree for > the time being. FreeBSD does a fairly good job autoscaling and reacting > to pressure with the VM subsystem for example. I don't see why we > can't Yes, and VM system allow to set different memory limits for proccess (and now for jails). > become good at doing it with the netstack. Manual tuning sucks and can > be just as dangerous if you tune things up to get performance, which > opens you up to the same problems. Autoscaling with limits is good. Automatic computation of limits (from available resources) also is good (currently limits frequently to small for modern installation, but don't remember about embeded systems). > >>> May be solved this trouble by preallocation "hidden" element in tqe > >>> for segment received in valid order and ready for send to application? > >>> T.e. when creating reassembled queue for tcp connection we allocation > >>> queue element (with room for data payload), used only when data ready > >>> for application. Allocation in queue for not breaking ABI (don't > >>> change struct tcpcb). > >> > >> I'm not sure I quite follow what you're suggesting here, but I think > >> Andre's proposed patch achieves the same goal and is arguably cleaner? > > > > Ande allocation on stack. My idea is different (sorry for bad english). > > > > 1. application open socket. > > 2. kernel allocated internal tcp structure for this socket. > > 2.1 additional step: kernel beforehand allocation one tseg_qent and > > place it in t_segq. this queue entry will be used only when we receive > > first good segment in right place. > > > > for example: > > > > [lost segment 100] (segment 101) (segment 102) ... (segment 100). > > > > segments 101, 102 and etc processed as usaly. > > segment 100 placed in reserved and previously allocated queue entry. > > > > after receive segment 100 we can send data to application (to user > > space). after send data queue entry from 2.1 not freed, this > > permanently allocated entry. > > Ok I understand. Why is your proposal better than stack allocated > though? I can think of a number of reasons why it's worse... I to be afraid stack allocation in this place (for list entry). Bugs in this code can cause kernel panic. From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 21:47:09 2011 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 7E7C4106564A; Thu, 11 Aug 2011 21:47:09 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 111228FC1B; Thu, 11 Aug 2011 21:47:08 +0000 (UTC) Received: by vws18 with SMTP id 18so2737456vws.13 for ; Thu, 11 Aug 2011 14:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/iJ0zcyTHjfZZOhIE21vpdsKqoM0PcOZMjZ5sEBi6N0=; b=UBpX5VUgCEB5V3ZYJj9Qa4xWJYimIxvNjHCNu3aF84Ra7fn6TSgu9AKJrqTVG2Fzh3 ZDcdJURo/wDRtcPrT6KRjnOlkpSaHeHNzHtLxCWckCKkwqCFG1zPF+qKdaq3sjuQv5zW iIzplxH9CzTpuTqGjypNTw9JOAtUCsfrgPB2k= MIME-Version: 1.0 Received: by 10.52.96.228 with SMTP id dv4mr146721vdb.144.1313099228209; Thu, 11 Aug 2011 14:47:08 -0700 (PDT) Received: by 10.220.186.134 with HTTP; Thu, 11 Aug 2011 14:47:08 -0700 (PDT) In-Reply-To: <20110811082531.GR43567@glebius.int.ru> References: <20110810160526.GO43567@FreeBSD.org> <20110811082531.GR43567@glebius.int.ru> Date: Thu, 11 Aug 2011 14:47:08 -0700 Message-ID: From: Freddie Cash To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: new CARP implementation 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, 11 Aug 2011 21:47:09 -0000 2011/8/11 Gleb Smirnoff > On Wed, Aug 10, 2011 at 09:38:04AM -0700, Freddie Cash wrote: > F> However, I'm not sure I understand the reasoning for removing the carpX > F> pseudo-interface. It's really nice having the symmetry between carpX, > F> vlanX, brX, and other pseudo-interfaces, and keeping the configuration > F> details separate from the underlying physical interface. > F> > F> This now makes creating/configuring CARP different from > creating/configuring > F> VLANs. :( > > This is done because VLANs _are_ interfaces, they are tunnels within > ethernet > interfaces, splitting one interface into a bunch. Bridges are interfaces, > as > well as LACP trunks (lagg(4)), since they group a number of interfaces into > one. CARP addresses _are not_ interfaces, they are addresses. IMHO, > implementing > them as virtual interface subtly attached to a real one, was a layering > violation. > > Thinking about it some more, and doing some reading on how VRRP and CARP work, I'm starting to see things from your point of view. Now you just need to figure out a way to make ifconfig(8) show which IPs on an interface are controlled via CARP. Perhaps add it to the carp: line as well? Or make the carp: a multi-line option? Or something along those lines? -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Aug 11 21:52:56 2011 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 AB8C01065673 for ; Thu, 11 Aug 2011 21:52:56 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 2D6508FC12 for ; Thu, 11 Aug 2011 21:52:55 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.4/8.14.4) with ESMTP id p7BLqsgK018847; Fri, 12 Aug 2011 01:52:54 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.4/8.14.4/Submit) id p7BLqsio018846; Fri, 12 Aug 2011 01:52:54 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 12 Aug 2011 01:52:54 +0400 From: Gleb Smirnoff To: Freddie Cash Message-ID: <20110811215254.GX43567@glebius.int.ru> References: <20110810160526.GO43567@FreeBSD.org> <20110811082531.GR43567@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: Re: new CARP implementation 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, 11 Aug 2011 21:52:56 -0000 On Thu, Aug 11, 2011 at 02:47:08PM -0700, Freddie Cash wrote: F> > On Wed, Aug 10, 2011 at 09:38:04AM -0700, Freddie Cash wrote: F> > F> However, I'm not sure I understand the reasoning for removing the carpX F> > F> pseudo-interface. It's really nice having the symmetry between carpX, F> > F> vlanX, brX, and other pseudo-interfaces, and keeping the configuration F> > F> details separate from the underlying physical interface. F> > F> F> > F> This now makes creating/configuring CARP different from F> > creating/configuring F> > F> VLANs. :( F> > F> > This is done because VLANs _are_ interfaces, they are tunnels within F> > ethernet F> > interfaces, splitting one interface into a bunch. Bridges are interfaces, F> > as F> > well as LACP trunks (lagg(4)), since they group a number of interfaces into F> > one. CARP addresses _are not_ interfaces, they are addresses. IMHO, F> > implementing F> > them as virtual interface subtly attached to a real one, was a layering F> > violation. F> > F> > Thinking about it some more, and doing some reading on how VRRP and CARP F> work, I'm starting to see things from your point of view. F> F> Now you just need to figure out a way to make ifconfig(8) show which IPs on F> an interface are controlled via CARP. Perhaps add it to the carp: line as F> well? Or make the carp: a multi-line option? Or something along those F> lines? The problem isn't with printf() layout unfortunately. The problem is that current interface between kernel and userland, that retrieves list of addresses on interface doesn't support passing vhid. Interface between libc and ifconfig neither. Problem is being worked on. I am now waiting for opinions from several developers. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 15:32:38 2011 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 2BE96106566C for ; Fri, 12 Aug 2011 15:32:38 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id DC4B58FC18 for ; Fri, 12 Aug 2011 15:32:37 +0000 (UTC) Received: by yib19 with SMTP id 19so2402011yib.13 for ; Fri, 12 Aug 2011 08:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LTl3+NGdj9ij3FBGwHmAjj3cY50q16v36srvlm2Kxds=; b=QGXrpsh5hAznodwMagChvsEm004CBJ8NNmyiVVTimnGnUrULYv8WsldKaZLH11M89p rYPxbqRK+86eJS4pK/XETHPH4mhGtjwV21Ic2+tENc9g+Pevfeng7GrF9p/iAeRmvHq4 H8tYd5c7Ld6oPEeF6ZLMvBH9BFN5RyA9G0kEQ= MIME-Version: 1.0 Received: by 10.142.174.21 with SMTP id w21mr248211wfe.162.1313163156650; Fri, 12 Aug 2011 08:32:36 -0700 (PDT) Received: by 10.68.60.101 with HTTP; Fri, 12 Aug 2011 08:32:36 -0700 (PDT) In-Reply-To: <20110811135454.GR94016@zxy.spb.ru> References: <1F95A4C2D54E4F369830143CBDB5FF86@multiplay.co.uk> <4E37C0F2.4080004@freebsd.org> <2B063B6D95AA4C27B004C50D96393F91@multiplay.co.uk> <4E3AA66A.6060605@freebsd.org> <20110805065743.GC94016@zxy.spb.ru> <4E4330B5.5030100@freebsd.org> <20110811123102.GQ94016@zxy.spb.ru> <4E43DA31.7000605@freebsd.org> <20110811135454.GR94016@zxy.spb.ru> Date: Fri, 12 Aug 2011 11:32:36 -0400 Message-ID: From: Arnaud Lacombe To: Slawa Olhovchenkov Content-Type: text/plain; charset=ISO-8859-1 Cc: Lawrence Stewart , Andre Oppermann , Steven Hartland , freebsd-net@freebsd.org Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? 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, 12 Aug 2011 15:32:38 -0000 Hi, On Thu, Aug 11, 2011 at 9:54 AM, Slawa Olhovchenkov wrote: > On Thu, Aug 11, 2011 at 11:33:37PM +1000, Lawrence Stewart wrote: > >> >>> Autotunig w/o limits is bad idea. This is way to DoS. >> >> >> >> Depends how it is implemented. With appropriate backpressure mechanisms >> >> put in place, it could be perfectly safe. I envisage reassembly segments >> >> being at the bottom of the heap in terms of importance, so if a machine >> >> were to come under memory pressure, they would be the first thing to be >> >> reclaimed. TCP would continue to operate if they got pulled out from >> >> under the connection as the protocol doesn't consider segments held in >> >> reassembly to have been delivered, so would recover via retransmission. >> > >> > Yes, TCP would continue to operate. But attacker don't allow to put >> > system under memory pressure. >> >> Without a concrete patch to discuss, let's just agree to disagree for >> the time being. FreeBSD does a fairly good job autoscaling and reacting >> to pressure with the VM subsystem for example. I don't see why we >> can't > > Yes, and VM system allow to set different memory limits for proccess (and now for jails). > >> become good at doing it with the netstack. Manual tuning sucks and can >> be just as dangerous if you tune things up to get performance, which >> opens you up to the same problems. > > Autoscaling with limits is good. > Automatic computation of limits (from available resources) also is > good (currently limits frequently to small for modern installation, > but don't remember about embeded systems). > All the useless limitation BSD puts all over the place wrt. memory management is a huge pain to deal with. nmbcluster, zone limitation and friend are just useless. Just try to use NetGraph with a consequent number of nodes and a high enough pps and the stuff with will start dropping packet all over the place, even if the box has Gigs of free memory. - Arnaud From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 17:39:02 2011 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 BA1231065670 for ; Fri, 12 Aug 2011 17:39:02 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (mail.ciam.ru [91.209.218.18]) by mx1.freebsd.org (Postfix) with ESMTP id 75CA88FC23 for ; Fri, 12 Aug 2011 17:39:02 +0000 (UTC) Received: from dhcp170-19-red.yandex.net ([95.108.170.19] helo=dhcp170-205-red.yandex.net) by mail.ciam.ru with esmtpa (Exim 4.x) id 1Qrv0v-000Gaj-B4 for net@FreeBSD.org; Fri, 12 Aug 2011 20:55:17 +0400 Message-ID: <4E455AF5.9040600@FreeBSD.org> Date: Fri, 12 Aug 2011 20:55:17 +0400 From: Sergey Matveychuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: net@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: panic: m_uiotombuf: progress != total 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, 12 Aug 2011 17:39:02 -0000 Hi. Just after upgrade from 8.2 to 9.0 kernel panics: panic: m_uiotombuf: progress != total cpuid = 1 KDB: enter: panic [ thread pid 1194 tid 100132 ] Stopped at kdb_enter+0x3b: movq $0,0x913242(%rip) db> bt Tracing pid 1194 tid 100132 td 0xfffffe0005c8f8c0 kdb_enter() at kdb_enter+0x3b panic() at panic+0x180 m_uiotombuf() at m_uiotombuf+0x142 sosend_generic() at sosend_generic+0x2c8 kern_sendit() at kern_sendit+0x191 sendit() at sendit+0xdc sendmsg() at sendmsg+0x87 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xdd --- syscall (28, FreeBSD ELF64, sendmsg), rip = 0x8019ad33c, rsp = 0x7fffffffd8f8, rbp = 0x7fffffffd930 --- From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 21:43:11 2011 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 99BA7106564A for ; Fri, 12 Aug 2011 21:43:11 +0000 (UTC) (envelope-from chip@2bithacker.net) Received: from mail.2bithacker.net (unknown [IPv6:2001:470:1f07:202::123]) by mx1.freebsd.org (Postfix) with ESMTP id 7020A8FC1A for ; Fri, 12 Aug 2011 21:43:11 +0000 (UTC) Received: from 2bithacker.net (nat-01-mht.dyndns.com [216.146.45.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: chip) by mail.2bithacker.net (Postfix) with ESMTPSA id CFACAF01870 for ; Fri, 12 Aug 2011 17:43:10 -0400 (EDT) Date: Fri, 12 Aug 2011 17:43:09 -0400 From: Chip Marshall To: freebsd-net@freebsd.org Message-ID: <20110812214309.GI72508@2bithacker.net> Mail-Followup-To: chip@2bithacker.net, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jQIvE3yXcK9X9HBh" Content-Disposition: inline X-OS: Mac OS X 10.6.8 i386 up 7 days User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Odd TCP RFC1323 Behavior X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chip@2bithacker.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 21:43:11 -0000 --jQIvE3yXcK9X9HBh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've been digging into an issue with SSH throughput and discovered that one of the servers involved isn't using RFC1323 window scaling and timestamps. The server is running 7.3-RELEASE-p3, and has net.inet.tcp.rfc1323 set to 1. When connecting out from the server, it sets both Window Scale and TimeStamp options in the SYN packet and everything is fine. When a connection comes into the server with WS and TS set in the SYN, the response varies. For port 53 (named) the SYN/ACK has WS/TS options. For port 22 (sshd) the SYN/ACK does not have WS/TS options, unless the connection is via lo0. ssh is OpenSSH_5.2p1, compiled from ports with default options. I'm really at a loss to explain this. Why does named use RFC1323 on bce0 when sshd doesn't? Why does sshd use RFC1323 on lo0 but not on bce0? I can provide PCAPs of the SYN, SYN/ACK exchanges if that will help. --=20 Chip Marshall http://weblog.2bithacker.net/ KB1QYW PGP key ID 43C4819E v4sw5PUhw4/5ln5pr5FOPck4ma4u6FLOw5Xm5l5Ui2e4t4/5ARWb7HKOen6a2Xs5IMr2g6CM --jQIvE3yXcK9X9HBh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk5Fnm0ACgkQnTUxIUPEgZ73qgCdF1xpXXVOzs6UjSe09mKsba/y 5yQAoLmj2cyE5/DrMIDz85pg7tqjWx2I =yC3U -----END PGP SIGNATURE----- --jQIvE3yXcK9X9HBh-- From owner-freebsd-net@FreeBSD.ORG Fri Aug 12 23:36:48 2011 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 86ABE106566B for ; Fri, 12 Aug 2011 23:36:48 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4A9768FC14 for ; Fri, 12 Aug 2011 23:36:48 +0000 (UTC) Received: by gwb15 with SMTP id 15so1325605gwb.13 for ; Fri, 12 Aug 2011 16:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=NX9sgeLK7h1ZTWDYzX7nuUweQaFW30Las9ZihgGyOqM=; b=DqTKKXuY5uz52XJB2KDpTF7Vdryn0XKzllF3lus8xVp/xneuI9GBPlZQO94Rp9RCUh 0mG2EQqIoYtOh3wBSRVu+v2B+vB7V+atH2L+J4rf7qI/ImQBV7y+w4kD/VUO+iLTOkfF pi4P4jQgZT0AbTpgVM4XjeqKnRHZdFxdRoCxM= MIME-Version: 1.0 Received: by 10.151.48.1 with SMTP id a1mr580362ybk.411.1313192207479; Fri, 12 Aug 2011 16:36:47 -0700 (PDT) Received: by 10.150.97.3 with HTTP; Fri, 12 Aug 2011 16:36:47 -0700 (PDT) In-Reply-To: <20110812214309.GI72508@2bithacker.net> References: <20110812214309.GI72508@2bithacker.net> Date: Fri, 12 Aug 2011 16:36:47 -0700 Message-ID: From: Kevin Oberman To: chip@2bithacker.net, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Odd TCP RFC1323 Behavior 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, 12 Aug 2011 23:36:48 -0000 On Fri, Aug 12, 2011 at 2:43 PM, Chip Marshall wrote: > I've been digging into an issue with SSH throughput and > discovered that one of the servers involved isn't using RFC1323 > window scaling and timestamps. > > The server is running 7.3-RELEASE-p3, and has > net.inet.tcp.rfc1323 set to 1. > > When connecting out from the server, it sets both Window Scale > and TimeStamp options in the SYN packet and everything is fine. > > When a connection comes into the server with WS and TS set in > the SYN, the response varies. For port 53 (named) the SYN/ACK > has WS/TS options. For port 22 (sshd) the SYN/ACK does not have > WS/TS options, unless the connection is via lo0. > > ssh is OpenSSH_5.2p1, compiled from ports with default options. > > I'm really at a loss to explain this. > > Why does named use RFC1323 on bce0 when sshd doesn't? > Why does sshd use RFC1323 on lo0 but not on bce0? > > I can provide PCAPs of the SYN, SYN/ACK exchanges if that > will help. Try installing security/openssh-portable from ports and enable the HPN patches. As it stands today, openssh locks the window size to a tiny value. This causes performance over wide area links to be simply terrible. Take a look at http://fasterdata.es.net/fasterdata/say-no-to-scp/ for more information on the issue. As you will see there, window scaling is the least of the performance issues with openssh. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Sat Aug 13 06:30:08 2011 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 6D8EC1065673; Sat, 13 Aug 2011 06:30:08 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from lavash.monkeybrains.net (mail.monkeybrains.net [208.69.40.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4B0B08FC08; Sat, 13 Aug 2011 06:30:08 +0000 (UTC) Received: from Computer-of-Penelope.local (adsl-75-30-231-66.dsl.pltn13.sbcglobal.net [75.30.231.66]) (authenticated bits=0) by lavash.monkeybrains.net (8.14.4/8.14.4) with ESMTP id p7D6670E054774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Aug 2011 23:06:07 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=monkeybrains.net; s=monkey; t=1313215568; bh=3k9rsCg06rZbnhnYg1kHWZHgVadRluZIRk2/NjFVQ5c=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PI3hD9vf8GTRBRoXc0z4kjRIHpDAZzgL/1GLPxblghGRpONIEiJ7dT6CTMFLquwft eDQBlVtFUalbr/gMkmn70/thfuar7QrMBe+WgmDVvy5KZovjOTsNNZ6GBwLNyFMVZJ /8tq4A+GvStV/xm3iigSQT148uNwDsffF1n/y8Xw= Message-ID: <4E4613DE.1030704@monkeybrains.net> Date: Fri, 12 Aug 2011 23:04:14 -0700 From: "Rudy (bulk)" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Gleb Smirnoff References: <20110810160526.GO43567@FreeBSD.org> In-Reply-To: <20110810160526.GO43567@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.96.5 at lavash.monkeybrains.net X-Virus-Status: Clean Cc: net@freebsd.org Subject: Re: new CARP implementation 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, 13 Aug 2011 06:30:08 -0000 Gleb Smirnoff wrote: > Hello networkers, > > I'd like to present for review and early testing (for brave ones) > a new CARP implementation. Super! I'll use it but am not brave enough for alpha. Maybe beta. :) Will this support multiple VHID per interface? Rudy From owner-freebsd-net@FreeBSD.ORG Sat Aug 13 10:28:18 2011 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 D0978106564A for ; Sat, 13 Aug 2011 10:28:18 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC528FC12 for ; Sat, 13 Aug 2011 10:28:18 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 4CA4425D388C; Sat, 13 Aug 2011 10:28:17 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 44571BD3C84; Sat, 13 Aug 2011 10:28:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id E5ac3fjtKbuC; Sat, 13 Aug 2011 10:28:14 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 186C0BD3C1C; Sat, 13 Aug 2011 10:28:14 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Sat, 13 Aug 2011 10:28:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0C8F244C-CB37-4039-97D2-42C08B3BEA76@lists.zabbadoz.net> References: <20110812214309.GI72508@2bithacker.net> To: Kevin Oberman X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, chip@2bithacker.net Subject: Re: Odd TCP RFC1323 Behavior 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, 13 Aug 2011 10:28:19 -0000 On Aug 12, 2011, at 11:36 PM, Kevin Oberman wrote: > On Fri, Aug 12, 2011 at 2:43 PM, Chip Marshall = wrote: >> I've been digging into an issue with SSH throughput and >> discovered that one of the servers involved isn't using RFC1323 >> window scaling and timestamps. >>=20 >> The server is running 7.3-RELEASE-p3, and has >> net.inet.tcp.rfc1323 set to 1. >>=20 >> When connecting out from the server, it sets both Window Scale >> and TimeStamp options in the SYN packet and everything is fine. >>=20 >> When a connection comes into the server with WS and TS set in >> the SYN, the response varies. For port 53 (named) the SYN/ACK >> has WS/TS options. For port 22 (sshd) the SYN/ACK does not have >> WS/TS options, unless the connection is via lo0. >>=20 >> ssh is OpenSSH_5.2p1, compiled from ports with default options. >>=20 >> I'm really at a loss to explain this. >>=20 >> Why does named use RFC1323 on bce0 when sshd doesn't? >> Why does sshd use RFC1323 on lo0 but not on bce0? >>=20 >> I can provide PCAPs of the SYN, SYN/ACK exchanges if that >> will help. >=20 > Try installing security/openssh-portable from ports and enable the HPN = patches. and let me point out that the relevant patch is in stock HEAD and will = ship by default with 9.0. >=20 > As it stands today, openssh locks the window size to a tiny value. > This causes performance over wide area links to be simply terrible. >=20 > Take a look at http://fasterdata.es.net/fasterdata/say-no-to-scp/ for > more information on the issue. As you will see there, window scaling > is the least of the performance issues with openssh. > --=20 > R. Kevin Oberman, Network Engineer - Retired > E-mail: kob6558@gmail.com > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Sat Aug 13 21:37:04 2011 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 11ACE106566B for ; Sat, 13 Aug 2011 21:37:04 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id C70148FC15 for ; Sat, 13 Aug 2011 21:37:03 +0000 (UTC) Received: by yxl31 with SMTP id 31so3091702yxl.13 for ; Sat, 13 Aug 2011 14:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6IUWork6LmTvObmUKtxEGSIVAXFHThc73sR9F33or+0=; b=bjf7wSILiV3N0keyXWy+EhS5zbv3HyXQktjA9NwnsS9br4s+wyCRqzscg3cNEa9gM6 oc4GaxcMqhFbrLPEke0WiePtJDEhbp9cK4WVWTyFjGMSu4khG26by4R3RhyzQ4zO609O yk6Idufclgoj+JOgRInzyhFLsHAXf5HryPYTE= MIME-Version: 1.0 Received: by 10.151.48.1 with SMTP id a1mr1532226ybk.411.1313271423079; Sat, 13 Aug 2011 14:37:03 -0700 (PDT) Received: by 10.150.97.3 with HTTP; Sat, 13 Aug 2011 14:37:03 -0700 (PDT) In-Reply-To: <0C8F244C-CB37-4039-97D2-42C08B3BEA76@lists.zabbadoz.net> References: <20110812214309.GI72508@2bithacker.net> <0C8F244C-CB37-4039-97D2-42C08B3BEA76@lists.zabbadoz.net> Date: Sat, 13 Aug 2011 14:37:03 -0700 Message-ID: From: Kevin Oberman To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, chip@2bithacker.net Subject: Re: Odd TCP RFC1323 Behavior 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, 13 Aug 2011 21:37:04 -0000 On Sat, Aug 13, 2011 at 3:28 AM, Bjoern A. Zeeb wrote: > > On Aug 12, 2011, at 11:36 PM, Kevin Oberman wrote: > >> >> Try installing security/openssh-portable from ports and enable the HPN patches. > > and let me point out that the relevant patch is in stock HEAD and will ship by default with 9.0. And let me thank whoever made this change. (DES?) I've been hoping to see this happen since at least version 6 and probably before. I wish it could be incorporated by OpenSSH, but I have been told that the PSC folks were perhaps a bit, ahh, indelicate in their approach to getting the patches included. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Sat Aug 13 22:10:04 2011 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 3261E106566C for ; Sat, 13 Aug 2011 22:10:04 +0000 (UTC) (envelope-from michael@rancid.berkeley.edu) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by mx1.freebsd.org (Postfix) with ESMTP id 134358FC0C for ; Sat, 13 Aug 2011 22:10:03 +0000 (UTC) Received: from c-69-181-185-223.hsd1.ca.comcast.net ([69.181.185.223] helo=towanda.burnttofu.net) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:msinatra@berkeley.edu) (envelope-from ) id 1QsMAQ-0002xt-5L; Sat, 13 Aug 2011 14:54:55 -0700 Message-ID: <4E46F2AA.2030304@rancid.berkeley.edu> Date: Sat, 13 Aug 2011 14:54:50 -0700 From: Michael Sinatra User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Kevin Oberman References: <20110812214309.GI72508@2bithacker.net> <0C8F244C-CB37-4039-97D2-42C08B3BEA76@lists.zabbadoz.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , chip@2bithacker.net, freebsd-net@freebsd.org Subject: Re: Odd TCP RFC1323 Behavior 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, 13 Aug 2011 22:10:04 -0000 On 08/13/11 14:37, Kevin Oberman wrote: > On Sat, Aug 13, 2011 at 3:28 AM, Bjoern A. Zeeb > wrote: >> >> On Aug 12, 2011, at 11:36 PM, Kevin Oberman wrote: >> >>> >>> Try installing security/openssh-portable from ports and enable the HPN patches. >> >> and let me point out that the relevant patch is in stock HEAD and will ship by default with 9.0. > > And let me thank whoever made this change. (DES?) I've been hoping to > see this happen since at least version 6 and probably before. > > I wish it could be incorporated by OpenSSH, but I have been told that > the PSC folks were perhaps a bit, ahh, indelicate in their approach to > getting the patches included. I agree this is great news. Based on CVS, it looks like brooks made the changes. Having the bundled SSH patched with HPN-type functionality is a big win for those who want to use a simple tool for large-scale data transfers over high-bandwidth links. michael