From owner-freebsd-net@FreeBSD.ORG Sun Mar 25 06:56:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2BFD1065670 for ; Sun, 25 Mar 2012 06:56:44 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 36BC88FC14 for ; Sun, 25 Mar 2012 06:56:43 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so5081599pbc.13 for ; Sat, 24 Mar 2012 23:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=yoStmQWYUSaTQXirE6zH78opgFWC5IQ+AgVxJXpVbMI=; b=HCM9SbtlWzTnfeh6r6ehEkPL030jP4MMHgIPDsoFLUM3lzFL8Dv+XwgYUvqGxtzAXq uGC+xaq3WnRJLVqwwBQ/v8HBM15Y5vmalSwruZosqVcYKpU4qD9quszNK/h5GuLez7s4 ZHdRB799TGZiMdR7CIC0ICqy15UysZ+KK2AWIc7tLC2epxRM17DZ6TclqmqA48NIY+kI 3FRzyx4PprWI8kO4qQw05PlZipUSVgU96SpKSXB0voxKMk8/PwJ5sAdPiszSmKNDn8Ov Aip4tP1sIbTF+LhuwLnc9tvq7iLbvEqJVShUKCqFac4nYobJlJs8G+OnCUppORTMqs5z HR1Q== Received: by 10.68.72.70 with SMTP id b6mr43616856pbv.58.1332658603606; Sat, 24 Mar 2012 23:56:43 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id i8sm9631591pbf.72.2012.03.24.23.56.40 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Mar 2012 23:56:42 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 25 Mar 2012 15:56:40 -0700 From: YongHyeon PYUN Date: Sun, 25 Mar 2012 15:56:40 -0700 To: Joe Holden Message-ID: <20120325225640.GA4493@michelle.cdnetworks.com> References: <4F64AB3B.9030806@rewt.org.uk> <20120319214744.GC7518@michelle.cdnetworks.com> <4F6B061F.9050403@rewt.org.uk> <4F6B7892.6090805@rewt.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F6B7892.6090805@rewt.org.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: msk/Yukon issues since 9.0-REL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 06:56:44 -0000 On Thu, Mar 22, 2012 at 07:08:02PM +0000, Joe Holden wrote: > Joe Holden wrote: > >YongHyeon PYUN wrote: > >>On Sat, Mar 17, 2012 at 03:18:19PM +0000, Joe Holden wrote: > >>>Hi guys, > >>> > >>>I've upgraded to 9.0-REL from RC3 (I think) and the previous > >>>workarounds I've used for msk/Yukon II problems don't seem to work > >>>anymore: > >>> > >>>rc.conf: > >>>ifconfig_msk0="inet 192.168.201.2/30 -lro -tso -vlanhwfilter -vlanhwtag" > >>> > >> > >>msk(4) does not support VLAN hardware filter and LRO. However I > >>don't understand how this affects stability of driver. > >> > >>>pciconf: > >>>mskc0@pci0:7:0:0: class=0x020000 card=0x81e6104d > >>>chip=0x435111ab rev=0x15 hdr=0x00 > >>> vendor = 'Marvell Technology Group Ltd.' > >>> device = '88E8036 PCI-E Fast Ethernet Controller' > >>> class = network > >>> subclass = ethernet > >>> > >>>I seem to get the usual error: > >>>msk0: watchdog timeout > >>>msk0: prefetch unit stuck? > >>>msk0: initialization failed: no memory for Rx buffers > >>> > >> > >>There was a related change after 9.0-RELEASE. The change already > >>merged to stable/9(r229874) So would you try latest stable/9 or > >>apply the change to 9.0-RELEASE? > >>http://svnweb.freebsd.org/base/stable/9/sys/dev/msk/if_msk.c?r1=229524&r2=229874&view=patch > >> > >> > >Well that's cute.... reboot during boot, no panic or errors on the > >console ... > > > >>>MSI(-X) is disabled but it doesn't seem to make any difference.... > >>> > >>>Is there anything I can try to either debug or "fix" it? > >>> > >> > >>If you've upgraded from somewhat old FreeBSD releases, make sure to > >>cold boot your box(i.e. completely remove power cord for several > >>minutes before booting). > >> > >>>Thanks, > >>>J > Ok so after removing sound from GENERIC it boots but the problem still Not sure how audio devices can affect msk(4). > occurs - the flags I used before did work (whether some didn't have any msk(4) had a long standing bug for some Yukon controllers that use 88E1149 PHY. The bug showed various problems depending on PHY configuration. See r222219 for more details. Due to unknown reason GPHY configuration is preserved until it's cold-booted. > effect I don't know, but once I found a combination that prevented the > problem I left it at that) > > Rather a concerning amount of regressions in 9... > > Thanks, > J > > From owner-freebsd-net@FreeBSD.ORG Sun Mar 25 08:30:26 2012 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 48D2F106566B for ; Sun, 25 Mar 2012 08:30:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 11FE18FC1A for ; Sun, 25 Mar 2012 08:30:25 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so5168357pbc.13 for ; Sun, 25 Mar 2012 01:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=/+xVaV7k8K5BTG7Pxuv0QxbBi+8cppaMI+Z4Nd9spc0=; b=WkZKcUNbgTHVAAsJnu6TsUq0oIWexRZhYD+1gX/stqvmLlx5/BpzOgJBU7dFq8ilym 6QPggfqkeIUmHe1yDiKoioF4eZ+bc9pvGxYHespF8oxeK/2OJNwcqPZiSme2KEKgcZin 0RHicLToBmkbtvBhkVZsca0fMJkuOCaWnAHIy0VZVUVualxwWiSToPZKAESrlf5x5uJ4 ZwjNFUkgYf9u7HLNyi7ZW9KenHBn/5W5ckhKcQstAhnb94if9N8TZ9YjSeWNzD2zTrbZ KvIGcrME9gZ31OIDZz89kRWli4ddq/Yai8thhQh/zpi9yUp6hHvu/OF57UX0vCV7Dz7I 7Msg== Received: by 10.68.197.194 with SMTP id iw2mr43442807pbc.26.1332664225692; Sun, 25 Mar 2012 01:30:25 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id e7sm9791951pbs.21.2012.03.25.01.30.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Mar 2012 01:30:24 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 25 Mar 2012 17:30:16 -0700 From: YongHyeon PYUN Date: Sun, 25 Mar 2012 17:30:16 -0700 To: Andreas Longwitz Message-ID: <20120326003016.GA1435@michelle.cdnetworks.com> References: <4F594856.3030303@incore.de> <20120312211907.GC3671@michelle.cdnetworks.com> <4F5E0AF7.30302@incore.de> <20120313202559.GA3360@michelle.cdnetworks.com> <4F66646E.4080603@incore.de> <20120320041647.GE7518@michelle.cdnetworks.com> <4F6DA161.9040408@incore.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline In-Reply-To: <4F6DA161.9040408@incore.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Intel 82550 Pro/100 Ethernet and Microcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 08:30:26 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Mar 24, 2012 at 11:26:41AM +0100, Andreas Longwitz wrote: > YongHyeon PYUN wrote: > > > I didn't ever try NFS on i82550C. If it can't handle fragmented IP > > datagrams, it would also have failed netperf UDP stream test since > > all UDP datagrams are fragmented. > > Yes, you are right. The test needs to run more than 10 seconds to see > lost packets. Running > netperf -H host_with_fxp -t UDP_STREAM -l 30000 > gives without loading microcode on the fxp independent of polling: > > Socket Message Elapsed Messages > Size Size Time Okay Errors Throughput > bytes bytes secs # # 10^6bits/sec > > 9216 9216 30001.38 38972627 194368988 95.77 > 41600 30001.38 34293209 84.28 > > With microcode loaded no packets are lost. > Ok. > >> The test command > >> netperf -H host_with_fxp -t UDP_STREAM > >> gives nearly always the same output > >> > >> Socket Message Elapsed Messages > >> Size Size Time Okay Errors Throughput > >> bytes bytes secs # # 10^6bits/sec > >> > >> 9216 9216 10.00 13069 1515880 96.34 > >> 41600 10.00 13069 96.34 > >> > >> And this output did not considerably change for the test cases fxp-type > >> i82550C or i82550, microcode loaded or not and polling yes or no. > >> > >> But I can answer your question concerning the CPU Saver funktion on > >> i82550C and its a little suprise (for me). In all my tests without > >> polling I checked the irq's on host_with_fxp using "vmstat -i". The > >> result is that the CPU Saver feature of the microcode does not work on > >> i82250C and it works on i82250. On i82250C the value of > >> dev.fxp.0.bundle_max is irrelevant, the i82250C always needs ca. 91000 > >> irq's for the netperf test. The same number of irq's needs the i82250 > >> with bundle_max=1, but when I set bundle_max=6 (the default), then the > >> number of irq's for the same test goes down to 91000/7 = 13000. > > > > Thanks for the detailed information. This indicates the microcode > > for i82550C does not have bundling feature. > > Yes, but the microcode solves the stability problem for UDP streams, and > to load the microcode without side effects I need my "bzero-patch". > It seems there are differences between yours and mine. I disabled microcode loading for 82550 family since my 82550C didn't work after loading the code(Microcode loading works but it locked up after that). However it seems the microcode still has some valid usage for certain 82550 configuration. :-( > > By chance, did you > > ever update your controller firmware to newest one? I don't > > remember whether I also updated controller firmware for i82550C but > > I used to update several i82559 controllers for PXE. > > Thank you for this hint, I didn't know that the firmware in the > cantroller can be updated. All of my i82550C (= rev 0x0d) sit on a > (intel) motherboard of type SCB2S, all of my i82550 (= rev 0x0c) are > external cards. The following information I got with a DOS-Tool called > IBABUILD.exe. This tool supports the Intel boot Agent on the controller. > On the external cards this tool can update the Intel boot Agent software > and I found versions 3.0.03, 4.0.19 and the newest is 4.2.0.3. If I remember correctly there is another tool that updates EEPROM which may affect controller operation mode. Unfortunately I don't remember details at the moment.(I don't heavily use fxp(4) controllers because it has lots of limitation and it's too tricky to work it without racing between hardware and driver. I just keep it to support fxp(4) for other users.) > But there never was any dependency between the version of the Intel boot > Agent software and microcode. For chips on the motherboard (LOM) the > tool does not show a version, but booting a server with PXE gives 4.0.17 > for the version of the Intel boot Agent software. It looks like this > software is only responsible for PXE and nothing else. > I've attached a patch which will show both compatibility and EEPROM ID word and allowed loading microcode for 82550 family. Let me know whether this patch works for you. I vaguely guess there are differences between LOM and non-LOM implementation(Mine is stand-alone PCI NIC). I would be able to selectively allow microcode loading after getting compatibility/EEPROM ID word. > > Regards > > Andreas Longwitz > --pf9I7BMVVzbSWLtt Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="fxp.82550.microcode.diff" Index: sys/dev/fxp/if_fxp.c =================================================================== --- sys/dev/fxp/if_fxp.c (revision 233418) +++ sys/dev/fxp/if_fxp.c (working copy) @@ -194,7 +194,7 @@ { 0x1229, 0x08, 0, "Intel 82559 Pro/100 Ethernet" }, { 0x1229, 0x09, 0, "Intel 82559ER Pro/100 Ethernet" }, { 0x1229, 0x0c, 0, "Intel 82550 Pro/100 Ethernet" }, - { 0x1229, 0x0d, 0, "Intel 82550 Pro/100 Ethernet" }, + { 0x1229, 0x0d, 0, "Intel 82550C Pro/100 Ethernet" }, { 0x1229, 0x0e, 0, "Intel 82550 Pro/100 Ethernet" }, { 0x1229, 0x0f, 0, "Intel 82551 Pro/100 Ethernet" }, { 0x1229, 0x10, 0, "Intel 82551 Pro/100 Ethernet" }, @@ -525,6 +525,13 @@ sc->flags |= FXP_FLAG_WOLCAP; } + if (sc->revision == FXP_REV_82550 || sc->revision == FXP_REV_82550_C) { + fxp_read_eeprom(sc, &data, 3, 1); + device_printf(dev, "Compatibility word : 0X%04x\n", data); + fxp_read_eeprom(sc, &data, 10, 1); + device_printf(dev, "EEPROM ID word : 0X%04x\n", data); + } + /* Receiver lock-up workaround detection. */ if (sc->revision < FXP_REV_82558_A4) { fxp_read_eeprom(sc, &data, 3, 1); @@ -3014,10 +3021,8 @@ static uint32_t fxp_ucode_d101b0[] = D101_B0_RCVBUNDLE_UCODE; static uint32_t fxp_ucode_d101ma[] = D101M_B_RCVBUNDLE_UCODE; static uint32_t fxp_ucode_d101s[] = D101S_RCVBUNDLE_UCODE; -#ifdef notyet static uint32_t fxp_ucode_d102[] = D102_B_RCVBUNDLE_UCODE; static uint32_t fxp_ucode_d102c[] = D102_C_RCVBUNDLE_UCODE; -#endif static uint32_t fxp_ucode_d102e[] = D102_E_RCVBUNDLE_UCODE; #define UCODE(x) x, sizeof(x)/sizeof(uint32_t) @@ -3035,12 +3040,10 @@ D101M_CPUSAVER_DWORD, D101M_CPUSAVER_BUNDLE_MAX_DWORD }, { FXP_REV_82559S_A, UCODE(fxp_ucode_d101s), D101S_CPUSAVER_DWORD, D101S_CPUSAVER_BUNDLE_MAX_DWORD }, -#ifdef notyet { FXP_REV_82550, UCODE(fxp_ucode_d102), D102_B_CPUSAVER_DWORD, D102_B_CPUSAVER_BUNDLE_MAX_DWORD }, { FXP_REV_82550_C, UCODE(fxp_ucode_d102c), D102_C_CPUSAVER_DWORD, D102_C_CPUSAVER_BUNDLE_MAX_DWORD }, -#endif { FXP_REV_82551_F, UCODE(fxp_ucode_d102e), D102_E_CPUSAVER_DWORD, D102_E_CPUSAVER_BUNDLE_MAX_DWORD }, { FXP_REV_82551_10, UCODE(fxp_ucode_d102e), @@ -3087,6 +3090,7 @@ sc->tunable_int_delay, uc->bundle_max_offset == 0 ? 0 : sc->tunable_bundle_max); sc->flags |= FXP_FLAG_UCODE; + bzero(cbp, FXP_TXCB_SZ); } #define FXP_SYSCTL_STAT_ADD(c, h, n, p, d) \ --pf9I7BMVVzbSWLtt-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 05:57:23 2012 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 8FA94106564A; Mon, 26 Mar 2012 05:57:23 +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 637B78FC14; Mon, 26 Mar 2012 05:57:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2Q5vNba099977; Mon, 26 Mar 2012 05:57:23 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2Q5vNwd099973; Mon, 26 Mar 2012 05:57:23 GMT (envelope-from linimon) Date: Mon, 26 Mar 2012 05:57:23 GMT Message-Id: <201203260557.q2Q5vNwd099973@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166285: [arp] FreeBSD v8.1 REL p8 arp: unknown hardware address format (0x0fff) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2012 05:57:23 -0000 Old Synopsis: FreeBSD v8.1 REL p8 arp: unknown hardware address format (0x0fff) New Synopsis: [arp] FreeBSD v8.1 REL p8 arp: unknown hardware address format (0x0fff) Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 26 05:56:42 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166285 From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 11:02:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 1F7FF106566C; Mon, 26 Mar 2012 11:02:53 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from dhcp170-36-red.yandex.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with ESMTP id 66A7E150CD8; Mon, 26 Mar 2012 11:02:51 +0000 (UTC) Message-ID: <4F704C1B.5080709@FreeBSD.org> Date: Mon, 26 Mar 2012 14:59:39 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111117 Thunderbird/8.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------060905060202080703000205" Cc: Gleb Smirnoff Subject: [PATCH] BPF locking redesign X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2012 11:02:53 -0000 This is a multi-part message in MIME format. --------------060905060202080703000205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello list! There are some patches that can significantly improve forwarding performance if BPF consumers are present. However, some changes are a bit hackish and ABI change is required. Those are split into separate patches I want to discuss. You probably need to merge r233505 for patches to work. Description: bpf_rwlock This is simple and straight-forwarded, we convert interface and descriptor locks to rwlock(9). Additionally, filter(descriptor) (reader) lock in bpf_mtap[2] is removed. This was suggested by glebius@. We protect filter by requesting interface writer lock on filter change. This greately improves performance: in most common case we need to acquire 1 reader lock instead of 2 mutexes. bpf_if structure is now covered by BPF_INTERNAL define. This permits including bpf.h without including rwlock stuff. However, this is is temporary solution, struct bpf_if should be made opaque for any external caller. Description: bpf_writers Linux and Solaris (at least OpenSolaris) has PF_PACKET socket families to send raw ethernet frames. The only FreeBSD interface that can be used to send raw frames is BPF. As a result, many programs like cdpd, lldpd, various dhcp stuff uses BPF only to send data. This leads us to the situation when software like cdpd, being run on high-traffic-volume interface significantly reduces overall performance since we have to acquire additional locks for every packet. Here we add sysctl that changes BPF behavior in the following way: If program came and opens BPF socket without explicitly specifyin read filter we assume it to be write-only and add it to special writer-only per-interface list. This makes bpf_peers_present() return 0, so no additional overhead is introduced. After filter is supplied, descriptor is added to original per-interface list permitting packets to be captured. Unfortunately, pcap_open_live() sets catch-all filter itself for the purpose of setting snap length. Fortunately, most programs explicitly sets (event catch-all) filter after that. tcpdump(1) is a good example. So a bit hackis approach is taken: we upgrade description only after second BIOCSETF is received. Sysctl is named net.bpf.optimize_writers and is turned off by default. Description: bpf_if_opaque. No patch at the moment. We can probably do the following: Create bpf_if structure on bpfattach2, but do not assign it to supplied pointer. Instead we put new structure, pointer, interface pointer to some kind of hash (with interface name as key). When _reader_ comes AND sets valid filter, we checks if we need to attach bpfif to interface. When reader disconnects, we set bpfif pointer back to zero. No additional locking is required here: same struct bpfif lives as long as interface exists, so pointer will be either NULL or pointer to structure in and period of time. Even if some thread on other CPU sees non-coherent value - no problem. NULL means no filter is set so we skips BPF, non-null starts BPF_MTAP which acquires rlock and determines that no peers are present. As a result, bpf_peers_present(x) simply returns (x). There is no need to expose struct bpfif to external users. Additionally, we do not request interface write lock to be acquired on every interface attach/departure which can potentially lead to small number of packets being dropped on mpd servers. Btw, we can consider changing rlock / wlock to _try_ one to avoid this behavior. Major drawback of this approach is totally broken ABI. Any pre-compiled network driver carries inlined bpf_peers_present() which assumes ifp->if_bpf to be non-NULL. However, we can introduce bpfattach3() or some special interface flag (set by if_alloc(), for example), indicating that driver uses new api, and retain original behavior for old drivers. -- WBR, Alexander --------------060905060202080703000205 Content-Type: text/plain; name="bpf_writers.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bpf_writers.diff" >From 2ca09cf74ef63fbde0ccede4a7e883c6f0add51d Mon Sep 17 00:00:00 2001 From: "Alexander V. Chernikov" Date: Mon, 26 Mar 2012 14:58:13 +0400 Subject: [PATCH 2/2] Optimize BPF writers --- share/man/man4/bpf.4 | 31 +++++++++++++--- sys/net/bpf.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++---- sys/net/bpf.h | 1 + sys/net/bpfdesc.h | 1 + 4 files changed, 120 insertions(+), 10 deletions(-) diff --git a/share/man/man4/bpf.4 b/share/man/man4/bpf.4 index b9d6742..44bed39 100644 --- a/share/man/man4/bpf.4 +++ b/share/man/man4/bpf.4 @@ -952,10 +952,33 @@ array initializers: .Fn BPF_STMT opcode operand and .Fn BPF_JUMP opcode operand true_offset false_offset . -.Sh FILES -.Bl -tag -compact -width /dev/bpf -.It Pa /dev/bpf -the packet filter device +.Sh SYSCTL VARIABLES +A set of +.Xr sysctl 8 +variables controls the behaviour of the +.Nm +subsystem +.Bl -tag -width indent +.It Va net.bpf.optimize_writers: No 0 +Various programs use BPF to send (but not receive) raw packets +(cdpd, lldpd, dhcpd, dhcp relays, etc. are good examples of such programs). +They do not need incoming packets to be send to them. Turning this option on +makes new BPF users to be attached to write-only interface list until program +explicitly specifies read filter via +.Cm pcap_set_filter() . +This removes any performance degradation for high-speed interfaces. +.It Va net.bpf.stats: +Binary interface for retrieving general statistics. +.It Va net.bpf.zerocopy_enable: No 0 +Permits zero-copy to be used with net BPF readers. Use with caution. +.It Va net.bpf.maxinsns: No 512 +Maximum number of instructions that BPF program can contain. Use +.Xr tcpdump 1 +-d option to determine approximate number of instruction for any filter. +.It Va net.bpf.maxbufsize: No 524288 +Maximum buffer size to allocate for packets buffer. +.It Va net.bpf.bufsize: No 4096 +Default buffer size to allocate for packets buffer. .El .Sh EXAMPLES The following filter is taken from the Reverse ARP Daemon. diff --git a/sys/net/bpf.c b/sys/net/bpf.c index c1d4da7..a3a64ad 100644 --- a/sys/net/bpf.c +++ b/sys/net/bpf.c @@ -176,6 +176,12 @@ SYSCTL_INT(_net_bpf, OID_AUTO, zerocopy_enable, CTLFLAG_RW, static SYSCTL_NODE(_net_bpf, OID_AUTO, stats, CTLFLAG_MPSAFE | CTLFLAG_RW, bpf_stats_sysctl, "bpf statistics portal"); +static VNET_DEFINE(int, bpf_optimize_writers) = 0; +#define V_bpf_optimize_writers VNET(bpf_optimize_writers) +SYSCTL_VNET_INT(_net_bpf, OID_AUTO, optimize_writers, + CTLFLAG_RW, &VNET_NAME(bpf_optimize_writers), 0, + "Do not send packets until BPF program is set"); + static d_open_t bpfopen; static d_read_t bpfread; static d_write_t bpfwrite; @@ -572,17 +578,66 @@ static void bpf_attachd(struct bpf_d *d, struct bpf_if *bp) { /* - * Point d at bp, and add d to the interface's list of listeners. - * Finally, point the driver's bpf cookie at the interface so - * it will divert packets to bpf. + * Point d at bp, and add d to the interface's list. + * Since there are many applicaiotns using BPF for + * sending raw packets only (dhcpd, cdpd are good examples) + * we can delay adding d to the list of active listeners until + * some filter is configured. */ - BPFIF_WLOCK(bp); d->bd_bif = bp; - LIST_INSERT_HEAD(&bp->bif_dlist, d, bd_next); + BPFIF_WLOCK(bp); + + if (V_bpf_optimize_writers != 0) { + /* Add to writers-only list */ + LIST_INSERT_HEAD(&bp->bif_wlist, d, bd_next); + /* + * We decrement bd_writer on every filter set operation. + * First BIOCSETF is done by pcap_open_live() to set up + * snap length. After that appliation usually sets its own filter + */ + d->bd_writer = 2; + } else + LIST_INSERT_HEAD(&bp->bif_dlist, d, bd_next); + + BPFIF_WUNLOCK(bp); + + BPF_LOCK(); bpf_bpfd_cnt++; + BPF_UNLOCK(); + + CTR3(KTR_NET, "%s: bpf_attach called by pid %d, adding to %s list", + __func__, d->bd_pid, d->bd_writer ? "writer" : "active"); + + if (V_bpf_optimize_writers == 0) + EVENTHANDLER_INVOKE(bpf_track, bp->bif_ifp, bp->bif_dlt, 1); +} + +/* + * Add d to the list of active bp filters. + * Reuqires bpf_attachd() to be called before + */ +static void +bpf_upgraded(struct bpf_d *d) +{ + struct bpf_if *bp; + + bp = d->bd_bif; + + BPFIF_WLOCK(bp); + BPFD_WLOCK(d); + + /* Remove from writers-only list */ + LIST_REMOVE(d, bd_next); + LIST_INSERT_HEAD(&bp->bif_dlist, d, bd_next); + /* Mark d as reader */ + d->bd_writer = 0; + + BPFD_WUNLOCK(d); BPFIF_WUNLOCK(bp); + CTR2(KTR_NET, "%s: upgrade required by pid %d", __func__, d->bd_pid); + EVENTHANDLER_INVOKE(bpf_track, bp->bif_ifp, bp->bif_dlt, 1); } @@ -596,12 +651,17 @@ bpf_detachd(struct bpf_d *d) struct bpf_if *bp; struct ifnet *ifp; + CTR2(KTR_NET, "%s: detach required by pid %d", __func__, d->bd_pid); + BPF_LOCK_ASSERT(); bp = d->bd_bif; BPFIF_WLOCK(bp); BPFD_WLOCK(d); + /* Save bd_writer value */ + error = d->bd_writer; + /* * Remove d from the interface's descriptor list. */ @@ -615,7 +675,9 @@ bpf_detachd(struct bpf_d *d) /* We're already protected by global lock. */ bpf_bpfd_cnt--; - EVENTHANDLER_INVOKE(bpf_track, ifp, bp->bif_dlt, 0); + /* Call event handler iff d is attached */ + if (error == 0) + EVENTHANDLER_INVOKE(bpf_track, ifp, bp->bif_dlt, 0); /* * Check if this descriptor had requested promiscuous mode. @@ -1536,6 +1598,7 @@ bpf_setf(struct bpf_d *d, struct bpf_program *fp, u_long cmd) #ifdef COMPAT_FREEBSD32 struct bpf_program32 *fp32; struct bpf_program fp_swab; + int need_upgrade = 0; if (cmd == BIOCSETWF32 || cmd == BIOCSETF32 || cmd == BIOCSETFNR32) { fp32 = (struct bpf_program32 *)fp; @@ -1611,6 +1674,16 @@ bpf_setf(struct bpf_d *d, struct bpf_program *fp, u_long cmd) #endif if (cmd == BIOCSETF) reset_d(d); + + /* + * Do not require upgrade by first BIOCSETF + * (used to set snaplen) by pcap_open_live() + */ + if ((d->bd_writer != 0) && (--d->bd_writer == 0)) + need_upgrade = 1; + CTR4(KTR_NET, "%s: filter function set by pid %d, " + "bd_writer counter %d, need_upgrade %d", + __func__, d->bd_pid, d->bd_writer, need_upgrade); } BPFD_WUNLOCK(d); BPFIF_WUNLOCK(d->bd_bif); @@ -1621,6 +1694,10 @@ bpf_setf(struct bpf_d *d, struct bpf_program *fp, u_long cmd) bpf_destroy_jit_filter(ofunc); #endif + /* Move d to active readers list */ + if (need_upgrade != 0) + bpf_upgraded(d); + return (0); } free((caddr_t)fcode, M_BPF); @@ -2265,6 +2342,7 @@ bpfattach2(struct ifnet *ifp, u_int dlt, u_int hdrlen, struct bpf_if **driverp) panic("bpfattach"); LIST_INIT(&bp->bif_dlist); + LIST_INIT(&bp->bif_wlist); bp->bif_ifp = ifp; bp->bif_dlt = dlt; rw_init(&bp->bif_lock, "bpf interface lock"); @@ -2520,6 +2598,13 @@ bpf_stats_sysctl(SYSCTL_HANDLER_ARGS) index = 0; LIST_FOREACH(bp, &bpf_iflist, bif_next) { BPFIF_RLOCK(bp); + /* Send writers-only first */ + LIST_FOREACH(bd, &bp->bif_wlist, bd_next) { + xbd = &xbdbuf[index++]; + BPFD_RLOCK(bd); + bpfstats_fill_xbpf(xbd, bd); + BPFD_RUNLOCK(bd); + } LIST_FOREACH(bd, &bp->bif_dlist, bd_next) { xbd = &xbdbuf[index++]; BPFD_RLOCK(bd); diff --git a/sys/net/bpf.h b/sys/net/bpf.h index 4c4f0c3..01e1bd2 100644 --- a/sys/net/bpf.h +++ b/sys/net/bpf.h @@ -1104,6 +1104,7 @@ struct bpf_if { u_int bif_hdrlen; /* length of link header */ struct ifnet *bif_ifp; /* corresponding interface */ struct rwlock bif_lock; /* interface lock */ + LIST_HEAD(, bpf_d) bif_wlist; /* writer-only list */ #endif }; diff --git a/sys/net/bpfdesc.h b/sys/net/bpfdesc.h index 9ea4522..e11fdc6 100644 --- a/sys/net/bpfdesc.h +++ b/sys/net/bpfdesc.h @@ -79,6 +79,7 @@ struct bpf_d { u_char bd_promisc; /* true if listening promiscuously */ u_char bd_state; /* idle, waiting, or timed out */ u_char bd_immediate; /* true to return on packet arrival */ + u_char bd_writer; /* non-zero if d is writer-only */ int bd_hdrcmplt; /* false to fill in src lladdr automatically */ int bd_direction; /* select packet direction */ int bd_tstamp; /* select time stamping function */ -- 1.7.9.4 --------------060905060202080703000205 Content-Type: text/plain; name="bpf_rwlock.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bpf_rwlock.diff" >From 00a39222ce5721e2fc3925657c3b1e69502d59b5 Mon Sep 17 00:00:00 2001 From: "Alexander V. Chernikov" Date: Mon, 26 Mar 2012 14:57:09 +0400 Subject: [PATCH 1/2] Change mutexes to rwlocks --- sys/kern/subr_witness.c | 4 +- sys/net/bpf.c | 251 +++++++++++++++++++++++++------------------- sys/net/bpf.h | 7 +- sys/net/bpf_buffer.c | 6 +- sys/net/bpf_zerocopy.c | 10 +- sys/net/bpfdesc.h | 23 ++-- sys/security/mac/mac_net.c | 2 + 7 files changed, 180 insertions(+), 123 deletions(-) diff --git a/sys/kern/subr_witness.c b/sys/kern/subr_witness.c index 7853e69..53529b3 100644 --- a/sys/kern/subr_witness.c +++ b/sys/kern/subr_witness.c @@ -563,8 +563,8 @@ static struct witness_order_list_entry order_lists[] = { * BPF */ { "bpf global lock", &lock_class_mtx_sleep }, - { "bpf interface lock", &lock_class_mtx_sleep }, - { "bpf cdev lock", &lock_class_mtx_sleep }, + { "bpf interface lock", &lock_class_rw }, + { "bpf cdev lock", &lock_class_rw }, { NULL, NULL }, /* * NFS server diff --git a/sys/net/bpf.c b/sys/net/bpf.c index cf8f2ec..c1d4da7 100644 --- a/sys/net/bpf.c +++ b/sys/net/bpf.c @@ -43,6 +43,8 @@ __FBSDID("$FreeBSD: head/sys/net/bpf.c 232449 2012-03-03 08:19:18Z jmallett $"); #include #include +#include +#include #include #include #include @@ -66,6 +68,7 @@ __FBSDID("$FreeBSD: head/sys/net/bpf.c 232449 2012-03-03 08:19:18Z jmallett $"); #include #include +#define BPF_INTERNAL #include #include #ifdef BPF_JITTER @@ -207,7 +210,7 @@ bpf_append_bytes(struct bpf_d *d, caddr_t buf, u_int offset, void *src, u_int len) { - BPFD_LOCK_ASSERT(d); + BPFD_WLOCK_ASSERT(d); switch (d->bd_bufmode) { case BPF_BUFMODE_BUFFER: @@ -227,7 +230,7 @@ bpf_append_mbuf(struct bpf_d *d, caddr_t buf, u_int offset, void *src, u_int len) { - BPFD_LOCK_ASSERT(d); + BPFD_WLOCK_ASSERT(d); switch (d->bd_bufmode) { case BPF_BUFMODE_BUFFER: @@ -249,7 +252,7 @@ static void bpf_buf_reclaimed(struct bpf_d *d) { - BPFD_LOCK_ASSERT(d); + BPFD_WLOCK_ASSERT(d); switch (d->bd_bufmode) { case BPF_BUFMODE_BUFFER: @@ -290,7 +293,6 @@ bpf_canfreebuf(struct bpf_d *d) static int bpf_canwritebuf(struct bpf_d *d) { - BPFD_LOCK_ASSERT(d); switch (d->bd_bufmode) { @@ -309,7 +311,7 @@ static void bpf_buffull(struct bpf_d *d) { - BPFD_LOCK_ASSERT(d); + BPFD_WLOCK_ASSERT(d); switch (d->bd_bufmode) { case BPF_BUFMODE_ZBUF: @@ -325,7 +327,7 @@ void bpf_bufheld(struct bpf_d *d) { - BPFD_LOCK_ASSERT(d); + BPFD_WLOCK_ASSERT(d); switch (d->bd_bufmode) { case BPF_BUFMODE_ZBUF: @@ -574,12 +576,12 @@ bpf_attachd(struct bpf_d *d, struct bpf_if *bp) * Finally, point the driver's bpf cookie at the interface so * it will divert packets to bpf. */ - BPFIF_LOCK(bp); + BPFIF_WLOCK(bp); d->bd_bif = bp; LIST_INSERT_HEAD(&bp->bif_dlist, d, bd_next); bpf_bpfd_cnt++; - BPFIF_UNLOCK(bp); + BPFIF_WUNLOCK(bp); EVENTHANDLER_INVOKE(bpf_track, bp->bif_ifp, bp->bif_dlt, 1); } @@ -594,20 +596,24 @@ bpf_detachd(struct bpf_d *d) struct bpf_if *bp; struct ifnet *ifp; + BPF_LOCK_ASSERT(); + bp = d->bd_bif; - BPFIF_LOCK(bp); - BPFD_LOCK(d); - ifp = d->bd_bif->bif_ifp; + BPFIF_WLOCK(bp); + BPFD_WLOCK(d); /* * Remove d from the interface's descriptor list. */ LIST_REMOVE(d, bd_next); - bpf_bpfd_cnt--; + ifp = bp->bif_ifp; d->bd_bif = NULL; - BPFD_UNLOCK(d); - BPFIF_UNLOCK(bp); + BPFD_WUNLOCK(d); + BPFIF_WUNLOCK(bp); + + /* We're already protected by global lock. */ + bpf_bpfd_cnt--; EVENTHANDLER_INVOKE(bpf_track, ifp, bp->bif_dlt, 0); @@ -642,16 +648,16 @@ bpf_dtor(void *data) { struct bpf_d *d = data; - BPFD_LOCK(d); + BPFD_WLOCK(d); if (d->bd_state == BPF_WAITING) callout_stop(&d->bd_callout); d->bd_state = BPF_IDLE; - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); funsetown(&d->bd_sigio); - mtx_lock(&bpf_mtx); + BPF_LOCK(); if (d->bd_bif) bpf_detachd(d); - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); #ifdef MAC mac_bpfdesc_destroy(d); #endif /* MAC */ @@ -689,14 +695,14 @@ bpfopen(struct cdev *dev, int flags, int fmt, struct thread *td) d->bd_bufmode = BPF_BUFMODE_BUFFER; d->bd_sig = SIGIO; d->bd_direction = BPF_D_INOUT; - d->bd_pid = td->td_proc->p_pid; + BPF_PID_REFRESH(d, td); #ifdef MAC mac_bpfdesc_init(d); mac_bpfdesc_create(td->td_ucred, d); #endif - mtx_init(&d->bd_mtx, devtoname(dev), "bpf cdev lock", MTX_DEF); - callout_init_mtx(&d->bd_callout, &d->bd_mtx, 0); - knlist_init_mtx(&d->bd_sel.si_note, &d->bd_mtx); + rw_init(&d->bd_lock, "bpf cdev lock"); + callout_init_rw(&d->bd_callout, &d->bd_lock, 0); + knlist_init_rw_reader(&d->bd_sel.si_note, &d->bd_lock); return (0); } @@ -725,10 +731,10 @@ bpfread(struct cdev *dev, struct uio *uio, int ioflag) non_block = ((ioflag & O_NONBLOCK) != 0); - BPFD_LOCK(d); - d->bd_pid = curthread->td_proc->p_pid; + BPFD_WLOCK(d); + BPF_PID_REFRESH_CUR(d); if (d->bd_bufmode != BPF_BUFMODE_BUFFER) { - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (EOPNOTSUPP); } if (d->bd_state == BPF_WAITING) @@ -764,18 +770,18 @@ bpfread(struct cdev *dev, struct uio *uio, int ioflag) * it before using it again. */ if (d->bd_bif == NULL) { - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (ENXIO); } if (non_block) { - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (EWOULDBLOCK); } - error = msleep(d, &d->bd_mtx, PRINET|PCATCH, + error = rw_sleep(d, &d->bd_lock, PRINET|PCATCH, "bpf", d->bd_rtout); if (error == EINTR || error == ERESTART) { - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (error); } if (error == EWOULDBLOCK) { @@ -793,7 +799,7 @@ bpfread(struct cdev *dev, struct uio *uio, int ioflag) break; if (d->bd_slen == 0) { - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (0); } ROTATE_BUFFERS(d); @@ -803,7 +809,7 @@ bpfread(struct cdev *dev, struct uio *uio, int ioflag) /* * At this point, we know we have something in the hold slot. */ - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); /* * Move data from hold buffer into user space. @@ -816,12 +822,12 @@ bpfread(struct cdev *dev, struct uio *uio, int ioflag) */ error = bpf_uiomove(d, d->bd_hbuf, d->bd_hlen, uio); - BPFD_LOCK(d); + BPFD_WLOCK(d); d->bd_fbuf = d->bd_hbuf; d->bd_hbuf = NULL; d->bd_hlen = 0; bpf_buf_reclaimed(d); - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (error); } @@ -833,7 +839,7 @@ static __inline void bpf_wakeup(struct bpf_d *d) { - BPFD_LOCK_ASSERT(d); + BPFD_WLOCK_ASSERT(d); if (d->bd_state == BPF_WAITING) { callout_stop(&d->bd_callout); d->bd_state = BPF_IDLE; @@ -851,7 +857,7 @@ bpf_timed_out(void *arg) { struct bpf_d *d = (struct bpf_d *)arg; - BPFD_LOCK_ASSERT(d); + BPFD_WLOCK_ASSERT(d); if (callout_pending(&d->bd_callout) || !callout_active(&d->bd_callout)) return; @@ -866,7 +872,7 @@ static int bpf_ready(struct bpf_d *d) { - BPFD_LOCK_ASSERT(d); + BPFD_WLOCK_ASSERT(d); if (!bpf_canfreebuf(d) && d->bd_hlen != 0) return (1); @@ -889,7 +895,7 @@ bpfwrite(struct cdev *dev, struct uio *uio, int ioflag) if (error != 0) return (error); - d->bd_pid = curthread->td_proc->p_pid; + BPF_PID_REFRESH_CUR(d); d->bd_wcount++; if (d->bd_bif == NULL) { d->bd_wdcount++; @@ -937,11 +943,11 @@ bpfwrite(struct cdev *dev, struct uio *uio, int ioflag) CURVNET_SET(ifp->if_vnet); #ifdef MAC - BPFD_LOCK(d); + BPFD_WLOCK(d); mac_bpfdesc_create_mbuf(d, m); if (mc != NULL) mac_bpfdesc_create_mbuf(d, mc); - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); #endif error = (*ifp->if_output)(ifp, m, &dst, NULL); @@ -970,7 +976,7 @@ static void reset_d(struct bpf_d *d) { - mtx_assert(&d->bd_mtx, MA_OWNED); + BPFD_WLOCK_ASSERT(d); if ((d->bd_hbuf != NULL) && (d->bd_bufmode != BPF_BUFMODE_ZBUF || bpf_canfreebuf(d))) { @@ -1037,12 +1043,12 @@ bpfioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flags, /* * Refresh PID associated with this descriptor. */ - BPFD_LOCK(d); - d->bd_pid = td->td_proc->p_pid; + BPFD_WLOCK(d); + BPF_PID_REFRESH(d, td); if (d->bd_state == BPF_WAITING) callout_stop(&d->bd_callout); d->bd_state = BPF_IDLE; - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); if (d->bd_locked == 1) { switch (cmd) { @@ -1108,11 +1114,11 @@ bpfioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flags, { int n; - BPFD_LOCK(d); + BPFD_WLOCK(d); n = d->bd_slen; if (d->bd_hbuf) n += d->bd_hlen; - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); *(int *)addr = n; break; @@ -1163,9 +1169,9 @@ bpfioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flags, * Flush read packet buffer. */ case BIOCFLUSH: - BPFD_LOCK(d); + BPFD_WLOCK(d); reset_d(d); - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); break; /* @@ -1488,15 +1494,15 @@ bpfioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flags, return (EINVAL); } - BPFD_LOCK(d); + BPFD_WLOCK(d); if (d->bd_sbuf != NULL || d->bd_hbuf != NULL || d->bd_fbuf != NULL || d->bd_bif != NULL) { - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); CURVNET_RESTORE(); return (EBUSY); } d->bd_bufmode = *(u_int *)addr; - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); break; case BIOCGETZMAX: @@ -1556,7 +1562,12 @@ bpf_setf(struct bpf_d *d, struct bpf_program *fp, u_long cmd) if (fp->bf_insns == NULL) { if (fp->bf_len != 0) return (EINVAL); - BPFD_LOCK(d); + /* + * Protect filter change by interface lock, too. + * The same lock order is used by bpf_detachd(). + */ + BPFIF_WLOCK(d->bd_bif); + BPFD_WLOCK(d); if (wfilter) d->bd_wfilter = NULL; else { @@ -1567,7 +1578,8 @@ bpf_setf(struct bpf_d *d, struct bpf_program *fp, u_long cmd) if (cmd == BIOCSETF) reset_d(d); } - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); + BPFIF_WUNLOCK(d->bd_bif); if (old != NULL) free((caddr_t)old, M_BPF); #ifdef BPF_JITTER @@ -1584,7 +1596,12 @@ bpf_setf(struct bpf_d *d, struct bpf_program *fp, u_long cmd) fcode = (struct bpf_insn *)malloc(size, M_BPF, M_WAITOK); if (copyin((caddr_t)fp->bf_insns, (caddr_t)fcode, size) == 0 && bpf_validate(fcode, (int)flen)) { - BPFD_LOCK(d); + /* + * Protect filter change by interface lock, too + * The same lock order is used by bpf_detachd(). + */ + BPFIF_WLOCK(d->bd_bif); + BPFD_WLOCK(d); if (wfilter) d->bd_wfilter = fcode; else { @@ -1595,7 +1612,8 @@ bpf_setf(struct bpf_d *d, struct bpf_program *fp, u_long cmd) if (cmd == BIOCSETF) reset_d(d); } - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); + BPFIF_WUNLOCK(d->bd_bif); if (old != NULL) free((caddr_t)old, M_BPF); #ifdef BPF_JITTER @@ -1659,9 +1677,9 @@ bpf_setif(struct bpf_d *d, struct ifreq *ifr) bpf_attachd(d, bp); } - BPFD_LOCK(d); + BPFD_WLOCK(d); reset_d(d); - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (0); } @@ -1685,8 +1703,8 @@ bpfpoll(struct cdev *dev, int events, struct thread *td) * Refresh PID associated with this descriptor. */ revents = events & (POLLOUT | POLLWRNORM); - BPFD_LOCK(d); - d->bd_pid = td->td_proc->p_pid; + BPFD_WLOCK(d); + BPF_PID_REFRESH(d, td); if (events & (POLLIN | POLLRDNORM)) { if (bpf_ready(d)) revents |= events & (POLLIN | POLLRDNORM); @@ -1700,7 +1718,7 @@ bpfpoll(struct cdev *dev, int events, struct thread *td) } } } - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (revents); } @@ -1720,12 +1738,12 @@ bpfkqfilter(struct cdev *dev, struct knote *kn) /* * Refresh PID associated with this descriptor. */ - BPFD_LOCK(d); - d->bd_pid = curthread->td_proc->p_pid; + BPFD_WLOCK(d); + BPF_PID_REFRESH_CUR(d); kn->kn_fop = &bpfread_filtops; kn->kn_hook = d; knlist_add(&d->bd_sel.si_note, kn, 1); - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (0); } @@ -1744,7 +1762,7 @@ filt_bpfread(struct knote *kn, long hint) struct bpf_d *d = (struct bpf_d *)kn->kn_hook; int ready; - BPFD_LOCK_ASSERT(d); + BPFD_WLOCK_ASSERT(d); ready = bpf_ready(d); if (ready) { kn->kn_data = d->bd_slen; @@ -1819,9 +1837,19 @@ bpf_tap(struct bpf_if *bp, u_char *pkt, u_int pktlen) int gottime; gottime = BPF_TSTAMP_NONE; - BPFIF_LOCK(bp); + + BPFIF_RLOCK(bp); + LIST_FOREACH(d, &bp->bif_dlist, bd_next) { - BPFD_LOCK(d); + /* + * We are not using any locks for d here because: + * 1) any filter change is protected by interface + * write lock + * 2) destroying/detaching d is protected by interface + * write lock, too + */ + + /* XXX: Do not protect counter for the sake of performance. */ ++d->bd_rcount; /* * NB: We dont call BPF_CHECK_DIRECTION() here since there is no @@ -1837,6 +1865,11 @@ bpf_tap(struct bpf_if *bp, u_char *pkt, u_int pktlen) #endif slen = bpf_filter(d->bd_rfilter, pkt, pktlen, pktlen); if (slen != 0) { + /* + * Filter matches. Let's to acquire write lock. + */ + BPFD_WLOCK(d); + d->bd_fcount++; if (gottime < bpf_ts_quality(d->bd_tstamp)) gottime = bpf_gettime(&bt, d->bd_tstamp, NULL); @@ -1845,10 +1878,10 @@ bpf_tap(struct bpf_if *bp, u_char *pkt, u_int pktlen) #endif catchpacket(d, pkt, pktlen, slen, bpf_append_bytes, &bt); + BPFD_WUNLOCK(d); } - BPFD_UNLOCK(d); } - BPFIF_UNLOCK(bp); + BPFIF_RUNLOCK(bp); } #define BPF_CHECK_DIRECTION(d, r, i) \ @@ -1857,6 +1890,7 @@ bpf_tap(struct bpf_if *bp, u_char *pkt, u_int pktlen) /* * Incoming linkage from device drivers, when packet is in an mbuf chain. + * Locking model is explained in bpf_tap(). */ void bpf_mtap(struct bpf_if *bp, struct mbuf *m) @@ -1876,13 +1910,13 @@ bpf_mtap(struct bpf_if *bp, struct mbuf *m) } pktlen = m_length(m, NULL); - gottime = BPF_TSTAMP_NONE; - BPFIF_LOCK(bp); + + BPFIF_RLOCK(bp); + LIST_FOREACH(d, &bp->bif_dlist, bd_next) { if (BPF_CHECK_DIRECTION(d, m->m_pkthdr.rcvif, bp->bif_ifp)) continue; - BPFD_LOCK(d); ++d->bd_rcount; #ifdef BPF_JITTER bf = bpf_jitter_enable != 0 ? d->bd_bfilter : NULL; @@ -1893,6 +1927,8 @@ bpf_mtap(struct bpf_if *bp, struct mbuf *m) #endif slen = bpf_filter(d->bd_rfilter, (u_char *)m, pktlen, 0); if (slen != 0) { + BPFD_WLOCK(d); + d->bd_fcount++; if (gottime < bpf_ts_quality(d->bd_tstamp)) gottime = bpf_gettime(&bt, d->bd_tstamp, m); @@ -1901,10 +1937,10 @@ bpf_mtap(struct bpf_if *bp, struct mbuf *m) #endif catchpacket(d, (u_char *)m, pktlen, slen, bpf_append_mbuf, &bt); + BPFD_WUNLOCK(d); } - BPFD_UNLOCK(d); } - BPFIF_UNLOCK(bp); + BPFIF_RUNLOCK(bp); } /* @@ -1938,14 +1974,17 @@ bpf_mtap2(struct bpf_if *bp, void *data, u_int dlen, struct mbuf *m) pktlen += dlen; gottime = BPF_TSTAMP_NONE; - BPFIF_LOCK(bp); + + BPFIF_RLOCK(bp); + LIST_FOREACH(d, &bp->bif_dlist, bd_next) { if (BPF_CHECK_DIRECTION(d, m->m_pkthdr.rcvif, bp->bif_ifp)) continue; - BPFD_LOCK(d); ++d->bd_rcount; slen = bpf_filter(d->bd_rfilter, (u_char *)&mb, pktlen, 0); if (slen != 0) { + BPFD_WLOCK(d); + d->bd_fcount++; if (gottime < bpf_ts_quality(d->bd_tstamp)) gottime = bpf_gettime(&bt, d->bd_tstamp, m); @@ -1954,10 +1993,10 @@ bpf_mtap2(struct bpf_if *bp, void *data, u_int dlen, struct mbuf *m) #endif catchpacket(d, (u_char *)&mb, pktlen, slen, bpf_append_mbuf, &bt); + BPFD_WUNLOCK(d); } - BPFD_UNLOCK(d); } - BPFIF_UNLOCK(bp); + BPFIF_RUNLOCK(bp); } #undef BPF_CHECK_DIRECTION @@ -2049,7 +2088,7 @@ catchpacket(struct bpf_d *d, u_char *pkt, u_int pktlen, u_int snaplen, int do_timestamp; int tstype; - BPFD_LOCK_ASSERT(d); + BPFD_WLOCK_ASSERT(d); /* * Detect whether user space has released a buffer back to us, and if @@ -2196,7 +2235,7 @@ bpf_freed(struct bpf_d *d) } if (d->bd_wfilter != NULL) free((caddr_t)d->bd_wfilter, M_BPF); - mtx_destroy(&d->bd_mtx); + rw_destroy(&d->bd_lock); } /* @@ -2228,13 +2267,13 @@ bpfattach2(struct ifnet *ifp, u_int dlt, u_int hdrlen, struct bpf_if **driverp) LIST_INIT(&bp->bif_dlist); bp->bif_ifp = ifp; bp->bif_dlt = dlt; - mtx_init(&bp->bif_mtx, "bpf interface lock", NULL, MTX_DEF); + rw_init(&bp->bif_lock, "bpf interface lock"); KASSERT(*driverp == NULL, ("bpfattach2: driverp already initialized")); *driverp = bp; - mtx_lock(&bpf_mtx); + BPF_LOCK(); LIST_INSERT_HEAD(&bpf_iflist, bp, bif_next); - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); bp->bif_hdrlen = hdrlen; @@ -2261,14 +2300,14 @@ bpfdetach(struct ifnet *ifp) /* Find all bpf_if struct's which reference ifp and detach them. */ do { - mtx_lock(&bpf_mtx); + BPF_LOCK(); LIST_FOREACH(bp, &bpf_iflist, bif_next) { if (ifp == bp->bif_ifp) break; } if (bp != NULL) LIST_REMOVE(bp, bif_next); - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); if (bp != NULL) { #ifdef INVARIANTS @@ -2276,11 +2315,11 @@ bpfdetach(struct ifnet *ifp) #endif while ((d = LIST_FIRST(&bp->bif_dlist)) != NULL) { bpf_detachd(d); - BPFD_LOCK(d); + BPFD_WLOCK(d); bpf_wakeup(d); - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); } - mtx_destroy(&bp->bif_mtx); + rw_destroy(&bp->bif_lock); free(bp, M_BPF); } } while (bp != NULL); @@ -2304,13 +2343,13 @@ bpf_getdltlist(struct bpf_d *d, struct bpf_dltlist *bfl) ifp = d->bd_bif->bif_ifp; n = 0; error = 0; - mtx_lock(&bpf_mtx); + BPF_LOCK(); LIST_FOREACH(bp, &bpf_iflist, bif_next) { if (bp->bif_ifp != ifp) continue; if (bfl->bfl_list != NULL) { if (n >= bfl->bfl_len) { - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); return (ENOMEM); } error = copyout(&bp->bif_dlt, @@ -2318,7 +2357,7 @@ bpf_getdltlist(struct bpf_d *d, struct bpf_dltlist *bfl) } n++; } - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); bfl->bfl_len = n; return (error); } @@ -2336,19 +2375,19 @@ bpf_setdlt(struct bpf_d *d, u_int dlt) if (d->bd_bif->bif_dlt == dlt) return (0); ifp = d->bd_bif->bif_ifp; - mtx_lock(&bpf_mtx); + BPF_LOCK(); LIST_FOREACH(bp, &bpf_iflist, bif_next) { if (bp->bif_ifp == ifp && bp->bif_dlt == dlt) break; } - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); if (bp != NULL) { opromisc = d->bd_promisc; bpf_detachd(d); bpf_attachd(d, bp); - BPFD_LOCK(d); + BPFD_WLOCK(d); reset_d(d); - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); if (opromisc) { error = ifpromisc(bp->bif_ifp, 1); if (error) @@ -2386,22 +2425,22 @@ bpf_zero_counters(void) struct bpf_if *bp; struct bpf_d *bd; - mtx_lock(&bpf_mtx); + BPF_LOCK(); LIST_FOREACH(bp, &bpf_iflist, bif_next) { - BPFIF_LOCK(bp); + BPFIF_RLOCK(bp); LIST_FOREACH(bd, &bp->bif_dlist, bd_next) { - BPFD_LOCK(bd); + BPFD_WLOCK(bd); bd->bd_rcount = 0; bd->bd_dcount = 0; bd->bd_fcount = 0; bd->bd_wcount = 0; bd->bd_wfcount = 0; bd->bd_zcopy = 0; - BPFD_UNLOCK(bd); + BPFD_WUNLOCK(bd); } - BPFIF_UNLOCK(bp); + BPFIF_RUNLOCK(bp); } - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); } static void @@ -2472,24 +2511,24 @@ bpf_stats_sysctl(SYSCTL_HANDLER_ARGS) if (bpf_bpfd_cnt == 0) return (SYSCTL_OUT(req, 0, 0)); xbdbuf = malloc(req->oldlen, M_BPF, M_WAITOK); - mtx_lock(&bpf_mtx); + BPF_LOCK(); if (req->oldlen < (bpf_bpfd_cnt * sizeof(*xbd))) { - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); free(xbdbuf, M_BPF); return (ENOMEM); } index = 0; LIST_FOREACH(bp, &bpf_iflist, bif_next) { - BPFIF_LOCK(bp); + BPFIF_RLOCK(bp); LIST_FOREACH(bd, &bp->bif_dlist, bd_next) { xbd = &xbdbuf[index++]; - BPFD_LOCK(bd); + BPFD_RLOCK(bd); bpfstats_fill_xbpf(xbd, bd); - BPFD_UNLOCK(bd); + BPFD_RUNLOCK(bd); } - BPFIF_UNLOCK(bp); + BPFIF_RUNLOCK(bp); } - mtx_unlock(&bpf_mtx); + BPF_UNLOCK(); error = SYSCTL_OUT(req, xbdbuf, index * sizeof(*xbd)); free(xbdbuf, M_BPF); return (error); diff --git a/sys/net/bpf.h b/sys/net/bpf.h index c47ad1d..4c4f0c3 100644 --- a/sys/net/bpf.h +++ b/sys/net/bpf.h @@ -1092,14 +1092,19 @@ SYSCTL_DECL(_net_bpf); /* * Descriptor associated with each attached hardware interface. + * FIXME: this structure is exposed to external callers to speed up + * bpf_peers_present() call. However we cover all fields not needed by + * this function via BPF_INTERNAL define */ struct bpf_if { LIST_ENTRY(bpf_if) bif_next; /* list of all interfaces */ LIST_HEAD(, bpf_d) bif_dlist; /* descriptor list */ +#ifdef BPF_INTERNAL u_int bif_dlt; /* link layer type */ u_int bif_hdrlen; /* length of link header */ struct ifnet *bif_ifp; /* corresponding interface */ - struct mtx bif_mtx; /* mutex for interface */ + struct rwlock bif_lock; /* interface lock */ +#endif }; void bpf_bufheld(struct bpf_d *d); diff --git a/sys/net/bpf_buffer.c b/sys/net/bpf_buffer.c index e257960..51b418e 100644 --- a/sys/net/bpf_buffer.c +++ b/sys/net/bpf_buffer.c @@ -184,9 +184,9 @@ bpf_buffer_ioctl_sblen(struct bpf_d *d, u_int *i) { u_int size; - BPFD_LOCK(d); + BPFD_WLOCK(d); if (d->bd_bif != NULL) { - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (EINVAL); } size = *i; @@ -195,7 +195,7 @@ bpf_buffer_ioctl_sblen(struct bpf_d *d, u_int *i) else if (size < BPF_MINBUFSIZE) *i = size = BPF_MINBUFSIZE; d->bd_bufsize = size; - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (0); } diff --git a/sys/net/bpf_zerocopy.c b/sys/net/bpf_zerocopy.c index 60fd76f..1bf0bd6 100644 --- a/sys/net/bpf_zerocopy.c +++ b/sys/net/bpf_zerocopy.c @@ -515,14 +515,14 @@ bpf_zerocopy_ioctl_rotzbuf(struct thread *td, struct bpf_d *d, struct zbuf *bzh; bzero(bz, sizeof(*bz)); - BPFD_LOCK(d); + BPFD_WLOCK(d); if (d->bd_hbuf == NULL && d->bd_slen != 0) { ROTATE_BUFFERS(d); bzh = (struct zbuf *)d->bd_hbuf; bz->bz_bufa = (void *)bzh->zb_uaddr; bz->bz_buflen = d->bd_hlen; } - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (0); } @@ -570,10 +570,10 @@ bpf_zerocopy_ioctl_setzbuf(struct thread *td, struct bpf_d *d, * We only allow buffers to be installed once, so atomically check * that no buffers are currently installed and install new buffers. */ - BPFD_LOCK(d); + BPFD_WLOCK(d); if (d->bd_hbuf != NULL || d->bd_sbuf != NULL || d->bd_fbuf != NULL || d->bd_bif != NULL) { - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); zbuf_free(zba); zbuf_free(zbb); return (EINVAL); @@ -593,6 +593,6 @@ bpf_zerocopy_ioctl_setzbuf(struct thread *td, struct bpf_d *d, * shared management region. */ d->bd_bufsize = bz->bz_buflen - sizeof(struct bpf_zbuf_header); - BPFD_UNLOCK(d); + BPFD_WUNLOCK(d); return (0); } diff --git a/sys/net/bpfdesc.h b/sys/net/bpfdesc.h index d8950b9..9ea4522 100644 --- a/sys/net/bpfdesc.h +++ b/sys/net/bpfdesc.h @@ -87,7 +87,7 @@ struct bpf_d { int bd_sig; /* signal to send upon packet reception */ struct sigio * bd_sigio; /* information for async I/O */ struct selinfo bd_sel; /* bsd select info */ - struct mtx bd_mtx; /* mutex for this descriptor */ + struct rwlock bd_lock; /* per-descriptor lock */ struct callout bd_callout; /* for BPF timeouts with select */ struct label *bd_label; /* MAC label for descriptor */ u_int64_t bd_fcount; /* number of packets which matched filter */ @@ -106,10 +106,19 @@ struct bpf_d { #define BPF_WAITING 1 /* waiting for read timeout in select */ #define BPF_TIMED_OUT 2 /* read timeout has expired in select */ -#define BPFD_LOCK(bd) mtx_lock(&(bd)->bd_mtx) -#define BPFD_UNLOCK(bd) mtx_unlock(&(bd)->bd_mtx) -#define BPFD_LOCK_ASSERT(bd) mtx_assert(&(bd)->bd_mtx, MA_OWNED) +#define BPFD_RLOCK(bd) rw_rlock(&(bd)->bd_lock) +#define BPFD_RUNLOCK(bd) rw_runlock(&(bd)->bd_lock) +#define BPFD_WLOCK(bd) rw_wlock(&(bd)->bd_lock) +#define BPFD_WUNLOCK(bd) rw_wunlock(&(bd)->bd_lock) +#define BPFD_WLOCK_ASSERT(bd) rw_assert(&(bd)->bd_lock, RA_WLOCKED) +#define BPFD_LOCK_ASSERT(bd) rw_assert(&(bd)->bd_lock, RA_LOCKED) +#define BPF_PID_REFRESH(bd, td) (bd)->bd_pid = (td)->td_proc->p_pid +#define BPF_PID_REFRESH_CUR(bd) (bd)->bd_pid = curthread->td_proc->p_pid + +#define BPF_LOCK() mtx_lock(&bpf_mtx) +#define BPF_UNLOCK() mtx_unlock(&bpf_mtx) +#define BPF_LOCK_ASSERT() mtx_assert(&bpf_mtx, MA_OWNED) /* * External representation of the bpf descriptor */ @@ -144,7 +153,9 @@ struct xbpf_d { u_int64_t bd_spare[4]; }; -#define BPFIF_LOCK(bif) mtx_lock(&(bif)->bif_mtx) -#define BPFIF_UNLOCK(bif) mtx_unlock(&(bif)->bif_mtx) +#define BPFIF_RLOCK(bif) rw_rlock(&(bif)->bif_lock) +#define BPFIF_RUNLOCK(bif) rw_runlock(&(bif)->bif_lock) +#define BPFIF_WLOCK(bif) rw_wlock(&(bif)->bif_lock) +#define BPFIF_WUNLOCK(bif) rw_wunlock(&(bif)->bif_lock) #endif diff --git a/sys/security/mac/mac_net.c b/sys/security/mac/mac_net.c index 56ee817..7857749 100644 --- a/sys/security/mac/mac_net.c +++ b/sys/security/mac/mac_net.c @@ -319,6 +319,7 @@ mac_bpfdesc_create_mbuf(struct bpf_d *d, struct mbuf *m) { struct label *label; + /* Assume reader lock is enough. */ BPFD_LOCK_ASSERT(d); if (mac_policy_count == 0) @@ -354,6 +355,7 @@ mac_bpfdesc_check_receive(struct bpf_d *d, struct ifnet *ifp) { int error; + /* Assume reader lock is enough. */ BPFD_LOCK_ASSERT(d); if (mac_policy_count == 0) -- 1.7.9.4 --------------060905060202080703000205-- From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 11:07:10 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AE22106564A for ; Mon, 26 Mar 2012 11:07:10 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 236C08FC12 for ; Mon, 26 Mar 2012 11:07:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2QB7AXJ018347 for ; Mon, 26 Mar 2012 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2QB79Kb018345 for freebsd-net@FreeBSD.org; Mon, 26 Mar 2012 11:07:09 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Mar 2012 11:07:09 GMT Message-Id: <201203261107.q2QB79Kb018345@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, 26 Mar 2012 11:07:10 -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/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165863 net [panic] [netinet] [patch] in_lltable_prefix_free() rac o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164569 net [msk] [hang] msk network driver cause freeze in FreeBS o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164400 net [ipsec] immediate crash after the start of ipsec proce o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162509 net [re] [panic] Kernel panic may be related to if_re.c (r o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re 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/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/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan 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/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 kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference 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 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/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 kern/136618 net [pf][stf] panic on cloning interface without unit numb 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 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/132277 net [crypto] [ipsec] poor performance using cryptodevice f 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 f 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/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy 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/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 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 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/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/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 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 398 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 14:00:59 2012 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 B002C106566B for ; Mon, 26 Mar 2012 14:00:59 +0000 (UTC) (envelope-from universite@ukr.net) Received: from ffe15.ukr.net (ffe15.ukr.net [195.214.192.50]) by mx1.freebsd.org (Postfix) with ESMTP id 62F6A8FC1B for ; Mon, 26 Mar 2012 14:00:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:Subject:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=VY06Oq1+rwS1Nr7XD0HXpfv0afxLZh/iXnjro8xxjEU=; b=M30ixTr5QT2rqWfAXV9b83x+YiYT0wJRms1IAofOmMC1KxbeT1SmIonT0k5HQ/eaHzyRvFv/MijWtcI3ptxRablyluF7N8FnOxvbs1+qIcwiwlDX/909WlKv3iiYhqdbNavgLr6uot2ZHL+hirlEuV0fsiwZDpSwQnrJlJc13qs=; Received: from mail by ffe15.ukr.net with local ID 1SCAD6-0002S7-LQ for net@freebsd.org; Mon, 26 Mar 2012 16:43:48 +0300 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" To: net@freebsd.org From: =?WINDOWS-1251?B?wuvg5Ojx6+DiIM/w7uTg7Q==?= X-Mailer: freemail.ukr.net 4.0 X-Originating-Ip: [91.208.138.251] Message-Id: <8904.1332769428.5720084203749900288@ffe15.ukr.net> X-Browser: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0 Date: Mon, 26 Mar 2012 16:43:48 +0300 Cc: Subject: The problem with MTU <1500 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2012 14:00:59 -0000 Dear all! I have two different values of uplink MTU - 1440 and 1492. And in a local network - 1500. In Cisco routers can be set 'set ip df 0', but I have no such router :( What options are there for FreeBSD? Only use the net/tcpmssd? Will it be possible to process both two channels of 1Gb? -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 14:16:51 2012 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 619671065672 for ; Mon, 26 Mar 2012 14:16:51 +0000 (UTC) (envelope-from kudzu@tenebras.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 17AF98FC14 for ; Mon, 26 Mar 2012 14:16:50 +0000 (UTC) Received: by yenl9 with SMTP id l9so4628278yen.13 for ; Mon, 26 Mar 2012 07:16:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/J1SM8/nc0mEUVUQaHPI3xd9LMBOAHAkNw5Hrac5biA=; b=I8lLU0OdyOauXomOY6e7PBYS0Y8XV4g6iOI+4zl0W84DEJWErDnIR4OgmLJyEpVYka ULPAmLuAedzznZHPMK5P+12F93ltRhfJJV3crCr0T52liqb57gdkBPjPCWEEqBvkCWoH 1ZJvqpDxozEdxlFb1MeObY+TzEbWaxV2RUt/wmZ64BYs3ev/mYQ5EQfQAp3+QKOr1pmv O7o06lEAEhP9c3WNYCPMrac6ikQpbFpz+EdIfhisOHu7dwwLGSHpnxA/+bhb4z0/miu4 iPVpV0Vnq0DI+6MRq7XTLt28RLHTjm2wzTtXo8edCbXLpW9HPO6oD8tFHISiRtFycSzo +liA== MIME-Version: 1.0 Received: by 10.60.4.134 with SMTP id k6mr27601055oek.19.1332771410198; Mon, 26 Mar 2012 07:16:50 -0700 (PDT) Received: by 10.60.119.105 with HTTP; Mon, 26 Mar 2012 07:16:50 -0700 (PDT) In-Reply-To: <8904.1332769428.5720084203749900288@ffe15.ukr.net> References: <8904.1332769428.5720084203749900288@ffe15.ukr.net> Date: Mon, 26 Mar 2012 07:16:50 -0700 Message-ID: From: Michael Sierchio To: =?UTF-8?B?0JLQu9Cw0LTQuNGB0LvQsNCyINCf0YDQvtC00LDQvQ==?= X-Gm-Message-State: ALoCoQkiVeH1c9NdwbumIO+KRUsPTdnd+wXAQZ17Ol23lvlJP+JG1leHiLpnunl8zRK8LVqS0agj Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: net@freebsd.org Subject: Re: The problem with MTU <1500 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2012 14:16:51 -0000 2012/3/26 =D0=92=D0=BB=D0=B0=D0=B4=D0=B8=D1=81=D0=BB=D0=B0=D0=B2 =D0=9F=D1= =80=D0=BE=D0=B4=D0=B0=D0=BD > > Dear all! > I have two different values of uplink MTU - 1440 and 1492. > And in a local network - 1500. > In Cisco routers can be set 'set ip df 0', but I have no such router :( > What options are there for FreeBSD? > man ifconfig - not the 'mtu' option. You should set the MTU size on the interface to match the uplink MTU. And you should make sure you handle ICMP need-frag error messages, otherwise Path MTU discovery will be broken. Only use the net/tcpmssd? That's a workaround for not properly handling ICMP error messages, and just for TCP ;-) > Will it be possible to process both two channels of 1Gb? > > Never. ;-) Not in practice. What is the bandwidth - delay product? That's a fraction of the 1Gbps you'll never get. - M From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 14:37:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B74D1065679 for ; Mon, 26 Mar 2012 14:37:53 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id E79C18FC1B for ; Mon, 26 Mar 2012 14:37:52 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 0E3325D52F; Mon, 26 Mar 2012 16:37:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id KOr6602OraFo; Mon, 26 Mar 2012 16:37:45 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 623945D52E; Mon, 26 Mar 2012 16:37:45 +0200 (CEST) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id 5177C450A8; Mon, 26 Mar 2012 16:37:45 +0200 (CEST) Message-ID: <4F707F39.9080204@incore.de> Date: Mon, 26 Mar 2012 16:37:45 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F594856.3030303@incore.de> <20120312211907.GC3671@michelle.cdnetworks.com> <4F5E0AF7.30302@incore.de> <20120313202559.GA3360@michelle.cdnetworks.com> <4F66646E.4080603@incore.de> <20120320041647.GE7518@michelle.cdnetworks.com> <4F6DA161.9040408@incore.de> <20120326003016.GA1435@michelle.cdnetworks.com> In-Reply-To: <20120326003016.GA1435@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Intel 82550 Pro/100 Ethernet and Microcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2012 14:37:53 -0000 YongHyeon PYUN wrote: > > I've attached a patch which will show both compatibility and EEPROM > ID word and allowed loading microcode for 82550 family. Let me > know whether this patch works for you. Yes, the patch workes fine and I have for my LOM's (rev 0x0d): fxp0: port .... fxp0: Compatibility word : 0X0d13 fxp0: EEPROM ID word : 0X5060 and for two external cards (rev 0x0c) I see fxp1: port ... fxp1: Compatibility word : 0X040b fxp1: EEPROM ID word : 0X58a0 fxp2: port ... fxp2: Compatibility word : 0X020b fxp2: EEPROM ID word : 0X50a0 > I vaguely guess there are > differences between LOM and non-LOM implementation(Mine is > stand-alone PCI NIC). I would be able to selectively allow > microcode loading after getting compatibility/EEPROM ID word. Thank you for investigating in this problem. Regards Andreas Longwitz From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 14:48:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 062EB106564A; Mon, 26 Mar 2012 14:48:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CEF248FC1E; Mon, 26 Mar 2012 14:48:12 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 862BA46B0D; Mon, 26 Mar 2012 10:48:12 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C3546B94E; Mon, 26 Mar 2012 10:48:11 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Mon, 26 Mar 2012 10:42:15 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4F6DB568.1060604@lexa.ru> In-Reply-To: <4F6DB568.1060604@lexa.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203261042.15948.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 26 Mar 2012 10:48:11 -0400 (EDT) Cc: Alex Tutubalin , Jeff Roberson , freebsd-stable@freebsd.org Subject: Re: 9-STABLE + Infiniband - incorrect interface counters X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2012 14:48:13 -0000 On Saturday, March 24, 2012 7:52:08 am Alex Tutubalin wrote: > Hi, > > I'm playing with two FreeBSD 9-STABLE boxes connected via 10Gbps > Infiniband (more details below) in Infiniband connected mode. > > I see incorrect interface statistics (e.g. in netstat output), output > counters are 2x more than expected. > > EXAMPLE, ftp transfer of 1 GiB file: > > ftp> put file /dev/null > local: file remote: /dev/null > 229 Entering Extended Passive Mode (|||57978|) > 150 Opening BINARY mode data connection for '/dev/null'. > 100% |***********************************| 953 MiB 390.43 MiB/s > 00:00 ETA > 226 Transfer complete. > 1000000000 bytes sent in 00:02 (390.13 MiB/s) > > Netstat on receiving side, counters are correct (for input): > > lexa@home-gw:/home/lexa# netstat -I ib1 5 > input (ib1) output > packets errs idrops bytes packets errs bytes colls > 0 0 0 0 0 0 0 0 > 13955 0 0 222688126 9027 0 1192796 0 > 48921 0 0 780832960 32129 0 4240596 0 > 0 0 0 0 0 0 80 0 > > Sum of bytes (input) is 1003521086, as expected. > > Netstat on sending size, output is 2x more: > > lexa@new-gw:/home/lexa# netstat -I ib0 5 > input (ib0) output > packets errs idrops bytes packets errs bytes colls > 1 0 0 100 0 0 0 0 > 41162 0 0 2305210 62878 0 2008325984 0 > 1 0 0 100 0 0 0 0 > > It looks like packet count is correct (13955+48921=62876, two packets > missed somewhere), while byte count is exact 2x more. Yes, this is a bug. if_obytes already gets incremented in IFQ_HANDOFF(), so the IB code doesn't need to do it again. Try the patch at www.freebsd.org/~jhb/patches/ipoib_obytes.patch I can't speak to the MTU issue though. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 15:09:25 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C648C106566B for ; Mon, 26 Mar 2012 15:09:25 +0000 (UTC) (envelope-from tretuliy2@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 97C938FC12 for ; Mon, 26 Mar 2012 15:09:25 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so7056449pbc.13 for ; Mon, 26 Mar 2012 08:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZWLppKXx+yFKxpFeU5tsvfWwyrnBcNJ2jzDYzaToVpw=; b=mjfiCb8oR1KmBJwGcgbQxlsW7hqYoFm3Xq3dhmdm72DISLlKPTX92oW6bQ7JDpBZOT rhkRGci5Hox0YYRwNH/cGRX0QeNa+rHsNL4qZYiNdRrIc9Pi1LIRrURf1oELwSGHqt64 HidKjyT3ydGKdDu2bkvTgLpTmnXvmpK1LCJaRmul2Sr4quOG+ibjkgfagM1MMErB1R9I tgYWgWeDv2jQz7IvMD9OChtGd+bCL+HdOvXg+HShQljEaxRqxuUwYqB3p+t/Do3LJ7PI jevIfKPQEV3B1z8dvbeW8TREwsAiA6MZKqmdDTxd95iSea2vMVYR6R0StxBlIlw7/IJL h+Ww== MIME-Version: 1.0 Received: by 10.68.223.33 with SMTP id qr1mr53883758pbc.47.1332774559863; Mon, 26 Mar 2012 08:09:19 -0700 (PDT) Received: by 10.143.83.8 with HTTP; Mon, 26 Mar 2012 08:09:19 -0700 (PDT) In-Reply-To: References: <8904.1332769428.5720084203749900288@ffe15.ukr.net> Date: Mon, 26 Mar 2012 18:09:19 +0300 Message-ID: From: =?KOI8-R?B?98HEyc0g9dLB2sHF1w==?= To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: The problem with MTU <1500 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2012 15:09:25 -0000 You may use this patch to ipfw http://www.freebsd.org/cgi/query-pr.cgi?pr=103454 Or you may use ng_patch netgraph node (man ng_patch(4) should give you some examples) The simpliest way to do what you want is pf rule scrub in on em0 no-df performance of all those methods you should check by youre self. From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 20:06:33 2012 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 ED55D106564A for ; Mon, 26 Mar 2012 20:06:33 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 727F78FC15 for ; Mon, 26 Mar 2012 20:06:33 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so5930970bkc.13 for ; Mon, 26 Mar 2012 13:06:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=jgwLz540mdkR/RHhnARQrr11nw15/asbnU2GLBpIBHw=; b=Nfky46FbzWnZ/O9k6rRoOU/TT+HkHZvf668F2otxBq5s1EYuRtzN37lPyNRYFzSNhf U6e0mXSoI+hli1KPrKIrvXbxBs+FX1Zm4Gf6rulkDVGGwHL5JxRHAfH0zg63pYskline VXJH0SjK2p2xA5/TrimgQk8eufgYKEIHHEgph3PO0CL1euK2GpJQyBGnabWjuyKPnIjW Oa6SHzCLUaFMdzF3ghhZwO4bOXLki97ILm30F5aRHLRWTIslIiU+lztP0tJlUW8N+EWH CkhxIXoI23copO6uk6zTzdZg8qgsIgITKiEg5m7Znaw02LaJDhzM9SH2qTjs+q/Vzz0x 0QVg== Received: by 10.204.136.220 with SMTP id s28mr9314045bkt.94.1332792392405; Mon, 26 Mar 2012 13:06:32 -0700 (PDT) Received: from [10.254.254.77] (ppp95-165-136-26.pppoe.spdop.ru. [95.165.136.26]) by mx.google.com with ESMTPS id o7sm34593707bkw.16.2012.03.26.13.06.31 (version=SSLv3 cipher=OTHER); Mon, 26 Mar 2012 13:06:31 -0700 (PDT) Message-ID: <4F70CC46.1070409@zonov.org> Date: Tue, 27 Mar 2012 00:06:30 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: =?windows-1251?Q?=C2=EB=E0=E4=E8=F1=EB=E0=E2_=CF=F0=EE=E4=E0=ED?= References: <8904.1332769428.5720084203749900288@ffe15.ukr.net> In-Reply-To: <8904.1332769428.5720084203749900288@ffe15.ukr.net> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQkWdv8kJiI1HHHhNB//WyX6tZ4MxigVLnfX3rymvEIt+ViKsNUl/4XoadizoSG6pIwVu4Cp Cc: net@freebsd.org Subject: Re: The problem with MTU <1500 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2012 20:06:34 -0000 On 26.03.2012 17:43, Âëàäèñëàâ Ïðîäàí wrote: > > Dear all! > I have two different values of uplink MTU - 1440 and 1492. > And in a local network - 1500. > In Cisco routers can be set 'set ip df 0', but I have no such router :( > What options are there for FreeBSD? sysctl net.inet.tcp.path_mtu_discovery=0 > Only use the net/tcpmssd? > Will it be possible to process both two channels of 1Gb? > > -- Andrey Zonov From owner-freebsd-net@FreeBSD.ORG Mon Mar 26 20:14:54 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6984106564A for ; Mon, 26 Mar 2012 20:14:54 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5831B8FC08 for ; Mon, 26 Mar 2012 20:14:54 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so5938471bkc.13 for ; Mon, 26 Mar 2012 13:14:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=6VYrFj06DC96eLde/NV9/sOtBonzEXHF7nXrO0Mljwk=; b=dQ0McOOITfajZtNSOLBMcmOIOlrbbtOY9+bXQq+UfZHfKHLeOhJiNE4Rajj/4kzGGI eD54HTcr0caTRv6UHVpovm846gDVRiNh7HIMffh9nIHBl9RtTRwjpbZ4lN5jiQlfkNYt HIMuxbeO9xYFrLhHr5L5nMxOJSUHA4gwVUJkWxtw0c3TVvqnqDSw8hu5HvMkJZPnAaQ4 1RCwAtPkvVMdRKkzST1QI8z8xqSW7QKNle6Ppij4oFIxGFQqpRCqwVzcc8AO9gSWcRhf 58VlMeK5C+7UEcIqdLEe7Cza4OKaoM4caKMSZTWIvEaf3xoPbT5qmbIYyLKotozEQSqS q4fA== Received: by 10.204.156.79 with SMTP id v15mr8865938bkw.37.1332792893094; Mon, 26 Mar 2012 13:14:53 -0700 (PDT) Received: from [10.254.254.77] (ppp95-165-136-26.pppoe.spdop.ru. [95.165.136.26]) by mx.google.com with ESMTPS id c4sm16784970bkh.0.2012.03.26.13.14.52 (version=SSLv3 cipher=OTHER); Mon, 26 Mar 2012 13:14:52 -0700 (PDT) Message-ID: <4F70CE3A.7050808@zonov.org> Date: Tue, 27 Mar 2012 00:14:50 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: =?windows-1251?Q?=C2=EB=E0=E4=E8=F1=EB=E0=E2_=CF=F0=EE=E4=E0=ED?= References: <8904.1332769428.5720084203749900288@ffe15.ukr.net> <4F70CC46.1070409@zonov.org> In-Reply-To: <4F70CC46.1070409@zonov.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQmfmeGj1DnOXEQz5UmUJAOwHb3haicpg832dyoyYR9ACxt4ZtNHti8k65ouoA5eCFnxTrk9 Cc: net@freebsd.org Subject: Re: The problem with MTU <1500 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 26 Mar 2012 20:14:54 -0000 On 27.03.2012 0:06, Andrey Zonov wrote: > On 26.03.2012 17:43, Âëàäèñëàâ Ïðîäàí wrote: >> >> Dear all! >> I have two different values of uplink MTU - 1440 and 1492. >> And in a local network - 1500. >> In Cisco routers can be set 'set ip df 0', but I have no such router :( >> What options are there for FreeBSD? > > sysctl net.inet.tcp.path_mtu_discovery=0 Ooops, please ignore this. > >> Only use the net/tcpmssd? >> Will it be possible to process both two channels of 1Gb? >> >> > -- Andrey Zonov From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 04:55:45 2012 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 6A116106564A for ; Tue, 27 Mar 2012 04:55:45 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 31FC48FC15 for ; Tue, 27 Mar 2012 04:55:45 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so7986034pbc.13 for ; Mon, 26 Mar 2012 21:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=or2DNgHi9x4v2mQDQ26Qv9JvnkpZpdFbgW9xE/heW84=; b=JYmWLlQ7rNXKKeY9RtjwpJG8I5YDEtFoxiBy+tGaHQ4YmmZ7R5bqMXTlMAefkL5qRT g2mExKDW205pVdRuuHRKvm/+XJWmPkMv1dDw4VS9ecBXVErWR4iJmx3Hv/+dEjcL3MPU RORPrHLKbw3i9H0Ox2lMg24c3SpJbJ/Vgul+EX84fsNO3yWDdQ2P2K4+dIZFkZl53fKi huoaK9JGaKC8ODE0GqJLG0jQsAqt01ebYfpcXXccDEXHOz5fxYySBwN/twSCpk61yKqm 5884ByiQx4ct//IYxu3nrtts58C9lAhfWUK+dc2rWT2lELBEGErD6PPDIzO4joYXtSF3 xt7w== Received: by 10.68.219.34 with SMTP id pl2mr58768473pbc.56.1332824144577; Mon, 26 Mar 2012 21:55:44 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id d4sm14035159pbe.36.2012.03.26.21.55.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Mar 2012 21:55:43 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 27 Mar 2012 13:55:40 -0700 From: YongHyeon PYUN Date: Tue, 27 Mar 2012 13:55:40 -0700 To: Andreas Longwitz Message-ID: <20120327205540.GA9298@michelle.cdnetworks.com> References: <4F594856.3030303@incore.de> <20120312211907.GC3671@michelle.cdnetworks.com> <4F5E0AF7.30302@incore.de> <20120313202559.GA3360@michelle.cdnetworks.com> <4F66646E.4080603@incore.de> <20120320041647.GE7518@michelle.cdnetworks.com> <4F6DA161.9040408@incore.de> <20120326003016.GA1435@michelle.cdnetworks.com> <4F707F39.9080204@incore.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <4F707F39.9080204@incore.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Intel 82550 Pro/100 Ethernet and Microcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 04:55:45 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Mar 26, 2012 at 04:37:45PM +0200, Andreas Longwitz wrote: > YongHyeon PYUN wrote: > > > > I've attached a patch which will show both compatibility and EEPROM > > ID word and allowed loading microcode for 82550 family. Let me > > know whether this patch works for you. > > Yes, the patch workes fine and I have for my LOM's (rev 0x0d): > > fxp0: port .... > fxp0: Compatibility word : 0X0d13 > fxp0: EEPROM ID word : 0X5060 > > and for two external cards (rev 0x0c) I see > > fxp1: port ... > fxp1: Compatibility word : 0X040b > fxp1: EEPROM ID word : 0X58a0 > fxp2: port ... > fxp2: Compatibility word : 0X020b > fxp2: EEPROM ID word : 0X50a0 > Thanks a lot! Here is final version. The patch checks whether the controller is i82550C with server extension. If driver see server NIC like yours it would allow microcode loading. I guess later 82550C controllers fixed the bug since mine has no problems to handle fragmented UDP datagrams. > > I vaguely guess there are > > differences between LOM and non-LOM implementation(Mine is > > stand-alone PCI NIC). I would be able to selectively allow > > microcode loading after getting compatibility/EEPROM ID word. > > Thank you for investigating in this problem. > > Regards > > Andreas Longwitz > --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="fxp.82550.microcode.diff2" Index: sys/dev/fxp/if_fxpvar.h =================================================================== --- sys/dev/fxp/if_fxpvar.h (revision 233418) +++ sys/dev/fxp/if_fxpvar.h (working copy) @@ -236,6 +236,7 @@ #define FXP_FLAG_WOLCAP 0x2000 /* WOL capability */ #define FXP_FLAG_WOL 0x4000 /* WOL active */ #define FXP_FLAG_RXBUG 0x8000 /* Rx lock-up bug */ +#define FXP_FLAG_NO_UCODE 0x10000 /* ucode is not applicable */ /* Macros to ease CSR access. */ #define CSR_READ_1(sc, reg) bus_read_1(sc->fxp_res[0], reg) Index: sys/dev/fxp/if_fxp.c =================================================================== --- sys/dev/fxp/if_fxp.c (revision 233418) +++ sys/dev/fxp/if_fxp.c (working copy) @@ -194,7 +194,7 @@ { 0x1229, 0x08, 0, "Intel 82559 Pro/100 Ethernet" }, { 0x1229, 0x09, 0, "Intel 82559ER Pro/100 Ethernet" }, { 0x1229, 0x0c, 0, "Intel 82550 Pro/100 Ethernet" }, - { 0x1229, 0x0d, 0, "Intel 82550 Pro/100 Ethernet" }, + { 0x1229, 0x0d, 0, "Intel 82550C Pro/100 Ethernet" }, { 0x1229, 0x0e, 0, "Intel 82550 Pro/100 Ethernet" }, { 0x1229, 0x0f, 0, "Intel 82551 Pro/100 Ethernet" }, { 0x1229, 0x10, 0, "Intel 82551 Pro/100 Ethernet" }, @@ -525,6 +525,18 @@ sc->flags |= FXP_FLAG_WOLCAP; } + if (sc->revision == FXP_REV_82550_C) { + /* + * 82550C with server extension requires microcode to + * receive fragmented UDP datagrams. However if the + * microcode is used for client-only featured 82550C + * it locks up controller. + */ + fxp_read_eeprom(sc, &data, 3, 1); + if ((data & 0x0400) == 0) + sc->flags |= FXP_FLAG_NO_UCODE; + } + /* Receiver lock-up workaround detection. */ if (sc->revision < FXP_REV_82558_A4) { fxp_read_eeprom(sc, &data, 3, 1); @@ -3014,10 +3026,8 @@ static uint32_t fxp_ucode_d101b0[] = D101_B0_RCVBUNDLE_UCODE; static uint32_t fxp_ucode_d101ma[] = D101M_B_RCVBUNDLE_UCODE; static uint32_t fxp_ucode_d101s[] = D101S_RCVBUNDLE_UCODE; -#ifdef notyet static uint32_t fxp_ucode_d102[] = D102_B_RCVBUNDLE_UCODE; static uint32_t fxp_ucode_d102c[] = D102_C_RCVBUNDLE_UCODE; -#endif static uint32_t fxp_ucode_d102e[] = D102_E_RCVBUNDLE_UCODE; #define UCODE(x) x, sizeof(x)/sizeof(uint32_t) @@ -3035,12 +3045,10 @@ D101M_CPUSAVER_DWORD, D101M_CPUSAVER_BUNDLE_MAX_DWORD }, { FXP_REV_82559S_A, UCODE(fxp_ucode_d101s), D101S_CPUSAVER_DWORD, D101S_CPUSAVER_BUNDLE_MAX_DWORD }, -#ifdef notyet { FXP_REV_82550, UCODE(fxp_ucode_d102), D102_B_CPUSAVER_DWORD, D102_B_CPUSAVER_BUNDLE_MAX_DWORD }, { FXP_REV_82550_C, UCODE(fxp_ucode_d102c), D102_C_CPUSAVER_DWORD, D102_C_CPUSAVER_BUNDLE_MAX_DWORD }, -#endif { FXP_REV_82551_F, UCODE(fxp_ucode_d102e), D102_E_CPUSAVER_DWORD, D102_E_CPUSAVER_BUNDLE_MAX_DWORD }, { FXP_REV_82551_10, UCODE(fxp_ucode_d102e), @@ -3055,6 +3063,9 @@ struct fxp_cb_ucode *cbp; int i; + if (sc->flags & FXP_FLAG_NO_UCODE) + return; + for (uc = ucode_table; uc->ucode != NULL; uc++) if (sc->revision == uc->revision) break; @@ -3087,6 +3098,7 @@ sc->tunable_int_delay, uc->bundle_max_offset == 0 ? 0 : sc->tunable_bundle_max); sc->flags |= FXP_FLAG_UCODE; + bzero(cbp, FXP_TXCB_SZ); } #define FXP_SYSCTL_STAT_ADD(c, h, n, p, d) \ --3MwIy2ne0vdjdPXF-- From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 13:30:03 2012 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 2E287106564A for ; Tue, 27 Mar 2012 13:30:03 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) by mx1.freebsd.org (Postfix) with ESMTP id D11908FC0C for ; Tue, 27 Mar 2012 13:30:02 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 71D045D5B0; Tue, 27 Mar 2012 15:21:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id 30fhIKKIw1lv; Tue, 27 Mar 2012 15:21:43 +0200 (CEST) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id CE9F35D5AF; Tue, 27 Mar 2012 15:21:43 +0200 (CEST) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.incore (Postfix) with ESMTP id BED91450AA; Tue, 27 Mar 2012 15:21:43 +0200 (CEST) Message-ID: <4F71BEE7.9080709@incore.de> Date: Tue, 27 Mar 2012 15:21:43 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F594856.3030303@incore.de> <20120312211907.GC3671@michelle.cdnetworks.com> <4F5E0AF7.30302@incore.de> <20120313202559.GA3360@michelle.cdnetworks.com> <4F66646E.4080603@incore.de> <20120320041647.GE7518@michelle.cdnetworks.com> <4F6DA161.9040408@incore.de> <20120326003016.GA1435@michelle.cdnetworks.com> <4F707F39.9080204@incore.de> <20120327205540.GA9298@michelle.cdnetworks.com> In-Reply-To: <20120327205540.GA9298@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Intel 82550 Pro/100 Ethernet and Microcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Mar 2012 13:30:03 -0000 YongHyeon PYUN wrote: > Thanks a lot! Here is final version. The patch checks whether > the controller is i82550C with server extension. If driver see > server NIC like yours it would allow microcode loading. > I guess later 82550C controllers fixed the bug since mine has no > problems to handle fragmented UDP datagrams. Ok, your final patch workes as expected, all my fxp's can load microcode and run without hangs od SCB timeouts. I think the PR's kern/103332 and kern/118909 can be closed now. Thank you again for investigate in this problem. Andreas Longwitz From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 16:58:05 2012 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 7B930106564A; Tue, 27 Mar 2012 16:58:05 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id DFE2F8FC16; Tue, 27 Mar 2012 16:58:04 +0000 (UTC) Received: by wern13 with SMTP id n13so98428wer.13 for ; Tue, 27 Mar 2012 09:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=i9vGKf1+iFQH/2zeDDxaMUzNCEp4FakeR56J+UdlTyk=; b=pkCGCYzoHblDyQN8vIO4b0vc8rO7QdOY2c8KXV86+Mu9TmmdNpeZOQ0dGc3j5z3OWG fKQd77n5yTW/IWY0+R7ravYHJcrUd7FlQpUz4OrhXkL2XiE9nHabNEMagnbGwzJlbtdy AtGIxw08tG1v2GKDbxEeB+RPKrJHzTXDKENgXWfQw929q/a0UdFbt8pxGCA4hAI7ZRpU H7EQqbCvl5LEUfms+Njfs1uEzfJNp+BvxlS2wikjFK6KJRpvOcSKSMX2AguF9PdtgM5I 8kzNlIHADwEWrjyr3qY4z+np6qWVWC4ogAJxMV0/EFmgzULlWdnGPajtk0KVOrARJZe3 +dhw== MIME-Version: 1.0 Received: by 10.180.101.231 with SMTP id fj7mr29262976wib.15.1332867483831; Tue, 27 Mar 2012 09:58:03 -0700 (PDT) Received: by 10.216.225.207 with HTTP; Tue, 27 Mar 2012 09:58:03 -0700 (PDT) Date: Tue, 27 Mar 2012 12:58:03 -0400 Message-ID: From: Arnaud Lacombe To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net Subject: Netgraph message size limitation. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Mar 2012 16:58:05 -0000 Hi Julian, In `sys/netgraph/ng_base.c', there is the following: static int ng_generic_msg(node_p here, item_p item, hook_p lasthook) { case NGM_BINARY2ASCII: { int bufSize = 20 * 1024; /* XXX hard coded constant */ [...] case NGM_ASCII2BINARY: { int bufSize = 2000; /* XXX hard coded constant */ I put on the side the reasoning behind archie@ bump of one value and not the other 12 years ago. What I would like to know is why use harcoded, undocumented, limits. It seems to me that there is no way the code can do anything clever at this point wrt. size of the data coming in or out. All the allocation and buffer management should be done by the parser. If my type specify a 512 32bits array, I should be to pass this array. Thought ? Thanks, - Arnaud From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 17:01:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6FA41065673 for ; Tue, 27 Mar 2012 17:01:15 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (unknown [IPv6:2001:b70:201:2::22]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBF08FC15 for ; Tue, 27 Mar 2012 17:01:15 +0000 (UTC) Received: from [172.16.11.44] (unknown [91.208.177.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 044A72285C; Tue, 27 Mar 2012 17:01:13 +0000 (UTC) Message-ID: <4F71F254.3040302@rewt.org.uk> Date: Tue, 27 Mar 2012 18:01:08 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4F64AB3B.9030806@rewt.org.uk> <20120319214744.GC7518@michelle.cdnetworks.com> <4F6B061F.9050403@rewt.org.uk> <4F6B7892.6090805@rewt.org.uk> <20120325225640.GA4493@michelle.cdnetworks.com> In-Reply-To: <20120325225640.GA4493@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: msk/Yukon issues since 9.0-REL X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Mar 2012 17:01:15 -0000 YongHyeon PYUN wrote: > On Thu, Mar 22, 2012 at 07:08:02PM +0000, Joe Holden wrote: >> Joe Holden wrote: >>> YongHyeon PYUN wrote: >>>> On Sat, Mar 17, 2012 at 03:18:19PM +0000, Joe Holden wrote: >>>>> Hi guys, >>>>> >>>>> I've upgraded to 9.0-REL from RC3 (I think) and the previous >>>>> workarounds I've used for msk/Yukon II problems don't seem to work >>>>> anymore: >>>>> >>>>> rc.conf: >>>>> ifconfig_msk0="inet 192.168.201.2/30 -lro -tso -vlanhwfilter -vlanhwtag" >>>>> >>>> msk(4) does not support VLAN hardware filter and LRO. However I >>>> don't understand how this affects stability of driver. >>>> >>>>> pciconf: >>>>> mskc0@pci0:7:0:0: class=0x020000 card=0x81e6104d >>>>> chip=0x435111ab rev=0x15 hdr=0x00 >>>>> vendor = 'Marvell Technology Group Ltd.' >>>>> device = '88E8036 PCI-E Fast Ethernet Controller' >>>>> class = network >>>>> subclass = ethernet >>>>> >>>>> I seem to get the usual error: >>>>> msk0: watchdog timeout >>>>> msk0: prefetch unit stuck? >>>>> msk0: initialization failed: no memory for Rx buffers >>>>> >>>> There was a related change after 9.0-RELEASE. The change already >>>> merged to stable/9(r229874) So would you try latest stable/9 or >>>> apply the change to 9.0-RELEASE? >>>> http://svnweb.freebsd.org/base/stable/9/sys/dev/msk/if_msk.c?r1=229524&r2=229874&view=patch >>>> >>>> >>> Well that's cute.... reboot during boot, no panic or errors on the >>> console ... >>> >>>>> MSI(-X) is disabled but it doesn't seem to make any difference.... >>>>> >>>>> Is there anything I can try to either debug or "fix" it? >>>>> >>>> If you've upgraded from somewhat old FreeBSD releases, make sure to >>>> cold boot your box(i.e. completely remove power cord for several >>>> minutes before booting). >>>> >>>>> Thanks, >>>>> J >> Ok so after removing sound from GENERIC it boots but the problem still > > Not sure how audio devices can affect msk(4). > Unrelated, when the HDA device was probed it caused a reset/panic - but nothing to do with msk This wasn't present in RC3 though, hence my comment about regressions >> occurs - the flags I used before did work (whether some didn't have any > > msk(4) had a long standing bug for some Yukon controllers that use > 88E1149 PHY. The bug showed various problems depending on PHY > configuration. See r222219 for more details. Due to unknown reason > GPHY configuration is preserved until it's cold-booted. > >> effect I don't know, but once I found a combination that prevented the >> problem I left it at that) >> >> Rather a concerning amount of regressions in 9... >> >> Thanks, >> J >> >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 17:26:13 2012 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 492CF106566B for ; Tue, 27 Mar 2012 17:26:13 +0000 (UTC) (envelope-from adarsh.joshi@qlogic.com) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by mx1.freebsd.org (Postfix) with ESMTP id 92D8C8FC0A for ; Tue, 27 Mar 2012 17:26:11 +0000 (UTC) Received: from mail31-db3-R.bigfish.com (10.3.81.253) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Mar 2012 16:55:42 +0000 Received: from mail31-db3 (localhost [127.0.0.1]) by mail31-db3-R.bigfish.com (Postfix) with ESMTP id AAB232C03E5 for ; Tue, 27 Mar 2012 16:55:41 +0000 (UTC) X-SpamScore: 1 X-BigFish: PS1(zzc85fhzz1202hzz8275bh8275dhz2ei2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:198.70.193.64; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub2.qlogic.com; EFVD:NLI Received-SPF: neutral (mail31-db3: 198.70.193.64 is neither permitted nor denied by domain of qlogic.com) client-ip=198.70.193.64; envelope-from=adarsh.joshi@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail31-db3 (localhost.localdomain [127.0.0.1]) by mail31-db3 (MessageSwitch) id 1332867337970697_13145; Tue, 27 Mar 2012 16:55:37 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.235]) by mail31-db3.bigfish.com (Postfix) with ESMTP id E946CA0109 for ; Tue, 27 Mar 2012 16:55:37 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.64) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Mar 2012 16:55:37 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub2.qlogic.org ([::1]) with mapi; Tue, 27 Mar 2012 09:55:48 -0700 From: Adarsh Joshi To: "freebsd-net@freebsd.org" Date: Tue, 27 Mar 2012 09:55:45 -0700 Thread-Topic: bus width and PCIe version Thread-Index: Ac0MOFcyLgzQRR2aTyGKUMeNbXlmqA== Message-ID: <5E4F49720D0BAD499EE1F01232234BA8743824C2AD@AVEXMB1.qlogic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: bus width and PCIe version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Mar 2012 17:26:13 -0000 Hello, Is there a command or log message where I can find out the bus width and PC= Ie version number on which my adapter is put on? I did take a look at pciconf and devinfo and also the dmesg logs but could = not find anything. I know it is visible on lspci on linux systems. Thanks Adarsh ________________________________ This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 18:33:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4194F106566B for ; Tue, 27 Mar 2012 18:33:26 +0000 (UTC) (envelope-from adarsh.joshi@qlogic.com) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by mx1.freebsd.org (Postfix) with ESMTP id E12568FC08 for ; Tue, 27 Mar 2012 18:33:25 +0000 (UTC) Received: from mail19-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Mar 2012 18:02:54 +0000 Received: from mail19-tx2 (localhost [127.0.0.1]) by mail19-tx2-R.bigfish.com (Postfix) with ESMTP id C2588400220; Tue, 27 Mar 2012 18:02:53 +0000 (UTC) X-SpamScore: -8 X-BigFish: PS-8(zz9371I542M98dKzz1202hzz8275dhz2ei2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:198.70.193.64; KIP:(null); UIP:(null); IPV:NLI; H:avexcashub1.qlogic.com; RD:avexcashub2.qlogic.com; EFVD:NLI Received-SPF: neutral (mail19-tx2: 198.70.193.64 is neither permitted nor denied by domain of qlogic.com) client-ip=198.70.193.64; envelope-from=adarsh.joshi@qlogic.com; helo=avexcashub1.qlogic.com ; 1.qlogic.com ; Received: from mail19-tx2 (localhost.localdomain [127.0.0.1]) by mail19-tx2 (MessageSwitch) id 1332871370955208_26803; Tue, 27 Mar 2012 18:02:50 +0000 (UTC) Received: from TX2EHSMHS017.bigfish.com (unknown [10.9.14.239]) by mail19-tx2.bigfish.com (Postfix) with ESMTP id E2D6D1C021B; Tue, 27 Mar 2012 18:02:50 +0000 (UTC) Received: from avexcashub1.qlogic.com (198.70.193.64) by TX2EHSMHS017.bigfish.com (10.9.99.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Mar 2012 18:02:48 +0000 Received: from avexmb1.qlogic.org ([fe80::9545:3a4f:c131:467d]) by avexcashub2.qlogic.org ([::1]) with mapi; Tue, 27 Mar 2012 11:03:01 -0700 From: Adarsh Joshi To: Chuck Swiger Date: Tue, 27 Mar 2012 11:02:59 -0700 Thread-Topic: bus width and PCIe version Thread-Index: Ac0MP1mHBeF8F05JQPqdnwtPby/JmgABDj/g Message-ID: <5E4F49720D0BAD499EE1F01232234BA8743824C2E5@AVEXMB1.qlogic.org> References: <5E4F49720D0BAD499EE1F01232234BA8743824C2AD@AVEXMB1.qlogic.org> <6944EDD3-53F4-4182-AA57-AF76787E94FA@mac.com> In-Reply-To: <6944EDD3-53F4-4182-AA57-AF76787E94FA@mac.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: qlogic.com Cc: "freebsd-net@freebsd.org" Subject: RE: bus width and PCIe version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Mar 2012 18:33:26 -0000 Thanks Chuck. For some reason, it says . Looks like a bug. I found a bug fil= ed for the same reason on Linux. Handle 0x0900, DMI type 9, 17 bytes System Slot Information Designation: PCI1 Type: x16 Current Usage: In Use Length: Long Characteristics: 3.3 V is provided PME signal is supported Bus Address: 0000:01:00.0 Adarsh -----Original Message----- From: Chuck Swiger [mailto:cswiger@mac.com] Sent: Tuesday, March 27, 2012 10:31 AM To: Adarsh Joshi Cc: freebsd-net@freebsd.org Subject: Re: bus width and PCIe version On Mar 27, 2012, at 9:55 AM, Adarsh Joshi wrote: > Is there a command or log message where I can find out the bus width and = PCIe version number on which my adapter is put on? There's a dmidecode utility in the ports which should be able to figure out= that info, IIRC. Regards, -- -Chuck This message and any attached documents contain information from QLogic Cor= poration or its wholly-owned subsidiaries that may be confidential. If you = are not the intended recipient, you may not read, copy, distribute, or use = this information. If you have received this transmission in error, please n= otify the sender immediately by reply e-mail and then delete this message. From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 20:37:01 2012 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 7230D1065675; Tue, 27 Mar 2012 20:37:01 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id CCD008FC1C; Tue, 27 Mar 2012 20:37:00 +0000 (UTC) Received: by wern13 with SMTP id n13so268288wer.13 for ; Tue, 27 Mar 2012 13:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=y1I8nrE0fIu+zb3DZRR2VT2+RDbOjAV/wlNzoj1L3xk=; b=wMtJnnKuPqV8pP8B1RBY+taZVvAnA6LCB2eqOCIW42WgkPavhV8UPQjbGG1k1kTtCO fpdCqizDThmBtnu3jUCF+KGfq6A1ZUucUnrW1Qv7IuPWDy0Mvl/Cl10LeC2VySeQ4aXT 916eGE7OXmaFsO/3Ok57wsl8MPTVRPifYSw2N9Nz8yuXdaO0Fp7pJma2HiL7AEQmFNkz iZ23WKHReiF/oYfuC8GwNnDpO4oMs+6AxWbQchY4UYLNByktxbt1d0a8V0ZAGGqwayj1 vcOv9dyq0P+QEFwEvqjQn9a+rxskHPvPgv7IZTOF4TPPev3lCXG8Jw9pMUWI+IZIZ/nb vWHQ== MIME-Version: 1.0 Received: by 10.216.205.93 with SMTP id i71mr15356884weo.51.1332880619250; Tue, 27 Mar 2012 13:36:59 -0700 (PDT) Received: by 10.180.79.137 with HTTP; Tue, 27 Mar 2012 13:36:59 -0700 (PDT) In-Reply-To: <201203090930.q299UCPX057950@freefall.freebsd.org> References: <201203090930.q299UCPX057950@freefall.freebsd.org> Date: Tue, 27 Mar 2012 16:36:59 -0400 Message-ID: From: Ryan Stone To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: kern/165863 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Mar 2012 20:37:01 -0000 On Fri, Mar 9, 2012 at 4:30 AM, Gleb Smirnoff wrote: > The following reply was made to PR kern/165863; it has been noted by GNAT= S. > > From: Gleb Smirnoff > To: Eric van Gyzen , > =A0 =A0 =A0 =A0Eric van Gyzen , emaste@FreeBSD.org > Cc: bug-followup@FreeBSD.org > Subject: kern/165863 > Date: Fri, 9 Mar 2012 13:20:56 +0400 > > =A0--BXVAT5kNtrzKuDFl > =A0Content-Type: text/plain; charset=3Dkoi8-r > =A0Content-Disposition: inline > > =A0 Hello, Eric and Ed. > > =A0 Can you look at this patch? I decided to utilize newer callout API, > =A0that allows to delegate lock retrieval to the callout subsystem, and > =A0this makes things simplier. Hope that should work. > > =A0 Patch is against head. > > =A0 Eric, can you please send me your test programs, that you use to > =A0reproduce the bug? I tested this patch today on head and 8.2-RELEASE. I was unable to reproduce any crashes, whereas before I could crash the system within minutes. However it appears that in6_lltable_prefix_free is similarly broken. The only saving grace is that there does not appear to be a code path that can actually call it. From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 21:08:46 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5997B106564A for ; Tue, 27 Mar 2012 21:08:46 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp04.sth.basefarm.net (ch-smtp04.sth.basefarm.net [80.76.153.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0AD608FC08 for ; Tue, 27 Mar 2012 21:08:45 +0000 (UTC) Received: from c83-253-236-121.bredband.comhem.se ([83.253.236.121]:35513 helo=falcon.midgard.homeip.net) by ch-smtp04.sth.basefarm.net with esmtp (Exim 4.76) (envelope-from ) id 1SCdcv-0002Ny-FE for freebsd-net@freebsd.org; Tue, 27 Mar 2012 23:08:27 +0200 Received: (qmail 37885 invoked from network); 27 Mar 2012 23:08:18 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 27 Mar 2012 23:08:18 +0200 Received: (qmail 10506 invoked by uid 1001); 27 Mar 2012 23:08:18 +0200 Date: Tue, 27 Mar 2012 23:08:18 +0200 From: Erik Trulsson To: Adarsh Joshi Message-ID: <20120327210818.GA10492@owl.midgard.homeip.net> References: <5E4F49720D0BAD499EE1F01232234BA8743824C2AD@AVEXMB1.qlogic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E4F49720D0BAD499EE1F01232234BA8743824C2AD@AVEXMB1.qlogic.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: 83.253.236.121 X-Scan-Result: No virus found in message 1SCdcv-0002Ny-FE. X-Scan-Signature: ch-smtp04.sth.basefarm.net 1SCdcv-0002Ny-FE b315624c31ec491c8ce7e4a52592f43e Cc: "freebsd-net@freebsd.org" Subject: Re: bus width and PCIe version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Mar 2012 21:08:46 -0000 On Tue, Mar 27, 2012 at 09:55:45AM -0700, Adarsh Joshi wrote: > Hello, > > Is there a command or log message where I can find out the bus width and PCIe version number on which my adapter is put on? > > I did take a look at pciconf and devinfo and also the dmesg logs but could not find anything. > > I know it is visible on lspci on linux systems. You can use lspci on FreeBSD as well. It is included in the sysutils/pciutils port. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 21:14:46 2012 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 74A9D106564A for ; Tue, 27 Mar 2012 21:14:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 006478FC14 for ; Tue, 27 Mar 2012 21:14:45 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so260061wib.13 for ; Tue, 27 Mar 2012 14:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LoXTr4luLF7jtVZrvOBWClyHclHDPMZZUBkvsqcBvyM=; b=iaccjbZ7AjJGOACwFBvGOjktCh3uyIcKLgB8iE5LzXMLleE8/gmqImreL+/bOo4qty TIN6SdsaNKSK3rKesqcyNPF6NJ2GGbP+2CZrR7TVjuepiNb1Pihm97+ELg7r1gLq3DBZ L/l5sMrn6HPIvyP5rA5QsJ6roRqlvtaAMoy0xbab0xd7sasSuFCc1Y0GQcDMauX1oc+Z 0SyBujHjT7bDecBtDn6OPrJD6zZzQ40ofTPzcuxH5awFpW2HoWPSh4l8GmaJZo+JgQh0 BnONLjwrN4ChdCMb423SuxeoXxN+njQPMzYy0HyIiv2E4tRsgGrYQ03mhJjyrDViUphK x6Sw== MIME-Version: 1.0 Received: by 10.180.82.132 with SMTP id i4mr1138178wiy.12.1332882877767; Tue, 27 Mar 2012 14:14:37 -0700 (PDT) Received: by 10.180.82.168 with HTTP; Tue, 27 Mar 2012 14:14:37 -0700 (PDT) In-Reply-To: <20120327210818.GA10492@owl.midgard.homeip.net> References: <5E4F49720D0BAD499EE1F01232234BA8743824C2AD@AVEXMB1.qlogic.org> <20120327210818.GA10492@owl.midgard.homeip.net> Date: Tue, 27 Mar 2012 14:14:37 -0700 Message-ID: From: Jack Vogel To: Erik Trulsson Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Adarsh Joshi Subject: Re: bus width and PCIe version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Mar 2012 21:14:46 -0000 I'm pretty sure that pciconf can give you this information, but you need to use the right flags, not to mention that you look at the correct device. Some drivers, like ixgbe, will report this information to you when loading. Jack On Tue, Mar 27, 2012 at 2:08 PM, Erik Trulsson wrote: > On Tue, Mar 27, 2012 at 09:55:45AM -0700, Adarsh Joshi wrote: > > Hello, > > > > Is there a command or log message where I can find out the bus width and > PCIe version number on which my adapter is put on? > > > > I did take a look at pciconf and devinfo and also the dmesg logs but > could not find anything. > > > > I know it is visible on lspci on linux systems. > > > You can use lspci on FreeBSD as well. It is included in the > sysutils/pciutils port. > > > > -- > > Erik Trulsson > ertr1013@student.uu.se > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 21:20:47 2012 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 9B1A9106566B for ; Tue, 27 Mar 2012 21:20:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5F9398FC21 for ; Tue, 27 Mar 2012 21:20:47 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q2RLJ8Kf065262 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 27 Mar 2012 14:19:09 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4F722EE7.50102@freebsd.org> Date: Tue, 27 Mar 2012 14:19:35 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Arnaud Lacombe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Netgraph message size limitation. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Mar 2012 21:20:47 -0000 On 3/27/12 9:58 AM, Arnaud Lacombe wrote: > Hi Julian, > > In `sys/netgraph/ng_base.c', there is the following: > > static int > ng_generic_msg(node_p here, item_p item, hook_p lasthook) > { > case NGM_BINARY2ASCII: > { > int bufSize = 20 * 1024; /* XXX hard coded constant */ > [...] > case NGM_ASCII2BINARY: > { > int bufSize = 2000; /* XXX hard coded constant */ > > I put on the side the reasoning behind archie@ bump of one value and > not the other 12 years ago. What I would like to know is why use > harcoded, undocumented, limits. It seems to me that there is no way > the code can do anything clever at this point wrt. size of the data > coming in or out. All the allocation and buffer management should be > done by the parser. If my type specify a 512 32bits array, I should be > to pass this array. Thought ? I have no real thoughts because Archie did the parser and I didn't really touch it. However given that Netgraph was written for a specific set of jobs and that since then people seem to have found all sorts of other things to do with it, it is quite possible that we should revisit these limits. regardless, they should probably be in the documentation.. I hope to get back to BSD work one of these years.. Until then, "patches accepted".. > Thanks, > - Arnaud > From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 21:39:10 2012 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 466E01065670 for ; Tue, 27 Mar 2012 21:39:10 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id EFF1F8FC14 for ; Tue, 27 Mar 2012 21:39:09 +0000 (UTC) Received: by vbmv11 with SMTP id v11so387548vbm.13 for ; Tue, 27 Mar 2012 14:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6y2th+n0qF7nPgTpBXE+ZTInzLBKgjm61q0+Q3+JXP8=; b=QfRm+eFdjLEX25GUrLruOcLpKwu54lOGylHiGRufUR3leZQ/JHLRaGpJco3xdr56qC 28fMHV9PrLnPdLO+hjIE844knWw9MLqDBU6uLrVEIrGTeCyhAmJn3jYxip1xclYFeAAi xzgixgv1xpc2095RSwDpyh1AaktqLqZOahkUna87ld5yQ9vpO1zgMp6bKyoch9cOqDWE 2i4RwQvD2007AH0Az+v3dnBIli+5JStPiTTSxNEthrkMqv8c8opmqRJXDh9qUeFrz7/S ziLn2D+YO+2l4TVfYIWDNG0sQd+3v6DwG0wbT6KHROSPorOPwnkHvWZ/3fTjhDRXAu0k KLpg== MIME-Version: 1.0 Received: by 10.52.90.20 with SMTP id bs20mr10542172vdb.98.1332884348929; Tue, 27 Mar 2012 14:39:08 -0700 (PDT) Received: by 10.220.198.138 with HTTP; Tue, 27 Mar 2012 14:39:08 -0700 (PDT) In-Reply-To: References: <5E4F49720D0BAD499EE1F01232234BA8743824C2AD@AVEXMB1.qlogic.org> <20120327210818.GA10492@owl.midgard.homeip.net> Date: Tue, 27 Mar 2012 14:39:08 -0700 Message-ID: From: Freddie Cash To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: bus width and PCIe version X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Mar 2012 21:39:10 -0000 On Tue, Mar 27, 2012 at 2:14 PM, Jack Vogel wrote: > I'm pretty sure that pciconf can give you this information, but you need to > use the right flags, not to mention that you look at the correct device. Yeah, it does: # pciconf -lc ... igb1@pci0:2:0:1: class=0x020000 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 128(512) link x4(x4) ... mps1@pci0:3:0:0: class=0x010700 card=0x040015d9 chip=0x00721000 rev=0x03 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' class = mass storage subclass = SAS cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[68] = PCI-Express 2 endpoint max data 128(4096) link x8(x8) cap 03[d0] = VPD cap 05[a8] = MSI supports 1 message, 64 bit cap 11[c0] = MSI-X supports 15 messages in map 0x14 enabled ... -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 21:40:10 2012 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 B94BC106564A for ; Tue, 27 Mar 2012 21:40:10 +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 A05168FC1C for ; Tue, 27 Mar 2012 21:40:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2RLeAr5076789 for ; Tue, 27 Mar 2012 21:40:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2RLeAeg076788; Tue, 27 Mar 2012 21:40:10 GMT (envelope-from gnats) Date: Tue, 27 Mar 2012 21:40:10 GMT Message-Id: <201203272140.q2RLeAeg076788@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Ryan Stone Cc: Subject: Re: kern/165863 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ryan Stone List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:40:10 -0000 The following reply was made to PR kern/165863; it has been noted by GNATS. From: Ryan Stone To: Eric van Gyzen Cc: Gleb Smirnoff , Eric van Gyzen , emaste@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/165863 Date: Tue, 27 Mar 2012 17:24:37 -0400 2012/3/9 Eric van Gyzen : > On 03/09/12 03:20, Gleb Smirnoff wrote: >> >> =A0 Hello, Eric and Ed. >> >> =A0 Can you look at this patch? I decided to utilize newer callout API, >> that allows to delegate lock retrieval to the callout subsystem, and >> this makes things simplier. Hope that should work. >> >> =A0 Patch is against head. > > > Doesn't arptimer() still need to acquire the if_afdata_lock in order to f= ree > the entry in the normal case (when the llentry is still in the hash bucke= t > list)? Oops, on reviewing the code I believe that this is correct. My test case wouldn't have had arp entries timing out so I wouldn't have hit this case. I'll try to come up with a test case for this. Unfortunately it's not as quite as simple just acquiring if_afdata_lock because of lock ordering problems. I think that we'll have to revert the usage of callout_init_rw so that arptimer can acquire the if_afdata_lock before acquiring the lock LLE_LOCK. From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 22:13:44 2012 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 42878106564A for ; Tue, 27 Mar 2012 22:13:44 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C671D8FC14 for ; Tue, 27 Mar 2012 22:13:43 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so507583bkc.13 for ; Tue, 27 Mar 2012 15:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=uipGjIbfquNmqmnTowCEwI/O0/j4pSd0YogWGVwiurQ=; b=Gw52KI1gy1CpWaQ8uSm4GNGlrUO5E4z70v5Icd7rqU0Zmi0663t/LN/mPUfgDW/Yg6 2gebqegzbyK0UGtVfahIn6zM7xMY+MkaJ7DR+KTiLd4ZUW9k1RP63f4JCBNOxSDivS6U KfeVAGJ3kCzAsWOvZ9V+kYCxqKTG6E5oi8LytvVnBdOPawkMoScUXwQR/J8ZYSxaR+1s e50y/kP6VqxPnPBtXdQIcu0MvQfS8IvLAByV/3KTWBOo5teIDQX4YwDF+9jMoqm0QrKe ONtirwrnC4lehtkPY4vELlWmqQtwFGXzRbHjKpSLjHk/zOWCOF65DOuivGG98xLzWA2N qpAg== MIME-Version: 1.0 Received: by 10.204.10.91 with SMTP id o27mr4607216bko.5.1332886422507; Tue, 27 Mar 2012 15:13:42 -0700 (PDT) Sender: nparhar@gmail.com Received: by 10.204.202.70 with HTTP; Tue, 27 Mar 2012 15:13:42 -0700 (PDT) Date: Tue, 27 Mar 2012 15:13:42 -0700 X-Google-Sender-Auth: Ja8TNfQo5gVyNhB0cwe52ddrkmk Message-ID: From: Navdeep Parhar To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: seq# of RST in tcp_dropwithreset X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 27 Mar 2012 22:13:44 -0000 When the kernel decides to respond with a RST to an incoming TCP segment, it uses its ack# (if valid) as the seq# of the RST. See this in tcp_dropwithreset: if (th->th_flags & TH_ACK) { tcp_respond(tp, mtod(m, void *), th, m, (tcp_seq)0, th->th_ack, TH_RST); } else { if (th->th_flags & TH_SYN) tlen++; tcp_respond(tp, mtod(m, void *), th, m, th->th_seq+tlen, (tcp_seq)0, TH_RST|TH_ACK); } This can have some unexpected results. I observed this on a link with a very high delay (B is FreeBSD, A could be anything). 1. There is a segment in flight from A to B. The ack# is X (all tx from B to A is up to date and acknowledged). 2. socket is closed on B. B sends a FIN with seq# X. 3. The segment from A arrives and elicits a RST from B. The seq# of this RST will again be X. A receives the FIN and then the RST with identical sequence numbers. The situation resolves itself eventually, when A retransmits and the retransmitted segment ACKs the FIN too and so the next time around B sends a RST with the "correct" seq# (one after the FIN). If there is a local tcpcb for the connection with state >= ESTABLISHED, wouldn't it be more accurate to use its snd_max as the seq# of the RST? Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 05:59:04 2012 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 EC3C9106566B; Wed, 28 Mar 2012 05:59:04 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BEB9E8FC14; Wed, 28 Mar 2012 05:59:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2S5x4qg040071; Wed, 28 Mar 2012 05:59:04 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2S5x4Ao040067; Wed, 28 Mar 2012 05:59:04 GMT (envelope-from linimon) Date: Wed, 28 Mar 2012 05:59:04 GMT Message-Id: <201203280559.q2S5x4Ao040067@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166462: [gre] gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2012 05:59:05 -0000 Old Synopsis: gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state New Synopsis: [gre] gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 28 05:58:53 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166462 From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 06:54:11 2012 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 BD4AD1065675 for ; Wed, 28 Mar 2012 06:54:11 +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 438C28FC0A for ; Wed, 28 Mar 2012 06:54:11 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q2S6s9Ix032376; Wed, 28 Mar 2012 10:54:09 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q2S6s9sh032375; Wed, 28 Mar 2012 10:54:09 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 28 Mar 2012 10:54:09 +0400 From: Gleb Smirnoff To: Ryan Stone Message-ID: <20120328065409.GS13561@glebius.int.ru> References: <201203090930.q299UCPX057950@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: kern/165863 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2012 06:54:11 -0000 On Tue, Mar 27, 2012 at 04:36:59PM -0400, Ryan Stone wrote: R> > From: Gleb Smirnoff R> > To: Eric van Gyzen , R> > š š š šEric van Gyzen , emaste@FreeBSD.org R> > Cc: bug-followup@FreeBSD.org R> > Subject: kern/165863 R> > Date: Fri, 9 Mar 2012 13:20:56 +0400 R> > R> > š--BXVAT5kNtrzKuDFl R> > šContent-Type: text/plain; charset=koi8-r R> > šContent-Disposition: inline R> > R> > š Hello, Eric and Ed. R> > R> > š Can you look at this patch? I decided to utilize newer callout API, R> > šthat allows to delegate lock retrieval to the callout subsystem, and R> > šthis makes things simplier. Hope that should work. R> > R> > š Patch is against head. R> > R> > š Eric, can you please send me your test programs, that you use to R> > šreproduce the bug? R> R> I tested this patch today on head and 8.2-RELEASE. I was unable to R> reproduce any crashes, whereas before I could crash the system within R> minutes. R> R> However it appears that in6_lltable_prefix_free is similarly broken. R> The only saving grace is that there does not appear to be a code path R> that can actually call it. Well, the patch I sent before definitely has problems. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 10:16:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 454411065676 for ; Wed, 28 Mar 2012 10:16:08 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B2F808FC1C for ; Wed, 28 Mar 2012 10:16:07 +0000 (UTC) Received: by lagv3 with SMTP id v3so1461239lag.13 for ; Wed, 28 Mar 2012 03:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type; bh=w22+wNvMwNAB1PKN9qAWdySXxV5tDhGQ4nhOshlN/IA=; b=MsHuJn6hHoKPcHTNea4GUfoDU2SqvAau3ZFSatKnvHxA55Tk3Rh6eungRLhDWOLPL9 faBQ0Dcz0oMKYx4OtrNb4EQSrnPIU8mjx/TDeolVnWwNTM5B8Agu2aXfI5cXl5Kh76VE rQrCy4Q0a6Fr0vOBsye9ooN0g10QUPupRber4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=w22+wNvMwNAB1PKN9qAWdySXxV5tDhGQ4nhOshlN/IA=; b=OaUjIaNlIZ9kasvQEt/CDPQJi4JUp5ORJNxeHEmP/H1VMq3tshO4BXdgK8+jsTfaUq 9EoIgjH6JBf2gTtj/6bt7T+AL5aqpZLZhzK5OfUnSPjxc2QZVqH8zsOzRPYXIk5nZ7Tg H5GwZLBSBKXi2/3r69F17+gT8/rKIIWmnTn/ltsz/+TmosgGC3NZROQ5hlX+NGVFHQUu BHQI5HD/jZkd47ahRTxJiYX8HNlcbhwoBlWSFdzdPctC4YT9AdraHv6TZqcDuHt7GAvj vAA8Hc6G/X7M9P9Ltocv8/F5pZYz16WkJTYp9R0Yx7ku4xmKDRraC8TuKc1fd+xbMTAL /9ng== MIME-Version: 1.0 Received: by 10.152.133.144 with SMTP id pc16mr22408936lab.0.1332929766506; Wed, 28 Mar 2012 03:16:06 -0700 (PDT) Received: by 10.112.77.15 with HTTP; Wed, 28 Mar 2012 03:16:06 -0700 (PDT) X-Originating-IP: [85.110.15.53] Date: Wed, 28 Mar 2012 13:16:06 +0300 Message-ID: From: "Raif S. Berent" To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQnOiEhWE97s7ctjglc/rfxJiuaGEVNvIlgdEiF4ALO1QwhnHez3SU7+KyNHjwSr/Bk5B6Sx Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: lagg problems on diskless client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2012 10:16:08 -0000 I have some problems implementing lagg(4) on dual NIC's on the diskless client side. It may be because my switch is a cheap, un-managed Gbit switch or hopefully some other reason. I would like to either get lagg working properly or find an alternative method of solving the problem. HARDWARE DESCRIPTION: I have mobo's with embedded 10/100 NIC's used as diskless cleints. For better performance I have added PCIe Gbit NIC's and Gbit switch. Since PXE cannot boot off an added PCIe NIC, I'm stuck with booting from embedded 10/100, then having to switch the traffic to the GBit NIC. In order to preserve port space on the GBit switch, I also have an old 10/100 hub plugged into one of the ports. Structure is: 10/100 NIC's --> 10/100 hub --> GBit switch --> server GBit NIC's --> GBit switch I concede that under this structure lagg's loadbalance or LACP are probably not going to work. I'll accept failover mode if I'm stuck with that - meaning, after the diskless client is done booting from the BIOS-recognized 10/100 NIC, it should switch traffic to the Gbit NIC and 10/100 should go "down". Unfortunately that does not work either. I have done as much testing as I can think of with: In general, as soon as lagg is brought up, NIC pool no longer responds to pings and gives an "I'm busy now" message. 1. On the server system, after lagg0 gets created as loadbalance, server stops responding to pings. However, tcpdump on server shows that ping requests are being received - it just does not respond. (No firewall running). Does this mean/indicate that my switch cannot handle lagg? 2. On a diskless node, lagg setup as failover behaves as other modes and results in system freeze (no ping response also). In below example, re1 is the Gbit-NIC and is set as primary NIC. > > ifconfig_lagg0="laggproto failover laggport re1 laggport re0 192.168.2.2 netmask 255.255.255.0" Curiously, under this setup tcpdump shows nfs response during frozen status. The second code snippet shows up when I un-plug the ethernet cable on re1 and lagg0 needs to fall back on re0. Server IP is 192.168.2.1, node is 2.2. > > 12:49:12.237477 IP 192.168.2.1.nfs > node2.76575838: reply ok 112 > > 12:59:54.323462 IP 192.168.2.1.nfsd > node2.740: Flags [R.], seq 4209474782, ack 2247908211, win 29127, options [nop,nop,TS val 2033479589 ecr 11647], length 0 Regards. From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 10:18:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07DEF106564A for ; Wed, 28 Mar 2012 10:18:04 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 757818FC0C for ; Wed, 28 Mar 2012 10:18:03 +0000 (UTC) Received: by lagv3 with SMTP id v3so1464313lag.13 for ; Wed, 28 Mar 2012 03:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=arvVfoPR8j6mH7ZFMbMfuxHTA65C1YmnjjWTW3RhrVQ=; b=fFKJfKomQ9R7mGxbb3CuKS4gqVtuda2ZP707aGCPMslGLD+GFmWCkFLfbZb5/kQCRh AKNIh1c+6SoI5qPeC2vz7hjjZ9ZNIB4yJGz+Qh3OoFKyzKfI1OyzqsM7UQotPmvSrRjt 52g2BHhI60Kmt1xO66AfZxThxDvjLV2wJkcys= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type:x-gm-message-state; bh=arvVfoPR8j6mH7ZFMbMfuxHTA65C1YmnjjWTW3RhrVQ=; b=S4lNF73S2y5Tzumwwr1vHePUwxrpO45p19ipHxgucpqgveqoejG5bYo1GrHkC8FaCy ZqTgUg+0xefGy0JryrOb1siCbvRlR8WrdxRUQzebKGO5o1jmLbrhhrQXdXJ9zGQ+s3EW kXASM1n8nwvlDUGAy5skS0QxaY8iqZj2El3bpFpH2BVio1nv56vi5ifSembRnq8T3XoK 8D4yG6y0TPpWeEyF+bamXDzvAoaZYIx0PEYtOdIn3ySMCnOGxvAsFMjtDj2ho8dWQ4/z akXCCXwJAnLOIXmo3IeFQ+buT15+378SXe6wT/xymZ99i6arQ3shbeY8fH1Sj9EOfPnY r8uA== MIME-Version: 1.0 Received: by 10.152.105.241 with SMTP id gp17mr24616428lab.21.1332929882376; Wed, 28 Mar 2012 03:18:02 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Wed, 28 Mar 2012 03:18:02 -0700 (PDT) X-Originating-IP: [85.110.15.53] Date: Wed, 28 Mar 2012 13:18:02 +0300 X-Google-Sender-Auth: ps44Xww_FuLlK7-qy9hmi11cHJs Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQlo17UXLucJB08b4J3b3VlD1klygw44UfzrHe6kAbeD9t0v/H4Qhs1jYXyQj/XW1FwpAkHj Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: (no subject) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2012 10:18:04 -0000 I have some problems implementing lagg(4) on dual NIC's on the diskless client side. It may be because my switch is a cheap, un-managed Gbit switch or hopefully some other reason. I would like to either get lagg working properly or find an alternative method of solving the problem. HARDWARE DESCRIPTION: I have mobo's with embedded 10/100 NIC's used as diskless cleints. For better performance I have added PCIe Gbit NIC's and Gbit switch. Since PXE cannot boot off an added PCIe NIC, I'm stuck with booting from embedded 10/100, then having to switch the traffic to the GBit NIC. In order to preserve port space on the GBit switch, I also have an old 10/100 hub plugged into one of the ports. Structure is: 10/100 NIC's --> 10/100 hub --> GBit switch --> server GBit NIC's --> GBit switch I concede that under this structure lagg's loadbalance or LACP are probably not going to work. I'll accept failover mode if I'm stuck with that - meaning, after the diskless client is done booting from the BIOS-recognized 10/100 NIC, it should switch traffic to the Gbit NIC and 10/100 should go "down". Unfortunately that does not work either. I have done as much testing as I can think of with: In general, as soon as lagg is brought up, NIC pool no longer responds to pings and gives an "I'm busy now" message. 1. On the server system, after lagg0 gets created as loadbalance, server stops responding to pings. However, tcpdump on server shows that ping requests are being received - it just does not respond. (No firewall running). Does this mean/indicate that my switch cannot handle lagg? 2. On a diskless node, lagg setup as failover behaves as other modes and results in system freeze (no ping response also). In below example, re1 is the Gbit-NIC and is set as primary NIC. > > ifconfig_lagg0="laggproto failover laggport re1 laggport re0 192.168.2.2 netmask 255.255.255.0" Curiously, under this setup tcpdump shows nfs response during frozen status. The second code snippet shows up when I un-plug the ethernet cable on re1 and lagg0 needs to fall back on re0. Server IP is 192.168.2.1, node is 2.2. > > 12:49:12.237477 IP 192.168.2.1.nfs > node2.76575838: reply ok 112 > > 12:59:54.323462 IP 192.168.2.1.nfsd > node2.740: Flags [R.], seq 4209474782, ack 2247908211, win 29127, options [nop,nop,TS val 2033479589 ecr 11647], length 0 Regards. From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 12:50:06 2012 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 39BA9106566B for ; Wed, 28 Mar 2012 12:50:06 +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 03D438FC17 for ; Wed, 28 Mar 2012 12:50:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2SCo5q4054010 for ; Wed, 28 Mar 2012 12:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2SCo5DZ054009; Wed, 28 Mar 2012 12:50:05 GMT (envelope-from gnats) Date: Wed, 28 Mar 2012 12:50:05 GMT Message-Id: <201203281250.q2SCo5DZ054009@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/165643: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:50:06 -0000 The following reply was made to PR kern/165643; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/165643: commit references a PR Date: Wed, 28 Mar 2012 12:40:41 +0000 (UTC) Author: zec Date: Wed Mar 28 12:40:30 2012 New Revision: 233602 URL: http://svn.freebsd.org/changeset/base/233602 Log: MFC: 232487 Properly restore curvnet context when returning early from ether_input_internal(). This change only affects options VIMAGE kernel builds. PR: kern/165643 Submitted by: Vijay Singh MFC after: 3 days Modified: stable/9/sys/net/if_ethersubr.c Directory Properties: stable/9/sys/ (props changed) stable/9/sys/amd64/include/xen/ (props changed) stable/9/sys/boot/ (props changed) stable/9/sys/boot/i386/efi/ (props changed) stable/9/sys/boot/ia64/efi/ (props changed) stable/9/sys/boot/ia64/ski/ (props changed) stable/9/sys/boot/powerpc/boot1.chrp/ (props changed) stable/9/sys/boot/powerpc/ofw/ (props changed) stable/9/sys/cddl/contrib/opensolaris/ (props changed) stable/9/sys/conf/ (props changed) stable/9/sys/contrib/dev/acpica/ (props changed) stable/9/sys/contrib/octeon-sdk/ (props changed) stable/9/sys/contrib/pf/ (props changed) stable/9/sys/contrib/x86emu/ (props changed) stable/9/sys/fs/ (props changed) stable/9/sys/fs/ntfs/ (props changed) stable/9/sys/i386/conf/XENHVM (props changed) Modified: stable/9/sys/net/if_ethersubr.c ============================================================================== --- stable/9/sys/net/if_ethersubr.c Wed Mar 28 12:30:16 2012 (r233601) +++ stable/9/sys/net/if_ethersubr.c Wed Mar 28 12:40:30 2012 (r233602) @@ -661,8 +661,10 @@ ether_input_internal(struct ifnet *ifp, m = (*lagg_input_p)(ifp, m); if (m != NULL) ifp = m->m_pkthdr.rcvif; - else + else { + CURVNET_RESTORE(); return; + } } /* @@ -681,6 +683,7 @@ ether_input_internal(struct ifnet *ifp, #endif ifp->if_ierrors++; m_freem(m); + CURVNET_RESTORE(); return; } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 12:50:08 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F378106566C for ; Wed, 28 Mar 2012 12:50:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 757D48FC08 for ; Wed, 28 Mar 2012 12:50:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2SCo8dW054015 for ; Wed, 28 Mar 2012 12:50:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2SCo8jK054014; Wed, 28 Mar 2012 12:50:08 GMT (envelope-from gnats) Date: Wed, 28 Mar 2012 12:50:08 GMT Message-Id: <201203281250.q2SCo8jK054014@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/165643: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:50:08 -0000 The following reply was made to PR kern/165643; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/165643: commit references a PR Date: Wed, 28 Mar 2012 12:41:36 +0000 (UTC) Author: zec Date: Wed Mar 28 12:41:17 2012 New Revision: 233603 URL: http://svn.freebsd.org/changeset/base/233603 Log: MFC 232487: Properly restore curvnet context when returning early from ether_input_internal(). This change only affects options VIMAGE kernel builds. PR: kern/165643 Submitted by: Vijay Singh MFC after: 3 days Modified: stable/8/sys/net/if_ethersubr.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/boot/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) stable/8/sys/dev/e1000/ (props changed) stable/8/sys/i386/conf/XENHVM (props changed) Modified: stable/8/sys/net/if_ethersubr.c ============================================================================== --- stable/8/sys/net/if_ethersubr.c Wed Mar 28 12:40:30 2012 (r233602) +++ stable/8/sys/net/if_ethersubr.c Wed Mar 28 12:41:17 2012 (r233603) @@ -660,8 +660,10 @@ ether_input(struct ifnet *ifp, struct mb m = (*lagg_input_p)(ifp, m); if (m != NULL) ifp = m->m_pkthdr.rcvif; - else + else { + CURVNET_RESTORE(); return; + } } /* @@ -680,6 +682,7 @@ ether_input(struct ifnet *ifp, struct mb #endif ifp->if_ierrors++; m_freem(m); + CURVNET_RESTORE(); return; } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Mar 28 18:38:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65329106566C for ; Wed, 28 Mar 2012 18:38:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 393128FC12 for ; Wed, 28 Mar 2012 18:38:05 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so2486614pbc.13 for ; Wed, 28 Mar 2012 11:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=GN09bCGDYXJU/HLzCVNeRScl6zzEhVWeGelTvKD8QZ0=; b=AwQB1XQlAfgEjJHQSt4DunsZPtjnVpLEv5ZrPib7rbbJ30tViuEpLG/3/kwBi24ecn u74l5Pid96ahBUcDUmomyEXZWNOgmVlqKH0WQpCGZSD/k7Mg4Jfi190A9kz2ZznbQxg8 EtPL7QNUkO3c7JaFzpg/0fuoJJ7gOiKc3ypmlhWrMDW0zVqpZNYvCSpmtK4DLj2Hdq3/ Po1/wfkKS6QGKyHynuG1t0kAgoU9kGg40Ku5v5Gvxo//0sxHtRhT3Cx2Xn74h7zxyDQ5 cig29tb9xgEEuV8SU8424O28o4lAWrPuDnclq5JuHUbwp0jteNQ35WTHwTPbEjsascTn CEUQ== MIME-Version: 1.0 Received: by 10.68.195.38 with SMTP id ib6mr62316216pbc.28.1332959879434; Wed, 28 Mar 2012 11:37:59 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Wed, 28 Mar 2012 11:37:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Mar 2012 11:37:59 -0700 X-Google-Sender-Auth: Rp980UPQhryP9ElaElmP3VZwiTU Message-ID: From: Adrian Chadd To: Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: (no subject) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Mar 2012 18:38:05 -0000 Hi, what's the routing table and ifconfig output look like? It sounds like you're creating the interface and moving things over without: * deleting the route/IP table entry; * create the lagg; * adding the interfaces to the lagg, including the one you booted off of; * assigning the correct IP and readding the default route. adrian From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 01:42:41 2012 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 0BB53106564A for ; Thu, 29 Mar 2012 01:42:41 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 69F818FC0C for ; Thu, 29 Mar 2012 01:42:40 +0000 (UTC) Received: by lagv3 with SMTP id v3so2766070lag.13 for ; Wed, 28 Mar 2012 18:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=VlvWR5A1KllbJNPwh6YTKOk8FbGyvbYAUcUv3qRZh4A=; b=KvvPIeIASLQCNj3ARLrjiXvnDXbvzUwCK8COSeNj6/tIg6z8GBk2OoE7sevfVKeLHR Ylfd+sT1e7CwDBc8ojECX+9IJBXGX0JDAcOLbK9jxLMMWyIsw4gfz2a87D/wuc+3HKKI bdjxwA5s/lFcNoRx7Q8odTx6R4d4+LzPGPxlk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=VlvWR5A1KllbJNPwh6YTKOk8FbGyvbYAUcUv3qRZh4A=; b=TKxEeXhO/lYPm5uBUkmFShiNh6dvRXHRVSa5lzahBy1/fiUBzJGpA+u/vN3oJdym+9 Ts5Hr1Faj7UHD93FcJPcC57fvlDwsdJ/FPe88TJkecpd+kdrGmERjSc8Lcf/yfc7f5/5 GPCqSon2zY0swBHhQKvpfg7oA+9BRCSymFVNPSncPbn2S8zo9zK0TtgWn/00yDdHbUJB +10GlRstxaI/7rnu5yD6O5hsTcE7BdBA0cG0ggjsLEjx0P0wuDlxKfoEGER7EcI+sZai 4f/YU9lFkV72YqHRVx8DW2lss1PjaTW0hOv2IKIvItdx1Eaou41pEKsAu5uuGtB6/yYj uGuA== MIME-Version: 1.0 Received: by 10.152.110.170 with SMTP id ib10mr28017088lab.7.1332985358918; Wed, 28 Mar 2012 18:42:38 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.77.15 with HTTP; Wed, 28 Mar 2012 18:42:38 -0700 (PDT) X-Originating-IP: [78.162.12.68] In-Reply-To: References: Date: Thu, 29 Mar 2012 04:42:38 +0300 X-Google-Sender-Auth: KbkEXhLEMVF6RV0IW7sRY6z7pQo Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQlBTgxDpdj7flIP1xkzeHoic9hNE3DYHCau65WDtLi1Mg5M/tVoWKx6VTIXDwMK85/0ka/B Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: (no subject) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Mar 2012 01:42:41 -0000 Hi Adrian, Re your comments; you are 100% right, as I have not done steps 1 & 4 from your list below. I must also admit that my knowledge of networking, on a scale of 0-10, is probably -1. I assume you mean for Client? For example, re0 has static IP assigned by DHCP and re1 (GBit NIC) has no IP untill I assign same MAC Address as re0, create lagg and do an ifconfig lagg. Can't boot Client at the moment as I have an NFS mount problem. All diskless clients boot from 192.168.2.1; DHCP, inetd, (and hopefully NFS) run from jail and are bound to that IP. No firewall (yet) on that NIC. I'd like to try steps 1 & 4 as per your suggestion and see if that solves it - so, 1. What commands should I run for steps 1 & 4 ? 2. lagg should be set up ass failover right? I assume loadbalance is impossible when hubs are involved? 3. Is it possible to assign lagg instruction through DHCP or some other service on HOST, rather than settings in CLIENT rc.conf? Thanks so much for your help... > On Wed, Mar 28, 2012 at 9:37 PM, Adrian Chadd wrote: > >> Hi, >> >> what's the routing table and ifconfig output look like? >> >> It sounds like you're creating the interface and moving things over >> without: >> >> * deleting the route/IP table entry; >> * create the lagg; >> * adding the interfaces to the lagg, including the one you booted off of; >> * assigning the correct IP and readding the default route. >> >> >> adrian >> > > From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 07:21:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 597AB106564A for ; Thu, 29 Mar 2012 07:21:03 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id DCB728FC0A for ; Thu, 29 Mar 2012 07:21:02 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2T7KuxC002146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Mar 2012 18:20:58 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q2T7Ku2B045470; Thu, 29 Mar 2012 18:20:56 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.5/Submit) id q2T7KsH2045469; Thu, 29 Mar 2012 18:20:54 +1100 (EST) (envelope-from peter) Date: Thu, 29 Mar 2012 18:20:54 +1100 From: Peter Jeremy To: "Raif S. Berent" Message-ID: <20120329072054.GA45082@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org Subject: Re: lagg problems on diskless client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Mar 2012 07:21:03 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Mar-28 13:16:06 +0300, "Raif S. Berent" wrote: >I have some problems implementing lagg(4) on dual NIC's on the diskless >client side. It may be because my switch is a cheap, un-managed Gbit switch >or hopefully some other reason. I would like to either get lagg working >properly or find an alternative method of solving the problem. Whilst I haven't specifically done this, I have done diskless booting on a wired NIC and then switched to a wired/wifi lagg. Have a look at http://www.bugs.au.freebsd.org/dokuwiki/doku.php/laggdiskless >I concede that under this structure lagg's loadbalance or LACP are probably >not going to work. FEC & LACP require support at both ends and so won't work. loadbalance & roundrobin should work but aren't really appropriate unless your interfaces are identical. >In general, as soon as lagg is brought up, NIC pool no longer responds to >pings and gives an "I'm busy now" message. Yes. Once you create the lagg, the interfaces comprising it will no longer work standalone and you can't atomically migrate the IP address =66rom re0 to lagg0 - hence the script linked from the above page. --=20 Peter Jeremy --liOOAslEiF7prFVr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk90DVYACgkQ/opHv/APuIde1gCgtZqapZoXKnt+0P4WLxoutfe4 VbEAni62yKnjrirkk5JPBrIfWtuAcX4O =JSbv -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 14:04:10 2012 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 5B6D51065673 for ; Thu, 29 Mar 2012 14:04:10 +0000 (UTC) (envelope-from hunter@comsys.com.ua) Received: from mail.ice-tech.com.ua (mail.ice-tech.com.ua [77.120.117.100]) by mx1.freebsd.org (Postfix) with ESMTP id 157828FC08 for ; Thu, 29 Mar 2012 14:04:09 +0000 (UTC) Received: from [94.247.224.226] (helo=hunters-MacBook-Pro.local) by mail.ice-tech.com.ua with esmtpa (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SDFQF-0004Y5-9b for freebsd-net@freebsd.org; Thu, 29 Mar 2012 16:29:51 +0300 Message-ID: <4F7463CF.8010206@comsys.com.ua> Date: Thu, 29 Mar 2012 16:29:51 +0300 From: Sergey Smitienko User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 94.247.224.226 X-SA-Exim-Mail-From: hunter@comsys.com.ua X-SA-Exim-Scanned: No (on mail.ice-tech.com.ua); SAEximRunCond expanded to false Subject: FreeBSD 9.0 generates incorrect SEC/ACK numbers under load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Mar 2012 14:04:10 -0000 Hello. I've run into a problem with a web server runing FreeBSD 9.0/amd64. What I believe is happening, is what server loses track of correct SEQ/ACK numbers on some connections. Here is an example: 15:20:00.347514 IP (tos 0x68, ttl 123, id 1181, offset 0, flags [DF], proto TCP (6), length 52) 93.72.14.220.49239 > 193.178.147.113.80: Flags [S], cksum 0x6995 (correct), seq 3881466934, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0 15:20:00.347526 IP (tos 0x10, ttl 254, id 28065, offset 0, flags [DF], proto TCP (6), length 44) 193.178.147.113.80 > 93.72.14.220.49239: Flags [S.], cksum 0x79fa (correct), seq 2151790680, ack 3881466935, win 0, options [mss 1460], length 0 15:20:00.361812 IP (tos 0x68, ttl 123, id 1183, offset 0, flags [DF], proto TCP (6), length 40) 93.72.14.220.49239 > 193.178.147.113.80: Flags [.], cksum 0x96c6 (correct), seq 3881466935, ack 2151790681, win 64240, length 0 15:20:00.361869 IP (tos 0x10, ttl 254, id 31305, offset 0, flags [DF], proto TCP (6), length 40) 193.178.147.113.80 > 93.72.14.220.49239: Flags [.], cksum 0x71b7 (correct), seq 2151790681, ack 3881466935, win 8192, length 0 Client sends "GET" request 15:20:48.236181 IP (tos 0x68, ttl 123, id 1353, offset 0, flags [DF], proto TCP (6), length 626) 93.72.14.220.49239 > 193.178.147.113.80: Flags [P.], cksum 0x7fc9 (correct), seq 3881466935:3881467521, ack 2151790681, win 64240, length 586 and then the "ping-pong" starts: 15:20:48.236198 IP (tos 0x0, ttl 254, id 63530, offset 0, flags [DF], proto TCP (6), length 40) 193.178.147.113.80 > 93.72.14.220.49239: Flags [.], cksum 0x8a97 (correct), seq 2991748588, ack 1985077892, win 8760, length 0 15:20:48.255998 IP (tos 0x68, ttl 123, id 1357, offset 0, flags [DF], proto TCP (6), length 40) 93.72.14.220.49239 > 193.178.147.113.80: Flags [.], cksum 0x947c (correct), seq 3881467521, ack 2151790681, win 64240, length 0 15:20:48.256015 IP (tos 0x0, ttl 254, id 53518, offset 0, flags [DF], proto TCP (6), length 40) 193.178.147.113.80 > 93.72.14.220.49239: Flags [.], cksum 0x8a97 (correct), seq 2991748588, ack 1985077892, win 8760, length 0 15:20:48.276084 IP (tos 0x68, ttl 123, id 1360, offset 0, flags [DF], proto TCP (6), length 40) 93.72.14.220.49239 > 193.178.147.113.80: Flags [.], cksum 0x947c (correct), seq 3881467521, ack 2151790681, win 64240, length 0 15:20:48.276099 IP (tos 0x0, ttl 254, id 42983, offset 0, flags [DF], proto TCP (6), length 40) 193.178.147.113.80 > 93.72.14.220.49239: Flags [.], cksum 0x8a97 (correct), seq 2991748588, ack 1985077892, win 8760, length 0 15:20:48.290914 IP (tos 0x68, ttl 123, id 1361, offset 0, flags [DF], proto TCP (6), length 40) 93.72.14.220.49239 > 193.178.147.113.80: Flags [.], cksum 0x947c (correct), seq 3881467521, ack 2151790681, win 64240, length 0 This happens on about 0.01% of connections. This tcpdump is recorded on the 193.178.147.113, before traffic hits the wire. So it's not a NIC fault. Server is running nginx and serving static content 200-500 request per second. Any ideas ? -- Sergey Smitienko From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 14:43:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18B5F106564A for ; Thu, 29 Mar 2012 14:43:44 +0000 (UTC) (envelope-from seth.mos@dds.nl) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by mx1.freebsd.org (Postfix) with ESMTP id C72828FC15 for ; Thu, 29 Mar 2012 14:43:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 933AA58D4D for ; Thu, 29 Mar 2012 16:43:42 +0200 (CEST) Received: from [10.0.2.53] (edge-pf.coltex.nl [91.227.27.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 8300758D20 for ; Thu, 29 Mar 2012 16:43:35 +0200 (CEST) Message-ID: <4F74755A.2040308@dds.nl> Date: Thu, 29 Mar 2012 16:44:42 +0200 From: Seth Mos User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at rotring X-Virus-Status: Clean Subject: 6rd status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Mar 2012 14:43:44 -0000 Hi, I've been trying to use the srd device patch from Masakazu-san from here. http://bougaidenpa.org/masakazu/archives/54 After walking through the configure steps and configuring a default route I get a network unreachable. http://www.pastie.org/private/j6ufhloh2kqesznee6y8na [2.1-DEVELOPMENT][root@pfsense.localdomain]/root(6): ping6 -c1 ipv6.google.com PING6(56=40+8+8 bytes) 2a02:1205:25ea:19b0:: --> 2a00:1450:400c:c01::67 ping6: sendmsg: Network is unreachable ping6: wrote ipv6.l.google.com 16 chars, ret=-1 --- ipv6.l.google.com ping6 statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss [2.1-DEVELOPMENT][root@pfsense.localdomain]/root(7): Any ideas on where to look? Kind regards, Seth From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 20:05:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0C161065673 for ; Thu, 29 Mar 2012 20:05:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A45AD8FC0C for ; Thu, 29 Mar 2012 20:05:57 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so673166pbc.13 for ; Thu, 29 Mar 2012 13:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WT7s2CT2ZEhxrH73DlZexjm0bjZKzB75zoQmQlcQ6AM=; b=igq9/4y3heI3gXhp0R2DPhhLdATDx8Xb5V6s5RKVHiFqTQiJvK/1GoDIIymXM1CfWo lXKKo2JD6ly89yG3sn+S5c2jaCj0OAmPEEwuXJuDvHpVYT3rsDuAojgrLbg9kTqQ6ckX tPyPLjezXDk+Y9IQIwqzJ1JOocaJ5piSTmenfEgOoWNB5chjpzXQ6JBbHDNAXMt9JNXW qsnxYqMyFQjF/9fFSdDxpUJ8o8a8P7ch68qsLwMovq5se0S4koRdulHe5ozIBLYXARpZ nPTRIWZYctiURj/NUZVZmNbJO0Dr5m9L11g65Ka9/xQSNFSzOM7QsL/8jHZixG8ng3dg qKFg== MIME-Version: 1.0 Received: by 10.68.202.195 with SMTP id kk3mr2992012pbc.96.1333051551209; Thu, 29 Mar 2012 13:05:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Thu, 29 Mar 2012 13:05:51 -0700 (PDT) In-Reply-To: <4F7463CF.8010206@comsys.com.ua> References: <4F7463CF.8010206@comsys.com.ua> Date: Thu, 29 Mar 2012 13:05:51 -0700 X-Google-Sender-Auth: 6pNAniirhX1f5B-i9O0-4xdQ5EM Message-ID: From: Adrian Chadd To: Sergey Smitienko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.0 generates incorrect SEC/ACK numbers under load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Mar 2012 20:05:57 -0000 Hi, I think a few people have noticed this. Would you mind creating a PR? Thanks, adrian From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 21:48:46 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C2EF106564A for ; Thu, 29 Mar 2012 21:48:46 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 1349A8FC14 for ; Thu, 29 Mar 2012 21:48:45 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so18349wib.13 for ; Thu, 29 Mar 2012 14:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8gO3V5meRXIoRWMXoMWk1mvzeJEhfk1x0ajZ0cw26F8=; b=WgTkAwDk7Z+JzYrdf/86SPoP4G1eLiU0kNEzmZoETxq2N2TGIMUGgrQSE+npKQIKVN FSaIbBi4dU8VKfFyOl64+9TOA3V2k/tQcwUnoPVa8LFIbKnVCYwqAwdb0h3s/Cuzh76b iSYk+RiIBMOGKGgs0vopMnM+8OQQPNkLk+EqFaSunLslgrh5KOA2d/nLafuwvsTGhwi9 /SQLiXpcppzuHnCRkqp3JVUFUKGbgvYHWOeQVmbVhaSNDKG9XKxN2jL9WzMxjumlBKEG VyaaqIQ1oQyPvUOZ14ZrYmaswSI+1CAsFok40xOjDvxxhW86ya0pKyrl/rJTZuwJQqI2 hxCg== MIME-Version: 1.0 Received: by 10.180.94.33 with SMTP id cz1mr9702301wib.13.1333057719181; Thu, 29 Mar 2012 14:48:39 -0700 (PDT) Received: by 10.180.79.137 with HTTP; Thu, 29 Mar 2012 14:48:39 -0700 (PDT) Date: Thu, 29 Mar 2012 17:48:39 -0400 Message-ID: From: Ryan Stone To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Subject: Removing an IPv6 address does not remove NDP entries on that subnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Mar 2012 21:48:46 -0000 Currently, if you remove an IPv4 address from an interface, all ARP cache entries on its subnet are invalidated. However, the same thing is not done for NDP cache entries when an IPv6 address is removed*. Is this correct behaviour? It seems weird to have IPv4 and IPv6 behave differently. * In a way this is a good thing as in6_lltable_prefix_free() is guaranteed to crash your kernel in two different ways, and that's not counting the race conditions that it's subject to. I plan on addressing these problems along with kern/165863, but in working on that I realized that it was impossible to test any changes. From owner-freebsd-net@FreeBSD.ORG Thu Mar 29 21:59:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC2F7106566C; Thu, 29 Mar 2012 21:59:39 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC488FC14; Thu, 29 Mar 2012 21:59:38 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so3560wib.13 for ; Thu, 29 Mar 2012 14:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GHlz166u2NjlKnc3cB0dVFb8oLC9r/HtwBvHvsklFE0=; b=06ipmV/a8hLLumYMQ1xMEi/sClQurzqxKRw4a1oaf83W9vzQy7F9Fkk3Llbat+y5rM iUxko/MXQ4+UUnIGs1dgf0R7yp+k0LCzsK37sWckDqsJuU3vbofvcQTogUQGPYhmw5ER hgdnoSeSJg+/27bvuqYoL6YWZoicdJIr01BkMEKEM6XlPGThhsCuOvvy7yme//Av4tu0 JkMZAloe3nJ22453dJz2OxV9PGyJ4cfE8VpOVAEBDprAFEAZtzgnjIA9QyPbKYpjSLs1 ALbicDpI0y5pHH5dEUmexWrZpcU1O4vOCNRItBSRLaj/58qAMGJ89eKyUOezD0qsFcgv FzYA== MIME-Version: 1.0 Received: by 10.180.95.74 with SMTP id di10mr2266419wib.1.1333058378223; Thu, 29 Mar 2012 14:59:38 -0700 (PDT) Received: by 10.180.79.137 with HTTP; Thu, 29 Mar 2012 14:59:38 -0700 (PDT) In-Reply-To: <201203090930.q299UCPX057950@freefall.freebsd.org> References: <201203090930.q299UCPX057950@freefall.freebsd.org> Date: Thu, 29 Mar 2012 17:59:38 -0400 Message-ID: From: Ryan Stone To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: kern/165863 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Mar 2012 21:59:39 -0000 Ok, I think that I have an approach that will work. This is heavily based off of glebius' proposal. The big difference is that instead of initializing the arptimer callout with the ll_entry's lock, I initialize it with the if_afdata_lock. This eliminates the LOR problem in arptimer. It also nicely prevents any races between arptimer and in_lltable_prefix_free. Either arptimer will run and ensure that prefix_free can never see an entry that arptimer is in the process of destroying, or prefix_free will stop the callout before arptimer gets a chance to start. I'll admit that it feels a bit dirty to be doing anything if the ifp at this level, but I'd argue that is an artifact of using a lock in the ifp to protect the lltable. The patch below is not yet complete; it doesn't fix the IPv6 case. IPv6 is looking much trickier as when an NDP entry is timed out nd6_free() will drop the LLE_WLOCK, acquire the IF_AFDATA_LOCK and then re-acquire the LLE_WLOCK. It's not immediately clear to me what the best way to handle the race between in6_lltable_prefix_free and nd6_llinfo_timer is. Holding the afdata_lock across all of nd6_llinfo_timer feels like overkill. Any comments on this approach? Am I going in the wrong direction? diff --git a/sys/netinet/if_ether.c b/sys/netinet/if_ether.c index bdb4efc..02d9af4 100644 --- a/sys/netinet/if_ether.c +++ b/sys/netinet/if_ether.c @@ -165,36 +165,26 @@ arptimer(void *arg) { struct ifnet *ifp; struct llentry *lle; - int pkts_dropped; + size_t pkts_dropped; KASSERT(arg != NULL, ("%s: arg NULL", __func__)); lle = (struct llentry *)arg; + + if (lle->la_flags & LLE_STATIC) + return; + ifp = lle->lle_tbl->llt_ifp; CURVNET_SET(ifp->if_vnet); - IF_AFDATA_LOCK(ifp); + IF_AFDATA_LOCK_ASSERT(ifp); LLE_WLOCK(lle); - if (lle->la_flags & LLE_STATIC) - LLE_WUNLOCK(lle); - else { - if (!callout_pending(&lle->la_timer) && - callout_active(&lle->la_timer)) { - callout_stop(&lle->la_timer); - LLE_REMREF(lle); - pkts_dropped = llentry_free(lle); - ARPSTAT_ADD(dropped, pkts_dropped); - ARPSTAT_INC(timeouts); - } else { -#ifdef DIAGNOSTIC - struct sockaddr *l3addr = L3_ADDR(lle); - log(LOG_INFO, - "arptimer issue: %p, IPv4 address: \"%s\"\n", lle, - inet_ntoa( - ((const struct sockaddr_in *)l3addr)->sin_addr)); -#endif - LLE_WUNLOCK(lle); - } - } - IF_AFDATA_UNLOCK(ifp); + LLE_REMREF(lle); + + /* llentry_free drops the LLE_WLOCK */ + pkts_dropped = llentry_free(lle); + + ARPSTAT_ADD(dropped, pkts_dropped); + ARPSTAT_INC(timeouts); + CURVNET_RESTORE(); } diff --git a/sys/netinet/in.c b/sys/netinet/in.c index ac0aada..0d5d80e 100644 --- a/sys/netinet/in.c +++ b/sys/netinet/in.c @@ -1275,15 +1275,17 @@ in_lltable_free(struct lltable *llt, struct llentry *lle) } static struct llentry * -in_lltable_new(const struct sockaddr *l3addr, u_int flags) +in_lltable_new(struct lltable *llt, const struct sockaddr *l3addr, u_int flags) { struct in_llentry *lle; + struct ifnet *ifp; lle = malloc(sizeof(struct in_llentry), M_LLTABLE, M_DONTWAIT | M_ZERO); if (lle == NULL) /* NB: caller generates msg */ return NULL; - callout_init(&lle->base.la_timer, CALLOUT_MPSAFE); + ifp = llt->llt_ifp; + callout_init_rw(&lle->base.la_timer, &ifp->if_afdata_lock, 0); /* * For IPv4 this will trigger "arpresolve" to generate * an ARP request. @@ -1292,6 +1294,7 @@ in_lltable_new(const struct sockaddr *l3addr, u_int flags) lle->l3_addr4 = *(const struct sockaddr_in *)l3addr; lle->base.lle_refcnt = 1; lle->base.lle_free = in_lltable_free; + lle->base.lle_tbl = llt; LLE_LOCK_INIT(&lle->base); return &lle->base; } @@ -1311,6 +1314,7 @@ in_lltable_prefix_free(struct lltable *llt, register int i; size_t pkts_dropped; + IF_AFDATA_WLOCK(llt->llt_ifp); for (i=0; i < LLTBL_HASHTBL_SIZE; i++) { LIST_FOREACH_SAFE(lle, &llt->lle_head[i], lle_next, next) { @@ -1318,20 +1322,19 @@ in_lltable_prefix_free(struct lltable *llt, * (flags & LLE_STATIC) means deleting all entries * including static ARP entries */ - if (IN_ARE_MASKED_ADDR_EQUAL((struct sockaddr_in *)L3_ADDR(lle), - pfx, msk) && - ((flags & LLE_STATIC) || !(lle->la_flags & LLE_STATIC))) { - int canceled; + if (IN_ARE_MASKED_ADDR_EQUAL(satosin(L3_ADDR(lle)), + pfx, msk) && ((flags & LLE_STATIC) || + !(lle->la_flags & LLE_STATIC))) { - canceled = callout_drain(&lle->la_timer); LLE_WLOCK(lle); - if (canceled) + if (callout_stop(&lle->la_timer)) LLE_REMREF(lle); pkts_dropped = llentry_free(lle); ARPSTAT_ADD(dropped, pkts_dropped); } } } + IF_AFDATA_WUNLOCK(llt->llt_ifp); } @@ -1451,7 +1454,7 @@ in_lltable_lookup(struct lltable *llt, u_int flags, const struct sockaddr *l3add in_lltable_rtcheck(ifp, flags, l3addr) != 0) goto done; - lle = in_lltable_new(l3addr, flags); + lle = in_lltable_new(llt, l3addr, flags); if (lle == NULL) { log(LOG_INFO, "lla_lookup: new lle malloc failed\n"); goto done; @@ -1462,7 +1465,6 @@ in_lltable_lookup(struct lltable *llt, u_int flags, const struct sockaddr *l3add lle->la_flags |= (LLE_VALID | LLE_STATIC); } - lle->lle_tbl = llt; lle->lle_head = lleh; LIST_INSERT_HEAD(lleh, lle, lle_next); } else if (flags & LLE_DELETE) { From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 04:28:47 2012 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 8B5EF106566C for ; Fri, 30 Mar 2012 04:28:47 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from plsvl-mailgw-01.bluecoat.com (plsvl-mailgw-01.bluecoat.com [199.91.133.11]) by mx1.freebsd.org (Postfix) with ESMTP id 6D35F8FC0A for ; Fri, 30 Mar 2012 04:28:47 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com (unknown [10.2.2.122]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 7231381A1B5; Thu, 29 Mar 2012 21:25:32 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Thu, 29 Mar 2012 21:28:40 -0700 From: "Li, Qing" To: Ryan Stone , freebsd-net Thread-Topic: Removing an IPv6 address does not remove NDP entries on that subnet Thread-Index: AQHNDfXGw+n6xQubT0ubQhqUaNrA/5aCPeZA Date: Fri, 30 Mar 2012 04:28:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: Removing an IPv6 address does not remove NDP entries on that subnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 04:28:47 -0000 >=20 > Currently, if you remove an IPv4 address from an interface, all ARP > cache entries on its subnet are invalidated. However, the same thing > is not done for NDP cache entries when an IPv6 address is removed*. > Is this correct behaviour? It seems weird to have IPv4 and IPv6 > behave differently. >=20 Yes, the behavior is different between IPv4 and IPv6 because=20 IPv6 manages prefixes and addresses separately. In IPv4 deleting=20 an address implies the prefix is also being deleted, that's not=20 the case with IPv6. >=20 > * In a way this is a good thing as in6_lltable_prefix_free() is > guaranteed to crash your kernel in two different ways, and that's not > counting the race conditions that it's subject to. > Could you please elaborate with some details on the two different ways in6_lltable_prefix_free() crashes the kernel definitively ? --Qing From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 05:43:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D3ED1065672 for ; Fri, 30 Mar 2012 05:43:23 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E0CC38FC16 for ; Fri, 30 Mar 2012 05:43:22 +0000 (UTC) Received: by iahk25 with SMTP id k25so654507iah.13 for ; Thu, 29 Mar 2012 22:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :in-reply-to:content-type; bh=Ti+WtlZquukdL3ahrNVETcRA0csZfpgmPpqYWcuqjoc=; b=Q9tt9U8P2jrhmdtXc+SBdGfbA8O1M0OWJsTFB5tIEfCQy/cEvPFSGHnwWzzE+J2fYV iKe8BqkVsMSkKUIGjQa5yIFuEfSP2HybWshYONECM4pUyZA9S7Ojx23o7a0WWGxibQL7 ZrllivnQzJF4/heVGEZ2en9vxRjPy0bZ42ZVA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :in-reply-to:x-gm-message-state:content-type; bh=Ti+WtlZquukdL3ahrNVETcRA0csZfpgmPpqYWcuqjoc=; b=Lp8KkeTBkS6ZQqIRBS6GDiirk+g0et3oN4HRozUGG1FJqBYiCT+sruWLzuJaoqy4lb HuRIpyt/Chf0YYDfalAQgUurL1iHxTZAxJ+8S9zZDmiPZDOkQV0pPzNuxBME3VoJ8L3r 1+XemffzNhPrflqWZnqzlKbpl/+dCgDgn7cZiFbeVbiNYBwCUWpQ/wweIwwMtlpCn+tP pGsAWmeN0lVD13mM8CNGdLNk9NFd5OnJmtO8AIjTglXMGAxixs7K6bTgMLYoxIRlwE7q E5neddqrWeGYqi52IAaXbg2bh93iCn19n6bO0fyLEL5VISKtZ76SMpOtSJn8obG2G2NI HnXw== Received: by 10.50.34.135 with SMTP id z7mr529603igi.17.1333086202107; Thu, 29 Mar 2012 22:43:22 -0700 (PDT) Received: from DataIX.net (adsl-99-181-151-192.dsl.klmzmi.sbcglobal.net. [99.181.151.192]) by mx.google.com with ESMTPS id nq4sm1276159igc.5.2012.03.29.22.43.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Mar 2012 22:43:21 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q2U5hJVT014468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2012 01:43:19 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q2U5hIB8014321; Fri, 30 Mar 2012 01:43:18 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Fri, 30 Mar 2012 01:43:18 -0400 From: Jason Hellenthal To: Beeblebrox Message-ID: <20120330054318.GB4154@DataIX.net> References: MIME-Version: 1.0 In-Reply-To: X-Gm-Message-State: ALoCoQk392Aq7f97nsupzpVbggpOmY8hQLeOvRp9C75tqsT7zj3DrK9te/u0zwSQYjfNPDTH4gOm Content-Type: multipart/mixed; boundary=14dae93409f38baf0504bc6f5143 Cc: freebsd-net@freebsd.org Subject: Re: (no subject) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 05:43:23 -0000 --14dae93409f38baf0504bc6f5143 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 29, 2012 at 04:42:38AM +0300, Beeblebrox wrote: > Hi Adrian, >=20 > Re your comments; you are 100% right, as I have not done steps 1 & 4 from > your list below. > I must also admit that my knowledge of networking, on a scale of 0-10, is > probably -1. >=20 > > I assume you mean for Client? For example, re0 has static IP assigned by > DHCP and re1 (GBit NIC) has no IP untill I assign same MAC Address as re0, > create lagg and do an ifconfig lagg. >=20 ***** Why on earth would you do that when configuring the LAgg does this for you...! ***** ALSO! you do not need an address on either of the nics!. That should be placed explicitly on the LAgg and add a alias for each sub address you would like... > > Can't boot Client at the moment as I have an NFS mount problem. All > diskless clients boot from 192.168.2.1; DHCP, inetd, (and hopefully NFS) > run from jail and are bound to that IP. No firewall (yet) on that NIC. >=20 > I'd like to try steps 1 & 4 as per your suggestion and see if that solves > it - so, > 1. What commands should I run for steps 1 & 4 ? > 2. lagg should be set up ass failover right? I assume loadbalance is > impossible when hubs are involved? > 3. Is it possible to assign lagg instruction through DHCP or some other > service on HOST, rather than settings in CLIENT rc.conf? >=20 > Thanks so much for your help... >=20 >=20 >=20 > > On Wed, Mar 28, 2012 at 9:37 PM, Adrian Chadd wrot= e: > > > >> Hi, > >> > >> what's the routing table and ifconfig output look like? > >> > >> It sounds like you're creating the interface and moving things over > >> without: > >> > >> * deleting the route/IP table entry; > >> * create the lagg; > >> * adding the interfaces to the lagg, including the one you booted off = of; > >> * assigning the correct IP and readding the default route. > >> > >> > >> adrian > >> > > > > > _______________________________________________ > 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 ;s =3D; --14dae93409f38baf0504bc6f5143 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPdUf2AAoJEJBXh4mJ2FR+6J8IAJjENRLt3yG1Fgv4nsD7KIHX U+5/MR8sOH5Xg63zL9DJ36YDNFs9NL7oBq5gUDDTMfbHNSWKbMcKTKqEAJUBSgVw Rlohh6ydUrPTJxw8UMG9oMFT3xCKEt/9fhipSGBoiW/SuKP//cyb5PC7pDxhfpqK vQhjIlnG/nz7QnE9dZ9k5zEdKmj1/9Bfxgq0aJHOK92+GOFWYFuVVrKxHrNRQrQ4 deLpYCsQbg5lU5K5wlBMvfre1bCHrp9WWGcty8oC9aEJBu+75v8rOuksLTNNV7yi ygk4FgCwzWe/yrs7kSX25x9hu93YmM//PM81AAJVozO21yLflZoREzfXctg/LEw= =w3hE -----END PGP SIGNATURE----- --14dae93409f38baf0504bc6f5143-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 07:25:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A4A0106566C for ; Fri, 30 Mar 2012 07:25:06 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id DEF518FC0C for ; Fri, 30 Mar 2012 07:25:05 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SDWCm-0002hs-2K for freebsd-net@freebsd.org; Fri, 30 Mar 2012 09:25:04 +0200 Received: from pool-108-35-132-213.nwrknj.fios.verizon.net ([108.35.132.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Mar 2012 09:25:03 +0200 Received: from ixew by pool-108-35-132-213.nwrknj.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Mar 2012 09:25:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: enoch Date: Fri, 30 Mar 2012 03:01:52 -0400 Lines: 26 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-108-35-132-213.nwrknj.fios.verizon.net User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 X-Enigmail-Version: 1.4 Subject: [nfe] DHCP failure on 8-stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:25:06 -0000 Recently it became extremely difficult to pass the DHCP discovery step on boot. Now I am using the buggy [nve] instead. Can anyone help? Thank you, Enoch. uname -a ~~~~~~~~ FreeBSD dome 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu Mar 29 14:37:00 EDT 2012 root@dome:/usr/obj/usr/src/sys/DOME amd64 nfe0 fails at DHCPDISCOVER. ifconfig: nfe0: flags=8843 metric 0 mtu 1500 options=82008 ether 00:1f:bc:00:19:dc inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 media: Ethernet autoselect (100baseTX ) status: active lspci: 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 07:38:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EBB0F106566B for ; Fri, 30 Mar 2012 07:38:25 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BA8818FC0A for ; Fri, 30 Mar 2012 07:38:25 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so1536550pbc.13 for ; Fri, 30 Mar 2012 00:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=YRAvr8UDodZJyP+docy2ZJw5XpNPhejOheTDS/6dHMA=; b=BfE5HFGhrqG/r7c1t1wye309wVi5zvkDW7sKX8r8L+c46dFZkpWSt81wx+8mzi9B/j Ywlq0BrTsOSMsAeI/vOULMLN1eN9ZmgWKRlYM4Iu87OGmrr4toWZH7SqtM0sw8RZIuhr 1Xdkizh0hDWpFZeN/QsY8QTkIxXtUC9rpnXc4Z2au0er+2oX7gN4LbE0Kdo9WxqpxThb GrJAO12wm0+X8S2NRn0zgvz4BB7hMhHu1oB1NGjGqKN2lDj+XXssdRKjOVSZElLoaHcE NSo3WZJrXElL8pr0JTTvIMqizE3YEDBBQiqC6kK3AbzyAls/7fklclZxkHmSWGMqzgsP rvtg== Received: by 10.68.135.105 with SMTP id pr9mr7365193pbb.49.1333093105374; Fri, 30 Mar 2012 00:38:25 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id m1sm6803306pbl.39.2012.03.30.00.38.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 00:38:24 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 30 Mar 2012 16:38:19 -0700 From: YongHyeon PYUN Date: Fri, 30 Mar 2012 16:38:19 -0700 To: enoch Message-ID: <20120330233819.GC7325@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [nfe] DHCP failure on 8-stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:38:26 -0000 On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: > Recently it became extremely difficult to pass the DHCP discovery step > on boot. Now I am using the buggy [nve] instead. > > Can anyone help? > Did you set synchronous_dhclient option in rc.conf? > Thank you, Enoch. > > uname -a > ~~~~~~~~ > FreeBSD dome 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu Mar 29 > 14:37:00 EDT 2012 root@dome:/usr/obj/usr/src/sys/DOME amd64 > > nfe0 fails at DHCPDISCOVER. > > ifconfig: > > nfe0: flags=8843 metric 0 mtu 1500 > options=82008 > ether 00:1f:bc:00:19:dc > inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > media: Ethernet autoselect (100baseTX ) > status: active > > lspci: > > 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 11:55:52 2012 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 1C2F8106567B for ; Fri, 30 Mar 2012 11:55:52 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 774728FC12 for ; Fri, 30 Mar 2012 11:55:51 +0000 (UTC) Received: (qmail 51866 invoked from network); 30 Mar 2012 11:48:12 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Mar 2012 11:48:12 -0000 Message-ID: <4F759DB3.2060706@freebsd.org> Date: Fri, 30 Mar 2012 13:49:07 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sergey Smitienko References: <4F7463CF.8010206@comsys.com.ua> In-Reply-To: <4F7463CF.8010206@comsys.com.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.0 generates incorrect SEC/ACK numbers under load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 11:55:52 -0000 On 29.03.2012 15:29, Sergey Smitienko wrote: > Hello. > > I've run into a problem with a web server runing FreeBSD 9.0/amd64. What > I believe is happening, is what server loses track of correct SEQ/ACK > numbers > on some connections. Here is an example: > > 15:20:00.347514 IP (tos 0x68, ttl 123, id 1181, offset 0, flags [DF], > proto TCP (6), length 52) > 93.72.14.220.49239> 193.178.147.113.80: Flags [S], cksum 0x6995 > (correct), seq 3881466934, win 8192, options [mss 1460,nop,wscale > 2,nop,nop,sackOK], length 0 > 15:20:00.347526 IP (tos 0x10, ttl 254, id 28065, offset 0, flags [DF], > proto TCP (6), length 44) > 193.178.147.113.80> 93.72.14.220.49239: Flags [S.], cksum 0x79fa > (correct), seq 2151790680, ack 3881466935, win 0, options [mss 1460], > length 0 The window reported in the SYN/ACK is zero and no window scaling is reported. Do you see this on good connections too? > 15:20:00.361812 IP (tos 0x68, ttl 123, id 1183, offset 0, flags [DF], > proto TCP (6), length 40) > 93.72.14.220.49239> 193.178.147.113.80: Flags [.], cksum 0x96c6 > (correct), seq 3881466935, ack 2151790681, win 64240, length 0 > 15:20:00.361869 IP (tos 0x10, ttl 254, id 31305, offset 0, flags [DF], > proto TCP (6), length 40) > 193.178.147.113.80> 93.72.14.220.49239: Flags [.], cksum 0x71b7 > (correct), seq 2151790681, ack 3881466935, win 8192, length 0 This packet is normally not necessary and it shouldn't be generated. Here it opens the window from zero to 8K (which is very small). Do you see it being generated on good connections too? > Client sends "GET" request > 15:20:48.236181 IP (tos 0x68, ttl 123, id 1353, offset 0, flags [DF], > proto TCP (6), length 626) > 93.72.14.220.49239> 193.178.147.113.80: Flags [P.], cksum 0x7fc9 > (correct), seq 3881466935:3881467521, ack 2151790681, win 64240, length 586 > > and then the "ping-pong" starts: > > 15:20:48.236198 IP (tos 0x0, ttl 254, id 63530, offset 0, flags [DF], > proto TCP (6), length 40) > 193.178.147.113.80> 93.72.14.220.49239: Flags [.], cksum 0x8a97 > (correct), seq 2991748588, ack 1985077892, win 8760, length 0 > 15:20:48.255998 IP (tos 0x68, ttl 123, id 1357, offset 0, flags [DF], > proto TCP (6), length 40) > 93.72.14.220.49239> 193.178.147.113.80: Flags [.], cksum 0x947c > (correct), seq 3881467521, ack 2151790681, win 64240, length 0 > 15:20:48.256015 IP (tos 0x0, ttl 254, id 53518, offset 0, flags [DF], > proto TCP (6), length 40) > 193.178.147.113.80> 93.72.14.220.49239: Flags [.], cksum 0x8a97 > (correct), seq 2991748588, ack 1985077892, win 8760, length 0 > 15:20:48.276084 IP (tos 0x68, ttl 123, id 1360, offset 0, flags [DF], > proto TCP (6), length 40) > 93.72.14.220.49239> 193.178.147.113.80: Flags [.], cksum 0x947c > (correct), seq 3881467521, ack 2151790681, win 64240, length 0 > 15:20:48.276099 IP (tos 0x0, ttl 254, id 42983, offset 0, flags [DF], > proto TCP (6), length 40) > 193.178.147.113.80> 93.72.14.220.49239: Flags [.], cksum 0x8a97 > (correct), seq 2991748588, ack 1985077892, win 8760, length 0 > 15:20:48.290914 IP (tos 0x68, ttl 123, id 1361, offset 0, flags [DF], > proto TCP (6), length 40) > 93.72.14.220.49239> 193.178.147.113.80: Flags [.], cksum 0x947c > (correct), seq 3881467521, ack 2151790681, win 64240, length 0 > This happens on about 0.01% of connections. This tcpdump is recorded on > the 193.178.147.113, before traffic hits the wire. > So it's not a NIC fault. Server is running nginx and serving static > content 200-500 request per second. > > Any ideas ? No smoking gun yet. The SYN/ACK is very dubious though in the first place. For the offset of SEQ and ACK it seems like some sort of inpcb mixup or 2MSL inference. What does "sysctl net.inet.tcp" on your server report? -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 13:04:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE3EA106564A; Fri, 30 Mar 2012 13:04:16 +0000 (UTC) (envelope-from hunter@comsys.com.ua) Received: from mail.ice-tech.com.ua (mail.ice-tech.com.ua [77.120.117.100]) by mx1.freebsd.org (Postfix) with ESMTP id 572998FC0C; Fri, 30 Mar 2012 13:04:15 +0000 (UTC) Received: from [94.247.224.226] (helo=hunters-MacBook-Pro.local) by mail.ice-tech.com.ua with esmtpa (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SDbUz-000Msx-Ld; Fri, 30 Mar 2012 16:04:13 +0300 Message-ID: <4F75AF4D.1040203@comsys.com.ua> Date: Fri, 30 Mar 2012 16:04:13 +0300 From: Sergey Smitienko User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Andre Oppermann References: <4F7463CF.8010206@comsys.com.ua> <4F759DB3.2060706@freebsd.org> In-Reply-To: <4F759DB3.2060706@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 94.247.224.226 X-SA-Exim-Mail-From: hunter@comsys.com.ua X-SA-Exim-Scanned: No (on mail.ice-tech.com.ua); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.0 generates incorrect SEC/ACK numbers under load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 13:04:16 -0000 Here you go, two sessions, one with win set in Syn/Ack packet and other with separate "windows open" Ack packet. 16:59:47.629750 IP (tos 0x0, ttl 123, id 55648, offset 0, flags [DF], proto TCP (6), length 48) 195.64.148.12.61153 > 193.178.147.113.80: Flags [S], cksum 0x5721 (correct), seq 770400880, win 65535, options [mss 1460,nop,nop,sackOK], length 0 16:59:47.629774 IP (tos 0x0, ttl 254, id 43755, offset 0, flags [DF], proto TCP (6), length 48) 193.178.147.113.80 > 195.64.148.12.61153: Flags [S.], cksum 0xeaa3 (correct), seq 2323563246, ack 770400881, win 8192, options [mss 1460,sackOK,eol], length 0 16:59:47.631873 IP (tos 0x0, ttl 123, id 40733, offset 0, flags [DF], proto TCP (6), length 40) 195.64.148.12.61153 > 193.178.147.113.80: Flags [.], cksum 0x3667 (correct), ack 2323563247, win 65535, length 0 16:59:47.633613 IP (tos 0x0, ttl 123, id 36942, offset 0, flags [DF], proto TCP (6), length 840) 195.64.148.12.61153 > 193.178.147.113.80: Flags [P.], cksum 0xcfb6 (correct), seq 770400881:770401681, ack 2323563247, win 65535, length 800 16:59:47.633710 IP (tos 0x0, ttl 254, id 22412, offset 0, flags [DF], proto TCP (6), length 1500) 193.178.147.113.80 > 195.64.148.12.61153: Flags [.], seq 2323563247:2323564707, ack 770401681, win 8760, length 1460 16:59:47.633721 IP (tos 0x0, ttl 254, id 22395, offset 0, flags [DF], proto TCP (6), length 340) 193.178.147.113.80 > 195.64.148.12.61153: Flags [P.], cksum 0x8323 (correct), seq 2323564707:2323565007, ack 770401681, win 8760, length 300 16:59:47.633745 IP (tos 0x0, ttl 254, id 17184, offset 0, flags [DF], proto TCP (6), length 40) 193.178.147.113.80 > 195.64.148.12.61153: Flags [F.], cksum 0x0a2e (correct), seq 2323565007, ack 770401681, win 8760, length 0 16:59:47.636215 IP (tos 0x0, ttl 123, id 65415, offset 0, flags [DF], proto TCP (6), length 40) 195.64.148.12.61153 > 193.178.147.113.80: Flags [.], cksum 0x2c67 (correct), ack 2323565007, win 65535, length 0 16:59:47.636607 IP (tos 0x0, ttl 123, id 48103, offset 0, flags [DF], proto TCP (6), length 40) 195.64.148.12.61153 > 193.178.147.113.80: Flags [.], cksum 0x2c66 (correct), ack 2323565008, win 65535, length 0 16:59:47.636841 IP (tos 0x0, ttl 123, id 39732, offset 0, flags [DF], proto TCP (6), length 40) 195.64.148.12.61153 > 193.178.147.113.80: Flags [F.], cksum 0x2c65 (correct), seq 770401681, ack 2323565008, win 65535, length 0 16:59:47.636855 IP (tos 0x0, ttl 254, id 37717, offset 0, flags [DF], proto TCP (6), length 40) 193.178.147.113.80 > 195.64.148.12.61153: Flags [.], cksum 0x0a2e (correct), ack 770401682, win 8759, length 0 17:01:58.437891 IP (tos 0x0, ttl 121, id 23760, offset 0, flags [DF], proto TCP (6), length 48) 92.231.64.37.61153 > 193.178.147.113.80: Flags [S], cksum 0x5c46 (correct), seq 3652856772, win 16384, options [mss 1452,nop,nop,sackOK], length 0 17:01:58.437907 IP (tos 0x10, ttl 254, id 61730, offset 0, flags [DF], proto TCP (6), length 44) 193.178.147.113.80 > 92.231.64.37.61153: Flags [S.], cksum 0x2c06 (correct), seq 3164719252, ack 3652856773, win 0, options [mss 1452], length 0 17:01:58.514354 IP (tos 0x0, ttl 121, id 23780, offset 0, flags [DF], proto TCP (6), length 40) 92.231.64.37.61153 > 193.178.147.113.80: Flags [.], cksum 0xffaa (correct), ack 3164719253, win 17424, length 0 17:01:58.514412 IP (tos 0x10, ttl 254, id 17560, offset 0, flags [DF], proto TCP (6), length 40) 193.178.147.113.80 > 92.231.64.37.61153: Flags [.], cksum 0x23bb (correct), ack 3652856773, win 8192, length 0 17:01:58.605052 IP (tos 0x0, ttl 121, id 23789, offset 0, flags [DF], proto TCP (6), length 690) 92.231.64.37.61153 > 193.178.147.113.80: Flags [P.], cksum 0x6b1c (correct), seq 3652856773:3652857423, ack 3164719253, win 17424, length 650 17:01:58.605123 IP (tos 0x0, ttl 254, id 54275, offset 0, flags [DF], proto TCP (6), length 1492) 193.178.147.113.80 > 92.231.64.37.61153: Flags [.], seq 3164719253:3164720705, ack 3652857423, win 8712, length 1452 17:01:58.605142 IP (tos 0x0, ttl 254, id 28400, offset 0, flags [DF], proto TCP (6), length 346) 193.178.147.113.80 > 92.231.64.37.61153: Flags [P.], cksum 0x6b55 (correct), seq 3164720705:3164721011, ack 3652857423, win 8712, length 306 17:01:58.605162 IP (tos 0x0, ttl 254, id 4658, offset 0, flags [DF], proto TCP (6), length 40) 193.178.147.113.80 > 92.231.64.37.61153: Flags [F.], cksum 0x184a (correct), seq 3164721011, ack 3652857423, win 8712, length 0 17:01:58.678888 IP (tos 0x0, ttl 121, id 23803, offset 0, flags [DF], proto TCP (6), length 40) 92.231.64.37.61153 > 193.178.147.113.80: Flags [.], cksum 0xf642 (correct), ack 3164721011, win 17424, length 0 17:01:58.680737 IP (tos 0x0, ttl 121, id 23804, offset 0, flags [DF], proto TCP (6), length 40) 92.231.64.37.61153 > 193.178.147.113.80: Flags [.], cksum 0xf641 (correct), ack 3164721012, win 17424, length 0 17:01:58.682290 IP (tos 0x0, ttl 121, id 23806, offset 0, flags [DF], proto TCP (6), length 40) 92.231.64.37.61153 > 193.178.147.113.80: Flags [F.], cksum 0xf640 (correct), seq 3652857423, ack 3164721012, win 17424, length 0 17:01:58.682314 IP (tos 0x0, ttl 254, id 64325, offset 0, flags [DF], proto TCP (6), length 40) 193.178.147.113.80 > 92.231.64.37.61153: Flags [.], cksum 0x184a (correct), ack 3652857424, win 8711, length 0 > sysctl net.inet.tcp net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 1460 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 8192 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1220 net.inet.tcp.cc.available: newreno net.inet.tcp.cc.algorithm: newreno net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 519 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.recvbuf_max: 2097152 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 0 net.inet.tcp.insecure_rst: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.ecn.enable: 0 net.inet.tcp.abc_l_var: 2 net.inet.tcp.rfc3465: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 65536 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 0 net.inet.tcp.tso: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 0 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 12852 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.soreceive_stream: 0 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 157 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 8192 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 1024 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 102400 net.inet.tcp.syncache.bucketlimit: 100 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.per_cpu_timers: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 30000 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 102400 From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 13:29:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F0FC1065677 for ; Fri, 30 Mar 2012 13:29:24 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id E50018FC08 for ; Fri, 30 Mar 2012 13:29:23 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so476007wib.13 for ; Fri, 30 Mar 2012 06:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gxiA2KThcyAy3d3zsi2Fj0UC8/RHVyjl4zqPSqd0Z2k=; b=R2e2IINmUPCdGL+q1DyCwe2XThGzsSV643DWi+xDHJokNxcu7U+Ak4kfFQbjFxPaRw rcpK2Iq9gkZM8rkX49PF2LdLnnVRyxiu/H/jCpzQBqKkszGpWM5erlsYO/XdS08VBIv1 gDRPBLDQCDHVcMme46SemZ8OjEdlM5wCBag5wAeCykRK3TEbpCE+b9S2a4eH++FVPFWA ygjw9YwwldhupLNJ3ad4k7ca7kDwfD1AMi1Abs9LcEPlhDpLfk6B5PL8jFm2uMSJID7F ZdzSu2SffO9+/EUtdglkUjJFV0WFuvbwkUpDmKTCAdM6/LU7eSxOnMdwvwqUTgYdbusi 7Cfw== MIME-Version: 1.0 Received: by 10.180.101.230 with SMTP id fj6mr6497936wib.13.1333114162622; Fri, 30 Mar 2012 06:29:22 -0700 (PDT) Received: by 10.180.79.137 with HTTP; Fri, 30 Mar 2012 06:29:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Mar 2012 09:29:22 -0400 Message-ID: From: Ryan Stone To: "Li, Qing" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net Subject: Re: Removing an IPv6 address does not remove NDP entries on that subnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 13:29:24 -0000 On Fri, Mar 30, 2012 at 12:28 AM, Li, Qing wrote: >> * In a way this is a good thing as in6_lltable_prefix_free() is >> guaranteed to crash your kernel in two different ways, and that's not >> counting the race conditions that it's subject to. >> > > =A0 =A0 =A0 =A0Could you please elaborate with some details on the two di= fferent > =A0 =A0 =A0 =A0ways in6_lltable_prefix_free() crashes the kernel definiti= vely ? First, it calls callout_drain on lle->le_timer, but that is never initialized for a v6 llentry. Second, it never stops the ln_timer_ch callout before it frees the llentry. Third, it modifies the lltable without holding IF_AFDATA_LOCK(in.c has the third problem: see the -net discussion about kern/165863). From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 14:14:47 2012 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 C6F5F1065672 for ; Fri, 30 Mar 2012 14:14:47 +0000 (UTC) (envelope-from krjeschke@omniti.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 483608FC1F for ; Fri, 30 Mar 2012 14:14:47 +0000 (UTC) Received: by obbwc18 with SMTP id wc18so1076967obb.13 for ; Fri, 30 Mar 2012 07:14:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:x-gm-message-state :content-type; bh=cOtWW0J9WhR6dke3AFp81tAPbaQBZp8OhgrlXdaTUjg=; b=DBNcRH+Dz4kckKC26OtmuLH7h9SBknd+hu0d0SnPbVlDjOO2VYczW3l7R6MD31fNpZ Z1NO619SmUdhJDVAHVE+VpER3ldhpoyCUls5ife48rnnlOCE3ZzCuUjrFe8a5Rf3BP4/ tJ3R9vXQxcDVc32RL3nj6eQ7R4126G8VZhq94SktekT27gscjQ/1wvz18Skbh0Ethn6a alCZn50yr1o3P7Nu1ofh8MmueZ/gsbcpkAjuUMfJsOnJtMLEnKQwqpJzqoSNFId9wZl6 zt89wI+25D/Jo3oelUI/JOfQsONJHHT2KlMmSQ35ucg4rFX1eRHy/FSuaq9OLupoBX5z DqKA== MIME-Version: 1.0 Received: by 10.60.25.73 with SMTP id a9mr3152374oeg.63.1333116886858; Fri, 30 Mar 2012 07:14:46 -0700 (PDT) Received: by 10.60.23.103 with HTTP; Fri, 30 Mar 2012 07:14:46 -0700 (PDT) Date: Fri, 30 Mar 2012 10:14:46 -0400 Message-ID: From: Katherine Jeschke To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQkbBuudVf4j9dVdJ3EIJNev/dsei/Q0qcRK4fRR77uvk06FZJzD0KC6OBqRwNtHjGOHOd44 Content-Type: text/plain; charset=ISO-8859-1 Subject: Surge 2012 CFP is Open! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 14:14:47 -0000 Surge 2012, the scalability conference, September 27-28, Baltimore, MD has opened its CFP. Please visit http://omniti.com/surge/2012/cfp for details. -- Katherine Jeschke Director of Marketing and Creative Services OmniTI Computer Consulting, Inc. 7070 Samuel Morse Drive, Ste.150 Columbia, MD 21046 O: 443-325-1357, 222 F: 410/872-4911 C: 443/643-6140 omniti.com Surge2012: http://omniti.com/surge/2012 PG Corridor Days - DC: http://pgday.bwpug.org/ The information contained in this electronic message and any attached documents is privileged, confidential, and protected from disclosure. If you are not the intended recipient, note that any review, disclosure, copying, distribution, or use of the contents of this electronic message or any attached documents is prohibited. If you have received this communication in error, please destroy it and notify us immediately by telephone (1-443-325-1360) or by electronic mail (info@omniti.com). Thank you. From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 14:22:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2EF1106564A for ; Fri, 30 Mar 2012 14:22:33 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id AA49B8FC16 for ; Fri, 30 Mar 2012 14:22:33 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4F2D62054D for ; Fri, 30 Mar 2012 10:22:27 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 30 Mar 2012 10:22:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:subject:content-type:content-transfer-encoding; s=smtpout; bh=nrWz6wli158vuPkE98vSHeINNCU=; b=UFu15aZ5iHZwuIZTn Lepfc0MHK4f/THrUnVZu6iF2fyv9j+/Is3DAz0jExZJeHhyd0BDvHHMjcIwZa6tO tG9NC12fA4NqkSZRLHzl51fUTM4P/4XWe88Zvx+5EeDcMaaDlcpcP39UQuUtzreq 5WNn7fOd4YTNZVK2kQyQhFvxu0= X-Sasl-enc: EMmjGJlQNS/yQpXFKREctxeREaXkU5Gxrg7IZjeANHHi 1333117346 Received: from [192.168.1.124] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPSA id 41BE38E008D for ; Fri, 30 Mar 2012 10:22:25 -0400 (EDT) Message-ID: <4F75C1A3.4030401@freebsd.org> Date: Sat, 31 Mar 2012 01:22:27 +1100 From: Darren Reed Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-AU; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:22:34 -0000 I've been tracking down some problems with FreeBSD's sending of TCP packets and seem to have come to the conclusion that in FreeBSD 8.2-RELEASE, when the system is working with a TCP connection that has a moderate delay in it, FreeBSD's TCP ignores the other end telling it that the window size is now 0 and continues to send data. I suspect that this is meant to make sense because it is expecting that the ACK that will open up the window is already in transit. But that only accounts for the condition where the TCP on FreeBSD can compute and decide that the remote TCP will have its buffer full. What I find harder to accept is that when FreeBSD's TCP receives a TCP packet from the remote end advertising a window of 0, FreeBSD's response is to send more data and not a window probe or is that now the expected behaviour? And whilst you might say "ok" for a packet of data, I'm somewhat hard pressed to explain why FreeBSD's TCP sends multiple packets with data in them after receiving a TCP packet from the other end advertising a zero window size. However this causes a problem with firewalls (;_) that are close to the FreeBSD end because for them, it appears that FreeBSD is sending data outside of its window. Is this a known problem? If so, has it been fixed in a later version of FreeBSD? (No, I haven't tested anything other than 8.2) In the packet flow below, 192.168.1.1 is FreeBSD and 10.1.1.1 is the other end. Darren -------------- DATA(1440):seq(5f665916|5f665eb6) ack(9349a95d)+4096=9349b95d pass ip #48089 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(1240):seq(9349b485|9349b95d) ack(5f664296)+66240=5f674556 pass ip #57457 1304(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(5f665eb6|5f666456) ack(9349a95d)+4096=9349b95d pass ip #48149 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(0):seq(9349b95d|9349b95d) ack(5f664296)+66240=5f674556 pass ip #57459 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(5f666456|5f6669f6) ack(9349a95d)+4096=9349b95d UFD2:td_end(5f6669f6) maxend(5f674556) pass ip #48150 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(0):seq(9349b95d|9349b95d) ack(5f664296)+66240=5f674556 pass ip #57460 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(5f6669f6|5f666f96) ack(9349a95d)+4096=9349b95d pass ip #48178 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(0):seq(9349b95d|9349b95d) ack(5f664296)+66240=5f674556 pass ip #57461 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(5f666f96|5f667536) ack(9349a95d)+4096=9349b95d pass ip #48181 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(0):seq(9349b95d|9349b95d) ack(5f664296)+66240=5f674556 pass ip #57462 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(5f667536|5f667ad6) ack(9349a95d)+4096=9349b95d pass ip #48182 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(0):seq(9349b95d|9349b95d) ack(5f664296)+66240=5f674556 pass ip #57463 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(5f667ad6|5f668076) ack(9349a95d)+4096=9349b95d pass ip #48183 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(0):seq(5f668076|5f668076) ack(9349a95d)+8192=9349c95d ack(9349a95d)+win(8192) pass ip #0 52(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(0):seq(9349b95d|9349b95d) ack(5f664296)+66240=5f674556 pass ip #57464 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1428):seq(9349b95d|9349bef1) ack(5f664296)+66240=5f674556 pass ip #57465 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1428):seq(9349bef1|9349c485) ack(5f664296)+66240=5f674556 pass ip #57466 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(5f668076|5f668616) ack(9349a95d)+8192=9349c95d pass ip #48184 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(0):seq(5f668bb6|5f668bb6) ack(9349a95d)+12288=9349d95d ack(9349a95d)+win(12288) pass ip #0 52(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(1240):seq(9349c485|9349c95d) ack(5f664296)+66240=5f674556 pass ip #57467 1304(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1428):seq(9349c95d|9349cef1) ack(5f664296)+66240=5f674556 pass ip #57468 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1428):seq(9349cef1|9349d485) ack(5f664296)+66240=5f674556 pass ip #57469 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(5f668bb6|5f669156) ack(9349a95d)+12288=9349d95d pass ip #48186 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(1240):seq(9349d485|9349d95d) ack(5f664296)+66240=5f674556 pass ip #57470 1312(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(5f664296|5f664836) ack(9349a95d)+12288=9349d95d pass ip #48193 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(0):seq(9349d95d|9349d95d) ack(5f668616)+48960=5f674556 pass ip #57471 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(0):seq(9349d95d|9349d95d) ack(5f668616)+54088=5f67595e ack(5f668616)+win(54088) pass ip #57476 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(0):seq(9349d95d|9349d95d) ack(5f668616)+60632=5f6772ee ack(5f668616)+win(60632) pass ip #57489 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(0):seq(9349d95d|9349d95d) ack(5f668616)+64728=5f6782ee ack(5f668616)+win(64728) pass ip #57491 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(0):seq(5f6696f6|5f6696f6) ack(9349b485)+9408=9349d945 pass ip #0 52(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(0):seq(5f6696f6|5f6696f6) ack(9349bef1)+6752=9349d951 pass ip #0 52(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(0):seq(5f6696f6|5f6696f6) ack(9349c95d)+4096=9349d95d pass ip #0 52(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(0):seq(5f6696f6|5f6696f6) ack(9349d485)+1216=9349d945 pass ip #0 52(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- win==0 DATA(1440):seq(5f668616|5f668bb6) ack(9349d95d)+1=9349d95e pass ip #48360 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A -------------- DATA(1440):seq(9349d95d|9349defd) ack(5f669156)+63360=5f6788d6 ack(5f669156) seq(9349d95d) block ip #57494 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(9349defd|9349e49d) ack(5f669156)+63360=5f6788d6 ackskew 1440 ack(5f669156) seq(9349defd) block ip #57495 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(9349e49d|9349ea3d) ack(5f669156)+63360=5f6788d6 ackskew 1440 ack(5f669156) seq(9349e49d) block ip #57496 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(9349ea3d|9349efdd) ack(5f669156)+63360=5f6788d6 ackskew 1440 ack(5f669156) seq(9349ea3d) block ip #57497 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- DATA(1440):seq(9349efdd|9349f57d) ack(5f669156)+63360=5f6788d6 ackskew 1440 ack(5f669156) seq(9349efdd) block ip #57498 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A -------------- From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 14:41:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F12F11065675 for ; Fri, 30 Mar 2012 14:41:03 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id A933B8FC18 for ; Fri, 30 Mar 2012 14:41:03 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SDd0Z-0002pr-8Q for freebsd-net@freebsd.org; Fri, 30 Mar 2012 16:40:55 +0200 Received: from pool-108-35-132-213.nwrknj.fios.verizon.net ([108.35.132.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Mar 2012 16:40:55 +0200 Received: from ixew by pool-108-35-132-213.nwrknj.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Mar 2012 16:40:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: enoch Date: Fri, 30 Mar 2012 10:40:44 -0400 Lines: 49 Message-ID: <4F75C5EC.6090303@hotmail.com> References: <20120330233819.GC7325@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org Cc: freebsd-net@freebsd.org X-Gmane-NNTP-Posting-Host: pool-108-35-132-213.nwrknj.fios.verizon.net User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 In-Reply-To: <20120330233819.GC7325@michelle.cdnetworks.com> X-Enigmail-Version: 1.4 Subject: Re: [nfe] DHCP failure on 8-stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 14:41:04 -0000 On 03/30/2012 19:38, YongHyeon PYUN wrote: > On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: >> Recently it became extremely difficult to pass the DHCP discovery step >> on boot. Now I am using the buggy [nve] instead. >> >> Can anyone help? >> > > Did you set synchronous_dhclient option in rc.conf? > Yes: ifconfig_nfe0="SYNCDHCP" I guess [nfe] is undergoing gradual devel changes of some sort as before it had some chance of reporting "empty headers" on initial ifconfig and refusing to work. Sorry, I should have reported when encountering the first problems rather than solve by reboot. In any case, the alternative [nve] should be marked "dangerous" as under heavy load it tends to crash the system. Thanks, Enoch. >> >> uname -a >> ~~~~~~~~ >> FreeBSD dome 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #7: Thu Mar 29 >> 14:37:00 EDT 2012 root@dome:/usr/obj/usr/src/sys/DOME amd64 >> >> nfe0 fails at DHCPDISCOVER. >> >> ifconfig: >> >> nfe0: flags=8843 metric 0 mtu 1500 >> options=82008 >> ether 00:1f:bc:00:19:dc >> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 >> media: Ethernet autoselect (100baseTX ) >> status: active >> >> lspci: >> >> 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 15:13:18 2012 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 E1081106566B for ; Fri, 30 Mar 2012 15:13:18 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 0F1E18FC08 for ; Fri, 30 Mar 2012 15:13:17 +0000 (UTC) Received: (qmail 52653 invoked from network); 30 Mar 2012 15:12:18 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Mar 2012 15:12:18 -0000 Message-ID: <4F75CD8A.2050509@freebsd.org> Date: Fri, 30 Mar 2012 17:13:14 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sergey Smitienko References: <4F7463CF.8010206@comsys.com.ua> <4F759DB3.2060706@freebsd.org> <4F75AF4D.1040203@comsys.com.ua> In-Reply-To: <4F75AF4D.1040203@comsys.com.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.0 generates incorrect SEC/ACK numbers under load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 15:13:19 -0000 On 30.03.2012 15:04, Sergey Smitienko wrote: > Here you go, two sessions, one with win set in Syn/Ack packet and other > with separate "windows open" Ack packet. Thanks for the tcpdumps. The window update issue seems to be separate from the seq#ack# problem. Why do set the recvspace to the very low value of 8192? Do you have any special settings on this system? Like transparent proxying, NAT and so on? Could you please try the patch after my signature to get a first grip on the window update problem. -- Andre $ svn diff netinet/tcp_syncache.c Index: netinet/tcp_syncache.c =================================================================== --- netinet/tcp_syncache.c (revision 233227) +++ netinet/tcp_syncache.c (working copy) @@ -1080,6 +1080,13 @@ sb_hiwat = so->so_rcv.sb_hiwat; ltflags = (tp->t_flags & (TF_NOOPT | TF_SIGNATURE)); + if (win != sb_hiwat && + (s = tcp_log_addrs(inc, th, NULL, NULL))) { + log(LOG_DEBUG, "%s; %s: win != sb_hiwat\n", + s, __func__); + free(s, M_TCPLOG); + } + /* By the time we drop the lock these should no longer be used. */ so = NULL; tp = NULL; > 16:59:47.629750 IP (tos 0x0, ttl 123, id 55648, offset 0, flags [DF], > proto TCP (6), length 48) > 195.64.148.12.61153> 193.178.147.113.80: Flags [S], cksum 0x5721 > (correct), seq 770400880, win 65535, options [mss 1460,nop,nop,sackOK], > length 0 > 16:59:47.629774 IP (tos 0x0, ttl 254, id 43755, offset 0, flags [DF], > proto TCP (6), length 48) > 193.178.147.113.80> 195.64.148.12.61153: Flags [S.], cksum 0xeaa3 > (correct), seq 2323563246, ack 770400881, win 8192, options [mss > 1460,sackOK,eol], length 0 > 16:59:47.631873 IP (tos 0x0, ttl 123, id 40733, offset 0, flags [DF], > proto TCP (6), length 40) > 195.64.148.12.61153> 193.178.147.113.80: Flags [.], cksum 0x3667 > (correct), ack 2323563247, win 65535, length 0 > 16:59:47.633613 IP (tos 0x0, ttl 123, id 36942, offset 0, flags [DF], > proto TCP (6), length 840) > 195.64.148.12.61153> 193.178.147.113.80: Flags [P.], cksum 0xcfb6 > (correct), seq 770400881:770401681, ack 2323563247, win 65535, length 800 > 16:59:47.633710 IP (tos 0x0, ttl 254, id 22412, offset 0, flags [DF], > proto TCP (6), length 1500) > 193.178.147.113.80> 195.64.148.12.61153: Flags [.], seq > 2323563247:2323564707, ack 770401681, win 8760, length 1460 > 16:59:47.633721 IP (tos 0x0, ttl 254, id 22395, offset 0, flags [DF], > proto TCP (6), length 340) > 193.178.147.113.80> 195.64.148.12.61153: Flags [P.], cksum 0x8323 > (correct), seq 2323564707:2323565007, ack 770401681, win 8760, length 300 > 16:59:47.633745 IP (tos 0x0, ttl 254, id 17184, offset 0, flags [DF], > proto TCP (6), length 40) > 193.178.147.113.80> 195.64.148.12.61153: Flags [F.], cksum 0x0a2e > (correct), seq 2323565007, ack 770401681, win 8760, length 0 > 16:59:47.636215 IP (tos 0x0, ttl 123, id 65415, offset 0, flags [DF], > proto TCP (6), length 40) > 195.64.148.12.61153> 193.178.147.113.80: Flags [.], cksum 0x2c67 > (correct), ack 2323565007, win 65535, length 0 > 16:59:47.636607 IP (tos 0x0, ttl 123, id 48103, offset 0, flags [DF], > proto TCP (6), length 40) > 195.64.148.12.61153> 193.178.147.113.80: Flags [.], cksum 0x2c66 > (correct), ack 2323565008, win 65535, length 0 > 16:59:47.636841 IP (tos 0x0, ttl 123, id 39732, offset 0, flags [DF], > proto TCP (6), length 40) > 195.64.148.12.61153> 193.178.147.113.80: Flags [F.], cksum 0x2c65 > (correct), seq 770401681, ack 2323565008, win 65535, length 0 > 16:59:47.636855 IP (tos 0x0, ttl 254, id 37717, offset 0, flags [DF], > proto TCP (6), length 40) > 193.178.147.113.80> 195.64.148.12.61153: Flags [.], cksum 0x0a2e > (correct), ack 770401682, win 8759, length 0 > 17:01:58.437891 IP (tos 0x0, ttl 121, id 23760, offset 0, flags [DF], > proto TCP (6), length 48) > > > 92.231.64.37.61153> 193.178.147.113.80: Flags [S], cksum 0x5c46 > (correct), seq 3652856772, win 16384, options [mss 1452,nop,nop,sackOK], > length 0 > 17:01:58.437907 IP (tos 0x10, ttl 254, id 61730, offset 0, flags [DF], > proto TCP (6), length 44) > 193.178.147.113.80> 92.231.64.37.61153: Flags [S.], cksum 0x2c06 > (correct), seq 3164719252, ack 3652856773, win 0, options [mss 1452], > length 0 > 17:01:58.514354 IP (tos 0x0, ttl 121, id 23780, offset 0, flags [DF], > proto TCP (6), length 40) > 92.231.64.37.61153> 193.178.147.113.80: Flags [.], cksum 0xffaa > (correct), ack 3164719253, win 17424, length 0 > 17:01:58.514412 IP (tos 0x10, ttl 254, id 17560, offset 0, flags [DF], > proto TCP (6), length 40) > 193.178.147.113.80> 92.231.64.37.61153: Flags [.], cksum 0x23bb > (correct), ack 3652856773, win 8192, length 0 > 17:01:58.605052 IP (tos 0x0, ttl 121, id 23789, offset 0, flags [DF], > proto TCP (6), length 690) > 92.231.64.37.61153> 193.178.147.113.80: Flags [P.], cksum 0x6b1c > (correct), seq 3652856773:3652857423, ack 3164719253, win 17424, length 650 > 17:01:58.605123 IP (tos 0x0, ttl 254, id 54275, offset 0, flags [DF], > proto TCP (6), length 1492) > 193.178.147.113.80> 92.231.64.37.61153: Flags [.], seq > 3164719253:3164720705, ack 3652857423, win 8712, length 1452 > 17:01:58.605142 IP (tos 0x0, ttl 254, id 28400, offset 0, flags [DF], > proto TCP (6), length 346) > 193.178.147.113.80> 92.231.64.37.61153: Flags [P.], cksum 0x6b55 > (correct), seq 3164720705:3164721011, ack 3652857423, win 8712, length 306 > 17:01:58.605162 IP (tos 0x0, ttl 254, id 4658, offset 0, flags [DF], > proto TCP (6), length 40) > 193.178.147.113.80> 92.231.64.37.61153: Flags [F.], cksum 0x184a > (correct), seq 3164721011, ack 3652857423, win 8712, length 0 > 17:01:58.678888 IP (tos 0x0, ttl 121, id 23803, offset 0, flags [DF], > proto TCP (6), length 40) > 92.231.64.37.61153> 193.178.147.113.80: Flags [.], cksum 0xf642 > (correct), ack 3164721011, win 17424, length 0 > 17:01:58.680737 IP (tos 0x0, ttl 121, id 23804, offset 0, flags [DF], > proto TCP (6), length 40) > 92.231.64.37.61153> 193.178.147.113.80: Flags [.], cksum 0xf641 > (correct), ack 3164721012, win 17424, length 0 > 17:01:58.682290 IP (tos 0x0, ttl 121, id 23806, offset 0, flags [DF], > proto TCP (6), length 40) > 92.231.64.37.61153> 193.178.147.113.80: Flags [F.], cksum 0xf640 > (correct), seq 3652857423, ack 3164721012, win 17424, length 0 > 17:01:58.682314 IP (tos 0x0, ttl 254, id 64325, offset 0, flags [DF], > proto TCP (6), length 40) > 193.178.147.113.80> 92.231.64.37.61153: Flags [.], cksum 0x184a > (correct), ack 3652857424, win 8711, length 0 > > >> sysctl net.inet.tcp > net.inet.tcp.rfc1323: 1 > net.inet.tcp.mssdflt: 1460 > net.inet.tcp.keepidle: 7200000 > net.inet.tcp.keepintvl: 75000 > net.inet.tcp.sendspace: 16384 > net.inet.tcp.recvspace: 8192 > net.inet.tcp.keepinit: 75000 > net.inet.tcp.delacktime: 100 > net.inet.tcp.v6mssdflt: 1220 > net.inet.tcp.cc.available: newreno > net.inet.tcp.cc.algorithm: newreno > net.inet.tcp.hostcache.purge: 0 > net.inet.tcp.hostcache.prune: 300 > net.inet.tcp.hostcache.expire: 3600 > net.inet.tcp.hostcache.count: 519 > net.inet.tcp.hostcache.bucketlimit: 30 > net.inet.tcp.hostcache.hashsize: 512 > net.inet.tcp.hostcache.cachelimit: 15360 > net.inet.tcp.recvbuf_max: 2097152 > net.inet.tcp.recvbuf_inc: 16384 > net.inet.tcp.recvbuf_auto: 0 > net.inet.tcp.insecure_rst: 0 > net.inet.tcp.ecn.maxretries: 1 > net.inet.tcp.ecn.enable: 0 > net.inet.tcp.abc_l_var: 2 > net.inet.tcp.rfc3465: 1 > net.inet.tcp.rfc3390: 1 > net.inet.tcp.rfc3042: 1 > net.inet.tcp.drop_synfin: 0 > net.inet.tcp.delayed_ack: 1 > net.inet.tcp.blackhole: 0 > net.inet.tcp.log_in_vain: 0 > net.inet.tcp.sendbuf_max: 65536 > net.inet.tcp.sendbuf_inc: 8192 > net.inet.tcp.sendbuf_auto: 0 > net.inet.tcp.tso: 1 > net.inet.tcp.local_slowstart_flightsize: 4 > net.inet.tcp.slowstart_flightsize: 1 > net.inet.tcp.path_mtu_discovery: 1 > net.inet.tcp.reass.overflows: 0 > net.inet.tcp.reass.cursegments: 0 > net.inet.tcp.reass.maxsegments: 12852 > net.inet.tcp.sack.globalholes: 0 > net.inet.tcp.sack.globalmaxholes: 65536 > net.inet.tcp.sack.maxholes: 128 > net.inet.tcp.sack.enable: 1 > net.inet.tcp.soreceive_stream: 0 > net.inet.tcp.isn_reseed_interval: 0 > net.inet.tcp.icmp_may_rst: 1 > net.inet.tcp.pcbcount: 157 > net.inet.tcp.do_tcpdrain: 1 > net.inet.tcp.tcbhashsize: 8192 > net.inet.tcp.log_debug: 0 > net.inet.tcp.minmss: 216 > net.inet.tcp.syncache.rst_on_sock_fail: 1 > net.inet.tcp.syncache.rexmtlimit: 3 > net.inet.tcp.syncache.hashsize: 1024 > net.inet.tcp.syncache.count: 0 > net.inet.tcp.syncache.cachelimit: 102400 > net.inet.tcp.syncache.bucketlimit: 100 > net.inet.tcp.syncookies_only: 0 > net.inet.tcp.syncookies: 1 > net.inet.tcp.timer_race: 0 > net.inet.tcp.per_cpu_timers: 0 > net.inet.tcp.finwait2_timeout: 60000 > net.inet.tcp.fast_finwait2_recycle: 0 > net.inet.tcp.always_keepalive: 1 > net.inet.tcp.rexmit_slop: 200 > net.inet.tcp.rexmit_min: 30 > net.inet.tcp.msl: 30000 > net.inet.tcp.nolocaltimewait: 0 > net.inet.tcp.maxtcptw: 102400 > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 16:01:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 602F71065672 for ; Fri, 30 Mar 2012 16:01:01 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 077108FC15 for ; Fri, 30 Mar 2012 16:01:00 +0000 (UTC) Received: by yenl9 with SMTP id l9so513994yen.13 for ; Fri, 30 Mar 2012 09:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :in-reply-to:content-type; bh=bNGQqrUKfGxnhaHEuWqDNT3POmfs7O6UjR7FoYI1DBc=; b=EHkYEBdpiQmuSl5jWWyK0c2ShwClsjHHDHTYGsg3Qhtf18AFKqceSzKBK/kPyCuFrd vAniT0rRRnotaatxUhYqFyYWIIUf0Vp3wC935EqpTIIwdIRyN6VUZLZdIIQbLMnAG9wr P6n3YY9k2GVials8JA2UjkGtrVW0H+VXLaEH0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :in-reply-to:x-gm-message-state:content-type; bh=bNGQqrUKfGxnhaHEuWqDNT3POmfs7O6UjR7FoYI1DBc=; b=puPxT+zQ/4tJZI2+9mZqqDBXHcjfxF1+UOkBhXGcSgYa3bC17iFqzEbimR9lj/sAZR HNB8cNBxMs7hUEf/LEjasbrqDRv9wVhGl68h5P/Q9Y8l5Lladq1Rm1+JDIzySE8TahZC lptH4lMI4fGjmgYJvdT5ZJytucJO6I7WCrvrR7jnaJPs6le6A7DnI/lm4dWpaiel9YI4 oNFDE1iZxLnRmm5awATfcZuTmHWNyxjA/XsgG9zazoYqxy8t1PlBAwdui4UM0Jz4LPxa /gYCI16Du8Ms69kjWQjf7J4rZDqJxofgISAAaNuvQL0MOjhZqC3N8d7b2KMgytr8JsIa ESrA== Received: by 10.50.159.196 with SMTP id xe4mr1798891igb.17.1333123259921; Fri, 30 Mar 2012 09:00:59 -0700 (PDT) Received: from DataIX.net ([99.181.151.192]) by mx.google.com with ESMTPS id l9sm2609206iga.6.2012.03.30.09.00.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 09:00:59 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q2UG0uEq001643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Mar 2012 12:00:56 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q2UG0tNS001576; Fri, 30 Mar 2012 12:00:56 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Fri, 30 Mar 2012 12:00:55 -0400 From: Jason Hellenthal To: Darren Reed Message-ID: <20120330160055.GB78586@DataIX.net> References: <4F75C1A3.4030401@freebsd.org> MIME-Version: 1.0 In-Reply-To: <4F75C1A3.4030401@freebsd.org> X-Gm-Message-State: ALoCoQkbbCLmXlT6aFomcWKHDuhLCNE4x40RSQjlSu0RErKEuKbHpkn3QJKmPfiuX/oDbJMCXPjQ Content-Type: multipart/mixed; boundary=14dae934059b5a91d004bc77f24d Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 16:01:01 -0000 --14dae934059b5a91d004bc77f24d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 31, 2012 at 01:22:27AM +1100, Darren Reed wrote: > I've been tracking down some problems with FreeBSD's sending > of TCP packets and seem to have come to the conclusion that > in FreeBSD 8.2-RELEASE, when the system is working with a > TCP connection that has a moderate delay in it, FreeBSD's > TCP ignores the other end telling it that the window size > is now 0 and continues to send data. I suspect that this is > meant to make sense because it is expecting that the ACK > that will open up the window is already in transit. But that > only accounts for the condition where the TCP on FreeBSD can > compute and decide that the remote TCP will have its buffer > full. What I find harder to accept is that when FreeBSD's > TCP receives a TCP packet from the remote end advertising > a window of 0, FreeBSD's response is to send more data and > not a window probe or is that now the expected behaviour? > And whilst you might say "ok" for a packet of data, I'm > somewhat hard pressed to explain why FreeBSD's TCP sends > multiple packets with data in them after receiving a TCP > packet from the other end advertising a zero window size. >=20 > However this causes a problem with firewalls (;_) that are > close to the FreeBSD end because for them, it appears that > FreeBSD is sending data outside of its window. >=20 > Is this a known problem? > If so, has it been fixed in a later version of FreeBSD? > (No, I haven't tested anything other than 8.2) >=20 > In the packet flow below, 192.168.1.1 is FreeBSD and 10.1.1.1 > is the other end. >=20 > Darren Hi Darren, I do believe this is the following bug at first glance that was patched after 8.2-RELEASE. and has to do more with x64 systems more than x32. See: "A Tale of a TCP Bug" for details... http://blogmal.42.org/tidbits/tcp-bug.story http://lists.freebsd.org/pipermail/freebsd-net/2011-April/028466.html >=20 > -------------- > DATA(1440):seq(5f665916|5f665eb6) ack(9349a95d)+4096=3D9349b95d > pass ip #48089 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(1240):seq(9349b485|9349b95d) ack(5f664296)+66240=3D5f674556 > pass ip #57457 1304(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(5f665eb6|5f666456) ack(9349a95d)+4096=3D9349b95d > pass ip #48149 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(0):seq(9349b95d|9349b95d) ack(5f664296)+66240=3D5f674556 > pass ip #57459 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(5f666456|5f6669f6) ack(9349a95d)+4096=3D9349b95d > UFD2:td_end(5f6669f6) maxend(5f674556) > pass ip #48150 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(0):seq(9349b95d|9349b95d) ack(5f664296)+66240=3D5f674556 > pass ip #57460 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(5f6669f6|5f666f96) ack(9349a95d)+4096=3D9349b95d > pass ip #48178 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(0):seq(9349b95d|9349b95d) ack(5f664296)+66240=3D5f674556 > pass ip #57461 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(5f666f96|5f667536) ack(9349a95d)+4096=3D9349b95d > pass ip #48181 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(0):seq(9349b95d|9349b95d) ack(5f664296)+66240=3D5f674556 > pass ip #57462 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(5f667536|5f667ad6) ack(9349a95d)+4096=3D9349b95d > pass ip #48182 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(0):seq(9349b95d|9349b95d) ack(5f664296)+66240=3D5f674556 > pass ip #57463 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(5f667ad6|5f668076) ack(9349a95d)+4096=3D9349b95d > pass ip #48183 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(0):seq(5f668076|5f668076) ack(9349a95d)+8192=3D9349c95d > ack(9349a95d)+win(8192) > pass ip #0 52(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(0):seq(9349b95d|9349b95d) ack(5f664296)+66240=3D5f674556 > pass ip #57464 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1428):seq(9349b95d|9349bef1) ack(5f664296)+66240=3D5f674556 > pass ip #57465 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1428):seq(9349bef1|9349c485) ack(5f664296)+66240=3D5f674556 > pass ip #57466 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(5f668076|5f668616) ack(9349a95d)+8192=3D9349c95d > pass ip #48184 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(0):seq(5f668bb6|5f668bb6) ack(9349a95d)+12288=3D9349d95d > ack(9349a95d)+win(12288) > pass ip #0 52(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(1240):seq(9349c485|9349c95d) ack(5f664296)+66240=3D5f674556 > pass ip #57467 1304(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1428):seq(9349c95d|9349cef1) ack(5f664296)+66240=3D5f674556 > pass ip #57468 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1428):seq(9349cef1|9349d485) ack(5f664296)+66240=3D5f674556 > pass ip #57469 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(5f668bb6|5f669156) ack(9349a95d)+12288=3D9349d95d > pass ip #48186 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(1240):seq(9349d485|9349d95d) ack(5f664296)+66240=3D5f674556 > pass ip #57470 1312(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(5f664296|5f664836) ack(9349a95d)+12288=3D9349d95d > pass ip #48193 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(0):seq(9349d95d|9349d95d) ack(5f668616)+48960=3D5f674556 > pass ip #57471 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(0):seq(9349d95d|9349d95d) ack(5f668616)+54088=3D5f67595e > ack(5f668616)+win(54088) > pass ip #57476 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(0):seq(9349d95d|9349d95d) ack(5f668616)+60632=3D5f6772ee > ack(5f668616)+win(60632) > pass ip #57489 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(0):seq(9349d95d|9349d95d) ack(5f668616)+64728=3D5f6782ee > ack(5f668616)+win(64728) > pass ip #57491 64(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(0):seq(5f6696f6|5f6696f6) ack(9349b485)+9408=3D9349d945 > pass ip #0 52(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(0):seq(5f6696f6|5f6696f6) ack(9349bef1)+6752=3D9349d951 > pass ip #0 52(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(0):seq(5f6696f6|5f6696f6) ack(9349c95d)+4096=3D9349d95d > pass ip #0 52(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(0):seq(5f6696f6|5f6696f6) ack(9349d485)+1216=3D9349d945 > pass ip #0 52(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > win=3D=3D0 > DATA(1440):seq(5f668616|5f668bb6) ack(9349d95d)+1=3D9349d95e > pass ip #48360 1492(20) 6 10.1.1.1,22 > 192.168.1.1,28808 A > -------------- > DATA(1440):seq(9349d95d|9349defd) ack(5f669156)+63360=3D5f6788d6 > ack(5f669156) seq(9349d95d) > block ip #57494 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(9349defd|9349e49d) ack(5f669156)+63360=3D5f6788d6 > ackskew 1440 > ack(5f669156) seq(9349defd) > block ip #57495 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(9349e49d|9349ea3d) ack(5f669156)+63360=3D5f6788d6 > ackskew 1440 > ack(5f669156) seq(9349e49d) > block ip #57496 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(9349ea3d|9349efdd) ack(5f669156)+63360=3D5f6788d6 > ackskew 1440 > ack(5f669156) seq(9349ea3d) > block ip #57497 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- > DATA(1440):seq(9349efdd|9349f57d) ack(5f669156)+63360=3D5f6788d6 > ackskew 1440 > ack(5f669156) seq(9349efdd) > block ip #57498 1492(20) 6 192.168.1.1,28808 > 10.1.1.1,22 A > -------------- >=20 > _______________________________________________ > 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 ;s =3D; --14dae934059b5a91d004bc77f24d Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJPddi3AAoJEJBXh4mJ2FR+qDIH/A4SdKPQdSGPSdPRuTXowx32 jnjWPeJdrQ4R19qyJ0DKYepgbXUuUHzJQ+IF9uMfJ7lGdGFG9S9nMBlqxY6Ukqdb jqKLjgTCG9CZVQk1NqCjek+RCn0MlXXdIxY4T+Hsk5Bnns+OkMATtFwJq81LYHQz 7/qg7MQe+vymZga+I5oK8j/PtxFYCzIOyqsy2pXVP86f/6/MwCRX3W6arMzMK4qo EoO1AHLHxeWKEVR/I8hXphRvt2lnIMtJDxgOR7ZrVNrwmyMJhaCf//Ge08jidUgZ d6r+rJLFUIIeSOq6PzOUWDHYHlW36MbA/JzeMrvbClfoQoXeIUlwBOFZA/HAp7A= =NKti -----END PGP SIGNATURE----- --14dae934059b5a91d004bc77f24d-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 16:06:09 2012 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 ACEB81065673 for ; Fri, 30 Mar 2012 16:06:09 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 08DFE8FC16 for ; Fri, 30 Mar 2012 16:06:08 +0000 (UTC) Received: (qmail 52906 invoked from network); 30 Mar 2012 16:05:09 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Mar 2012 16:05:09 -0000 Message-ID: <4F75D9ED.7080707@freebsd.org> Date: Fri, 30 Mar 2012 18:06:05 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: darrenr@freebsd.org References: <4F75C1A3.4030401@freebsd.org> In-Reply-To: <4F75C1A3.4030401@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 16:06:09 -0000 On 30.03.2012 16:22, Darren Reed wrote: > I've been tracking down some problems with FreeBSD's sending > of TCP packets and seem to have come to the conclusion that > in FreeBSD 8.2-RELEASE, when the system is working with a > TCP connection that has a moderate delay in it, FreeBSD's > TCP ignores the other end telling it that the window size > is now 0 and continues to send data. I suspect that this is > meant to make sense because it is expecting that the ACK > that will open up the window is already in transit. But that > only accounts for the condition where the TCP on FreeBSD can > compute and decide that the remote TCP will have its buffer > full. What I find harder to accept is that when FreeBSD's > TCP receives a TCP packet from the remote end advertising > a window of 0, FreeBSD's response is to send more data and > not a window probe or is that now the expected behaviour? > And whilst you might say "ok" for a packet of data, I'm > somewhat hard pressed to explain why FreeBSD's TCP sends > multiple packets with data in them after receiving a TCP > packet from the other end advertising a zero window size. > > However this causes a problem with firewalls (;_) that are > close to the FreeBSD end because for them, it appears that > FreeBSD is sending data outside of its window. > > Is this a known problem? > If so, has it been fixed in a later version of FreeBSD? > (No, I haven't tested anything other than 8.2) The window update acceptance test is too restrictive. In your case the last updated seq# tracking gets it wrong and prevents the update. The code hasn't changed for a long time and newer versions behave the same. The concept patch below simplifies the logic, better tracks the seq# and is a bit more permissive. -- Andre $ svn diff netinet/tcp_input.c Index: netinet/tcp_input.c =================================================================== --- netinet/tcp_input.c (revision 233227) +++ netinet/tcp_input.c (working copy) @@ -1717,7 +1730,7 @@ * Pull snd_wl1 up to prevent seq wrap relative to * th_seq. */ - tp->snd_wl1 = th->th_seq; + tp->snd_wl1 = th->th_seq + tlen; /* * Pull rcv_up up to prevent seq wrap relative to * rcv_nxt. @@ -2710,15 +2723,16 @@ * Don't look at window if no ACK: TAC's send garbage on first SYN. */ if ((thflags & TH_ACK) && - (SEQ_LT(tp->snd_wl1, th->th_seq) || - (tp->snd_wl1 == th->th_seq && (SEQ_LT(tp->snd_wl2, th->th_ack) || - (tp->snd_wl2 == th->th_ack && tiwin > tp->snd_wnd))))) { + (BYTES_THIS_ACK(tp, th) > 0 || /* new data acked */ + SEQ_GT(th->th_seq, tp->snd_wl1) || /* new data received */ + (th->th_seq == tp->snd_wl1 && tiwin > tp->snd_wnd))) { /* pure win update */ + /* keep track of pure window updates */ if (tlen == 0 && tp->snd_wl2 == th->th_ack && tiwin > tp->snd_wnd) TCPSTAT_INC(tcps_rcvwinupd); tp->snd_wnd = tiwin; - tp->snd_wl1 = th->th_seq; + tp->snd_wl1 = th->th_seq + tlen; tp->snd_wl2 = th->th_ack; if (tp->snd_wnd > tp->max_sndwnd) tp->max_sndwnd = tp->snd_wnd; From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 17:39:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73626106566B for ; Fri, 30 Mar 2012 17:39:14 +0000 (UTC) (envelope-from krzysiek@airnet.opole.pl) Received: from base.airnet.opole.pl (dns.airnet.opole.pl [82.160.97.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2B8598FC0A for ; Fri, 30 Mar 2012 17:39:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by base.airnet.opole.pl (Postfix) with ESMTP id 4AB897FF02F for ; Fri, 30 Mar 2012 19:33:21 +0200 (CEST) Received: from base.airnet.opole.pl ([127.0.0.1]) by localhost (base.airnet.opole.pl [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 62934-04 for ; Fri, 30 Mar 2012 19:33:21 +0200 (CEST) Received: from [10.10.11.223] (unknown [82.160.97.77]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: krzysiek@airnet.opole.pl) by base.airnet.opole.pl (Postfix) with ESMTPSA id 1C93E7FF02D for ; Fri, 30 Mar 2012 19:33:21 +0200 (CEST) Message-ID: <4F75EE5C.4060002@airnet.opole.pl> Date: Fri, 30 Mar 2012 19:33:16 +0200 From: Krzysztof Barcikowski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD 9.0 unexpected change of static route X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 17:39:14 -0000 Hi, After upgrade from FreeBSD 8.1 to FreeBSD 9.0-release (amd64) I've observed an unexpected behavior. From time to time, the static route's gateway I have defined in my rc.conf changes to random IP address. In rc.conf I have: static_routes="spp" route_spp="-net 10.0.0.0/16 10.250.0.2" it results with: #netstat -nr | grep "10.0.0.0" 10.0.0.0/16 10.250.0.2 UGS 2 373253416 lan which is OK, but after two days the route changed to: #netstat -nr | grep "10.0.0.0" 10.0.0.0/16 213.199.225.14 UGS 455 2058321449 lan The changed gateway address is different each time, beside that I've noticed one or two cases when the default route changed. (changes gateway IP addressess are DNS ip's, popular sites ip's, but not only). No routing software is running, I have the same configuration as on FreeBSD 8.1 (which was OK for over a year). I tried to log all the "route -n monitor" output but no events are visible at the time when the static route is changed. Do you have any idea how can I track down what's happening, or what could change the routing table entry? Perhaps I'm not aware of differences between FreeBSD 8.1 and 9.0. Thank you for your help. Kind regards! Krzysiek Barcikowski From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 22:01:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4BBD106566C; Fri, 30 Mar 2012 22:01:26 +0000 (UTC) (envelope-from hunter@comsys.com.ua) Received: from mail.ice-tech.com.ua (mail.ice-tech.com.ua [77.120.117.100]) by mx1.freebsd.org (Postfix) with ESMTP id 503548FC14; Fri, 30 Mar 2012 22:01:26 +0000 (UTC) Received: from 94.244.147.77.nash.net.ua ([94.244.147.77] helo=hunters-MacBook-Pro.local) by mail.ice-tech.com.ua with esmtpa (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SDjsl-0003L4-2b; Sat, 31 Mar 2012 01:01:19 +0300 Message-ID: <4F762D11.1080604@comsys.com.ua> Date: Sat, 31 Mar 2012 01:00:49 +0300 From: Sergey Smitienko User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Andre Oppermann References: <4F7463CF.8010206@comsys.com.ua> <4F759DB3.2060706@freebsd.org> <4F75AF4D.1040203@comsys.com.ua> <4F75CD8A.2050509@freebsd.org> In-Reply-To: <4F75CD8A.2050509@freebsd.org> X-SA-Exim-Connect-IP: 94.244.147.77 X-SA-Exim-Mail-From: hunter@comsys.com.ua X-SA-Exim-Scanned: No (on mail.ice-tech.com.ua); SAEximRunCond expanded to false Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 9.0 generates incorrect SEQ/ACK numbers under load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 22:01:26 -0000 30.03.12 18:13, Andre Oppermann wrote: > On 30.03.2012 15:04, Sergey Smitienko wrote: >> Here you go, two sessions, one with win set in Syn/Ack packet and other >> with separate "windows open" Ack packet. > > Thanks for the tcpdumps. The window update issue seems to be separate > from the seq#ack# problem. No, it's not. You gave me an idea. I have pf running on the server. It's has basic ruleset. We have table with 4k+ networks of our usual visitors. pf rules looks like this: pass in quick from to port 80 keep state pass in quick from any to port 80 synproxy state. So, in case of synproxy pf anwers Syn packet with Syn/Ack without knowledge of window size, and then passes connection to the kernel tcp stack and generates "window open" Ack packet. I've replaced "synproxy state" with usual "keep state" in pf and I don't see any Syn/Ack packets with zero window size. >From the over side, I have 20Gb of tcpdump files with 10^8 packets recorded. I've wrote a simple parser, which can detect sessions with incorrect sec/ack numbers. Then I've checked all IP addresses with failed TCP sessions and non of them was from set. So, 100% of failed sessions was comming through pf synproxy state. Synproxy state also include modulate state function, which is basicky an addition of random number to seq/ack numbers. So, I think there is a case, then tcp comming from kernel is not properly modulated/demodulated by pf and this causes generation of incorrect seq/ack numbers. > Why do set the recvspace to the very low value of 8192? 8K is big enough for usual GET request or for POST with login or comment. -- Sergey Smitienko From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 22:07:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 312D41065673 for ; Fri, 30 Mar 2012 22:07:23 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED82A8FC0A for ; Fri, 30 Mar 2012 22:07:22 +0000 (UTC) Received: by obbwc18 with SMTP id wc18so1706114obb.13 for ; Fri, 30 Mar 2012 15:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cX4NdmGa0gFG47AzFQHr/pQIVKS44ROe+XFC3eFx2iw=; b=wxf0jczf51DZfOkRZeZsqDJ577jT+T0Kd3Cl6CR1rXtk4wTvtQHNdjlP1XBLfm0QY4 zkTBp1BcyOXOnf6wp95Dx/Jd3ube3WE5uaEIWLHBOefpRLx2KO2nemNF5sfP3ELYPjC8 t35V7fFb+Nkg8XZWckmpkCIOk4JeKpdLCYPf8lagIZY8K940OyOxTw+b1+WcjRpXj6zr o4Z24DpD13k+2amLZX6J/83KatuexD2y7XkAQOsKzmapAauTNh/RolTriB4nKcHOfugc Gt/564enZxEndddyU4n2GlQ+2g/ntx7pgNtGapqrfTuIL+8gJMpha40+z5zVcKJ8knYD O+GQ== MIME-Version: 1.0 Received: by 10.60.14.36 with SMTP id m4mr95740oec.37.1333145242321; Fri, 30 Mar 2012 15:07:22 -0700 (PDT) Received: by 10.182.47.135 with HTTP; Fri, 30 Mar 2012 15:07:22 -0700 (PDT) Date: Fri, 30 Mar 2012 15:07:22 -0700 Message-ID: From: Jason Wolfe To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Possible interoperability issue with TCP timestamps between FreeBSD and Linux X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 22:07:23 -0000 So I'm seeing an issue that appears to be caused by the strict TCP timestamp adherence in the Linux kernel when there are connections being initiated by both sides of a Linux and FreeBSD pair of servers. What is looks like is FreeBSD is only tracking the timestamp for the remote host for connections it initiates, while the Linux box is tracking it globally for any transactions. As you can see below, this discrepancy seems to be causing Linux to ignore SYN packets when FreeBSD is attempting to connect after what they believe should be the proper timestamp has desyncd. You'll see after 3 SYN failures, FreeBSD drops timestamp support and the connection goes through properly, so this is usually causing about a 10s delay on the handshake. Tail end of a valid/successful transfer initiated by FreeBSD 8.2-RELEASE to Linux. This box in particular is 2.6.32, but we've seen it on other kernels: 18:09:22.271473 IP FreeBSD.56757 > Linux.80: Flags [.], ack 322, win 12559, options [nop,nop,TS val 827470242 ecr 1108508974], length 0 18:09:22.271615 IP FreeBSD.56757 > Linux.80: Flags [F.], seq 247, ack 322, win 12579, options [nop,nop,TS val 827470242 ecr 1108508974], length 0 18:09:22.271888 IP FreeBSD.56757 > Linux.80: Flags [.], ack 323, win 12579, options [nop,nop,TS val 827470242 ecr 1108508974], length 0 18:09:22.980495 IP FreeBSD.56777 > Linux.80: Flags [S], seq 1706839142, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val 827470951 ecr 0], length 0 18:09:22.980665 IP FreeBSD.56777 > Linux.80: Flags [.], ack 3814836667, win 12579, options [nop,nop,TS val 827470951 ecr 1108509044], length 0 18:09:22.980711 IP FreeBSD.56777 > Linux.80: Flags [P.], ack 1, win 12579, options [nop,nop,TS val 827470951 ecr 1108509044], length 247 18:09:23.001063 IP FreeBSD.56777 > Linux.80: Flags [.], ack 322, win 12559, options [nop,nop,TS val 827470971 ecr 1108509047], length 0 18:09:23.001226 IP FreeBSD.56777 > Linux.80: Flags [F.], seq 247, ack 322, win 12579, options [nop,nop,TS val 827470971 ecr 1108509047], length 0 18:09:23.001541 IP FreeBSD.56777 > Linux.80: Flags [.], ack 323, win 12579, options [nop,nop,TS val 827470972 ecr 1108509047], length 0 Here's a request initiated by Linux to FreeBSD. Note how the timestamp value is a lot higher. 18:09:26.513392 IP FreeBSD.1983 > Linux.24747: Flags [S.], seq 2239886569, ack 3865964318, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val 1857101612 ecr 1108509398], length 0 18:09:26.513680 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 1, win 12579, options [nop,nop,TS val 1857101612 ecr 1108509398], length 0 18:09:26.513692 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 622, win 12540, options [nop,nop,TS val 1857101612 ecr 1108509398], length 0 18:09:26.559776 IP FreeBSD.1983 > Linux.24747: Flags [P.], ack 622, win 12579, options [nop,nop,TS val 1857101658 ecr 1108509398], length 285 18:09:26.568579 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509402], length 1448 18:09:26.568584 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509402], length 1448 18:09:26.568587 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509402], length 1448 18:09:26.568591 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509402], length 1448 18:09:26.568843 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509403], length 1448 18:09:26.568847 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509403], length 1448 18:09:26.568850 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509403], length 1448 18:09:26.568854 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509403], length 1448 18:09:26.568861 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509403], length 1448 18:09:26.568864 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509403], length 1448 18:09:26.568867 IP FreeBSD.1983 > Linux.24747: Flags [P.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509403], length 954 18:09:26.569222 IP FreeBSD.1983 > Linux.24747: Flags [.], ack 623, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509403], length 0 18:09:26.569235 IP FreeBSD.1983 > Linux.24747: Flags [F.], seq 15720, ack 623, win 12579, options [nop,nop,TS val 1857101667 ecr 1108509403], length 0 Then, we make another connection initiated by FreeBSD, but with a sequence number that logically follows from the original outbound connection. This fails, until eventually we automatically give up on timestamps. 18:09:34.631349 IP FreeBSD.57007 > Linux.80: Flags [S], seq 704145119, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val 827482602 ecr 0], length 0 18:09:37.360671 IP FreeBSD.57056 > Linux.80: Flags [S], seq 2653481758, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val 827485331 ecr 0], length 0 18:09:37.631176 IP FreeBSD.57007 > Linux.80: Flags [S], seq 704145119, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val 827485602 ecr 0], length 0 18:09:40.360134 IP FreeBSD.57056 > Linux.80: Flags [S], seq 2653481758, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val 827488331 ecr 0], length 0 18:09:40.831125 IP FreeBSD.57007 > Linux.80: Flags [S], seq 704145119, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val 827488802 ecr 0], length 0 18:09:43.560084 IP FreeBSD.57056 > Linux.80: Flags [S], seq 2653481758, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val 827491531 ecr 0], length 0 18:09:44.031076 IP FreeBSD.57007 > Linux.80: Flags [S], seq 704145119, win 65535, options [mss 1460,sackOK,eol], length 0 18:09:44.031280 IP FreeBSD.57007 > Linux.80: Flags [.], ack 4142946180, win 65535, length 0 We confirmed this further by disabled TCP timestamps on the Linux box via the 'net.ipv4.tcp_timestamps' sysctl, and the problem cleared up. Has any one else seen this? Is there a more graceful work around aside from disabling timestamp support in Linux, or is there a sysctl I'm missing in FreeBSD that causes the timestamp to be global for each peer? Thanks, Jason From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 22:12:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F7711065670 for ; Fri, 30 Mar 2012 22:12:42 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id CFC6F8FC0A for ; Fri, 30 Mar 2012 22:12:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id C9785446003 for ; Fri, 30 Mar 2012 18:04:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfGL9DYOHL00 for ; Fri, 30 Mar 2012 18:04:35 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id D0936446002 for ; Fri, 30 Mar 2012 18:04:34 -0400 (EDT) From: Andrew Boyer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2012 18:04:24 -0400 Message-Id: To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: LACP kernel panics: /* unlocking is safe here */ X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 22:12:42 -0000 While investigating a LACP issue, I turned on LACP_DEBUG on a debug = kernel. In this configuration it's easy to panic the kernel - just run = 'ifconfig lagg0 laggproto lacp' on a lagg that's already in LACP mode = and receiving LACP messages. The problem is that lagg_lacp_detach() drops the lagg wlock (with the = comment in the title), which allows incoming LACP messages to get = through lagg_input() while the structure is being destroyed in = lacp_detach(). There's a very simple fix, but I don't know if it's the best way to fix = it. Resetting the protocol before calling sc_detach causes any further = incoming packets to be dropped until the lagg gets reconfigured. = Thoughts? Is it safe to just hold on to the lagg wlock across the callout_drain() = calls in lacp_detach()? That's what OpenBSD does. -Andrew Index: sys/net/if_lagg.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/net/if_lagg.c (revision 233707) +++ sys/net/if_lagg.c (working copy) @@ -952,9 +952,10 @@ } if (sc->sc_proto !=3D LAGG_PROTO_NONE) { LAGG_WLOCK(sc); + /* Reset protocol */ + sc->sc_proto =3D LAGG_PROTO_NONE; error =3D sc->sc_detach(sc); - /* Reset protocol and pointers */ - sc->sc_proto =3D LAGG_PROTO_NONE; + /* Reset pointers */ sc->sc_detach =3D NULL; sc->sc_start =3D NULL; sc->sc_input =3D NULL; -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 23:44:15 2012 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 277841065672 for ; Fri, 30 Mar 2012 23:44:15 +0000 (UTC) (envelope-from josh@signalboxes.net) Received: from mail.signaltotrust.net (hewbert.com [69.164.207.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0AB8FC12 for ; Fri, 30 Mar 2012 23:44:14 +0000 (UTC) Received: from [192.168.1.51] (unknown [67.158.43.219]) (Authenticated sender: josh) by mail.signaltotrust.net (Postfix) with ESMTPSA id 9F9D562E1; Fri, 30 Mar 2012 17:36:53 -0600 (MDT) Message-ID: <4F764392.6090400@signalboxes.net> Date: Fri, 30 Mar 2012 17:36:50 -0600 From: Josh Beard User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: NFS: rpc.statd/lockd becomes unresponsive X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 23:44:15 -0000 Hello, We've recently setup a FreeBSD 9.0-RELEASE (x64) system to test as an NFS server for "live" network homes for Mac clients (mostly 10.5 and 10.6 clients). We're a public school district and normally have around 150-200 users logged in at a time with network homes. Currently, we're using netatalk (AFP) on a Linux box, after migrating from an aging Mac OS X server. Unfortunately, netatalk has some serious performance issues under the load we're putting it under and we'd like to migrate to NFS. We've tried several Linux distributions and various kernels and we're now testing FreeBSD (and tested FreeNAS) with similar setups. Unfortunately, they all suffer the same issue. As a test, I have a series of scripts to simulate user activity on the clients (e.g. opening Word, opening a browser, doing some read/writes with dd, etc). After a while, NFS on the server runs into an issue where (what I think happens) rpc.statd can't talk to rpc.lockd. Being Mac clients, they all get a rather ugly dialog box stating that their connection to the server has been lost. It's worth mentioning that this server is a KVM 'guest' on a Linux server. I'm aware of some I/O issues there, but I don't have a decent piece of hardware to really test this on. I allocated 4 CPUs to it and 10GB of RAM. I've tested with the virtio net drivers and without. Considering I've seen the same symptoms on around 6 Linux distributions, with various kernels, FreeNAS, and FreeBSD, I wouldn't be surprised to get the same results if I weren't virtualized. I haven't really done any tuning on the FreeBSD server, it's fairly vanilla. We have around ~2600 machines throughout our campus, with limited remote management capabilities (that's on the big agenda to tackle), so changing NFS mount options there would be rather difficult. These are LDAP accounts with the NFS mounts in LDAP as well, for what it's worth. The clients mount it pretty vanilla (output of 'mount' on client): freenas.dsdk12.schoollocal:/mnt/homes on /net/freenas.dsdk12.schoollocal/mnt/homes (nfs, nodev, nosuid, automounted, nobrowse) On the server, my /etc/exports looks like this: /srv/homes -alldirs -network 172.30.0.0/16 This export doesn't have a lot of data - it's 150 small home directories of test accounts. No other activity is being done on this server. The filesystem if UFS. /etc/rc.conf on the server: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r -l" nfsd_enable="YES" mountd_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" nfs_server_flags="-t -n 128" When this occurs, /var/log/messages starts to fill up with this: Mar 30 16:35:18 freefs kernel: Failed to contact local NSM - rpc error 5 Mar 30 16:35:20 freefs rpc.statd: unmon request from localhost, no matching monitor Mar 30 16:35:44 freefs rpc.statd: unmon request from localhost, no matching monitor -- repeated a few times every few seconds -- Mar 30 16:54:50 freefs rpc.statd: Unsolicited notification from host hs00508s4434.dsdk12.schoollocal Mar 30 16:55:01 freefs rpc.statd: Unsolicited notification from host hs00520s4539.dsdk12.schoollocal Mar 30 16:55:10 freefs rpc.statd: Failed to call rpc.statd client at host localhost nfsstat shortly after a failure: Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 1208 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 177 951 226 28 3 6 0 2 BioRLHits Misses BioD Hits Misses DirE Hits Misses Accs Hits Misses 49 3 13 5 9 0 148 9 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 262698 101012 1575347 29 1924761 2172712 0 43792 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 27447 0 21 5596 1691 118073 0 2596146 Mknod Fsstat Fsinfo PathConf Commit 0 83638 108 108 183632 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 9172982 Server Write Gathering: WriteOps WriteRPC Opsaved 2172712 2172712 0 rpcinfo shortly after a failure: program version netid address service owner 100000 4 tcp 0.0.0.0.0.111 rpcbind superuser 100000 3 tcp 0.0.0.0.0.111 rpcbind superuser 100000 2 tcp 0.0.0.0.0.111 rpcbind superuser 100000 4 udp 0.0.0.0.0.111 rpcbind superuser 100000 3 udp 0.0.0.0.0.111 rpcbind superuser 100000 2 udp 0.0.0.0.0.111 rpcbind superuser 100000 4 tcp6 ::.0.111 rpcbind superuser 100000 3 tcp6 ::.0.111 rpcbind superuser 100000 4 udp6 ::.0.111 rpcbind superuser 100000 3 udp6 ::.0.111 rpcbind superuser 100000 4 local /var/run/rpcbind.sock rpcbind superuser 100000 3 local /var/run/rpcbind.sock rpcbind superuser 100000 2 local /var/run/rpcbind.sock rpcbind superuser 100005 1 udp6 ::.2.119 mountd superuser 100005 3 udp6 ::.2.119 mountd superuser 100005 1 tcp6 ::.2.119 mountd superuser 100005 3 tcp6 ::.2.119 mountd superuser 100005 1 udp 0.0.0.0.2.119 mountd superuser 100005 3 udp 0.0.0.0.2.119 mountd superuser 100005 1 tcp 0.0.0.0.2.119 mountd superuser 100005 3 tcp 0.0.0.0.2.119 mountd superuser 100024 1 udp6 ::.3.191 status superuser 100024 1 tcp6 ::.3.191 status superuser 100024 1 udp 0.0.0.0.3.191 status superuser 100024 1 tcp 0.0.0.0.3.191 status superuser 100003 2 tcp 0.0.0.0.8.1 nfs superuser 100003 3 tcp 0.0.0.0.8.1 nfs superuser 100003 2 tcp6 ::.8.1 nfs superuser 100003 3 tcp6 ::.8.1 nfs superuser 100021 0 udp6 ::.3.248 nlockmgr superuser 100021 0 tcp6 ::.2.220 nlockmgr superuser 100021 0 udp 0.0.0.0.3.202 nlockmgr superuser 100021 0 tcp 0.0.0.0.2.255 nlockmgr superuser 100021 1 udp6 ::.3.248 nlockmgr superuser 100021 1 tcp6 ::.2.220 nlockmgr superuser 100021 1 udp 0.0.0.0.3.202 nlockmgr superuser 100021 1 tcp 0.0.0.0.2.255 nlockmgr superuser 100021 3 udp6 ::.3.248 nlockmgr superuser 100021 3 tcp6 ::.2.220 nlockmgr superuser 100021 3 udp 0.0.0.0.3.202 nlockmgr superuser 100021 3 tcp 0.0.0.0.2.255 nlockmgr superuser 100021 4 udp6 ::.3.248 nlockmgr superuser 100021 4 tcp6 ::.2.220 nlockmgr superuser 100021 4 udp 0.0.0.0.3.202 nlockmgr superuser 100021 4 tcp 0.0.0.0.2.255 nlockmgr superuser 300019 1 tcp 0.0.0.0.2.185 amd superuser 300019 1 udp 0.0.0.0.2.162 amd superuser The load can get fairly high during my 'stress' tests, but not *that* high. I'm surprised to see these particular symptoms that affect every connected user at the same time and would expect slowdowns rather than the issue I'm seeing. Any ideas or nudges in the right direction are most welcome. This is severely plaguing us and our students :\ Thanks, Josh From owner-freebsd-net@FreeBSD.ORG Fri Mar 30 23:52:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B2BF1065693 for ; Fri, 30 Mar 2012 23:52:32 +0000 (UTC) (envelope-from josh@hewbert.com) Received: from mail.signaltotrust.net (hewbert.com [69.164.207.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4CF568FC22 for ; Fri, 30 Mar 2012 23:52:32 +0000 (UTC) Received: from [192.168.1.51] (unknown [67.158.43.219]) (Authenticated sender: josh) by mail.signaltotrust.net (Postfix) with ESMTPSA id CA22C62E1 for ; Fri, 30 Mar 2012 17:52:31 -0600 (MDT) Message-ID: <4F76473F.9010608@hewbert.com> Date: Fri, 30 Mar 2012 17:52:31 -0600 From: Josh Beard User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4F764392.6090400@signalboxes.net> In-Reply-To: <4F764392.6090400@signalboxes.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: NFS: rpc.statd/lockd becomes unresponsive X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Mar 2012 23:52:32 -0000 On 03/30/2012 05:36 PM, Josh Beard wrote: > Hello, > snip Whoops, realized freebsd-fs is probably a more appropriate list for this. My apologies. Josh From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 07:53:38 2012 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 EB8A71065672 for ; Sat, 31 Mar 2012 07:53:38 +0000 (UTC) (envelope-from darernr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id B1D708FC0A for ; Sat, 31 Mar 2012 07:53:38 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id BE07320C7B for ; Sat, 31 Mar 2012 03:53:37 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Sat, 31 Mar 2012 03:53:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=Hud9Bey83ynvFSoSkRYpb1 f3ZvQ=; b=VxhCeW0/1YC8x77+TRidF5gaOXgGCKEu9M1UEiQl4va3EIpPbZQ4Fb kT7mPa+uZmw9XRo5LqJuHtIGK05HOTiYZk/pngYeIA2Oaj+xlBkDYq85983+Jymx T6PSYhLOR66v3Z1OkDOCHjzx9kaM7tzdAdePFNgbLY705pzxvrnAc= X-Sasl-enc: NNnmCopT2epMcm8t5EhgUy2wo05Gksk1oh4mNp8fj22R 1333180417 Received: from [192.168.1.23] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPSA id 9A1F38E00B7; Sat, 31 Mar 2012 03:53:36 -0400 (EDT) Message-ID: <4F76C61A.1000704@freebsd.org> Date: Sat, 31 Mar 2012 19:53:46 +1100 From: Darren Reed User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Jason Hellenthal References: <4F75C1A3.4030401@freebsd.org> <20120330160055.GB78586@DataIX.net> In-Reply-To: <20120330160055.GB78586@DataIX.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Mar 2012 07:53:39 -0000 Jason Hellenthal wrote: > On Sat, Mar 31, 2012 at 01:22:27AM +1100, Darren Reed wrote: > >> I've been tracking down some problems with FreeBSD's sending >> of TCP packets and seem to have come to the conclusion that >> in FreeBSD 8.2-RELEASE, when the system is working with a >> TCP connection that has a moderate delay in it, FreeBSD's >> TCP ignores the other end telling it that the window size >> is now 0 and continues to send data. I suspect that this is >> meant to make sense because it is expecting that the ACK >> that will open up the window is already in transit. But that >> only accounts for the condition where the TCP on FreeBSD can >> compute and decide that the remote TCP will have its buffer >> full. What I find harder to accept is that when FreeBSD's >> TCP receives a TCP packet from the remote end advertising >> a window of 0, FreeBSD's response is to send more data and >> not a window probe or is that now the expected behaviour? >> And whilst you might say "ok" for a packet of data, I'm >> somewhat hard pressed to explain why FreeBSD's TCP sends >> multiple packets with data in them after receiving a TCP >> packet from the other end advertising a zero window size. >> >> However this causes a problem with firewalls (;_) that are >> close to the FreeBSD end because for them, it appears that >> FreeBSD is sending data outside of its window. >> >> Is this a known problem? >> If so, has it been fixed in a later version of FreeBSD? >> (No, I haven't tested anything other than 8.2) >> >> In the packet flow below, 192.168.1.1 is FreeBSD and 10.1.1.1 >> is the other end. >> >> Darren >> > > Hi Darren, > > I do believe this is the following bug at first glance that was patched > after 8.2-RELEASE. and has to do more with x64 systems more than x32. > > See: "A Tale of a TCP Bug" for details... > > http://blogmal.42.org/tidbits/tcp-bug.story > > http://lists.freebsd.org/pipermail/freebsd-net/2011-April/028466.html > That patch alone is not enough to fix the problem - I still see FreeBSD 8.2 sending out data after it has received a TCP packet with a window size of 0. Next I'll try adding Andre's. Darren From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 08:06:41 2012 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 729171065747 for ; Sat, 31 Mar 2012 08:06:41 +0000 (UTC) (envelope-from darernr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 378D68FC08 for ; Sat, 31 Mar 2012 08:06:41 +0000 (UTC) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C5461203C3 for ; Sat, 31 Mar 2012 04:06:40 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Sat, 31 Mar 2012 04:06:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=kTz8FQ8pTe58AD4Tl7TtrU g3yso=; b=NE+hix5W4J44lJb5JWywMCdfDOi2B7iJA3zZ3Ll5xCO8+mn6WSv8hD PUiyyCESg7JplZeWXBbMMfItlqRiNcNuC6/5xBnLZojNEr2gYWjcz1zTNHUrvsgS AuReye7KIvAx7OLxG5EtSLMXF1SQjX+Jk11GPcryP4Pnz3eTMujAs= X-Sasl-enc: sMXR68jt46DJvYlcGV0Y3Q+hAJEYQUINI4lmR/stROo2 1333181200 Received: from [192.168.1.23] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPSA id 452238E0201; Sat, 31 Mar 2012 04:06:38 -0400 (EDT) Message-ID: <4F76C929.5080400@freebsd.org> Date: Sat, 31 Mar 2012 20:06:49 +1100 From: Darren Reed User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andre Oppermann References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> In-Reply-To: <4F75D9ED.7080707@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: darrenr@freebsd.org, freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Mar 2012 08:06:41 -0000 Andre Oppermann wrote: > On 30.03.2012 16:22, Darren Reed wrote: >> I've been tracking down some problems with FreeBSD's sending >> of TCP packets and seem to have come to the conclusion that >> in FreeBSD 8.2-RELEASE, when the system is working with a >> TCP connection that has a moderate delay in it, FreeBSD's >> TCP ignores the other end telling it that the window size >> is now 0 and continues to send data. I suspect that this is >> meant to make sense because it is expecting that the ACK >> that will open up the window is already in transit. But that >> only accounts for the condition where the TCP on FreeBSD can >> compute and decide that the remote TCP will have its buffer >> full. What I find harder to accept is that when FreeBSD's >> TCP receives a TCP packet from the remote end advertising >> a window of 0, FreeBSD's response is to send more data and >> not a window probe or is that now the expected behaviour? >> And whilst you might say "ok" for a packet of data, I'm >> somewhat hard pressed to explain why FreeBSD's TCP sends >> multiple packets with data in them after receiving a TCP >> packet from the other end advertising a zero window size. >> >> However this causes a problem with firewalls (;_) that are >> close to the FreeBSD end because for them, it appears that >> FreeBSD is sending data outside of its window. >> >> Is this a known problem? >> If so, has it been fixed in a later version of FreeBSD? >> (No, I haven't tested anything other than 8.2) > > The window update acceptance test is too restrictive. In your case > the last updated seq# tracking gets it wrong and prevents the update. > > The code hasn't changed for a long time and newer versions behave the > same. > > The concept patch below simplifies the logic, better tracks the seq# > and is a bit more permissive. > This patch does not apply cleanly against 8.2 (BYTES_THIS_ACK is not present in 8.2.) I'll add in the obvious missing #defines and see how I go. Darren From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 09:40:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0563C106566C for ; Sat, 31 Mar 2012 09:40:48 +0000 (UTC) (envelope-from darernr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id C39928FC19 for ; Sat, 31 Mar 2012 09:40:47 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1CFA920CC9 for ; Sat, 31 Mar 2012 05:40:47 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Sat, 31 Mar 2012 05:40:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=mmlxM3GfSaUNwt4VIua88y f9TfQ=; b=mYiNDSxMRaxyRU6yF+4fZSySIqCFV8JvUGbArqfmQvmtImovEsv+e9 UgNOdyNd4RlHRI0qqijAe4wY8UmgcT1/Pp4yPUOklKz7B5j9IJK12rxsV7Jv1C9G p2k4/j/V+6i1E+LdlaIZidkEN2MBLeo7xEJkuDSRXH26Pp/Szh1S4= X-Sasl-enc: DZ3+yZJfwz5UVOxMY8kCmAWTq/oNjiZgaAO1RYPmrhMA 1333186846 Received: from [192.168.1.23] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPSA id E52568E0192; Sat, 31 Mar 2012 05:40:45 -0400 (EDT) Message-ID: <4F76DF39.7080807@freebsd.org> Date: Sat, 31 Mar 2012 21:40:57 +1100 From: Darren Reed User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andre Oppermann References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F76C929.5080400@freebsd.org> In-Reply-To: <4F76C929.5080400@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Mar 2012 09:40:48 -0000 Darren Reed wrote: > Andre Oppermann wrote: >> On 30.03.2012 16:22, Darren Reed wrote: >>> I've been tracking down some problems with FreeBSD's sending >>> of TCP packets and seem to have come to the conclusion that >>> in FreeBSD 8.2-RELEASE, when the system is working with a >>> TCP connection that has a moderate delay in it, FreeBSD's >>> TCP ignores the other end telling it that the window size >>> is now 0 and continues to send data. I suspect that this is >>> meant to make sense because it is expecting that the ACK >>> that will open up the window is already in transit. But that >>> only accounts for the condition where the TCP on FreeBSD can >>> compute and decide that the remote TCP will have its buffer >>> full. What I find harder to accept is that when FreeBSD's >>> TCP receives a TCP packet from the remote end advertising >>> a window of 0, FreeBSD's response is to send more data and >>> not a window probe or is that now the expected behaviour? >>> And whilst you might say "ok" for a packet of data, I'm >>> somewhat hard pressed to explain why FreeBSD's TCP sends >>> multiple packets with data in them after receiving a TCP >>> packet from the other end advertising a zero window size. >>> >>> However this causes a problem with firewalls (;_) that are >>> close to the FreeBSD end because for them, it appears that >>> FreeBSD is sending data outside of its window. >>> >>> Is this a known problem? >>> If so, has it been fixed in a later version of FreeBSD? >>> (No, I haven't tested anything other than 8.2) >> >> The window update acceptance test is too restrictive. In your case >> the last updated seq# tracking gets it wrong and prevents the update. >> >> The code hasn't changed for a long time and newer versions behave the >> same. >> >> The concept patch below simplifies the logic, better tracks the seq# >> and is a bit more permissive. >> > > This patch does not apply cleanly against 8.2 (BYTES_THIS_ACK > is not present in 8.2.) > > I'll add in the obvious missing #defines and see how I go. This patch does not resolve the problem either. Darren From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 10:39:51 2012 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 1AD02106564A for ; Sat, 31 Mar 2012 10:39:51 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1A88FC0C for ; Sat, 31 Mar 2012 10:39:50 +0000 (UTC) Received: (qmail 58524 invoked from network); 31 Mar 2012 10:38:41 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 Mar 2012 10:38:41 -0000 Message-ID: <4F76DEF1.8080600@freebsd.org> Date: Sat, 31 Mar 2012 12:39:45 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Darren Reed References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F76C929.5080400@freebsd.org> <4F76DF39.7080807@freebsd.org> In-Reply-To: <4F76DF39.7080807@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Mar 2012 10:39:51 -0000 On 31.03.2012 12:40, Darren Reed wrote: > Darren Reed wrote: >> Andre Oppermann wrote: >>> On 30.03.2012 16:22, Darren Reed wrote: >>>> I've been tracking down some problems with FreeBSD's sending >>>> of TCP packets and seem to have come to the conclusion that >>>> in FreeBSD 8.2-RELEASE, when the system is working with a >>>> TCP connection that has a moderate delay in it, FreeBSD's >>>> TCP ignores the other end telling it that the window size >>>> is now 0 and continues to send data. I suspect that this is >>>> meant to make sense because it is expecting that the ACK >>>> that will open up the window is already in transit. But that >>>> only accounts for the condition where the TCP on FreeBSD can >>>> compute and decide that the remote TCP will have its buffer >>>> full. What I find harder to accept is that when FreeBSD's >>>> TCP receives a TCP packet from the remote end advertising >>>> a window of 0, FreeBSD's response is to send more data and >>>> not a window probe or is that now the expected behaviour? >>>> And whilst you might say "ok" for a packet of data, I'm >>>> somewhat hard pressed to explain why FreeBSD's TCP sends >>>> multiple packets with data in them after receiving a TCP >>>> packet from the other end advertising a zero window size. >>>> >>>> However this causes a problem with firewalls (;_) that are >>>> close to the FreeBSD end because for them, it appears that >>>> FreeBSD is sending data outside of its window. >>>> >>>> Is this a known problem? >>>> If so, has it been fixed in a later version of FreeBSD? >>>> (No, I haven't tested anything other than 8.2) >>> >>> The window update acceptance test is too restrictive. In your case >>> the last updated seq# tracking gets it wrong and prevents the update. >>> >>> The code hasn't changed for a long time and newer versions behave the >>> same. >>> >>> The concept patch below simplifies the logic, better tracks the seq# >>> and is a bit more permissive. >>> >> >> This patch does not apply cleanly against 8.2 (BYTES_THIS_ACK >> is not present in 8.2.) >> >> I'll add in the obvious missing #defines and see how I go. > > This patch does not resolve the problem either. Is there a way to "easily" reproduce the traffic pattern that causes this problem? -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 12:25:50 2012 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 64F12106566B for ; Sat, 31 Mar 2012 12:25:50 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id AB3498FC16 for ; Sat, 31 Mar 2012 12:25:49 +0000 (UTC) Received: (qmail 59066 invoked from network); 31 Mar 2012 12:24:34 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 Mar 2012 12:24:34 -0000 Message-ID: <4F76F7C2.9080404@freebsd.org> Date: Sat, 31 Mar 2012 14:25:38 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jason Wolfe References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Possible interoperability issue with TCP timestamps between FreeBSD and Linux X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 12:25:50 -0000 On 31.03.2012 00:07, Jason Wolfe wrote: > So I'm seeing an issue that appears to be caused by the strict TCP > timestamp adherence in the Linux kernel when there are connections > being initiated by both sides of a Linux and FreeBSD pair of servers. > What is looks like is FreeBSD is only tracking the timestamp for the > remote host for connections it initiates, while the Linux box is > tracking it globally for any transactions. As you can see below, this > discrepancy seems to be causing Linux to ignore SYN packets when > FreeBSD is attempting to connect after what they believe should be the > proper timestamp has desyncd. You'll see after 3 SYN failures, > FreeBSD drops timestamp support and the connection goes through > properly, so this is usually causing about a 10s delay on the > handshake. > > Tail end of a valid/successful transfer initiated by FreeBSD > 8.2-RELEASE to Linux. This box in particular is 2.6.32, but we've > seen it on other kernels: > > 18:09:22.271473 IP FreeBSD.56757> Linux.80: Flags [.], > ack 322, win 12559, options [nop,nop,TS val 827470242 ecr 1108508974], > length 0 > 18:09:22.271615 IP FreeBSD.56757> Linux.80: Flags > [F.], seq 247, ack 322, win 12579, options [nop,nop,TS val 827470242 > ecr 1108508974], length 0 > 18:09:22.271888 IP FreeBSD.56757> Linux.80: Flags [.], > ack 323, win 12579, options [nop,nop,TS val 827470242 ecr 1108508974], > length 0 > 18:09:22.980495 IP FreeBSD.56777> Linux.80: Flags [S], > seq 1706839142, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS > val 827470951 ecr 0], length 0 > 18:09:22.980665 IP FreeBSD.56777> Linux.80: Flags [.], > ack 3814836667, win 12579, options [nop,nop,TS val 827470951 ecr > 1108509044], length 0 > 18:09:22.980711 IP FreeBSD.56777> Linux.80: Flags > [P.], ack 1, win 12579, options [nop,nop,TS val 827470951 ecr > 1108509044], length 247 > 18:09:23.001063 IP FreeBSD.56777> Linux.80: Flags [.], > ack 322, win 12559, options [nop,nop,TS val 827470971 ecr 1108509047], > length 0 > 18:09:23.001226 IP FreeBSD.56777> Linux.80: Flags > [F.], seq 247, ack 322, win 12579, options [nop,nop,TS val 827470971 > ecr 1108509047], length 0 > 18:09:23.001541 IP FreeBSD.56777> Linux.80: Flags [.], > ack 323, win 12579, options [nop,nop,TS val 827470972 ecr 1108509047], > length 0 > > Here's a request initiated by Linux to FreeBSD. Note how > the timestamp value is a lot higher. > > 18:09:26.513392 IP FreeBSD.1983> Linux.24747: Flags > [S.], seq 2239886569, ack 3865964318, win 65535, options [mss > 1460,nop,wscale 4,sackOK,TS val 1857101612 ecr 1108509398], length 0 > 18:09:26.513680 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 1, win 12579, options [nop,nop,TS val 1857101612 ecr > 1108509398], length 0 > 18:09:26.513692 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 622, win 12540, options [nop,nop,TS val 1857101612 ecr > 1108509398], length 0 > 18:09:26.559776 IP FreeBSD.1983> Linux.24747: Flags > [P.], ack 622, win 12579, options [nop,nop,TS val 1857101658 ecr > 1108509398], length 285 > 18:09:26.568579 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr > 1108509402], length 1448 > 18:09:26.568584 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr > 1108509402], length 1448 > 18:09:26.568587 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr > 1108509402], length 1448 > 18:09:26.568591 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr > 1108509402], length 1448 > 18:09:26.568843 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr > 1108509403], length 1448 > 18:09:26.568847 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr > 1108509403], length 1448 > 18:09:26.568850 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr > 1108509403], length 1448 > 18:09:26.568854 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr > 1108509403], length 1448 > 18:09:26.568861 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr > 1108509403], length 1448 > 18:09:26.568864 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr > 1108509403], length 1448 > 18:09:26.568867 IP FreeBSD.1983> Linux.24747: Flags > [P.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr > 1108509403], length 954 > 18:09:26.569222 IP FreeBSD.1983> Linux.24747: Flags > [.], ack 623, win 12579, options [nop,nop,TS val 1857101667 ecr > 1108509403], length 0 > 18:09:26.569235 IP FreeBSD.1983> Linux.24747: Flags > [F.], seq 15720, ack 623, win 12579, options [nop,nop,TS val > 1857101667 ecr 1108509403], length 0 > > Then, we make another connection initiated by FreeBSD, but with a > sequence number that > logically follows from the original outbound connection. This fails, > until eventually we automatically give up on timestamps. > > 18:09:34.631349 IP FreeBSD.57007> Linux.80: Flags [S], > seq 704145119, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val > 827482602 ecr 0], length 0 > 18:09:37.360671 IP FreeBSD.57056> Linux.80: Flags [S], > seq 2653481758, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS > val 827485331 ecr 0], length 0 > 18:09:37.631176 IP FreeBSD.57007> Linux.80: Flags [S], > seq 704145119, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val > 827485602 ecr 0], length 0 > 18:09:40.360134 IP FreeBSD.57056> Linux.80: Flags [S], > seq 2653481758, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS > val 827488331 ecr 0], length 0 > 18:09:40.831125 IP FreeBSD.57007> Linux.80: Flags [S], > seq 704145119, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val > 827488802 ecr 0], length 0 > 18:09:43.560084 IP FreeBSD.57056> Linux.80: Flags [S], > seq 2653481758, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS > val 827491531 ecr 0], length 0 > 18:09:44.031076 IP FreeBSD.57007> Linux.80: Flags [S], > seq 704145119, win 65535, options [mss 1460,sackOK,eol], length 0 > 18:09:44.031280 IP FreeBSD.57007> Linux.80: Flags [.], > ack 4142946180, win 65535, length 0 > > We confirmed this further by disabled TCP timestamps on the Linux box > via the 'net.ipv4.tcp_timestamps' sysctl, and the problem cleared up. > Has any one else seen this? Is there a more graceful work around > aside from disabling timestamp support in Linux, or is there a sysctl > I'm missing in FreeBSD that causes the timestamp to be global for each > peer? Linux does the per-host timestamp check only when you hit a 2MSL graveyard connection. It happens in net/ipv4/tcp_ipv4.c around line 1376 within a PAWS check. Our in- and outbound timestamps are not synchronized to the same base. A timestamp on an SYN/ACK is somewhat randomized. Whereas a timestamp in a SYN is based off ticks and increases with later connections. It seems you have a large number of short lived connections between these hosts. You may want to increase the port range for outgoing connections to avoid recycling port numbers within the 2MSL time frame. Alternatively you could decrease the 2MSL time on Linux. Or you can turn off syncookies on FreeBSD to avoid the SYN/ACK timestamp randomization. Linux has over-engineered this whole thing for little to no benefit. This additional check presumably also wrecks busy NAT IP addresses where port recycling is fast. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 20:16:53 2012 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 7A0BB1065674; Sat, 31 Mar 2012 20:16:53 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 305D08FC1D; Sat, 31 Mar 2012 20:16:53 +0000 (UTC) Received: by obbwc18 with SMTP id wc18so2848253obb.13 for ; Sat, 31 Mar 2012 13:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=MWrKgiC/r6PQIRquxokq7+ac+iqOKbM6QsAj7QDh41k=; b=QsfOc6IX1FCvetL2k/0wp7GPz5eHP2RiqTh9/l7R6+WNMwkYm6BoqTNPkIoTJJ8Sj5 bBcAjqOD3nrk9Fvme6XI03is5F2JNwHGJqP/cGlnakkqAVSqposvhb/ByRKQ4A7t0J0d 0A7VJf6mx2XqzqX9erCMns2JnvP864hWxWrY1ZXnJQUHTV/6sCWc8Q+GGeFwiZcnh2Xx rsTjKZqoLaJAfl6/UgkUage6rLuGokUw7RBu8NWgc0hsXcV2ywxQg5tYKCPWQAnyk7/j wDheacqC8ZaQij3p+cKV9UJiKsJ7CpxPQBx7kl+8cx+VYcyOqlDjHZxoNCnM2+gtG5gF 5JGQ== MIME-Version: 1.0 Received: by 10.60.14.166 with SMTP id q6mr4051137oec.17.1333225012683; Sat, 31 Mar 2012 13:16:52 -0700 (PDT) Received: by 10.182.47.135 with HTTP; Sat, 31 Mar 2012 13:16:52 -0700 (PDT) In-Reply-To: <4F76F7C2.9080404@freebsd.org> References: <4F76F7C2.9080404@freebsd.org> Date: Sat, 31 Mar 2012 13:16:52 -0700 Message-ID: From: Jason Wolfe To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Possible interoperability issue with TCP timestamps between FreeBSD and Linux X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 20:16:53 -0000 On Sat, Mar 31, 2012 at 5:25 AM, Andre Oppermann wrote: > On 31.03.2012 00:07, Jason Wolfe wrote: >> >> So I'm seeing an issue that appears to be caused by the strict TCP >> timestamp adherence in the Linux kernel when there are connections >> being initiated by both sides of a Linux and FreeBSD pair of servers. >> What is looks like is FreeBSD is only tracking the timestamp for the >> remote host for connections it initiates, while the Linux box is >> tracking it globally for any transactions. =A0As you can see below, this >> discrepancy seems to be causing Linux to ignore SYN packets when >> FreeBSD is attempting to connect after what they believe should be the >> proper timestamp has desyncd. =A0You'll see after 3 SYN failures, >> FreeBSD drops timestamp support and the connection goes through >> properly, so this is usually causing about a 10s delay on the >> handshake. >> >> Tail end of a valid/successful transfer initiated by FreeBSD >> 8.2-RELEASE to Linux. =A0This box in particular is 2.6.32, but we've >> seen it on other kernels: >> >> 18:09:22.271473 IP FreeBSD.56757> =A0Linux.80: Flags [.], >> ack 322, win 12559, options [nop,nop,TS val 827470242 ecr 1108508974], >> length 0 >> 18:09:22.271615 IP FreeBSD.56757> =A0Linux.80: Flags >> [F.], seq 247, ack 322, win 12579, options [nop,nop,TS val 827470242 >> ecr 1108508974], length 0 >> 18:09:22.271888 IP FreeBSD.56757> =A0Linux.80: Flags [.], >> ack 323, win 12579, options [nop,nop,TS val 827470242 ecr 1108508974], >> length 0 >> 18:09:22.980495 IP FreeBSD.56777> =A0Linux.80: Flags [S], >> seq 1706839142, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS >> val 827470951 ecr 0], length 0 >> 18:09:22.980665 IP FreeBSD.56777> =A0Linux.80: Flags [.], >> ack 3814836667, win 12579, options [nop,nop,TS val 827470951 ecr >> 1108509044], length 0 >> 18:09:22.980711 IP FreeBSD.56777> =A0Linux.80: Flags >> [P.], ack 1, win 12579, options [nop,nop,TS val 827470951 ecr >> 1108509044], length 247 >> 18:09:23.001063 IP FreeBSD.56777> =A0Linux.80: Flags [.], >> ack 322, win 12559, options [nop,nop,TS val 827470971 ecr 1108509047], >> length 0 >> 18:09:23.001226 IP FreeBSD.56777> =A0Linux.80: Flags >> [F.], seq 247, ack 322, win 12579, options [nop,nop,TS val 827470971 >> ecr 1108509047], length 0 >> 18:09:23.001541 IP FreeBSD.56777> =A0Linux.80: Flags [.], >> ack 323, win 12579, options [nop,nop,TS val 827470972 ecr 1108509047], >> length 0 >> >> Here's a request initiated by Linux to FreeBSD. =A0Note how >> the timestamp value is a lot higher. >> >> 18:09:26.513392 IP FreeBSD.1983> =A0Linux.24747: Flags >> [S.], seq 2239886569, ack 3865964318, win 65535, options [mss >> 1460,nop,wscale 4,sackOK,TS val 1857101612 ecr 1108509398], length 0 >> 18:09:26.513680 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 1, win 12579, options [nop,nop,TS val 1857101612 ecr >> 1108509398], length 0 >> 18:09:26.513692 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 622, win 12540, options [nop,nop,TS val 1857101612 ecr >> 1108509398], length 0 >> 18:09:26.559776 IP FreeBSD.1983> =A0Linux.24747: Flags >> [P.], ack 622, win 12579, options [nop,nop,TS val 1857101658 ecr >> 1108509398], length 285 >> 18:09:26.568579 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr >> 1108509402], length 1448 >> 18:09:26.568584 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr >> 1108509402], length 1448 >> 18:09:26.568587 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr >> 1108509402], length 1448 >> 18:09:26.568591 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr >> 1108509402], length 1448 >> 18:09:26.568843 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr >> 1108509403], length 1448 >> 18:09:26.568847 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr >> 1108509403], length 1448 >> 18:09:26.568850 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr >> 1108509403], length 1448 >> 18:09:26.568854 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr >> 1108509403], length 1448 >> 18:09:26.568861 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr >> 1108509403], length 1448 >> 18:09:26.568864 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr >> 1108509403], length 1448 >> 18:09:26.568867 IP FreeBSD.1983> =A0Linux.24747: Flags >> [P.], ack 622, win 12579, options [nop,nop,TS val 1857101667 ecr >> 1108509403], length 954 >> 18:09:26.569222 IP FreeBSD.1983> =A0Linux.24747: Flags >> [.], ack 623, win 12579, options [nop,nop,TS val 1857101667 ecr >> 1108509403], length 0 >> 18:09:26.569235 IP FreeBSD.1983> =A0Linux.24747: Flags >> [F.], seq 15720, ack 623, win 12579, options [nop,nop,TS val >> 1857101667 ecr 1108509403], length 0 >> >> Then, we make another connection initiated by FreeBSD, but with a >> sequence number that >> logically follows from the original outbound connection. =A0This fails, >> until eventually we automatically give up on timestamps. >> >> 18:09:34.631349 IP FreeBSD.57007> =A0Linux.80: Flags [S], >> seq 704145119, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val >> 827482602 ecr 0], length 0 >> 18:09:37.360671 IP FreeBSD.57056> =A0Linux.80: Flags [S], >> seq 2653481758, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS >> val 827485331 ecr 0], length 0 >> 18:09:37.631176 IP FreeBSD.57007> =A0Linux.80: Flags [S], >> seq 704145119, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val >> 827485602 ecr 0], length 0 >> 18:09:40.360134 IP FreeBSD.57056> =A0Linux.80: Flags [S], >> seq 2653481758, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS >> val 827488331 ecr 0], length 0 >> 18:09:40.831125 IP FreeBSD.57007> =A0Linux.80: Flags [S], >> seq 704145119, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS val >> 827488802 ecr 0], length 0 >> 18:09:43.560084 IP FreeBSD.57056> =A0Linux.80: Flags [S], >> seq 2653481758, win 65535, options [mss 1460,nop,wscale 4,sackOK,TS >> val 827491531 ecr 0], length 0 >> 18:09:44.031076 IP FreeBSD.57007> =A0Linux.80: Flags [S], >> seq 704145119, win 65535, options [mss 1460,sackOK,eol], length 0 >> 18:09:44.031280 IP FreeBSD.57007> =A0Linux.80: Flags [.], >> ack 4142946180, win 65535, length 0 >> >> We confirmed this further by disabled TCP timestamps on the Linux box >> via the 'net.ipv4.tcp_timestamps' sysctl, and the problem cleared up. >> Has any one else seen this? =A0Is there a more graceful work around >> aside from disabling timestamp support in Linux, or is there a sysctl >> I'm missing in FreeBSD that causes the timestamp to be global for each >> peer? > > > Linux does the per-host timestamp check only when you hit a 2MSL > graveyard connection. =A0It happens in net/ipv4/tcp_ipv4.c around > line 1376 within a PAWS check. > > Our in- and outbound timestamps are not synchronized to the same > base. =A0A timestamp on an SYN/ACK is somewhat randomized. =A0Whereas > a timestamp in a SYN is based off ticks and increases with later > connections. > > It seems you have a large number of short lived connections between > these hosts. =A0You may want to increase the port range for outgoing > connections to avoid recycling port numbers within the 2MSL time frame. > Alternatively you could decrease the 2MSL time on Linux. =A0Or you can > turn off syncookies on FreeBSD to avoid the SYN/ACK timestamp > randomization. > > Linux has over-engineered this whole thing for little to no benefit. > This additional check presumably also wrecks busy NAT IP addresses > where port recycling is fast. > > -- > Andre Andre, It sounds like disabling net.ipv4.tcp_timestamps as we are in Linux may be the quickest path to resolution without much real world effect. The Linux box only talks with internal hosts, whereas the FBSD does with external end users. We already have the port range on both sides opened up, so it seems the alternative to neutering it completely is lowering the net.ipv4.tcp_fin_timeout and disabling net.ipv4.tcp_tw_recycle, but it still has a chance to hit this scenario as it's heavily trafficked. net.inet.ip.portrange.first: 10000 net.inet.ip.portrange.last: 65535 net.ipv4.ip_local_port_range =3D 1024 61000 Thank you for the info, Jason From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 20:49:47 2012 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 0BF0D106566B for ; Sat, 31 Mar 2012 20:49:47 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (unknown [IPv6:2001:b70:201:2::22]) by mx1.freebsd.org (Postfix) with ESMTP id C14068FC14 for ; Sat, 31 Mar 2012 20:49:46 +0000 (UTC) Received: from [172.16.11.44] (unknown [91.208.177.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 87B2D2280C for ; Sat, 31 Mar 2012 21:49:45 +0100 (BST) Message-ID: <4F776DE5.5020507@rewt.org.uk> Date: Sat, 31 Mar 2012 21:49:41 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: kern.eventtimer.periodic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Mar 2012 20:49:47 -0000 Hey, So I have another box that has time issues since being upgraded to 9.0-REL, again kern.eventtimer.periodic=1 seems to be the fix. Should this perhaps be a default in future releases? From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 20:56:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49791106566B for ; Sat, 31 Mar 2012 20:56:14 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (unknown [IPv6:2001:b70:201:2::22]) by mx1.freebsd.org (Postfix) with ESMTP id D512F8FC14 for ; Sat, 31 Mar 2012 20:56:10 +0000 (UTC) Received: from [172.16.11.44] (unknown [91.208.177.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by hosted.mx.as41113.net (Postfix) with ESMTPSA id 1D8012280C; Sat, 31 Mar 2012 21:56:10 +0100 (BST) Message-ID: <4F776F65.2060703@rewt.org.uk> Date: Sat, 31 Mar 2012 21:56:05 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4F776DE5.5020507@rewt.org.uk> In-Reply-To: <4F776DE5.5020507@rewt.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable-net@freebsd.org Subject: Re: kern.eventtimer.periodic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 31 Mar 2012 20:56:14 -0000 Joe Holden wrote: > Hey, > > So I have another box that has time issues since being upgraded to > 9.0-REL, again kern.eventtimer.periodic=1 seems to be the fix. > > Should this perhaps be a default in future releases? Oops, that should have been to -stable! sorry for the noise