From owner-freebsd-net@FreeBSD.ORG Sun Mar 18 16:24:33 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 9D004106566B for ; Sun, 18 Mar 2012 16:24:33 +0000 (UTC) (envelope-from sol289@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 714788FC0A for ; Sun, 18 Mar 2012 16:24:33 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so822377pbc.13 for ; Sun, 18 Mar 2012 09:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Z1BKJMOoqALZxDWE1UtzPfs/m+VABkE6qEWT7XaW3jg=; b=j/3kdWIMM6EXTfrmTbHvB2TDQnTOq2/kNTZDGMm+HPimca5snALHFmNdhWy98ysWyZ PykIqP3Gxxa/olh49s90XD13G6NaAflJhiGmn6Rc3c+84DT0u2OiXaCJov0Rh4XIQpsU nZIJO9/VQ+cXqIv39JCVvSq+COucTVlmFANpebuMs8rU5o8NU8B4Nh7JTvwQIfzOM7Vl 0mdy8SVByvV5SCQFZbqCb0lbnG4WRVqdB201amy63vgBCmmyy3mdNRovSsPqzRMGrHYH nJqO3SrwKZ5fpzrPaxdCJ/7crB64NAhIQ/8/0WT84SYasLSoVQHhALN8ZD9Pvph2Asbs EcWA== Received: by 10.68.191.168 with SMTP id gz8mr32367974pbc.37.1332087873026; Sun, 18 Mar 2012 09:24:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.74.137 with HTTP; Sun, 18 Mar 2012 09:24:12 -0700 (PDT) In-Reply-To: References: <4F630D23.2070509@netfence.it> From: Alexander Lunev Date: Sun, 18 Mar 2012 20:24:12 +0400 Message-ID: To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: LAGG and CARP troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 16:24:33 -0000 On Fri, Mar 16, 2012 at 7:42 PM, Freddie Cash wrote: > If you're adventurous, could you upgrade a test box to 10-CURRENT and > try the new CARP code? I will try it on vmware stations. -- your sweet isn't ready yet From owner-freebsd-net@FreeBSD.ORG Sun Mar 18 22:40: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 18E93106566B for ; Sun, 18 Mar 2012 22:40:57 +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 9D1078FC08 for ; Sun, 18 Mar 2012 22:40:56 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id D73DA5D29F; Sun, 18 Mar 2012 23:40:48 +0100 (CET) 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 FnDmzidkQTzB; Sun, 18 Mar 2012 23:40:47 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id DC2AE5D29D; Sun, 18 Mar 2012 23:40:47 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 38CDA450A8; Sun, 18 Mar 2012 23:40:47 +0100 (CET) Message-ID: <4F66646E.4080603@incore.de> Date: Sun, 18 Mar 2012 23:40:46 +0100 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> In-Reply-To: <20120313202559.GA3360@michelle.cdnetworks.com> Content-Type: text/plain; charset=us-ascii 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: Sun, 18 Mar 2012 22:40:57 -0000 YongHyeon PYUN wrote: > > The microcode is normally used to reduce high number of interrupts > under heavy network load by bundling multiple RX frames. ok, I understand. But I have DEVICE_POLLING and HZ=1000 in the kernel source, so interrupts do not occur. > However > your reason to use microcode for i82550C looks weird since the > microcode used for i82550C does not have a fix for TCO bug. > The microcode for i82550(fxp2 in your system) indeed has fix for > TCO bug and includes additional feature for bundling. According to the comments in rcvbundl.h it is just directly opposed. > If you're > suffering from TCO bug of i82550, NFS over UDP issue should happen > only on i82550(fxp2). Can you check whether the NFS issue happens > on i82550C (fxp0 and fxp1) without loading the microcode? The NFS issue happens on fxp0 (i82550C) without loading of microcode: Mar 16 16:12:52 dssresv1 kernel: nfs server dsscam:/prod/mobotix: not responding Mar 16 16:13:24 dssresv1 kernel: nfs server dsscam:/prod/mobotix: not responding Mar 16 16:13:56 dssresv1 kernel: nfs server dsscam:/prod/mobotix: not responding Mar 16 16:14:28 dssresv1 kernel: nfs server dsscam:/prod/mobotix: not responding Mar 16 16:14:59 dssresv1 kernel: nfs server dsscam:/prod/mobotix: is alive again The last message appears immediately after loading the microcode with ifconfig fxp0 link0. > I still can't explain why your i82550C with the loaded microcode > does not generates SCB timeouts because mine always shows the error > right after loading the microcode. In FreeBSD 6 and 8 I need my bzero-patch to get fxp working, In FreeBSD 4 - on the same hardware - this was not necessary. > Are you actively using fxp0 or fxp1 after loading the microcode? Yes I have 6 server with fxp0/fxp1 i82550C and 2 server with fxp0/fxp1 i82550 on motherboard in production, additionally some fxp2 i82550 external cards. All run with microcode loaded and polling. > If yes, could you check whether > the CPU Saver feature of the microcode really works on i82550C? > You may be able to use netperf UDP stream test to verify that. I did some tests with netperf 2.5.0, At first I had to patch some format strings in netperf from %d to %lld for uint64_t variables to get readable output from netperf on my i386 systems. 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. Regards Andreas Longwitz From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 05:47:55 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 290BC106564A for ; Mon, 19 Mar 2012 05:47:55 +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 ED3F18FC12 for ; Mon, 19 Mar 2012 05:47:54 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so1064682pbc.13 for ; Sun, 18 Mar 2012 22:47:54 -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=yfICbeLhDR6lwemtvoEzM9n+b7nmjZWDQIvq0RnHcmA=; b=AbjGxTBjaJAfgvZ7mbeX7Y+MaU+rW9bRqn9bCkv1nhMg8nxoOlArtkT+2WRRd0OPe1 +M5NnubxV0M/BqdHnzBsZFpWBzB+Y1BeKsOr0nRwG3BfLjZyTScFbEOIEM1F2TKXwIvm UFSdFe5lEvOSpyqs2JJcZRcBWOZM/MJh4mgHawkRb/EpsCXXisM+oe98zcUAqkFMVa+r fHkhZN9vVbaYdfuzjfw6C4zqIHV8RItxeuvTQM9djLxjbEeAnQy26oXt3nXGIxYPlYJe h6ma+BIhl9c2GsVqE1qsHlZrqBXrPRWnpaTzxFiNxfW7p7UiVWS/Nt0bYqaYli2A/MCc Z3hw== Received: by 10.68.203.202 with SMTP id ks10mr22802404pbc.84.1332136074644; Sun, 18 Mar 2012 22:47:54 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id b7sm10539866pba.2.2012.03.18.22.47.52 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Mar 2012 22:47:54 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 19 Mar 2012 14:47:44 -0700 From: YongHyeon PYUN Date: Mon, 19 Mar 2012 14:47:44 -0700 To: Joe Holden Message-ID: <20120319214744.GC7518@michelle.cdnetworks.com> References: <4F64AB3B.9030806@rewt.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F64AB3B.9030806@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: Mon, 19 Mar 2012 05:47:55 -0000 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 > 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 From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 11:07:18 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 02EDC1065674 for ; Mon, 19 Mar 2012 11:07:18 +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 DF3268FC22 for ; Mon, 19 Mar 2012 11:07:17 +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 q2JB7HuO033654 for ; Mon, 19 Mar 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2JB7HAV033652 for freebsd-net@FreeBSD.org; Mon, 19 Mar 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Mar 2012 11:07:17 GMT Message-Id: <201203191107.q2JB7HAV033652@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, 19 Mar 2012 11:07:18 -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/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 bin/165413 net [netgraph]: ngctl(8) does not work as advertised 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 396 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 12:17: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 9F37E1065670 for ; Mon, 19 Mar 2012 12:17:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6BF4C8FC16 for ; Mon, 19 Mar 2012 12:17:01 +0000 (UTC) Received: by dald2 with SMTP id d2so10603852dal.13 for ; Mon, 19 Mar 2012 05:17:01 -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=DOagoC1IXI1AfQtoaI2qfcSRcIKVETG7HsGV8Hsdv2U=; b=Uv/eRMVD2mkC4l4qrv8rdqHuoRp+dESRm1n+CqWRHYid6rRruPYPjY2PW4Fb7sEDYJ 66UojHXxkBC/ggyZ5kLv/qZ40+Q5o1BHHA0hh9IWRxg1mSGbixpdlOsanGRe8SeBSc7i oENHl7AlaZ9gyObvcg9tvzCWDM5Kfv+WJMkaOpnh9OXCoaPPm4PcVM+c/+A8rWW5CTkC e/PgZgSzpqdmhxj4uqbNyI64UqWUWjPFPkjhu/QKM3RnhHk7kanCuxS+Zuf6iQ8fHDQC IPdni2fuqUcFeM9RByJ2A23DxuO6urmOQ4LJY5ZcG/ha+HDqYrpilNAbJ+aoohUQqZbu GC/g== Received: by 10.68.232.162 with SMTP id tp2mr39258064pbc.165.1332159420882; Mon, 19 Mar 2012 05:17:00 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id z5sm11248274pbn.35.2012.03.19.05.16.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 05:17:00 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 19 Mar 2012 21:16:47 -0700 From: YongHyeon PYUN Date: Mon, 19 Mar 2012 21:16:47 -0700 To: Andreas Longwitz Message-ID: <20120320041647.GE7518@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F66646E.4080603@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: Mon, 19 Mar 2012 12:17:01 -0000 On Sun, Mar 18, 2012 at 11:40:46PM +0100, Andreas Longwitz wrote: > YongHyeon PYUN wrote: > > > > The microcode is normally used to reduce high number of interrupts > > under heavy network load by bundling multiple RX frames. > > ok, I understand. But I have DEVICE_POLLING and HZ=1000 in the kernel > source, so interrupts do not occur. > Good data point. I'll try that on my box. > > However > > your reason to use microcode for i82550C looks weird since the > > microcode used for i82550C does not have a fix for TCO bug. > > The microcode for i82550(fxp2 in your system) indeed has fix for > > TCO bug and includes additional feature for bundling. > > According to the comments in rcvbundl.h it is just directly opposed. > > > If you're > > suffering from TCO bug of i82550, NFS over UDP issue should happen > > only on i82550(fxp2). Can you check whether the NFS issue happens > > on i82550C (fxp0 and fxp1) without loading the microcode? > > The NFS issue happens on fxp0 (i82550C) without loading of microcode: > Mar 16 16:12:52 dssresv1 kernel: nfs server > dsscam:/prod/mobotix: not responding > Mar 16 16:13:24 dssresv1 kernel: nfs server > dsscam:/prod/mobotix: not responding > Mar 16 16:13:56 dssresv1 kernel: nfs server > dsscam:/prod/mobotix: not responding > Mar 16 16:14:28 dssresv1 kernel: nfs server > dsscam:/prod/mobotix: not responding > Mar 16 16:14:59 dssresv1 kernel: nfs server > dsscam:/prod/mobotix: is alive again > 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. > The last message appears immediately after loading the microcode with > ifconfig fxp0 link0. > > > I still can't explain why your i82550C with the loaded microcode > > does not generates SCB timeouts because mine always shows the error > > right after loading the microcode. > > In FreeBSD 6 and 8 I need my bzero-patch to get fxp working, In FreeBSD > 4 - on the same hardware - this was not necessary. > > > Are you actively using fxp0 or fxp1 after loading the microcode? > > Yes I have 6 server with fxp0/fxp1 i82550C and 2 server with fxp0/fxp1 > i82550 on motherboard in production, additionally some fxp2 i82550 > external cards. All run with microcode loaded and polling. > > > If yes, could you check whether > > the CPU Saver feature of the microcode really works on i82550C? > > You may be able to use netperf UDP stream test to verify that. > > I did some tests with netperf 2.5.0, At first I had to patch some format > strings in netperf from %d to %lld for uint64_t variables to get > readable output from netperf on my i386 systems. > Yeah, that is one of bug of netperf. > 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. 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. > > > Regards > > Andreas Longwitz > From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 12:40:14 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 F2B96106564A for ; Mon, 19 Mar 2012 12:40:14 +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 DB4078FC19 for ; Mon, 19 Mar 2012 12:40:14 +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 q2JCeEvn023915 for ; Mon, 19 Mar 2012 12:40:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2JCeEXJ023914; Mon, 19 Mar 2012 12:40:14 GMT (envelope-from gnats) Date: Mon, 19 Mar 2012 12:40:14 GMT Message-Id: <201203191240.q2JCeEXJ023914@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Andrey Simonenko Cc: Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Simonenko List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 12:40:15 -0000 The following reply was made to PR bin/131567; it has been noted by GNATS. From: Andrey Simonenko To: bug-followup@freebsd.org Cc: Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg Date: Mon, 19 Mar 2012 14:37:05 +0200 Updated unix_cmsg: all flags were converted to 'bool' datatype from , use macro variables values from for return values in all exit() calls. Verified correctness of unix_cmsg on 9.0-STABLE and 10-CURRENT. diff -ruNp unix_cmsg.orig/README unix_cmsg/README --- unix_cmsg.orig/README 2006-05-29 21:40:55.000000000 +0300 +++ unix_cmsg/README 2012-03-19 13:42:52.000000000 +0200 @@ -1,7 +1,7 @@ $FreeBSD: src/tools/regression/sockets/unix_cmsg/README,v 1.1 2006/05/29 18:40:55 maxim Exp $ About unix_cmsg -================ +=============== This program is a collection of regression tests for ancillary (control) data for PF_LOCAL sockets (local domain or Unix domain sockets). There @@ -13,8 +13,8 @@ is correct in received message. Sometim messages to Server. It is better to change the owner of unix_cmsg to some safe user -(eg. nobody:nogroup) and set SUID and SGID bits, else some tests -can give correct results for wrong implementation. +(eg. nobody:nogroup) and set SUID and SGID bits, else some tests that +check credentials can give correct results for wrong implementation. Available options ================= @@ -24,13 +24,13 @@ Available options -h Output help message and exit. --t +-t socktype Run tests only for the given socket type: "stream" or "dgram". With this option it is possible to run only particular test, not all of them. -z Do not send real control data if possible. Struct cmsghdr{} - should be followed by real control data. It is not clear if + should be followed by real control data. It is not clear whether a sender should give control data in all cases (this is not documented and an arbitrary application can choose anything). @@ -90,6 +90,13 @@ For SOCK_STREAM sockets: message with data and control message with SCM_TIMESTAMP type followed by struct timeval{}. + 6: Check LOCAL_PEERCRED socket option + + This test does not use control data for PF_LOCAL sockets, but can be + implemented here. Client connects to Server. Both Client and Server + verify that credentials of the peer are correct using LOCAL_PEERCRED + socket option. + For SOCK_DGRAM sockets: ---------------------- @@ -110,7 +117,7 @@ For SOCK_DGRAM sockets: structure should contain correct information. 3: Sending cmsgcred, receiving sockcred - + Server creates datagram socket and set socket option LOCAL_CREDS for it. Client sends one message with data and control message with SOCK_CREDS type to Server. Server should receive one message with diff -ruNp unix_cmsg.orig/unix_cmsg.c unix_cmsg/unix_cmsg.c --- unix_cmsg.orig/unix_cmsg.c 2006-05-31 11:10:34.000000000 +0300 +++ unix_cmsg/unix_cmsg.c 2012-03-19 14:26:40.000000000 +0200 @@ -27,10 +27,12 @@ #include __FBSDID("$FreeBSD: src/tools/regression/sockets/unix_cmsg/unix_cmsg.c,v 1.2 2006/05/31 08:10:34 maxim Exp $"); -#include +#include #include #include +#include #include +#include #include #include @@ -38,16 +40,16 @@ __FBSDID("$FreeBSD: src/tools/regression #include #include #include +#include #include #include -#include #include #include +#include #include #include #include #include -#include #include /* @@ -68,7 +70,7 @@ __FBSDID("$FreeBSD: src/tools/regression * * Each function which can block, is run under TIMEOUT, if timeout * occurs, then test function returns -2 or a client process exits - * with nonzero return code. + * with non-zero return code. */ #ifndef LISTENQ @@ -76,46 +78,88 @@ __FBSDID("$FreeBSD: src/tools/regression #endif #ifndef TIMEOUT -# define TIMEOUT 60 +# define TIMEOUT 5 #endif #define EXTRA_CMSG_SPACE 512 /* Memory for not expected control data. */ -static int t_cmsgcred(void), t_sockcred_stream1(void); -static int t_sockcred_stream2(void), t_cmsgcred_sockcred(void); -static int t_sockcred_dgram(void), t_timestamp(void); +static int t_cmsgcred(void); +static int t_sockcred_stream1(void); +static int t_sockcred_stream2(void); +static int t_cmsgcred_sockcred(void); +static int t_sockcred_dgram(void); +static int t_timestamp(void); +static int t_peercred(void); struct test_func { - int (*func)(void); /* Pointer to function. */ - const char *desc; /* Test description. */ + int (*func)(void); /* Pointer to function. */ + const char *desc; /* Test description. */ }; -static struct test_func test_stream_tbl[] = { - { NULL, " 0: All tests" }, - { t_cmsgcred, " 1: Sending, receiving cmsgcred" }, - { t_sockcred_stream1, " 2: Receiving sockcred (listening socket has LOCAL_CREDS)" }, - { t_sockcred_stream2, " 3: Receiving sockcred (accepted socket has LOCAL_CREDS)" }, - { t_cmsgcred_sockcred, " 4: Sending cmsgcred, receiving sockcred" }, - { t_timestamp, " 5: Sending, receiving timestamp" }, - { NULL, NULL } +static const struct test_func test_stream_tbl[] = { + { + .func = NULL, + .desc = "All tests" + }, + { + .func = t_cmsgcred, + .desc = "Sending, receiving cmsgcred" + }, + { + .func = t_sockcred_stream1, + .desc = "Receiving sockcred (listening socket has LOCAL_CREDS)" + }, + { + .func = t_sockcred_stream2, + .desc = "Receiving sockcred (accepted socket has LOCAL_CREDS)" + }, + { + .func = t_cmsgcred_sockcred, + .desc = "Sending cmsgcred, receiving sockcred" + }, + { + .func = t_timestamp, + .desc = "Sending, receiving timestamp" + }, + { + .func = t_peercred, + .desc = "Check LOCAL_PEERCRED socket option" + } }; -static struct test_func test_dgram_tbl[] = { - { NULL, " 0: All tests" }, - { t_cmsgcred, " 1: Sending, receiving cmsgcred" }, - { t_sockcred_dgram, " 2: Receiving sockcred" }, - { t_cmsgcred_sockcred, " 3: Sending cmsgcred, receiving sockcred" }, - { t_timestamp, " 4: Sending, receiving timestamp" }, - { NULL, NULL } +#define TEST_STREAM_TBL_SIZE \ + (sizeof(test_stream_tbl) / sizeof(test_stream_tbl[0])) + +static const struct test_func test_dgram_tbl[] = { + { + .func = NULL, + .desc = "All tests" + }, + { + .func = t_cmsgcred, + .desc = "Sending, receiving cmsgcred" + }, + { + .func = t_sockcred_dgram, + .desc = "Receiving sockcred" + }, + { + .func = t_cmsgcred_sockcred, + .desc = "Sending cmsgcred, receiving sockcred" + }, + { + .func = t_timestamp, + .desc = "Sending, receiving timestamp" + } }; -#define TEST_STREAM_NO_MAX (sizeof(test_stream_tbl) / sizeof(struct test_func) - 2) -#define TEST_DGRAM_NO_MAX (sizeof(test_dgram_tbl) / sizeof(struct test_func) - 2) +#define TEST_DGRAM_TBL_SIZE \ + (sizeof(test_dgram_tbl) / sizeof(test_dgram_tbl[0])) -static const char *myname = "SERVER"; /* "SERVER" or "CLIENT" */ +static const char *myname; /* "SERVER" or "CLIENT" */ -static int debug = 0; /* 1, if -d. */ -static int no_control_data = 0; /* 1, if -z. */ +static bool debug = false; /* -d */ +static bool no_control_data = false;/* -z */ static u_int nfailed = 0; /* Number of failed tests. */ @@ -131,17 +175,11 @@ static char ipc_message[] = "hello"; static struct sockaddr_un servaddr; /* Server address. */ -static sigjmp_buf env_alrm; - static uid_t my_uid; static uid_t my_euid; static gid_t my_gid; static gid_t my_egid; -/* - * my_gids[0] is EGID, next items are supplementary GIDs, - * my_ngids determines valid items in my_gids array. - */ static gid_t my_gids[NGROUPS_MAX]; static int my_ngids; @@ -150,38 +188,35 @@ static pid_t client_pid; /* PID of fork #define dbgmsg(x) do { \ if (debug) \ logmsgx x ; \ -} while (/* CONSTCOND */0) +} while (0) static void logmsg(const char *, ...) __printflike(1, 2); static void logmsgx(const char *, ...) __printflike(1, 2); static void output(const char *, ...) __printflike(1, 2); -extern char *__progname; /* The name of program. */ - /* * Output the help message (-h switch). */ static void -usage(int quick) +usage(bool verbose) { - const struct test_func *test_func; + u_int i; - fprintf(stderr, "Usage: %s [-dhz] [-t ] [testno]\n", - __progname); - if (quick) + fprintf(stderr, "usage: %s [-dhz] [-t socktype] [testno]\n", + getprogname()); + if (!verbose) return; fprintf(stderr, "\n Options are:\n\ -d\t\t\tOutput debugging information\n\ -h\t\t\tOutput this help message and exit\n\ - -t \t\tRun test only for the given socket type:\n\ -\t\t\tstream or dgram\n\ + -t socktype\t\tRun test only for socket type: stream or dgram\n\ -z\t\t\tDo not send real control data if possible\n\n"); fprintf(stderr, " Available tests for stream sockets:\n"); - for (test_func = test_stream_tbl; test_func->desc != NULL; ++test_func) - fprintf(stderr, " %s\n", test_func->desc); + for (i = 0; i < TEST_STREAM_TBL_SIZE; ++i) + fprintf(stderr, " %u: %s\n", i, test_stream_tbl[i].desc); fprintf(stderr, "\n Available tests for datagram sockets:\n"); - for (test_func = test_dgram_tbl; test_func->desc != NULL; ++test_func) - fprintf(stderr, " %s\n", test_func->desc); + for (i = 0; i < TEST_DGRAM_TBL_SIZE; ++i) + fprintf(stderr, " %u: %s\n", i, test_dgram_tbl[i].desc); } /* @@ -195,7 +230,7 @@ output(const char *format, ...) va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "output: vsnprintf failed"); + err(EXIT_FAILURE, "output: vsnprintf failed"); write(STDOUT_FILENO, buf, strlen(buf)); va_end(ap); } @@ -210,18 +245,16 @@ logmsg(const char *format, ...) va_list ap; int errno_save; - errno_save = errno; /* Save errno. */ - + errno_save = errno; va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "logmsg: vsnprintf failed"); + err(EXIT_FAILURE, "logmsg: vsnprintf failed"); if (errno_save == 0) output("%s: %s\n", myname, buf); else output("%s: %s: %s\n", myname, buf, strerror(errno_save)); va_end(ap); - - errno = errno_save; /* Restore errno. */ + errno = errno_save; } /* @@ -235,33 +268,47 @@ logmsgx(const char *format, ...) va_start(ap, format); if (vsnprintf(buf, sizeof(buf), format, ap) < 0) - err(EX_SOFTWARE, "logmsgx: vsnprintf failed"); + err(EXIT_FAILURE, "logmsgx: vsnprintf failed"); output("%s: %s\n", myname, buf); va_end(ap); } /* - * Run tests from testno1 to testno2. + * Run tests for the given socket type. */ static int -run_tests(u_int testno1, u_int testno2) +run_tests(int type, u_int testno1) { - const struct test_func *test_func; - u_int i, nfailed1; + const struct test_func *tf; + u_int i, nfailed1, testno2; - output("Running tests for %s sockets:\n", sock_type_str); - test_func = (sock_type == SOCK_STREAM ? - test_stream_tbl : test_dgram_tbl) + testno1; + sock_type = type; + if (type == SOCK_STREAM) { + sock_type_str = "SOCK_STREAM"; + tf = test_stream_tbl; + i = TEST_STREAM_TBL_SIZE - 1; + } else { + sock_type_str = "SOCK_DGRAM"; + tf = test_dgram_tbl; + i = TEST_DGRAM_TBL_SIZE - 1; + } + if (testno1 == 0) { + testno1 = 1; + testno2 = i; + } else + testno2 = testno1; + output("Running tests for %s sockets:\n", sock_type_str); nfailed1 = 0; - for (i = testno1; i <= testno2; ++test_func, ++i) { - output(" %s\n", test_func->desc); - switch (test_func->func()) { + for (i = testno1, tf += testno1; i <= testno2; ++tf, ++i) { + output(" %u: %s\n", i, tf->desc); + switch (tf->func()) { case -1: ++nfailed1; break; case -2: - logmsgx("some system error occurred, exiting"); + logmsgx("some system error or timeout occurred, " + "exiting"); return (-1); } } @@ -284,181 +331,222 @@ run_tests(u_int testno1, u_int testno2) return (0); } -/* ARGSUSED */ +/* + * Initialize signals handlers. + */ static void -sig_alrm(int signo __unused) +sig_init(void) { - siglongjmp(env_alrm, 1); + struct sigaction sigact; + + sigact.sa_handler = SIG_IGN; + sigact.sa_flags = 0; + sigemptyset(&sigact.sa_mask); + if (sigaction(SIGPIPE, &sigact, (struct sigaction *)NULL) < 0) + err(EXIT_FAILURE, "sigaction(SIGPIPE)"); } /* - * Initialize signals handlers. + * Output this process UID, GID, groups from getgroups(), EUID and EGID. */ static void -sig_init(void) +show_my_id(void) { - struct sigaction sa; + int i; - sa.sa_handler = SIG_IGN; - sigemptyset(&sa.sa_mask); - sa.sa_flags = 0; - if (sigaction(SIGPIPE, &sa, (struct sigaction *)NULL) < 0) - err(EX_OSERR, "sigaction(SIGPIPE)"); - - sa.sa_handler = sig_alrm; - if (sigaction(SIGALRM, &sa, (struct sigaction *)NULL) < 0) - err(EX_OSERR, "sigaction(SIGALRM)"); + if (!debug) + return; + logmsgx("UID %lu, GID %lu, groups from getgroups():", + (u_long)my_uid, (u_long)my_gid); + for (i = 0; i < my_ngids; ++i) + logmsgx(" GID %lu", (u_long)my_gids[i]); + logmsgx("EUID %lu, EGID %lu", (u_long)my_euid, (u_long)my_egid); +} + +static int +fork_client(void) +{ + client_pid = fork(); + if (client_pid == 0) + myname = "CLIENT"; + else if (client_pid == (pid_t)-1) { + logmsg("fork"); + return (-1); + } + return (0); } int main(int argc, char *argv[]) { const char *errstr; - int opt, dgramflag, streamflag; - u_int testno1, testno2; + u_int testno; + int opt, rv; + bool dgramflag, streamflag; - dgramflag = streamflag = 0; + dgramflag = streamflag = false; while ((opt = getopt(argc, argv, "dht:z")) != -1) switch (opt) { case 'd': - debug = 1; + debug = true; break; case 'h': - usage(0); - return (EX_OK); + usage(true); + return (EXIT_SUCCESS); case 't': if (strcmp(optarg, "stream") == 0) - streamflag = 1; + streamflag = true; else if (strcmp(optarg, "dgram") == 0) - dgramflag = 1; + dgramflag = true; else - errx(EX_USAGE, "wrong socket type in -t option"); + errx(EXIT_FAILURE, "option -t: " + "wrong socket type"); break; case 'z': - no_control_data = 1; + no_control_data = true; break; case '?': default: - usage(1); - return (EX_USAGE); + usage(false); + return (EXIT_FAILURE); } if (optind < argc) { if (optind + 1 != argc) - errx(EX_USAGE, "too many arguments"); - testno1 = strtonum(argv[optind], 0, UINT_MAX, &errstr); + errx(EXIT_FAILURE, "too many arguments"); + testno = strtonum(argv[optind], 0, UINT_MAX, &errstr); if (errstr != NULL) - errx(EX_USAGE, "wrong test number: %s", errstr); + errx(EXIT_FAILURE, "wrong test number: %s", errstr); } else - testno1 = 0; + testno = 0; - if (dgramflag == 0 && streamflag == 0) - dgramflag = streamflag = 1; + if (!dgramflag && !streamflag) + dgramflag = streamflag = true; - if (dgramflag && streamflag && testno1 != 0) - errx(EX_USAGE, "you can use particular test, only with datagram or stream sockets"); + if (dgramflag && streamflag && testno != 0) + errx(EXIT_FAILURE, "you can use particular test, only " + "with datagram or stream sockets"); if (streamflag) { - if (testno1 > TEST_STREAM_NO_MAX) - errx(EX_USAGE, "given test %u for stream sockets does not exist", - testno1); + if (testno >= TEST_STREAM_TBL_SIZE) + errx(EXIT_FAILURE, "given test %u for stream " + "sockets does not exist", testno); } else { - if (testno1 > TEST_DGRAM_NO_MAX) - errx(EX_USAGE, "given test %u for datagram sockets does not exist", - testno1); + if (testno >= TEST_DGRAM_TBL_SIZE) + errx(EXIT_FAILURE, "given test %u for datagram " + "sockets does not exist", testno); } my_uid = getuid(); my_euid = geteuid(); my_gid = getgid(); my_egid = getegid(); - switch (my_ngids = getgroups(sizeof(my_gids) / sizeof(my_gids[0]), my_gids)) { + my_ngids = getgroups(sizeof(my_gids) / sizeof(my_gids[0]), my_gids); + switch (my_ngids) { case -1: - err(EX_SOFTWARE, "getgroups"); + err(EXIT_FAILURE, "getgroups"); /* NOTREACHED */ case 0: - errx(EX_OSERR, "getgroups returned 0 groups"); + errx(EXIT_FAILURE, "getgroups returned no groups"); } sig_init(); if (mkdtemp(tempdir) == NULL) - err(EX_OSERR, "mkdtemp"); + err(EXIT_FAILURE, "mkdtemp"); - if (streamflag) { - sock_type = SOCK_STREAM; - sock_type_str = "SOCK_STREAM"; - if (testno1 == 0) { - testno1 = 1; - testno2 = TEST_STREAM_NO_MAX; - } else - testno2 = testno1; - if (run_tests(testno1, testno2) < 0) - goto failed; - testno1 = 0; - } - - if (dgramflag) { - sock_type = SOCK_DGRAM; - sock_type_str = "SOCK_DGRAM"; - if (testno1 == 0) { - testno1 = 1; - testno2 = TEST_DGRAM_NO_MAX; - } else - testno2 = testno1; - if (run_tests(testno1, testno2) < 0) - goto failed; - } + myname = "SERVER"; + rv = EXIT_SUCCESS; + show_my_id(); + if (streamflag) + if (run_tests(SOCK_STREAM, testno) < 0) + rv = EXIT_FAILURE; + if (dgramflag && rv == EXIT_SUCCESS) + if (run_tests(SOCK_DGRAM, testno) < 0) + rv = EXIT_FAILURE; if (rmdir(tempdir) < 0) { logmsg("rmdir(%s)", tempdir); - return (EX_OSERR); + rv = EXIT_FAILURE; } - return (nfailed ? EX_OSERR : EX_OK); + return (nfailed > 0 ? EXIT_FAILURE : rv); +} -failed: - if (rmdir(tempdir) < 0) - logmsg("rmdir(%s)", tempdir); - return (EX_OSERR); +/* + * Close socket descriptor, if sock_path is not equal to NULL, + * then unlink the given path. + */ +static int +close_socket(const char *sock_path, int fd) +{ + int rv; + + if (close(fd) < 0) { + logmsg("close_socket: close"); + rv = -1; + } else + rv = 0; + if (sock_path != NULL) + if (unlink(sock_path) < 0) { + logmsg("close_socket: unlink(%s)", sock_path); + rv = -1; + } + return (rv); } /* * Create PF_LOCAL socket, if sock_path is not equal to NULL, then - * bind() it. Return socket address in addr. Return file descriptor + * bind() it. Return socket address in *un. Return file descriptor * or -1 if some error occurred. */ static int -create_socket(char *sock_path, size_t sock_path_len, struct sockaddr_un *addr) +create_socket(char *sock_path, size_t sock_path_len, struct sockaddr_un *un) { - int rv, fd; + struct timeval tv; + int fd; - if ((fd = socket(PF_LOCAL, sock_type, 0)) < 0) { - logmsg("create_socket: socket(PF_LOCAL, %s, 0)", sock_type_str); + fd = socket(PF_LOCAL, sock_type, 0); + if (fd < 0) { + logmsg("create_socket: socket(PF_LOCAL, %s, 0)", + sock_type_str); return (-1); } + tv.tv_sec = TIMEOUT; + tv.tv_usec = 0; + if (setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)) < 0 || + setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, &tv, sizeof(tv)) < 0) { + logmsg("create_socket: setsockopt(SO_RCVTIMEO/SO_SNDTIMEO)"); + goto failed; + } + if (sock_path != NULL) { - if ((rv = snprintf(sock_path, sock_path_len, "%s/%s", - tempdir, myname)) < 0) { + int rv; + + rv = snprintf(sock_path, sock_path_len, "%s/%s", tempdir, + myname); + if (rv < 0) { logmsg("create_socket: snprintf failed"); goto failed; } if ((size_t)rv >= sock_path_len) { - logmsgx("create_socket: too long path name for given buffer"); + logmsgx("create_socket: too long path name for " + "given buffer"); goto failed; } - - memset(addr, 0, sizeof(addr)); - addr->sun_family = AF_LOCAL; - if (strlen(sock_path) >= sizeof(addr->sun_path)) { - logmsgx("create_socket: too long path name (>= %lu) for local domain socket", - (u_long)sizeof(addr->sun_path)); + if (strlen(sock_path) >= sizeof(un->sun_path)) { + logmsgx("create_socket: too long path name (>= %zu) " + "for local domain socket", sizeof(un->sun_path)); goto failed; } - strcpy(addr->sun_path, sock_path); - if (bind(fd, (struct sockaddr *)addr, SUN_LEN(addr)) < 0) { + memset(un, 0, sizeof(un)); + un->sun_family = PF_LOCAL; + strcpy(un->sun_path, sock_path); + un->sun_len = SUN_LEN(un); + + if (bind(fd, (struct sockaddr *)un, un->sun_len) < 0) { logmsg("create_socket: bind(%s)", sock_path); goto failed; } @@ -473,43 +561,49 @@ failed: } /* - * Call create_socket() for server listening socket. - * Return socket descriptor or -1 if some error occurred. + * Create server socket. */ static int create_server_socket(void) { - return (create_socket(serv_sock_path, sizeof(serv_sock_path), &servaddr)); -} + int fd; -/* - * Create unbound socket. - */ -static int -create_unbound_socket(void) -{ - return (create_socket((char *)NULL, 0, (struct sockaddr_un *)NULL)); + fd = create_socket(serv_sock_path, sizeof(serv_sock_path), &servaddr); + if (fd < 0) + return (-1); + + if (sock_type == SOCK_STREAM) { + int val; + + if (listen(fd, LISTENQ) < 0) { + logmsg("create_server_socket: listen"); + goto failed; + } + val = fcntl(fd, F_GETFL, 0); + if (val < 0) { + logmsg("create_server_socket: fcntl(F_GETFL)"); + goto failed; + } + if (fcntl(fd, F_SETFL, val | O_NONBLOCK) < 0) { + logmsg("create_server_socket: fcntl(F_SETFL)"); + goto failed; + } + } + + return (fd); + +failed: + (void)close_socket(serv_sock_path, fd); + return (-1); } /* - * Close socket descriptor, if sock_path is not equal to NULL, - * then unlink the given path. + * Create client socket. */ static int -close_socket(const char *sock_path, int fd) +create_client_socket(void) { - int error = 0; - - if (close(fd) < 0) { - logmsg("close_socket: close"); - error = -1; - } - if (sock_path != NULL) - if (unlink(sock_path) < 0) { - logmsg("close_socket: unlink(%s)", sock_path); - error = -1; - } - return (error); + return (create_socket((char *)NULL, 0, (struct sockaddr_un *)NULL)); } /* @@ -524,7 +618,7 @@ connect_server(int fd) * If PF_LOCAL listening socket's queue is full, then connect() * returns ECONNREFUSED immediately, do not need timeout. */ - if (connect(fd, (struct sockaddr *)&servaddr, sizeof(servaddr)) < 0) { + if (connect(fd, (struct sockaddr *)&servaddr, servaddr.sun_len) < 0) { logmsg("connect_server: connect(%s)", serv_sock_path); return (-1); } @@ -533,34 +627,23 @@ connect_server(int fd) } /* - * sendmsg() with timeout. + * sendmsg() wrapper. */ static int -sendmsg_timeout(int fd, struct msghdr *msg, size_t n) +send_message(int fd, const struct msghdr *msg, size_t n) { ssize_t nsent; - dbgmsg(("sending %lu bytes", (u_long)n)); - - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sendmsg_timeout: cannot send message to %s (timeout)", serv_sock_path); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("sending %zu bytes", n)); nsent = sendmsg(fd, msg, 0); - - (void)alarm(0); - if (nsent < 0) { - logmsg("sendmsg_timeout: sendmsg"); + logmsg("send_message: sendmsg"); return (-1); } - if ((size_t)nsent != n) { - logmsgx("sendmsg_timeout: sendmsg: short send: %ld of %lu bytes", - (long)nsent, (u_long)n); + logmsgx("send_message: sendmsg: short send: " + "%zd of %zu bytes", nsent, n); return (-1); } @@ -568,63 +651,73 @@ sendmsg_timeout(int fd, struct msghdr *m } /* - * accept() with timeout. + * accept() wrapper. */ static int -accept_timeout(int listenfd) +accept_connection(int listenfd) { - int fd; + fd_set rset; + struct timeval tv; + int fd, rv, val; dbgmsg(("accepting connection")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("accept_timeout: cannot accept connection (timeout)"); + FD_ZERO(&rset); + FD_SET(listenfd, &rset); + tv.tv_sec = TIMEOUT; + tv.tv_usec = 0; + rv = select(listenfd + 1, &rset, (fd_set *)NULL, (fd_set *)NULL, &tv); + if (rv < 0) { + logmsg("accept_connection: select"); + return (-1); + } + if (rv == 0) { + logmsgx("accept_connection: select timeout"); return (-1); } - - (void)alarm(TIMEOUT); fd = accept(listenfd, (struct sockaddr *)NULL, (socklen_t *)NULL); - - (void)alarm(0); - if (fd < 0) { - logmsg("accept_timeout: accept"); + logmsg("accept_connection: accept"); return (-1); } + val = fcntl(fd, F_GETFL, 0); + if (val < 0) { + logmsg("accept_connection: fcntl(F_GETFL)"); + goto failed; + } + if (fcntl(fd, F_SETFL, val & ~O_NONBLOCK) < 0) { + logmsg("accept_connection: fcntl(F_SETFL)"); + goto failed; + } + return (fd); + +failed: + if (close(fd) < 0) + logmsg("accept_connection: close"); + return (-1); } /* - * recvmsg() with timeout. + * recvmsg() wrapper. */ static int -recvmsg_timeout(int fd, struct msghdr *msg, size_t n) +recv_message(int fd, struct msghdr *msg, size_t n) { ssize_t nread; - dbgmsg(("receiving %lu bytes", (u_long)n)); - - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("recvmsg_timeout: cannot receive message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("receiving %zu bytes", n)); nread = recvmsg(fd, msg, MSG_WAITALL); - - (void)alarm(0); - if (nread < 0) { - logmsg("recvmsg_timeout: recvmsg"); + logmsg("recv_message: recvmsg"); return (-1); } - if ((size_t)nread != n) { - logmsgx("recvmsg_timeout: recvmsg: short read: %ld of %lu bytes", - (long)nread, (u_long)n); + logmsgx("recv_message: recvmsg: short read: " + "%zd of %zu bytes", nread, n); return (-1); } @@ -632,7 +725,7 @@ recvmsg_timeout(int fd, struct msghdr *m } /* - * Wait for synchronization message (1 byte) with timeout. + * Wait for synchronization message (1 byte). */ static int sync_recv(int fd) @@ -642,25 +735,13 @@ sync_recv(int fd) dbgmsg(("waiting for sync message")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sync_recv: cannot receive sync message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); - nread = read(fd, &buf, 1); - - (void)alarm(0); - if (nread < 0) { logmsg("sync_recv: read"); return (-1); } - if (nread != 1) { - logmsgx("sync_recv: read: short read: %ld of 1 byte", - (long)nread); + logmsgx("sync_recv: read: short read: %zd of 1 byte", nread); return (-1); } @@ -668,7 +749,7 @@ sync_recv(int fd) } /* - * Send synchronization message (1 byte) with timeout. + * Send synchronization message (1 byte). */ static int sync_send(int fd) @@ -677,25 +758,13 @@ sync_send(int fd) dbgmsg(("sending sync message")); - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("sync_send: cannot send sync message (timeout)"); - return (-1); - } - - (void)alarm(TIMEOUT); - nsent = write(fd, "", 1); - - (void)alarm(0); - if (nsent < 0) { logmsg("sync_send: write"); return (-1); } - if (nsent != 1) { - logmsgx("sync_send: write: short write: %ld of 1 byte", - (long)nsent); + logmsgx("sync_send: write: short write: %zd of 1 byte", nsent); return (-1); } @@ -711,36 +780,29 @@ wait_client(void) int status; pid_t pid; - if (sigsetjmp(env_alrm, 1) != 0) { - logmsgx("wait_client: cannot get exit status of client PID %ld (timeout)", - (long)client_pid); - return (-1); - } - - (void)alarm(TIMEOUT); + dbgmsg(("waiting for a client")); pid = waitpid(client_pid, &status, 0); - - (void)alarm(0); - if (pid == (pid_t)-1) { logmsg("wait_client: waitpid"); return (-1); } if (WIFEXITED(status)) { - if (WEXITSTATUS(status) != 0) { - logmsgx("wait_client: exit status of client PID %ld is %d", - (long)client_pid, WEXITSTATUS(status)); + if (WEXITSTATUS(status) != EXIT_SUCCESS) { + logmsgx("wait_client: exit status of client PID %ld " + "is %d", (long)client_pid, WEXITSTATUS(status)); return (-1); } } else { if (WIFSIGNALED(status)) - logmsgx("wait_client: abnormal termination of client PID %ld, signal %d%s", - (long)client_pid, WTERMSIG(status), WCOREDUMP(status) ? " (core file generated)" : ""); + logmsgx("wait_client: abnormal termination of client " + "PID %ld, signal %d%s", (long)client_pid, + WTERMSIG(status), WCOREDUMP(status) ? + " (core file generated)" : ""); else - logmsgx("wait_client: termination of client PID %ld, unknown status", - (long)client_pid); + logmsgx("wait_client: termination of client PID %ld, " + "unknown status", (long)client_pid); return (-1); } @@ -748,28 +810,27 @@ wait_client(void) } /* - * Check if n supplementary GIDs in gids are correct. (my_gids + 1) - * has (my_ngids - 1) supplementary GIDs of current process. + * Check whether n GIDs in gids are correct. */ static int check_groups(const gid_t *gids, int n) { + int i, j, rv; char match[NGROUPS_MAX] = { 0 }; - int error, i, j; - if (n != my_ngids - 1) { - logmsgx("wrong number of groups %d != %d (returned from getgroups() - 1)", - n, my_ngids - 1); - error = -1; + if (n != my_ngids) { + logmsgx("wrong number of groups %d != %d (returned from " + "getgroups())", n, my_ngids); + rv = -1; } else - error = 0; + rv = 0; for (i = 0; i < n; ++i) { - for (j = 1; j < my_ngids; ++j) { + for (j = 0; j < my_ngids; ++j) { if (gids[i] == my_gids[j]) { if (match[j]) { logmsgx("duplicated GID %lu", (u_long)gids[i]); - error = -1; + rv = -1; } else match[j] = 1; break; @@ -777,15 +838,15 @@ check_groups(const gid_t *gids, int n) } if (j == my_ngids) { logmsgx("unexpected GID %lu", (u_long)gids[i]); - error = -1; + rv = -1; } } - for (j = 1; j < my_ngids; ++j) + for (j = 0; j < my_ngids; ++j) if (match[j] == 0) { - logmsgx("did not receive supplementary GID %u", my_gids[j]); - error = -1; + logmsgx("did not receive GID %lu", (u_long)my_gids[j]); + rv = -1; } - return (error); + return (rv); } /* @@ -802,16 +863,19 @@ t_cmsgcred_client(u_int n) struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - int fd; u_int i; + int fd, rv; assert(n == 1 || n == 2); - if ((fd = create_unbound_socket()) < 0) + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -834,20 +898,16 @@ t_cmsgcred_client(u_int n) for (i = 0; i < n; ++i) { dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; } - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); - + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd)) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -858,28 +918,27 @@ failed: static int t_cmsgcred_server(int fd1) { - char buf[IPC_MESSAGE_SIZE]; union { struct cmsghdr cm; - char control[CMSG_SPACE(sizeof(struct cmsgcred)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(sizeof(struct cmsgcred)) + + EXTRA_CMSG_SPACE]; } control_un; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - const struct cmsgcred *cmcredptr; - socklen_t controllen; - int error, error2, fd2; + const struct cmsgcred *cmcred; u_int i; + int fd2, rv; + char buf[IPC_MESSAGE_SIZE]; if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); } else fd2 = fd1; - error = 0; - - controllen = sizeof(control_un.control); + rv = 0; for (i = 0; i < 2; ++i) { iov[0].iov_base = buf; @@ -890,29 +949,31 @@ t_cmsgcred_server(int fd1) msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = controllen; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - controllen = CMSG_SPACE(sizeof(struct cmsgcred)); - - if (recvmsg_timeout(fd2, &msg, sizeof(buf)) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + break; + } if (msg.msg_flags & MSG_CTRUNC) { - logmsgx("#%u control data was truncated, MSG_CTRUNC flag is on", - i); - goto next_error; + logmsgx("#%u control data was truncated, MSG_CTRUNC " + "flag is on", i); + goto next; } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("#%u msg_controllen %u < %lu (sizeof(struct cmsghdr))", - i, (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); - goto next_error; + logmsgx("#%u msg_controllen %u < %zu " + "(sizeof(struct cmsghdr))", i, + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); + goto next; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); - goto next_error; + goto next; } dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, @@ -921,142 +982,120 @@ t_cmsgcred_server(int fd1) if (cmptr->cmsg_level != SOL_SOCKET) { logmsgx("#%u cmsg_level %d != SOL_SOCKET", i, cmptr->cmsg_level); - goto next_error; + goto next; } if (cmptr->cmsg_type != SCM_CREDS) { logmsgx("#%u cmsg_type %d != SCM_CREDS", i, cmptr->cmsg_type); - goto next_error; + goto next; } if (cmptr->cmsg_len != CMSG_LEN(sizeof(struct cmsgcred))) { - logmsgx("#%u cmsg_len %u != %lu (CMSG_LEN(sizeof(struct cmsgcred))", - i, (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(sizeof(struct cmsgcred))); - goto next_error; + logmsgx("#%u cmsg_len %u != %zu " + "(CMSG_LEN(sizeof(struct cmsgcred))", i, + (u_int)cmptr->cmsg_len, + CMSG_LEN(sizeof(struct cmsgcred))); + goto next; } - cmcredptr = (const struct cmsgcred *)CMSG_DATA(cmptr); + cmcred = (struct cmsgcred *)CMSG_DATA(cmptr); - error2 = 0; - if (cmcredptr->cmcred_pid != client_pid) { + if (cmcred->cmcred_pid != client_pid) { logmsgx("#%u cmcred_pid %ld != %ld (PID of client)", - i, (long)cmcredptr->cmcred_pid, (long)client_pid); - error2 = 1; + i, (long)cmcred->cmcred_pid, (long)client_pid); + goto next; } - if (cmcredptr->cmcred_uid != my_uid) { - logmsgx("#%u cmcred_uid %lu != %lu (UID of current process)", - i, (u_long)cmcredptr->cmcred_uid, (u_long)my_uid); - error2 = 1; - } - if (cmcredptr->cmcred_euid != my_euid) { - logmsgx("#%u cmcred_euid %lu != %lu (EUID of current process)", - i, (u_long)cmcredptr->cmcred_euid, (u_long)my_euid); - error2 = 1; - } - if (cmcredptr->cmcred_gid != my_gid) { - logmsgx("#%u cmcred_gid %lu != %lu (GID of current process)", - i, (u_long)cmcredptr->cmcred_gid, (u_long)my_gid); - error2 = 1; + if (cmcred->cmcred_uid != my_uid) { + logmsgx("#%u cmcred_uid %lu != %lu (UID of current " + "process)", i, (u_long)cmcred->cmcred_uid, + (u_long)my_uid); + goto next; + } + if (cmcred->cmcred_euid != my_euid) { + logmsgx("#%u cmcred_euid %lu != %lu (EUID of current " + "process)", i, (u_long)cmcred->cmcred_euid, + (u_long)my_euid); + goto next; + } + if (cmcred->cmcred_gid != my_gid) { + logmsgx("#%u cmcred_gid %lu != %lu (GID of current " + "process)", i, (u_long)cmcred->cmcred_gid, + (u_long)my_gid); + goto next; } - if (cmcredptr->cmcred_ngroups == 0) { + if (cmcred->cmcred_ngroups == 0) { logmsgx("#%u cmcred_ngroups = 0, this is wrong", i); - error2 = 1; - } else { - if (cmcredptr->cmcred_ngroups > NGROUPS_MAX) { - logmsgx("#%u cmcred_ngroups %d > %u (NGROUPS_MAX)", - i, cmcredptr->cmcred_ngroups, NGROUPS_MAX); - error2 = 1; - } else if (cmcredptr->cmcred_ngroups < 0) { - logmsgx("#%u cmcred_ngroups %d < 0", - i, cmcredptr->cmcred_ngroups); - error2 = 1; - } else { - dbgmsg(("#%u cmcred_ngroups = %d", i, - cmcredptr->cmcred_ngroups)); - if (cmcredptr->cmcred_groups[0] != my_egid) { - logmsgx("#%u cmcred_groups[0] %lu != %lu (EGID of current process)", - i, (u_long)cmcredptr->cmcred_groups[0], (u_long)my_egid); - error2 = 1; - } - if (check_groups(cmcredptr->cmcred_groups + 1, cmcredptr->cmcred_ngroups - 1) < 0) { - logmsgx("#%u cmcred_groups has wrong GIDs", i); - error2 = 1; - } - } + goto next; } - - if (error2) - goto next_error; - - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("#%u control data has extra header", i); - goto next_error; + if (cmcred->cmcred_ngroups < 0) { + logmsgx("#%u cmcred_ngroups %d < 0", + i, cmcred->cmcred_ngroups); + goto next; + } + if (cmcred->cmcred_ngroups > NGROUPS_MAX) { + logmsgx("#%u cmcred_ngroups %d > %u (NGROUPS_MAX)", + i, cmcred->cmcred_ngroups, NGROUPS_MAX); + goto next; + } + + dbgmsg(("#%u cmcred_ngroups = %d", i, cmcred->cmcred_ngroups)); + if (cmcred->cmcred_groups[0] != my_egid) { + logmsgx("#%u cmcred_groups[0] %lu != %lu (EGID of " + "current process)", i, + (u_long)cmcred->cmcred_groups[0], (u_long)my_egid); + goto next; + } + if (check_groups(cmcred->cmcred_groups, + cmcred->cmcred_ngroups) < 0) { + logmsgx("#%u cmcred_groups has wrong GIDs", i); + goto next; + } + + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("#%u control data has extra header, " + "this is wrong", i); + goto next; } - continue; -next_error: - error = -1; +next: + rv = -1; } if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_cmsgcred(void) { - int error, fd; + int fd, rv; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) - _exit(1); + if (close_socket((char *)NULL, fd) < 0) + _exit(EXIT_FAILURE); t_cmsgcred_client(2); } - if ((error = t_cmsgcred_server(fd)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_cmsgcred_server(fd); if (wait_client() < 0) - goto failed; - - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } /* @@ -1067,20 +1106,23 @@ t_sockcred_client(int type) { struct msghdr msg; struct iovec iov[1]; - int fd; u_int i; + int fd, rv; assert(type == 0 || type == 1); - if ((fd = create_unbound_socket()) < 0) + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; if (type == 1) if (sync_recv(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -1094,19 +1136,15 @@ t_sockcred_client(int type) msg.msg_flags = 0; for (i = 0; i < 2; ++i) - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; - - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd) < 0) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -1119,232 +1157,222 @@ failed: static int t_sockcred_server(int type, int fd1, u_int n) { - char buf[IPC_MESSAGE_SIZE]; union { struct cmsghdr cm; - char control[CMSG_SPACE(SOCKCREDSIZE(NGROUPS_MAX)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(SOCKCREDSIZE(NGROUPS_MAX)) + + EXTRA_CMSG_SPACE]; } control_un; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; const struct sockcred *sockcred; - int error, error2, fd2, optval; u_int i; + int fd2, rv, optval; + char buf[IPC_MESSAGE_SIZE]; assert(n == 1 || n == 2); assert(type == 0 || type == 1); + rv = -2; + if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); if (type == 1) { optval = 1; - if (setsockopt(fd2, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { - logmsg("setsockopt(LOCAL_CREDS) for accepted socket"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + if (setsockopt(fd2, 0, LOCAL_CREDS, &optval, + sizeof(optval)) < 0) { + logmsg("setsockopt(LOCAL_CREDS) for accepted " + "socket"); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } if (sync_send(fd2) < 0) - goto failed; + goto done; } } else fd2 = fd1; - error = 0; + rv = 0; for (i = 0; i < n; ++i) { iov[0].iov_base = buf; - iov[0].iov_len = sizeof buf; + iov[0].iov_len = sizeof(buf); msg.msg_name = NULL; msg.msg_namelen = 0; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = sizeof control_un.control; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - if (recvmsg_timeout(fd2, &msg, sizeof buf) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + break; + } if (msg.msg_flags & MSG_CTRUNC) { - logmsgx("control data was truncated, MSG_CTRUNC flag is on"); - goto next_error; + logmsgx("control data was truncated, MSG_CTRUNC flag " + "is on"); + goto next; } + dbgmsg(("#%u msg_controllen = %u", i, + (u_int)msg.msg_controllen)); + if (i != 0 && sock_type == SOCK_STREAM) { if (msg.msg_controllen != 0) { - logmsgx("second message has control data, this is wrong for stream sockets"); - goto next_error; + logmsgx("second message has control data, " + "this is wrong for stream sockets"); + goto next; } - dbgmsg(("#%u msg_controllen = %u", i, - (u_int)msg.msg_controllen)); continue; } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("#%u msg_controllen %u < %lu (sizeof(struct cmsghdr))", - i, (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); - goto next_error; + logmsgx("#%u msg_controllen %u < %zu " + "(sizeof(struct cmsghdr))", i, + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); + goto next; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); - goto next_error; + goto next; } - dbgmsg(("#%u msg_controllen = %u, cmsg_len = %u", i, - (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); + dbgmsg(("#%u cmsg_len = %u", i, (u_int)cmptr->cmsg_len)); if (cmptr->cmsg_level != SOL_SOCKET) { logmsgx("#%u cmsg_level %d != SOL_SOCKET", i, cmptr->cmsg_level); - goto next_error; + goto next; } if (cmptr->cmsg_type != SCM_CREDS) { logmsgx("#%u cmsg_type %d != SCM_CREDS", i, cmptr->cmsg_type); - goto next_error; + goto next; } if (cmptr->cmsg_len < CMSG_LEN(SOCKCREDSIZE(1))) { - logmsgx("#%u cmsg_len %u != %lu (CMSG_LEN(SOCKCREDSIZE(1)))", - i, (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(SOCKCREDSIZE(1))); - goto next_error; + logmsgx("#%u cmsg_len %u != %zu " + "(CMSG_LEN(SOCKCREDSIZE(1)))", i, + (u_int)cmptr->cmsg_len, CMSG_LEN(SOCKCREDSIZE(1))); + goto next; } - sockcred = (const struct sockcred *)CMSG_DATA(cmptr); + sockcred = (struct sockcred *)CMSG_DATA(cmptr); - error2 = 0; if (sockcred->sc_uid != my_uid) { - logmsgx("#%u sc_uid %lu != %lu (UID of current process)", - i, (u_long)sockcred->sc_uid, (u_long)my_uid); - error2 = 1; + logmsgx("#%u sc_uid %lu != %lu (UID of current " + "process)", i, (u_long)sockcred->sc_uid, + (u_long)my_uid); + goto next; } if (sockcred->sc_euid != my_euid) { - logmsgx("#%u sc_euid %lu != %lu (EUID of current process)", - i, (u_long)sockcred->sc_euid, (u_long)my_euid); - error2 = 1; + logmsgx("#%u sc_euid %lu != %lu (EUID of current " + "process)", i, (u_long)sockcred->sc_euid, + (u_long)my_euid); + goto next; } if (sockcred->sc_gid != my_gid) { - logmsgx("#%u sc_gid %lu != %lu (GID of current process)", - i, (u_long)sockcred->sc_gid, (u_long)my_gid); - error2 = 1; + logmsgx("#%u sc_gid %lu != %lu (GID of current " + "process)", i, (u_long)sockcred->sc_gid, + (u_long)my_gid); + goto next; } if (sockcred->sc_egid != my_egid) { - logmsgx("#%u sc_egid %lu != %lu (EGID of current process)", - i, (u_long)sockcred->sc_gid, (u_long)my_egid); - error2 = 1; + logmsgx("#%u sc_egid %lu != %lu (EGID of current " + "process)", i, (u_long)sockcred->sc_gid, + (u_long)my_egid); + goto next; + } + if (sockcred->sc_ngroups == 0) { + logmsgx("#%u sc_ngroups %d = 0, this is wrong", + i, sockcred->sc_ngroups); + goto next; + } + if (sockcred->sc_ngroups < 0) { + logmsgx("#%u sc_ngroups %d < 0", + i, sockcred->sc_ngroups); + goto next; } if (sockcred->sc_ngroups > NGROUPS_MAX) { logmsgx("#%u sc_ngroups %d > %u (NGROUPS_MAX)", i, sockcred->sc_ngroups, NGROUPS_MAX); - error2 = 1; - } else if (sockcred->sc_ngroups < 0) { - logmsgx("#%u sc_ngroups %d < 0", - i, sockcred->sc_ngroups); - error2 = 1; - } else { - dbgmsg(("#%u sc_ngroups = %d", i, sockcred->sc_ngroups)); - if (check_groups(sockcred->sc_groups, sockcred->sc_ngroups) < 0) { - logmsgx("#%u sc_groups has wrong GIDs", i); - error2 = 1; - } + goto next; } - if (error2) - goto next_error; - - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("#%u control data has extra header, this is wrong", - i); - goto next_error; + dbgmsg(("#%u sc_ngroups = %d", i, sockcred->sc_ngroups)); + if (check_groups(sockcred->sc_groups, + sockcred->sc_ngroups) < 0) { + logmsgx("#%u sc_groups has wrong GIDs", i); + goto next; } + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("#%u control data has extra header, " + "this is wrong", i); + goto next; + } continue; -next_error: - error = -1; +next: + rv = -1; } - -done_close: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: +done: if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_sockcred(int type) { - int error, fd, optval; + int fd, rv, optval; assert(type == 0 || type == 1); - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; if (type == 0) { optval = 1; - if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { + if (setsockopt(fd, 0, LOCAL_CREDS, &optval, + sizeof(optval)) < 0) { logmsg("setsockopt(LOCAL_CREDS) for %s socket", - sock_type == SOCK_STREAM ? "stream listening" : "datagram"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + sock_type_str); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } } - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) - _exit(1); + if (close_socket((char *)NULL, fd) < 0) + _exit(EXIT_FAILURE); t_sockcred_client(type); } - if ((error = t_sockcred_server(type, fd, 2)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_sockcred_server(type, fd, 2); if (wait_client() < 0) - goto failed; - -done_close: - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } static int @@ -1368,59 +1396,39 @@ t_sockcred_dgram(void) static int t_cmsgcred_sockcred(void) { - int error, fd, optval; + int fd, rv, optval; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; optval = 1; - if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof optval) < 0) { - logmsg("setsockopt(LOCAL_CREDS) for %s socket", - sock_type == SOCK_STREAM ? "stream listening" : "datagram"); - if (errno == ENOPROTOOPT) { - error = -1; - goto done_close; - } - goto failed; + if (setsockopt(fd, 0, LOCAL_CREDS, &optval, sizeof(optval)) < 0) { + logmsg("setsockopt(LOCAL_CREDS) for %s socket", sock_type_str); + if (errno == ENOPROTOOPT) + rv = -1; + goto done; } - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) - _exit(1); + if (close_socket((char *)NULL, fd) < 0) + _exit(EXIT_FAILURE); t_cmsgcred_client(1); } - if ((error = t_sockcred_server(0, fd, 1)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_sockcred_server(0, fd, 1); if (wait_client() < 0) - goto failed; - -done_close: - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); - } - return (error); - -failed: + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } /* @@ -1437,13 +1445,16 @@ t_timestamp_client(void) struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; - int fd; + int fd, rv; - if ((fd = create_unbound_socket()) < 0) + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; if (connect_server(fd) < 0) - goto failed_close; + goto done; iov[0].iov_base = ipc_message; iov[0].iov_len = IPC_MESSAGE_SIZE; @@ -1454,7 +1465,7 @@ t_timestamp_client(void) msg.msg_iovlen = 1; msg.msg_control = control_un.control; msg.msg_controllen = no_control_data ? - sizeof(struct cmsghdr) :sizeof control_un.control; + sizeof(struct cmsghdr) : sizeof(control_un.control); msg.msg_flags = 0; cmptr = CMSG_FIRSTHDR(&msg); @@ -1466,19 +1477,15 @@ t_timestamp_client(void) dbgmsg(("msg_controllen = %u, cmsg_len = %u", (u_int)msg.msg_controllen, (u_int)cmptr->cmsg_len)); - if (sendmsg_timeout(fd, &msg, IPC_MESSAGE_SIZE) < 0) - goto failed_close; - - if (close_socket((const char *)NULL, fd) < 0) - goto failed; - - _exit(0); - -failed_close: - (void)close_socket((const char *)NULL, fd); + if (send_message(fd, &msg, IPC_MESSAGE_SIZE) < 0) + goto done; + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd) < 0) + rv = EXIT_FAILURE; failed: - _exit(1); + _exit(rv); } /* @@ -1490,36 +1497,40 @@ t_timestamp_server(int fd1) { union { struct cmsghdr cm; - char control[CMSG_SPACE(sizeof(struct timeval)) + EXTRA_CMSG_SPACE]; + char control[CMSG_SPACE(sizeof(struct timeval)) + + EXTRA_CMSG_SPACE]; } control_un; - char buf[IPC_MESSAGE_SIZE]; - int error, fd2; struct msghdr msg; struct iovec iov[1]; struct cmsghdr *cmptr; const struct timeval *timeval; + int fd2, rv; + char buf[IPC_MESSAGE_SIZE]; if (sock_type == SOCK_STREAM) { - if ((fd2 = accept_timeout(fd1)) < 0) + fd2 = accept_connection(fd1); + if (fd2 < 0) return (-2); } else fd2 = fd1; iov[0].iov_base = buf; - iov[0].iov_len = sizeof buf; + iov[0].iov_len = sizeof(buf); msg.msg_name = NULL; msg.msg_namelen = 0; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_control = control_un.control; - msg.msg_controllen = sizeof control_un.control;; + msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; - if (recvmsg_timeout(fd2, &msg, sizeof buf) < 0) - goto failed; + if (recv_message(fd2, &msg, sizeof(buf)) < 0) { + rv = -2; + goto done; + } - error = -1; + rv = -1; if (msg.msg_flags & MSG_CTRUNC) { logmsgx("control data was truncated, MSG_CTRUNC flag is on"); @@ -1527,12 +1538,13 @@ t_timestamp_server(int fd1) } if (msg.msg_controllen < sizeof(struct cmsghdr)) { - logmsgx("msg_controllen %u < %lu (sizeof(struct cmsghdr))", - (u_int)msg.msg_controllen, (u_long)sizeof(struct cmsghdr)); + logmsgx("msg_controllen %u < %zu (sizeof(struct cmsghdr))", + (u_int)msg.msg_controllen, sizeof(struct cmsghdr)); goto done; } - if ((cmptr = CMSG_FIRSTHDR(&msg)) == NULL) { + cmptr = CMSG_FIRSTHDR(&msg); + if (cmptr == NULL) { logmsgx("CMSG_FIRSTHDR is NULL"); goto done; } @@ -1551,80 +1563,202 @@ t_timestamp_server(int fd1) } if (cmptr->cmsg_len != CMSG_LEN(sizeof(struct timeval))) { - logmsgx("cmsg_len %u != %lu (CMSG_LEN(sizeof(struct timeval))", - (u_int)cmptr->cmsg_len, (u_long)CMSG_LEN(sizeof(struct timeval))); + logmsgx("cmsg_len %u != %zu (CMSG_LEN(sizeof(struct timeval))", + (u_int)cmptr->cmsg_len, CMSG_LEN(sizeof(struct timeval))); goto done; } - timeval = (const struct timeval *)CMSG_DATA(cmptr); + timeval = (struct timeval *)CMSG_DATA(cmptr); - dbgmsg(("timeval tv_sec %jd, tv_usec %jd", + dbgmsg(("timeval tv_sec %"PRIdMAX", tv_usec %"PRIdMAX, (intmax_t)timeval->tv_sec, (intmax_t)timeval->tv_usec)); - if ((cmptr = CMSG_NXTHDR(&msg, cmptr)) != NULL) { - logmsgx("control data has extra header"); + if (CMSG_NXTHDR(&msg, cmptr) != NULL) { + logmsgx("control data has extra header, this is wrong"); goto done; } - error = 0; - + rv = 0; done: if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) { - logmsg("close"); - return (-2); - } - return (error); - -failed: - if (sock_type == SOCK_STREAM) - if (close(fd2) < 0) - logmsg("close"); - return (-2); + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); } static int t_timestamp(void) { - int error, fd; + int fd, rv; - if ((fd = create_server_socket()) < 0) + fd = create_server_socket(); + if (fd < 0) return (-2); - if (sock_type == SOCK_STREAM) - if (listen(fd, LISTENQ) < 0) { - logmsg("listen"); - goto failed; - } + rv = -2; - if ((client_pid = fork()) == (pid_t)-1) { - logmsg("fork"); - goto failed; - } + if (fork_client() < 0) + goto done; if (client_pid == 0) { - myname = "CLIENT"; - if (close_socket((const char *)NULL, fd) < 0) - _exit(1); + if (close_socket((char *)NULL, fd) < 0) + _exit(EXIT_FAILURE); t_timestamp_client(); } - if ((error = t_timestamp_server(fd)) == -2) { - (void)wait_client(); - goto failed; - } + rv = t_timestamp_server(fd); if (wait_client() < 0) + rv = -2; +done: + if (close_socket(serv_sock_path, fd) < 0) + rv = -2; + return (rv); +} + +/* + * Verify that xucred structure has correct credentials. + */ +static int +check_xucred(const struct xucred *xucred, socklen_t len) +{ + if (len != sizeof(*xucred)) { + logmsgx("option value size %zu != %zu (sizeof(struct xucred))", + (size_t)len, sizeof(*xucred)); + return (-1); + } + if (xucred->cr_version != XUCRED_VERSION) { + logmsgx("cr_version %u != %d (XUCRED_VERSION)", + xucred->cr_version, XUCRED_VERSION); + return (-1); + } + if (xucred->cr_uid != my_euid) { + logmsgx("cr_uid %lu != %lu (EUID of current process)", + (u_long)xucred->cr_uid, (u_long)my_euid); + return (-1); + } + if (xucred->cr_ngroups == 0) { + logmsgx("cr_ngroups = 0, this is wrong"); + return (-1); + } + if (xucred->cr_ngroups < 0) { + logmsgx("cr_ngroups < 0, this is wrong"); + return (-1); + } + if (xucred->cr_ngroups > NGROUPS_MAX) { + logmsgx("cr_ngroups %hu > %u (NGROUPS_MAX)", + xucred->cr_ngroups, NGROUPS_MAX); + return (-1); + } + if (xucred->cr_groups[0] != my_egid) { + logmsgx("cr_groups[0] %lu != %lu (EGID of current process)", + (u_long)xucred->cr_groups[0], (u_long)my_egid); + return (-1); + } + if (check_groups(xucred->cr_groups, xucred->cr_ngroups) < 0) { + logmsgx("cr_groups has wrong GIDs"); + return (-1); + } + return (0); +} + +/* + * Connect to server and set LOCAL_PEERCRED socket option for connected + * socket. Verify that credentials of the peer are correct. + */ +static void +t_peercred_client(void) +{ + struct xucred xucred; + socklen_t len; + int fd, rv; + + rv = EXIT_FAILURE; + + fd = create_client_socket(); + if (fd < 0) goto failed; - if (close_socket(serv_sock_path, fd) < 0) { - logmsgx("close_socket failed"); - return (-2); + if (connect_server(fd) < 0) + goto done; + + len = sizeof(xucred); + if (getsockopt(fd, 0, LOCAL_PEERCRED, &xucred, &len) < 0) { + logmsg("getsockopt(LOCAL_PEERCRED)"); + goto done; } - return (error); + if (check_xucred(&xucred, len) < 0) + goto done; + + rv = EXIT_SUCCESS; +done: + if (close_socket((char *)NULL, fd) < 0) + rv = EXIT_FAILURE; failed: + _exit(rv); +} + +/* + * Accept connection from client and set LOCAL_PEERCRED socket option for + * connected socket. Verify that credentials of the peer are correct. + */ +static int +t_peercred_server(int fd1) +{ + struct xucred xucred; + socklen_t len; + int fd2, rv; + + fd2 = accept_connection(fd1); + if (fd2 < 0) + return (-2); + + len = sizeof(xucred); + if (getsockopt(fd2, 0, LOCAL_PEERCRED, &xucred, &len) < 0) { + logmsg("getsockopt(LOCAL_PEERCRED)"); + rv = -2; + goto done; + } + + if (check_xucred(&xucred, len) < 0) { + rv = -1; + goto done; + } + + rv = 0; +done: + if (close_socket((char *)NULL, fd2) < 0) + rv = -2; + return (rv); +} + +static int +t_peercred(void) +{ + int fd, rv; + + fd = create_server_socket(); + if (fd < 0) + return (-2); + + rv = -2; + + if (fork_client() < 0) + goto done; + + if (client_pid == 0) { + if (close_socket((char *)NULL, fd) < 0) + _exit(EXIT_FAILURE); + t_peercred_client(); + } + + rv = t_peercred_server(fd); + + if (wait_client() < 0) + rv = -2; +done: if (close_socket(serv_sock_path, fd) < 0) - logmsgx("close_socket failed"); - return (-2); + rv = -2; + return (rv); } diff -ruNp unix_cmsg.orig/unix_cmsg.t unix_cmsg/unix_cmsg.t --- unix_cmsg.orig/unix_cmsg.t 2006-05-29 21:40:55.000000000 +0300 +++ unix_cmsg/unix_cmsg.t 2012-03-19 13:42:52.000000000 +0200 @@ -23,14 +23,15 @@ run() done } -echo "1..15" +echo "1..16" for desc in \ "Sending, receiving cmsgcred" \ - "Receiving sockcred (listening socket has LOCAL_CREDS) # TODO" \ - "Receiving sockcred (accepted socket has LOCAL_CREDS) # TODO" \ - "Sending cmsgcred, receiving sockcred # TODO" \ - "Sending, receiving timestamp" + "Receiving sockcred (listening socket has LOCAL_CREDS)" \ + "Receiving sockcred (accepted socket has LOCAL_CREDS)" \ + "Sending cmsgcred, receiving sockcred" \ + "Sending, receiving timestamp" \ + "Check LOCAL_PEERCRED socket option" do n=`expr ${n} + 1` run ${n} stream "" ${n} "STREAM ${desc}" @@ -48,10 +49,10 @@ do run ${n} dgram "" ${i} "DGRAM ${desc}" done -run 10 stream -z 1 "STREAM Sending, receiving cmsgcred (no control data)" -run 11 stream -z 4 "STREAM Sending cmsgcred, receiving sockcred (no control data) # TODO" -run 12 stream -z 5 "STREAM Sending, receiving timestamp (no control data)" +run 11 stream -z 1 "STREAM Sending, receiving cmsgcred (no control data)" +run 12 stream -z 4 "STREAM Sending cmsgcred, receiving sockcred (no control data) # TODO" +run 13 stream -z 5 "STREAM Sending, receiving timestamp (no control data)" -run 13 dgram -z 1 "DGRAM Sending, receiving cmsgcred (no control data)" -run 14 dgram -z 3 "DGRAM Sending cmsgcred, receiving sockcred (no control data) # TODO" -run 15 dgram -z 4 "DGRAM Sending, receiving timestamp (no control data)" +run 14 dgram -z 1 "DGRAM Sending, receiving cmsgcred (no control data)" +run 15 dgram -z 3 "DGRAM Sending cmsgcred, receiving sockcred (no control data) # TODO" +run 16 dgram -z 4 "DGRAM Sending, receiving timestamp (no control data)" From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 16:11:17 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 85561106566C for ; Mon, 19 Mar 2012 16:11:17 +0000 (UTC) (envelope-from freebsd@mikej.com) Received: from remote.confluenttech.com (remote.confluenttech.com [69.55.228.170]) by mx1.freebsd.org (Postfix) with ESMTP id 613868FC14 for ; Mon, 19 Mar 2012 16:11:16 +0000 (UTC) Received: from firewall.mikej.com (99-89-65-18.uvs.lsvlky.sbcglobal.net [99.89.65.18]) by remote.confluenttech.com (8.14.3/8.14.3) with ESMTP id q2JGBFSn016177 for ; Mon, 19 Mar 2012 09:11:16 -0700 (PDT) (envelope-from freebsd@mikej.com) Received: from firewall.mikej.com (localhost [127.0.0.1]) by firewall.mikej.com (8.14.5/8.13.3) with ESMTP id q2JGBAZf082659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Mar 2012 12:11:15 -0400 (EDT) (envelope-from freebsd@mikej.com) Received: (from www@localhost) by firewall.mikej.com (8.14.5/8.13.4/Submit) id q2JGBAS9082657; Mon, 19 Mar 2012 12:11:10 -0400 (EDT) (envelope-from freebsd@mikej.com) X-Authentication-Warning: firewall.mikej.com: www set sender to freebsd@mikej.com using -f To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 19 Mar 2012 12:11:10 -0400 From: jammin2night Mail-Reply-To: Message-ID: <51f939ac5fb636ae90ba1b0fd628e40b@mail.mikej.com> X-Sender: freebsd@mikej.com User-Agent: Roundcube Webmail/0.6-beta Subject: Cloning VLAN interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@mikej.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 16:11:17 -0000 FreeBSD charon 9.0-STABLE FreeBSD 9.0-STABLE #14 r233107: Sun Mar 18 05:26:58 EDT 2012 root@charon:/usr/obj/usr/src/sys/CHARON amd64 Hello: I have a machine that has a 802.1q trunk attached which works fine. I can create VLAN interfaces, apply an IP address to them and all is good. I have VirtualBox running on this machine and need to present an interface to a VM that does not support trunking natively. I've googled and searched the archive trying to figure out how to create an interface that VirtualBox will use where the 802.1Q tags are removed but have not had any success. I attempted to create a netgraph interface like: #!/bin/sh ngctl shutdown re0: ngctl mkpeer re0: vlan lower downstream ngctl name re0:lower vlan ngctl connect re0: vlan: upper upstream ngctl mkpeer vlan: eiface vlan10 ether ngctl msg vlan: addfilter '{ vlan=10 hook="vlan10" }' but this nuked my VLAN10 interface. Using tcpdump I saw no traffic on interface VLAN10 or interface ngeth0. I probably going about this all wrong or just don't get the netgraph hooks. If there is an example as to how to this this I just missed it. Any pointers on how to accomplish this? Thanks. From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 16:58:31 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 A595A106564A for ; Mon, 19 Mar 2012 16:58:31 +0000 (UTC) (envelope-from rozhuk.im@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 26B838FC08 for ; Mon, 19 Mar 2012 16:58:30 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so6239507bkc.13 for ; Mon, 19 Mar 2012 09:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=aDcsLzeZByWhsZG7WAZeBVWGj5goRC8p+orcu9qPpo8=; b=xnlCiB+5xzhLq8vK3u7ECKRqKANH0YkcVq0BMwvPOLoi4RsZbPYhgmMstgBw5NgGn7 at0KKFza7gqwlXcopj5+111VQ+4KCqwyGU4tu0BBppqj+Mj/zEr57P0Zh1BrLdGRXudl HEuYv57O7Q2+sls1fdw1XBKVB3XDzyVXxAl1mU7bPgP0OxMdsd53B8Ngmaf7DA75gINW JUaZzyWn7+sSUzpeo5Gn2+p6FfvhsPE3LTUBU1QMtdzJZbALjewmWkLpRzTfFxYs36oA d/5JbwZwFmQpNL9WW0d6/tNOHcy5MOMc/au9306hLdKDuEObO/Znp/hJlhJrq/WBl4w7 FAgQ== Received: by 10.204.132.79 with SMTP id a15mr4762798bkt.86.1332176310091; Mon, 19 Mar 2012 09:58:30 -0700 (PDT) Received: from rimwks1w7x64 ([164.215.85.206]) by mx.google.com with ESMTPS id u14sm26932140bkp.2.2012.03.19.09.58.27 (version=SSLv3 cipher=OTHER); Mon, 19 Mar 2012 09:58:28 -0700 (PDT) From: rozhuk.im@gmail.com To: , References: <51f939ac5fb636ae90ba1b0fd628e40b@mail.mikej.com> In-Reply-To: <51f939ac5fb636ae90ba1b0fd628e40b@mail.mikej.com> Date: Tue, 20 Mar 2012 01:58:25 +0900 Message-ID: <4f6765b4.0e70cc0a.351f.3bfb@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: ru Thread-Index: Ac0F6vVTi95tlm/6Rj+KCMGxEOvODQABdJQg Cc: Subject: RE: Cloning VLAN interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 16:58:31 -0000 #!/bin/sh ngctl shutdown re0:lower ngctl shutdown re0:upper ngctl mkpeer re0: hub lower lower ngctl name re0:lower re0-hub ngctl connect re0: re0-hub: upper upper ngctl mkpeer re0-hub: vlan downstream downstream ngctl name re0-hub: downstream re0-vlan ngctl mkpeer re0-vlan: eiface vlan10 ether ngctl msg re0-vlan: addfilter '{ vlan=10 hook="vlan10" }' > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of jammin2night > Sent: Tuesday, March 20, 2012 1:11 AM > To: freebsd-net@freebsd.org > Subject: Cloning VLAN interfaces > > FreeBSD charon 9.0-STABLE FreeBSD 9.0-STABLE #14 r233107: Sun Mar 18 > 05:26:58 EDT 2012 root@charon:/usr/obj/usr/src/sys/CHARON amd64 > > Hello: > > I have a machine that has a 802.1q trunk attached which works fine. I > can create VLAN interfaces, apply an IP address to them and all is > good. > > I have VirtualBox running on this machine and need to present an > interface to a VM that does not support trunking natively. I've > googled and searched the archive trying to figure out how to create an > interface that VirtualBox will use where the 802.1Q tags are removed > but have not had any success. > > I attempted to create a netgraph interface like: > > #!/bin/sh > > ngctl shutdown re0: > ngctl mkpeer re0: vlan lower downstream > ngctl name re0:lower vlan > ngctl connect re0: vlan: upper upstream > ngctl mkpeer vlan: eiface vlan10 ether > ngctl msg vlan: addfilter '{ vlan=10 hook="vlan10" }' > > but this nuked my VLAN10 interface. Using tcpdump I saw no traffic on > interface VLAN10 or interface ngeth0. I probably going about this all > wrong or just don't get the netgraph hooks. > > If there is an example as to how to this this I just missed it. > > Any pointers on how to accomplish this? > > Thanks. > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 17:12:35 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 04C2C106566C for ; Mon, 19 Mar 2012 17:12:35 +0000 (UTC) (envelope-from freebsd@mikej.com) Received: from remote.confluenttech.com (remote.confluenttech.com [69.55.228.170]) by mx1.freebsd.org (Postfix) with ESMTP id D5EE98FC0A for ; Mon, 19 Mar 2012 17:12:33 +0000 (UTC) Received: from firewall.mikej.com (99-89-65-18.uvs.lsvlky.sbcglobal.net [99.89.65.18]) by remote.confluenttech.com (8.14.3/8.14.3) with ESMTP id q2JHCWdV064756 for ; Mon, 19 Mar 2012 10:12:33 -0700 (PDT) (envelope-from freebsd@mikej.com) Received: from firewall.mikej.com (localhost [127.0.0.1]) by firewall.mikej.com (8.14.5/8.13.3) with ESMTP id q2JHCQBr087026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Mar 2012 13:12:31 -0400 (EDT) (envelope-from freebsd@mikej.com) Received: (from www@localhost) by firewall.mikej.com (8.14.5/8.13.4/Submit) id q2JHCQ4G087024; Mon, 19 Mar 2012 13:12:26 -0400 (EDT) (envelope-from freebsd@mikej.com) X-Authentication-Warning: firewall.mikej.com: www set sender to freebsd@mikej.com using -f To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 19 Mar 2012 13:12:25 -0400 From: jammin2night Mail-Reply-To: In-Reply-To: <4f6765b4.0e70cc0a.351f.3bfb@mx.google.com> References: <51f939ac5fb636ae90ba1b0fd628e40b@mail.mikej.com> <4f6765b4.0e70cc0a.351f.3bfb@mx.google.com> Message-ID: <2ef74c561a597ebd6508625698a9563f@mail.mikej.com> X-Sender: freebsd@mikej.com User-Agent: Roundcube Webmail/0.6-beta Subject: RE: Cloning VLAN interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@mikej.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:12:35 -0000 Thanks for you reply! All goes well until: (root@charon) ~# ngctl name re0-hub: downstream re0-vlan ngctl: usage: name (root@charon) ~# (root@charon) ~# ngctl list There are 6 total nodes: Name: Type: vlan ID: 0000001c Num hooks: 1 Name: em0 Type: ether ID: 00000002 Num hooks: 0 Name: re0 Type: ether ID: 00000001 Num hooks: 2 Name: vlan10 Type: ether ID: 00000003 Num hooks: 0 Name: ngctl4248 Type: socket ID: 00000027 Num hooks: 0 Name: re0-hub Type: hub ID: 00000017 Num hooks: 3 (root@charon) ~# On 19.03.2012 12:58, rozhuk.im@gmail.com wrote: > #!/bin/sh > > ngctl shutdown re0:lower > ngctl shutdown re0:upper > > ngctl mkpeer re0: hub lower lower > ngctl name re0:lower re0-hub > ngctl connect re0: re0-hub: upper upper > > ngctl mkpeer re0-hub: vlan downstream downstream > ngctl name re0-hub: downstream re0-vlan > ngctl mkpeer re0-vlan: eiface vlan10 ether > ngctl msg re0-vlan: addfilter '{ vlan=10 hook="vlan10" }' > > >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of jammin2night >> Sent: Tuesday, March 20, 2012 1:11 AM >> To: freebsd-net@freebsd.org >> Subject: Cloning VLAN interfaces >> >> FreeBSD charon 9.0-STABLE FreeBSD 9.0-STABLE #14 r233107: Sun Mar 18 >> 05:26:58 EDT 2012 root@charon:/usr/obj/usr/src/sys/CHARON amd64 >> >> Hello: >> >> I have a machine that has a 802.1q trunk attached which works fine. >> I >> can create VLAN interfaces, apply an IP address to them and all is >> good. >> >> I have VirtualBox running on this machine and need to present an >> interface to a VM that does not support trunking natively. I've >> googled and searched the archive trying to figure out how to create >> an >> interface that VirtualBox will use where the 802.1Q tags are removed >> but have not had any success. >> >> I attempted to create a netgraph interface like: >> >> #!/bin/sh >> >> ngctl shutdown re0: >> ngctl mkpeer re0: vlan lower downstream >> ngctl name re0:lower vlan >> ngctl connect re0: vlan: upper upstream >> ngctl mkpeer vlan: eiface vlan10 ether >> ngctl msg vlan: addfilter '{ vlan=10 hook="vlan10" }' >> >> but this nuked my VLAN10 interface. Using tcpdump I saw no traffic >> on >> interface VLAN10 or interface ngeth0. I probably going about this >> all >> wrong or just don't get the netgraph hooks. >> >> If there is an example as to how to this this I just missed it. >> >> Any pointers on how to accomplish this? >> >> Thanks. >> >> >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to >> "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 18:19:20 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 CD1EA106566C for ; Mon, 19 Mar 2012 18:19:20 +0000 (UTC) (envelope-from rozhuk.im@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 4CC9F8FC15 for ; Mon, 19 Mar 2012 18:19:19 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so6319869bkc.13 for ; Mon, 19 Mar 2012 11:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=USiorudL7mJQWKOo1SubF9zveqPIa/gvu2LW7hZ7MkE=; b=b6WZWkQKXJ52ucJZ65D8hUSG1tms4Yq7QgIeMSnJhxUR8oawVR+bbBSz2zdtgZSKX6 v9F/GaBpWA/4cDZ/H/Oiyrfcb8pmdR3AqVmYuk8LOippTcBThUpuUEv9z3MIE2dn+zjL mfw1ysHz/pMFyA23/yyXZZ7xHg5XBr+Llm2RBM73EoYkyMvtvwGptdVgXHyvfKcoLFEr M87NYi95Ms6LfNCBrK1+SZyWxngqhIt/d7TFA31LCvbOwPN/TxmI19JUas2DlJj3wzku 9OtAJv1xePVSm5ffBOtSfZ6G/Uz1yn7ENM5rNzNCmNsmEVkBE6/6KQHtOZF0tZbzcl3H UGVQ== Received: by 10.204.154.209 with SMTP id p17mr5263068bkw.6.1332181159086; Mon, 19 Mar 2012 11:19:19 -0700 (PDT) Received: from rimwks1w7x64 ([164.215.85.206]) by mx.google.com with ESMTPS id u5sm27310495bka.5.2012.03.19.11.19.16 (version=SSLv3 cipher=OTHER); Mon, 19 Mar 2012 11:19:18 -0700 (PDT) From: rozhuk.im@gmail.com To: , References: <51f939ac5fb636ae90ba1b0fd628e40b@mail.mikej.com> <4f6765b4.0e70cc0a.351f.3bfb@mx.google.com> <2ef74c561a597ebd6508625698a9563f@mail.mikej.com> In-Reply-To: <2ef74c561a597ebd6508625698a9563f@mail.mikej.com> Date: Tue, 20 Mar 2012 03:19:14 +0900 Message-ID: <4f6778a6.0512cc0a.2ef6.545f@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: ru Thread-Index: Ac0F85w8LInQTGVBQBKs2H7rOS1XIgACRtPg Cc: Subject: RE: Cloning VLAN interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:19:20 -0000 Remove space: name re0-hub:downstream re0-vlan > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of jammin2night > Sent: Tuesday, March 20, 2012 2:12 AM > To: freebsd-net@freebsd.org > Subject: RE: Cloning VLAN interfaces > > Thanks for you reply! All goes well until: > > (root@charon) ~# ngctl name re0-hub: downstream re0-vlan > ngctl: usage: name > (root@charon) ~# > > > (root@charon) ~# ngctl list > There are 6 total nodes: > Name: Type: vlan ID: 0000001c Num > hooks: > 1 > Name: em0 Type: ether ID: 00000002 Num > hooks: > 0 > Name: re0 Type: ether ID: 00000001 Num > hooks: > 2 > Name: vlan10 Type: ether ID: 00000003 Num > hooks: > 0 > Name: ngctl4248 Type: socket ID: 00000027 Num > hooks: > 0 > Name: re0-hub Type: hub ID: 00000017 Num > hooks: > 3 > (root@charon) ~# > > > > On 19.03.2012 12:58, rozhuk.im@gmail.com wrote: > > #!/bin/sh > > > > ngctl shutdown re0:lower > > ngctl shutdown re0:upper > > > > ngctl mkpeer re0: hub lower lower > > ngctl name re0:lower re0-hub > > ngctl connect re0: re0-hub: upper upper > > > > ngctl mkpeer re0-hub: vlan downstream downstream ngctl name re0-hub: > > downstream re0-vlan ngctl mkpeer re0-vlan: eiface vlan10 ether ngctl > > msg re0-vlan: addfilter '{ vlan=10 hook="vlan10" }' > > > > > >> -----Original Message----- > >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > >> net@freebsd.org] On Behalf Of jammin2night > >> Sent: Tuesday, March 20, 2012 1:11 AM > >> To: freebsd-net@freebsd.org > >> Subject: Cloning VLAN interfaces > >> > >> FreeBSD charon 9.0-STABLE FreeBSD 9.0-STABLE #14 r233107: Sun Mar 18 > >> 05:26:58 EDT 2012 root@charon:/usr/obj/usr/src/sys/CHARON amd64 > >> > >> Hello: > >> > >> I have a machine that has a 802.1q trunk attached which works fine. > >> I > >> can create VLAN interfaces, apply an IP address to them and all is > >> good. > >> > >> I have VirtualBox running on this machine and need to present an > >> interface to a VM that does not support trunking natively. I've > >> googled and searched the archive trying to figure out how to create > >> an interface that VirtualBox will use where the 802.1Q tags are > >> removed but have not had any success. > >> > >> I attempted to create a netgraph interface like: > >> > >> #!/bin/sh > >> > >> ngctl shutdown re0: > >> ngctl mkpeer re0: vlan lower downstream ngctl name re0:lower vlan > >> ngctl connect re0: vlan: upper upstream ngctl mkpeer vlan: eiface > >> vlan10 ether ngctl msg vlan: addfilter '{ vlan=10 hook="vlan10" }' > >> > >> but this nuked my VLAN10 interface. Using tcpdump I saw no traffic > >> on interface VLAN10 or interface ngeth0. I probably going about this > >> all wrong or just don't get the netgraph hooks. > >> > >> If there is an example as to how to this this I just missed it. > >> > >> Any pointers on how to accomplish this? > >> > >> Thanks. > >> > >> > >> > >> > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to > >> "freebsd-net-unsubscribe@freebsd.org" > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to > > "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 19:34:12 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 E84AC106564A for ; Mon, 19 Mar 2012 19:34:12 +0000 (UTC) (envelope-from sol289@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 BB4A78FC12 for ; Mon, 19 Mar 2012 19:34:12 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so1440592pbc.13 for ; Mon, 19 Mar 2012 12:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=s/ajVh6HPvDYLMinZ0SphJLoXukbnhlai+rMbfFQCW0=; b=esnJj9mF6z3qUa1huq7YScrHChYBflg01cAy1BtizquH9OVRKV4ncMisSni8+HReXT bwCuHYcJgZvWpPJ+Q0Ix6/cp/3z8viq2Rlm1ukQ5i2W7ePvUvDPb6P0vk2FSlKviX86f Zqz46BfLN/MGtHQlmnMlQ4qmr0lnfWMEbik5k2qdUtAbZ1nha1wJ7gEgfYkNe2aG0Akk Lv82woX5L2QoVi5ZtvIvmUQxkpDps/hmwQUz0xvirwFcj9yrHv/gPTaVtNrtcee1wIKb s4eFfOcOfizDpBpldvpGCwShAR8ExYITYju4H8E1vYQuaRGx0UIjXeRPZUcV/XMTdegU UOPQ== Received: by 10.68.134.168 with SMTP id pl8mr28438382pbb.16.1332185645930; Mon, 19 Mar 2012 12:34:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.74.137 with HTTP; Mon, 19 Mar 2012 12:33:45 -0700 (PDT) In-Reply-To: References: <4F630D23.2070509@netfence.it> From: Alexander Lunev Date: Mon, 19 Mar 2012 23:33:45 +0400 Message-ID: To: Freddie Cash Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org Subject: Re: LAGG and CARP troubles X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 19:34:13 -0000 On Fri, Mar 16, 2012 at 7:42 PM, Freddie Cash wrote: > If you're adventurous, could you upgrade a test box to 10-CURRENT and > try the new CARP code? Ok, i've set up a distributed network: 10-C1 === internet === 8.2-R === internet === 10-C2 10-C1 and 10-C2 is 10-CURRENT on vmware running on different machines and located in different networks, they are openvpn clients, which connects to real server 8.2-R through internet, and none of them can see other on data link level. 10-C1 differs from 10-C2 only in MAC addresses and in em0 configuration, which is interface for connecting to internet. There are no firewalls on 10-C, just the network interface, openvpn, bridge and carp. ifconfig for 10-C (skipping em0 lo0 plip0): # ifconfig em1: flags=8943 metric 0 mtu 1500 options=98 ether 00:0c:29:91:9d:ea inet 10.100.100.100 netmask 0xffffff00 broadcast 10.100.100.255 vhid 1 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active carp: MASTER vhid 1 advbase 1 advskew 0 tap0: flags=8943 metric 0 mtu 1500 options=80000 ether 00:bd:4e:4d:00:00 nd6 options=29 Opened by PID 1166 bridge0: flags=8843 metric 0 mtu 1500 ether 02:d7:b7:da:d6:00 inet 10.80.90.6 netmask 0xffffff00 broadcast 10.80.90.255 nd6 options=21 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: em1 flags=143 ifmaxaddr 0 port 3 priority 128 path cost 20000 member: tap0 flags=143 ifmaxaddr 0 port 7 priority 128 path cost 2000000 CARP configured by same command on both 10-C1 and 10-C2 with advskew 100 parameter on one of them: 10-C1# ifconfig em1 vhid 1 pass pppp 10.100.100.100/24 10-C2# ifconfig em1 vhid 1 advskew 100 pass pppp 10.100.100.100/24 After configuring CARP i see advertisings on bridge0 interface of 8.2-R from both 10-C, i see advertisings from 10-C1 on bridge0 interface of 10-C2 and vice versa, and i see advertisings on em1 interfaces of 10-C1 and 10-C2 from both 10-C: # tcpdump -ne -i em1 net 10.100.100 22:06:14.660011 00:0c:29:cc:fa:84 > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 10.100.100.100 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36 22:06:14.769632 00:0c:29:91:9d:ea > 01:00:5e:00:00:12, ethertype IPv4 (0x0800), length 70: 10.100.100.100 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 0, authtype none, intvl 1s, length 36 ^C I see same strings in /var/log/messages of 10-C1 and 10-C2 Mar 19 21:08:50 home kernel: carp: VHID 1@em1: INIT -> BACKUP Mar 19 21:08:53 home kernel: carp: VHID 1@em1: BACKUP -> MASTER (master down) So, result is basically the same as in my old post here: i see CARP messages on both ends on interfaces but CARPs doesn't see them. BUT HERE'S THE NEWS: # netstat -s -p carp carp: 3164 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for wrong TTL 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication > 3164 discarded for bad vhid 0 discarded because of a bad address list 1962 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error Though net.inet.carp.log = 2, i see no messages about bad packets. Why CARP thinks that vhid are bad? Can i debug CARP on 10-C? -- your sweet isn't ready yet From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 21:27:39 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 BC601106564A; Mon, 19 Mar 2012 21:27:39 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 7BB2A8FC14; Mon, 19 Mar 2012 21:27:39 +0000 (UTC) Received: from [127.0.0.1] (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q2JLRCdX061326; Mon, 19 Mar 2012 14:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1332192433; bh=YZlUo4oxYyse7f1zTzG5GMatXnbBLq3WopkNt1FlCP0=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=HOohWaN46xtmaI0AopnAk0/RfifQ+SbEjJUm7jzNOUriPSY/U0sJcsHHK57bbTy8I ys3Lbx/e7zkbZYckrT9IqzTAviPgYpiXLrmt0LIJAV+7V/c5HytSjYnD6WRiRJjwoD GG4zUXgnlzgeCIK8jY+nhvRPDXBwOtGtde5vFS5g= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20120224180653.GA18456@michelle.cdnetworks.com> References: <1329958728.78750.6.camel@powernoodle-l7.corp.yahoo.com> <20120223213344.GC13815@michelle.cdnetworks.com> <1330021403.3443.11.camel@powernoodle-l7.corp.yahoo.com> <20120224180653.GA18456@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 19 Mar 2012 14:27:11 -0700 Message-ID: <1332192431.7409.6.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: bge(4) failure, Dell 12G hardware, BCM5720C X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 21:27:39 -0000 On Fri, 2012-02-24 at 10:06 -0800, YongHyeon PYUN wrote: > On Thu, Feb 23, 2012 at 10:23:23AM -0800, Sean Bruno wrote: > > > > > As you see ukphy(4) was attached to bge2 so it may cause various > > > issues. > > > Is bge2 ASF/IPMI enabled interface? It seems ASF handling in > > > bge(4) causes more trouble on recent controllers. Unfortunately > > > disabling ASF may also trigger other problems like NMI. > > > I believe bge(4) should always honor ASF/IMPI firmware instead of > > > relying on hw.bge.allow_asf tunable and have to strictly follow > > > firmware handshake sequence. Just ignoring ASF/IMPI firmware seems > > > to confuse firmware. > > > Unfortunately all these information is undocumented and fixing it > > > requires real hardware access. > > > > ASF/IPMI -- I've tried disabling things, but it just fails miserably. I > > can at least get the host to a login via serial console and poke at > > things. > > > > Do you want me to rig up a test for you on this box? I suspect I can do > > something temporarily in the freebsd cluster with this box. > > > > Hmm, I still have to understand what is correct handshake sequence > for ASF/IPMI firmware. This handshake may be related with suspend/ > resume as well as WOL. I'll let you know when I have experimental > patch. > > > Sean > > Hrm, looking at the BCM57XX programming guide, I see that there's a section on ASF. Is that what you're looking for or is there a different bit of information you are trying to find? Sean ref. http://www.broadcom.com/collateral/pg/57XX-PG105-R.pdf From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 22:04:56 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 869A21065674 for ; Mon, 19 Mar 2012 22:04:56 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 40FEB8FC17 for ; Mon, 19 Mar 2012 22:04:56 +0000 (UTC) Received: by yhgm50 with SMTP id m50so7164460yhg.13 for ; Mon, 19 Mar 2012 15:04:55 -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=pxsYXRcjebkTHLMD/1A/XXMsQCjzI7Ks5z6+HzoZ/ZA=; b=uRsNtDJ6VErgj87F7waKjY/sYSVS3ClFbR1eH3wiF0wbKofXMgRhMMdX6EeMt+huT6 xFHoIXIAc442HEz+3Z+fDOjOut1JkNNQ+DQ3KIWnSW6ACyjpKedOPXZdOobQiNUHcw9b YeUjQbcvgiobLe9SRcnNacOTcBxubug9Ci11bDPGTTMxGdvPFHb4BXJy4GQB4t6usc8i LCkQSmAPK6etby4AeJ6jk0fOTJ7KZ+j5J0d3vNUUsrZMALJoUWYiaPSzPe0mTzUTMWUp HYcPjrqvvJ9PWrBhPeP1JdBLu8bvWJ0vfRjYFXQt/M80suhKqeqz3IaN1NNp/uGqK9om vBrw== MIME-Version: 1.0 Received: by 10.182.109.106 with SMTP id hr10mr15352985obb.27.1332194695687; Mon, 19 Mar 2012 15:04:55 -0700 (PDT) Received: by 10.182.47.135 with HTTP; Mon, 19 Mar 2012 15:04:55 -0700 (PDT) In-Reply-To: References: <0F2031C9-3A37-4994-BBE7-869D9F975170@gmail.com> Date: Mon, 19 Mar 2012 15:04:55 -0700 Message-ID: From: Jason Wolfe To: grarpamp Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Stuck in FIN_WAIT_2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:04:56 -0000 Is 'tcpdrop' present? Looks like it was in 5 at least, but I couldn't validate in 4. At any rate sounds like your going the upgrade route. I've had no issues with a 20s timeout and fast recycle as mentioned in 8.X also. Jason On Thu, Mar 15, 2012 at 2:43 PM, grarpamp wrote: >> net.inet.tcp.finwait2_timeout <-- lower this >> net.inet.tcp.fast_finwait2_recycle <-- set this to 1 > > Not present. This state has lingered for a couple > years. It needs upgraded anyways, reboot coming. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 23:58: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 130CF106566C; Mon, 19 Mar 2012 23:58:46 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id CBB318FC17; Mon, 19 Mar 2012 23:58:45 +0000 (UTC) Received: by dald2 with SMTP id d2so11493718dal.13 for ; Mon, 19 Mar 2012 16:58:45 -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=MLCrfjpdYNxNqX4pIQiT/qdetCpXkTpRHzcN9nbyBxM=; b=FstdDY4WeeFxWmJogYJJJzCOvpKrp/QPCgwsm4Raj2yrX71eyXYUopRHGtPL1oRnkX 7QATSV50yTihosYYnlcZn3twxBpd+pArmyop2Iv2OtfUgs+pTXBxMMNUv1MBzYtgEDBv LTYAL4n0MZZs3yiT3ImaqRf+xT5vbubakMXPn/1YmpNnxzlkQdthJ/zpP6jctKz9mlZS D7LPkGtUh6XrF8ON+9SBLQ133BRUO/1eGYtnm9O9TzNsFmiFFNJ99F80lllMFEBPsVSR EKWczvA7b6I4UmEKbAi1pDlVkpDX18FEERK2GrwCd/Riw0OAFZsmC+ZgiwGofAX4GQuw lAhg== Received: by 10.68.135.100 with SMTP id pr4mr25823009pbb.79.1332201525279; Mon, 19 Mar 2012 16:58:45 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id b4sm12361821pbc.7.2012.03.19.16.58.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 16:58:44 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 20 Mar 2012 08:58:39 -0700 From: YongHyeon PYUN Date: Tue, 20 Mar 2012 08:58:39 -0700 To: Sean Bruno Message-ID: <20120320155839.GA11016@michelle.cdnetworks.com> References: <1329958728.78750.6.camel@powernoodle-l7.corp.yahoo.com> <20120223213344.GC13815@michelle.cdnetworks.com> <1330021403.3443.11.camel@powernoodle-l7.corp.yahoo.com> <20120224180653.GA18456@michelle.cdnetworks.com> <1332192431.7409.6.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1332192431.7409.6.camel@powernoodle-l7.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" Subject: Re: bge(4) failure, Dell 12G hardware, BCM5720C 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: Mon, 19 Mar 2012 23:58:46 -0000 On Mon, Mar 19, 2012 at 02:27:11PM -0700, Sean Bruno wrote: > On Fri, 2012-02-24 at 10:06 -0800, YongHyeon PYUN wrote: > > On Thu, Feb 23, 2012 at 10:23:23AM -0800, Sean Bruno wrote: > > > > > > > As you see ukphy(4) was attached to bge2 so it may cause various > > > > issues. > > > > Is bge2 ASF/IPMI enabled interface? It seems ASF handling in > > > > bge(4) causes more trouble on recent controllers. Unfortunately > > > > disabling ASF may also trigger other problems like NMI. > > > > I believe bge(4) should always honor ASF/IMPI firmware instead of > > > > relying on hw.bge.allow_asf tunable and have to strictly follow > > > > firmware handshake sequence. Just ignoring ASF/IMPI firmware seems > > > > to confuse firmware. > > > > Unfortunately all these information is undocumented and fixing it > > > > requires real hardware access. > > > > > > ASF/IPMI -- I've tried disabling things, but it just fails miserably. I > > > can at least get the host to a login via serial console and poke at > > > things. > > > > > > Do you want me to rig up a test for you on this box? I suspect I can do > > > something temporarily in the freebsd cluster with this box. > > > > > > > Hmm, I still have to understand what is correct handshake sequence > > for ASF/IPMI firmware. This handshake may be related with suspend/ > > resume as well as WOL. I'll let you know when I have experimental > > patch. > > > > > Sean > > > > > Hrm, looking at the BCM57XX programming guide, I see that there's a > section on ASF. Is that what you're looking for or is there a different > bit of information you are trying to find? > Yes the public data sheet mentions ASF specific registers. However what we want to know is communication interface between ASF/IPM firmware and driver. This would be done via several undocumented mailbox registers for each events(driver up/down, WOL configuration, suspend and resume etc). bge(4) does not care about registers that make ASF work. > Sean > > ref. http://www.broadcom.com/collateral/pg/57XX-PG105-R.pdf > From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 00:16:37 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 654CD106564A; Tue, 20 Mar 2012 00:16:37 +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 380A58FC0C; Tue, 20 Mar 2012 00:16:37 +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 q2K0GbU9073769; Tue, 20 Mar 2012 00:16:37 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2K0GbQQ073765; Tue, 20 Mar 2012 00:16:37 GMT (envelope-from linimon) Date: Tue, 20 Mar 2012 00:16:37 GMT Message-Id: <201203200016.q2K0GbQQ073765@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166255: [net] [patch] It should be possible to disable "promiscuous mode enabled" messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 00:16:37 -0000 Synopsis: [net] [patch] It should be possible to disable "promiscuous mode enabled" messages Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 20 00:16:29 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166255 From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 14:19:40 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 559E41065670 for ; Tue, 20 Mar 2012 14:19:40 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id CBE838FC15 for ; Tue, 20 Mar 2012 14:19:39 +0000 (UTC) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id q2KEJVW5022582 for ; Tue, 20 Mar 2012 15:19:32 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id AD3262CBD0E for ; Tue, 20 Mar 2012 15:19:26 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 20 Mar 2012 15:54:13 +0100 From: Gustau Perez Querol To: In-Reply-To: <51f939ac5fb636ae90ba1b0fd628e40b@mail.mikej.com> References: <51f939ac5fb636ae90ba1b0fd628e40b@mail.mikej.com> Message-ID: X-Sender: gperez@entel.upc.edu User-Agent: RoundCube Webmail/0.5.1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Tue, 20 Mar 2012 15:19:32 +0100 (CET) Subject: Re: Cloning VLAN interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 14:19:40 -0000 On Mon, 19 Mar 2012 12:11:10 -0400, jammin2night wrote: > FreeBSD charon 9.0-STABLE FreeBSD 9.0-STABLE #14 r233107: Sun Mar 18 > 05:26:58 EDT 2012 root@charon:/usr/obj/usr/src/sys/CHARON amd64 > > Hello: > > I have a machine that has a 802.1q trunk attached which works fine. > I can create VLAN interfaces, apply an IP address to them and all is > good. > > I have VirtualBox running on this machine and need to present an > interface to a VM that does not support trunking natively. I've > googled and searched the archive trying to figure out how to create > an > interface that VirtualBox will use where the 802.1Q tags are removed > but have not had any success. If I understood you correctly, you want to bridge the interface without 802.1q, so the tag/untag would be done by the host machine? If that's the case you can bridge the guest's virtual interface to the vlan interface, so the guest won't see the tags. You can't do with the VBox GUI, but the VBox TUI (VBoxManage ) is able to do what you want. Let's suppose you want to bridge the host's vlan10 interface with the first virtual interface of a virtual machine named "FreeBSD virtual machine" and let's suppose it will be a virtio interface: VBoxManage modifyvm "FreeBSD virtual machine" --nic1 bridge --nictype bridge virtio --bridgeadapter vlan10 Actually I'm using this kind of setup with around 10 virtual machines, each one serving 5 vlans. It is a very flexible setup because the virtual machines don't need to worry about the physical segmentation of my network, but only the logical segmentation (at IP level). Gustau > > > > _______________________________________________ > 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 20 15:15: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 2EADE106566B for ; Tue, 20 Mar 2012 15:15:47 +0000 (UTC) (envelope-from timon@timon.net.nz) Received: from frost.plasmahost.ru (plasmahost.ru [178.63.60.242]) by mx1.freebsd.org (Postfix) with ESMTP id 9E84E8FC1A for ; Tue, 20 Mar 2012 15:15:46 +0000 (UTC) Received: from timon.home.timon.net.nz ([87.242.97.5]) (AUTH: PLAIN timon@timon.net.nz, TLS: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by frost.plasmahost.ru with ESMTPSA; Tue, 20 Mar 2012 15:14:50 +0000 id 0002797C.000000004F689EED.00015879 Message-ID: <4F689DE6.1040103@timon.net.nz> Date: Tue, 20 Mar 2012 19:10:30 +0400 From: Alexandr Matveev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120209 Thunderbird/10.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: Assign a large number of IPv6 addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 15:15:47 -0000 Hello. I have a IPv6 subnet and I have a number of servers, that act like a accelerator with nginx. Those are behind load-balancers. I give each website a unique combination of IP addresses from a pool (so each website has a different set of four IP addresses). I need to assign those IP addresses to accelerators, so they accept the packets that comes from the balancers. I need to assign all of addresses (500,000 IPs) from IPv6 subnet to a single FreeBSD interface. If I do that, FreeBSD hangs. Right now this is working with IPv4 addresses, but there are only 100 of them. Since IPv6 networks are bigger - more addresses can be added to unique combination. On Linux I can mark this network as 'local', so it accepts all packets that come to those addresses. Can I do this on FreeBSD and how? This is the linux command I use: ip -6 route add local 2a00:15f8:f000::/64 dev eth0 -- Alexandr Matveev From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 17:16:31 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 BB0451065677 for ; Tue, 20 Mar 2012 17:16:31 +0000 (UTC) (envelope-from ihsan.junaidi@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8E0AC8FC1A for ; Tue, 20 Mar 2012 17:16:31 +0000 (UTC) Received: by dald2 with SMTP id d2so338173dal.13 for ; Tue, 20 Mar 2012 10:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=CRFDQdVqCi1rwtfR2oMM/5ZYblNpczT3gASnr1JGSPs=; b=gBP3DitOq9HxkD7hYCkVnsXxt2bWGn3CCo1K3YXOzgtUzp9+m8Pt4ykCemfhixrlW1 N/PJnFKwydCiFfJKWuJVs4vqLKI1/wfIOmpuCb8hJsX7z99mostp7JzFGBREAbbvTlt4 TTgwXvBBY2V0y1r2JS0MKK9K8YstmpEhZkq29eQqzk7JoWrusTqOizWKa3B4TH8JLCw+ CemLG2peR6C2FP2npgYYea9xzV+/pCPw88SPerDh/epX++R12+3MRlzL0elQ97ICIyh3 S7BPWlr51S5TLn/wcEOvIFEcY4qfqPQqUM+Y+kWG1hMf7LjJVoU3ZXvrNJIablUGKPiS mU/Q== Received: by 10.68.229.73 with SMTP id so9mr2804737pbc.163.1332263791244; Tue, 20 Mar 2012 10:16:31 -0700 (PDT) Received: from [192.168.2.243] ([175.142.144.21]) by mx.google.com with ESMTPS id y9sm1689531pbu.40.2012.03.20.10.16.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 10:16:30 -0700 (PDT) From: Ihsan Junaidi Ibrahim Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Mar 2012 01:16:26 +0800 Message-Id: <4DCC5341-CE31-4D2A-9569-D27242DABB2F@gmail.com> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: netstat: memstat_sysctl_all: Too many CPUs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 17:16:31 -0000 Hi folks, While trying to poke around my mbuf stats, I ran across the following = error message. ihsan@sv01:~ $ netstat -m netstat: memstat_sysctl_all: Too many CPUs It's an E3-1230 CPU on a Supermicro X9SCM-F with 4G RAM. I'm on 9.0-RELEASE. Has anybody encountered this before? From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 17:45:34 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 79403106566B; Tue, 20 Mar 2012 17:45:34 +0000 (UTC) (envelope-from nitroboost@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0BEB58FC14; Tue, 20 Mar 2012 17:45:33 +0000 (UTC) Received: by yhgm50 with SMTP id m50so397018yhg.13 for ; Tue, 20 Mar 2012 10:45:33 -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=dGHlYepAZrnpJ8RFBvnuIIL8Ywv66DFwKtIiJa6DSnY=; b=ybzDMkoK86YWmesi+5ZTNyQLzhTeYLMPIK83H0dysJSnbAsgouDYGUQB9EKxJAAunk 50HYqGWTBCeSLa6Cdwfaqyr0+BjP/sRWhrY8/CgsVFv3a9sjradjO/Ip4ULMgPdyzmXk Kymy0BtrjkoOsxlEsiXZTlKv2V7iYeCC6n2SkQRXdvKbEVR7wyuG3hUyczDjKz1qOzAT t/wiBzLXp5GPlAR+tyIDgkLoOzRPXvYvNiCTetiFVvV/f6H59TyNRfY00E9sgd/+jkTT rGvwk49DYZu8vagermC4pk1n7+xBovfiRIDO37Uf/4ruEVzfbEy8vvJcBMduVBirhAPf 7Ijw== MIME-Version: 1.0 Received: by 10.60.18.137 with SMTP id w9mr1039037oed.7.1332265533237; Tue, 20 Mar 2012 10:45:33 -0700 (PDT) Received: by 10.182.47.135 with HTTP; Tue, 20 Mar 2012 10:45:32 -0700 (PDT) In-Reply-To: <201203151417.04507.jhb@freebsd.org> References: <4F5C587B.6010004@gmail.com> <201203151417.04507.jhb@freebsd.org> Date: Tue, 20 Mar 2012 10:45:32 -0700 Message-ID: From: Jason Wolfe To: John Baldwin , Hooman Fazaeli , Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 17:45:34 -0000 On Thu, Mar 15, 2012 at 11:17 AM, John Baldwin wrote: > On Sunday, March 11, 2012 3:47:07 am Hooman Fazaeli wrote: >> On 3/11/2012 5:31 AM, Adrian Chadd wrote: >> > Are you able to post the patch here? >> > Maybe Jack can look at what's going on and apply it to the latest >> > intel ethernet driver. >> > >> > >> > Adrian >> > >> >> Below is the patch for if_em.c (7.2.3). It simply checks driver's >> queue status when the link state changes (inactive -> active) and >> start transmit task if queue(s) are not empty. >> >> It also contains stuff I have added to compile on 7 plus some code >> for test and diagnostics. > > Hmm, so I have yet to test this, but I found several bugs related to tran= smit > in em(4) and igb(4) recently just reading the code. =A0(Mostly unnecessar= y > scheduling of tasks for transmit.) =A0I've included your change of restar= ting > TX when link becomes active. =A0I've also updated it to fix resume for em > and igb to DTRT when buf_ring is used, and to not include old-style start > routines at all when using multiq. =A0It is at > http://www.freebsd.org/~jhb/patches/e1000_txeof2.patch > > -- > John Baldwin John/Hooman, Thank for the patch sirs, so far it does look like it did the trick. I'll know for certain here in a few days if I'm still in the clear. I'm guessing after it goes through some more testing it'll be too late to slip it into 8.3? Adrian, Sounds like you might be all set on hardware, but if anything falls through let me know. Jason From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 18:39:17 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 10E08106566C for ; Tue, 20 Mar 2012 18:39:17 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 824238FC08 for ; Tue, 20 Mar 2012 18:39:16 +0000 (UTC) Received: by lboi15 with SMTP id i15so375246lbo.13 for ; Tue, 20 Mar 2012 11:39:15 -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=+/EGmgylV0Y0qn4mj6KkvCEbH5xi7fWTOABWWJHmBVs=; b=lMDubY52Z4rdM0r9zJI1hgkXQ0y/QXZuvB6LLO2/8nOMH9KgTa9rWgUFddnn2FLGiV Z0JoPZuRdy70pbVwh3btKQx3Df0GWqrdy453Fc55NBq/7hxzKEXDwmTs0jnsZP6SIcjP rZ56iTCmWa1Tf01vJ32qfg9SSK912SSukCXmum+Vfu9+HYW0Bx7Zs2xgMy8iX6Hr0HPM dFXGjxhVYjiUOw4g2sp0KJd1KKregT9Rc+FNq60Gd9CxdwxwHMC2KESVjnv0JJuBisuC ZIXtfQ+qbUK3GcNBH23uuAD+eXeqIoJcw36zjQ9v/8+HUW/x7rxyuC/RdNi5nK9urRRD +UQg== MIME-Version: 1.0 Received: by 10.152.128.38 with SMTP id nl6mr717905lab.15.1332268755307; Tue, 20 Mar 2012 11:39:15 -0700 (PDT) Received: by 10.152.21.73 with HTTP; Tue, 20 Mar 2012 11:39:15 -0700 (PDT) In-Reply-To: <4DCC5341-CE31-4D2A-9569-D27242DABB2F@gmail.com> References: <4DCC5341-CE31-4D2A-9569-D27242DABB2F@gmail.com> Date: Tue, 20 Mar 2012 21:39:15 +0300 Message-ID: From: Sergey Kandaurov To: Ihsan Junaidi Ibrahim Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: netstat: memstat_sysctl_all: Too many CPUs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 18:39:17 -0000 On 20 March 2012 21:16, Ihsan Junaidi Ibrahim wrote: > Hi folks, > > While trying to poke around my mbuf stats, I ran across the following error message. > > ihsan@sv01:~ $ netstat -m > netstat: memstat_sysctl_all: Too many CPUs > > It's an E3-1230 CPU on a Supermicro X9SCM-F with 4G RAM. > > I'm on 9.0-RELEASE. > > Has anybody encountered this before? > Well, that means that you are likely running libmemstat(3) library from RELENG_8. This error message (and a reason for it) was removed in 9.0. In 8.x and earlier this error was possible when kernel is compiled with MAXCPU kernel option value greater than 32. If you upgraded to 9.0 from an earlier release than please make sure you have kernel and world in sync. -- wbr, pluknet From owner-freebsd-net@FreeBSD.ORG Tue Mar 20 19:04:02 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 17DA6106566C; Tue, 20 Mar 2012 19:04:02 +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 DD08C8FC0A; Tue, 20 Mar 2012 19:04:01 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 907F146B17; Tue, 20 Mar 2012 15:04:01 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F160FB91C; Tue, 20 Mar 2012 15:04:00 -0400 (EDT) From: John Baldwin To: Jason Wolfe Date: Tue, 20 Mar 2012 14:57:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201203151417.04507.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203201457.24776.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Mar 2012 15:04:01 -0400 (EDT) Cc: freebsd-net@freebsd.org, Adrian Chadd , Hooman Fazaeli Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 19:04:02 -0000 On Tuesday, March 20, 2012 1:45:32 pm Jason Wolfe wrote: > On Thu, Mar 15, 2012 at 11:17 AM, John Baldwin wrote: > > On Sunday, March 11, 2012 3:47:07 am Hooman Fazaeli wrote: > >> On 3/11/2012 5:31 AM, Adrian Chadd wrote: > >> > Are you able to post the patch here? > >> > Maybe Jack can look at what's going on and apply it to the latest > >> > intel ethernet driver. > >> > > >> > > >> > Adrian > >> > > >> > >> Below is the patch for if_em.c (7.2.3). It simply checks driver's > >> queue status when the link state changes (inactive -> active) and > >> start transmit task if queue(s) are not empty. > >> > >> It also contains stuff I have added to compile on 7 plus some code > >> for test and diagnostics. > > > > Hmm, so I have yet to test this, but I found several bugs related to transmit > > in em(4) and igb(4) recently just reading the code. (Mostly unnecessary > > scheduling of tasks for transmit.) I've included your change of restarting > > TX when link becomes active. I've also updated it to fix resume for em > > and igb to DTRT when buf_ring is used, and to not include old-style start > > routines at all when using multiq. It is at > > http://www.freebsd.org/~jhb/patches/e1000_txeof2.patch > > > > -- > > John Baldwin > > John/Hooman, > > Thank for the patch sirs, so far it does look like it did the trick. > I'll know for certain here in a few days if I'm still in the clear. > I'm guessing after it goes through some more testing it'll be too late > to slip it into 8.3? Yes, this is too late for 8.3, but thanks for testing! -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 05:57:59 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 1EC61106564A for ; Wed, 21 Mar 2012 05:57:59 +0000 (UTC) (envelope-from ihsan.junaidi@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id E22638FC08 for ; Wed, 21 Mar 2012 05:57:58 +0000 (UTC) Received: by dald2 with SMTP id d2so1253508dal.13 for ; Tue, 20 Mar 2012 22:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=AtYfdPBTHjaN3769oH1lg1pwIcTsRW01DHenV61Km1M=; b=Y1UF5G/IluXjb0/ryYIIjEr6HMqlguUjS9nmJusJkLiy64mA5PjPGtiE2p4vP0MWf9 +pUXYWaJEbycfqMB1awQe9YFMaz+4dUofrt4nx+Us17WCUtjrohxqeHSSRgMfA7fEvgu tjw3RMHvnh0zFXNPOkDzWMTWyBQ3YEED6fe+xlc0/B9L4Zxumx9T7rXdZBo9I4gSGU0i 4nqBoQkN6ZLJlfiDgmVPGpkH/3761EWnWsKAt/LtRjcHLcHBYqtjH6/lGjoqEuCseYEF jCy+Ej7mPjnFod2oWXIi2lRUyOZyltBqUQvBKbK1miZ9f2pqBaqFtCFPX0bC1NavUi93 VBjQ== Received: by 10.68.228.67 with SMTP id sg3mr8066097pbc.17.1332309478279; Tue, 20 Mar 2012 22:57:58 -0700 (PDT) Received: from [10.0.20.68] ([211.24.220.233]) by mx.google.com with ESMTPS id p9sm626122pbb.9.2012.03.20.22.57.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 22:57:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ihsan Junaidi Ibrahim In-Reply-To: Date: Wed, 21 Mar 2012 13:57:53 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DCC5341-CE31-4D2A-9569-D27242DABB2F@gmail.com> To: Sergey Kandaurov X-Mailer: Apple Mail (2.1257) Cc: freebsd-net@freebsd.org Subject: Re: netstat: memstat_sysctl_all: Too many CPUs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 05:57:59 -0000 Sergey, It was upgraded from 8.2-RELEASE via freebsd-update so I'd assume the = kernel and world are in sync. Since I'm already on 9.0, is there a way to fix this without going = through the whole buildworld thing? This box is on a GENERIC kernel. ihsan On Mar 21, 2012, at 2:39 AM, Sergey Kandaurov wrote: > On 20 March 2012 21:16, Ihsan Junaidi Ibrahim = wrote: >> Hi folks, >>=20 >> While trying to poke around my mbuf stats, I ran across the following = error message. >>=20 >> ihsan@sv01:~ $ netstat -m >> netstat: memstat_sysctl_all: Too many CPUs >>=20 >> It's an E3-1230 CPU on a Supermicro X9SCM-F with 4G RAM. >>=20 >> I'm on 9.0-RELEASE. >>=20 >> Has anybody encountered this before? >>=20 >=20 > Well, that means that you are likely running libmemstat(3) library = from > RELENG_8. This error message (and a reason for it) was removed in 9.0. > In 8.x and earlier this error was possible when kernel is compiled > with MAXCPU kernel option value greater than 32. > If you upgraded to 9.0 from an earlier release than please > make sure you have kernel and world in sync. >=20 > --=20 > wbr, > pluknet From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 10:18:51 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 9E4C3106577D for ; Wed, 21 Mar 2012 10:18:51 +0000 (UTC) (envelope-from mike.barnardq@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 E416E8FC16 for ; Wed, 21 Mar 2012 10:18:50 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so5033157wib.13 for ; Wed, 21 Mar 2012 03:18:44 -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=aPSlCXIMVqKzYDy5e66gxuZxJixcO9XvEErJPuOOyZc=; b=tsMOk3KPzD8nS0KAI0xg9Z1prv8Q6JRN8OnMpp44qs3/egmK4NQqkOW1J/sZD7dPMk xaBwaasXu9UrWAg4o2XPBc60ei606Hz/QdkPMiPcfl8SPSrt6hCyElRovBM5Qs18Kt73 7y1OVpoqk8A7mh0c+Bmj1jHFV5C1fujW8N3lGDOHehkOQmWlv6AzFmuqqUqQbKnxrQcb hzMazonj8kba8hclJaoqmnAawZGARSobxllzfrLdJFOSSmw44kTA7rtV0T+JYHyGdcLy sfHFfkP8KDtKPcjuro3zWt/8lfuxmZ49tFMnzox/zmE164gp1ogzxCyVG5KFfW/DoLAe s50g== MIME-Version: 1.0 Received: by 10.180.94.33 with SMTP id cz1mr7729678wib.13.1332325124075; Wed, 21 Mar 2012 03:18:44 -0700 (PDT) Received: by 10.180.104.164 with HTTP; Wed, 21 Mar 2012 03:18:44 -0700 (PDT) Date: Wed, 21 Mar 2012 13:18:44 +0300 Message-ID: From: Mike Barnard To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: CARP Active-Active X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 10:18:51 -0000 Hi, I hope this is the right place to ask about this (didn't think PF list would be ideal for this question). I have been reading on CARP in active-active mode and was wondering whether this is possible in FreeBSD. It is possible to get it done on OpenBSD ( www.kernel-panic.it/openbsd/carp/carp4.html#carp-4.2.2)? Does FreeBSD yet have IP load balacing on CARP? Are there plans to do this on FreeBSD? -- Mike Of course, you might discount this possibility, but remember that one in a million chances happen 99% of the time. ------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 11:02:30 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 943B4106566B for ; Wed, 21 Mar 2012 11:02:30 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail1.icritical.com (mail1.icritical.com [93.95.13.41]) by mx1.freebsd.org (Postfix) with SMTP id E63038FC12 for ; Wed, 21 Mar 2012 11:02:29 +0000 (UTC) Received: (qmail 28657 invoked from network); 21 Mar 2012 11:02:32 -0000 Received: from localhost (127.0.0.1) by mail1.icritical.com with SMTP; 21 Mar 2012 11:02:32 -0000 Received: (qmail 28642 invoked by uid 599); 21 Mar 2012 11:02:32 -0000 Received: from unknown (HELO hydrogen.icritical.com) (212.57.254.146) by mail1.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 21 Mar 2012 11:02:32 +0000 Message-ID: <4F69B540.7070706@icritical.com> Date: Wed, 21 Mar 2012 11:02:24 +0000 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120204 Thunderbird/10.0 MIME-Version: 1.0 To: Gustau Perez Querol References: <51f939ac5fb636ae90ba1b0fd628e40b@mail.mikej.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2012 11:02:24.0362 (UTC) FILETIME=[1883DCA0:01CD0752] X-Virus-Scanned: by iCritical at mail1.icritical.com Cc: freebsd-net@freebsd.org Subject: Re: Cloning VLAN interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 11:02:30 -0000 On 03/20/12 14:54, Gustau Perez Querol wrote: > VBoxManage modifyvm "FreeBSD virtual machine" --nic1 bridge --nictype > bridge virtio --bridgeadapter vlan10 On my machines running virtualbox-ose-4.0.14, VBoxManage won't accept vlan interfaces either - I need to kill the GUI then edit the config files to change the physical interface to vlanN. Also, when altering any other setting by the GUI, the process needs repeating. -- Sorry for the following... The information contained in this message is confidential and is intended for the addressee only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Critical Software Ltd. reserves the right to monitor and record e-mail messages sent to and from this address for the purposes of investigating or detecting any unauthorised use of its system and ensuring its effective operation. Critical Software Ltd. registered in England, 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. ------------------------------------------------------------ This message has been scanned for security threats by iCritical. For further information, please visit www.icritical.com ------------------------------------------------------------ From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 12:40: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 58C2D1065674 for ; Wed, 21 Mar 2012 12:40:41 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9838FC0A for ; Wed, 21 Mar 2012 12:40:40 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1360896vcm.13 for ; Wed, 21 Mar 2012 05:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NVE5MckLBnCCkna3qUJ/B9EF9jO6zpjftPTXSQswM64=; b=sXE6LoX4Jc/hasFXMSg9tVjCdmKr86gwttFDOCZ8Rc8irO/iAjG+HDyb3vlp6n57pF +eDyz4yhldhsvB/IzQAa4ruvpzmiCOUbbV4luplJBucCEUDrE1PO++na47BCWPblx+qt fuc1epNHZaouL/14zOQExP81x5tTvmLEs0H2VJAY8ABwe9OS0iMzrCzTl8pIVHNDJXtx UXT6qJh8Ot0RtOJDv1F/KMTrGz5PIbfHPqRfwHXh+Of91thjD+h8v0W0q7muRd8WPzbN D8IMKQ5UzmcXnRNfSK9YKXJmJvq+EVTOhiqS8qejVP6l3SvK/sRMw+OFIh16HzEDCRGY XSvA== MIME-Version: 1.0 Received: by 10.220.155.71 with SMTP id r7mr1802201vcw.24.1332333640150; Wed, 21 Mar 2012 05:40:40 -0700 (PDT) Received: by 10.52.161.71 with HTTP; Wed, 21 Mar 2012 05:40:40 -0700 (PDT) In-Reply-To: References: <4DCC5341-CE31-4D2A-9569-D27242DABB2F@gmail.com> Date: Wed, 21 Mar 2012 12:40:40 +0000 Message-ID: From: Tom Evans To: Ihsan Junaidi Ibrahim Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, Sergey Kandaurov Subject: Re: netstat: memstat_sysctl_all: Too many CPUs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:40:41 -0000 On Wed, Mar 21, 2012 at 5:57 AM, Ihsan Junaidi Ibrahim wrote: > Sergey, > > It was upgraded from 8.2-RELEASE via freebsd-update so I'd assume the kernel and world are in sync. > Confirm this, eg by running "ident /usr/bin/netstat" You could also try the IDS feature of freebsd-update to check the status of world - "freebsd-update IDS" I'm not sure of the best way of restoring a particular release, but you could always download {base,doc,games,kernel,ports,src}.txz from 9.0 release and install them over what you already have there. Cheers Tom From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 12:46: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 F29A0106564A for ; Wed, 21 Mar 2012 12:46:09 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7CBAF8FC0C for ; Wed, 21 Mar 2012 12:46:09 +0000 (UTC) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id q2LCk7HW008458 for ; Wed, 21 Mar 2012 13:46:08 +0100 Received: from webmail.entel.upc.edu (wireless.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id D1FA52CBD0E for ; Wed, 21 Mar 2012 13:46:02 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 21 Mar 2012 14:21:33 +0100 From: Gustau Perez Querol To: In-Reply-To: <4F69B540.7070706@icritical.com> References: <51f939ac5fb636ae90ba1b0fd628e40b@mail.mikej.com> <4F69B540.7070706@icritical.com> Message-ID: <4e8108fbc66bbfe24a18d743497cadbd@webmail.entel.upc.edu> X-Sender: gperez@entel.upc.edu User-Agent: RoundCube Webmail/0.5.1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Wed, 21 Mar 2012 13:46:08 +0100 (CET) Subject: Re: Cloning VLAN interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:46:10 -0000 On Wed, 21 Mar 2012 11:02:24 +0000, Matt Burke wrote: > On 03/20/12 14:54, Gustau Perez Querol wrote: >> VBoxManage modifyvm "FreeBSD virtual machine" --nic1 bridge >> --nictype >> bridge virtio --bridgeadapter vlan10 > > On my machines running virtualbox-ose-4.0.14, VBoxManage won't accept > vlan > interfaces either - I need to kill the GUI then edit the config files > to > change the physical interface to vlanN. Mmm, I first tried the 4.1.51r40008 (the devel one). Now I'm running 4.1.X (from redports) and the VBoxManage accepts an vlan interface as a bridged interface. > > Also, when altering any other setting by the GUI, the process needs > repeating. > That is correct, I have just checked that behavior and it also happens to me. I also noticed that the vbox GUI gets confused only if you go the properties of the machine using a bridged vlan interface. If you don't go to the properties of the virtual machine, you will see in the panel on the right side that the virtual interfaces remain bridged to your real vlan interfaces. It would appear I've been lucky, as I'm running vbox in a headless machine so I have always used the TUI (which doesn't get confused about using vlan interfaces). If you succeed with ng, please let us know, I'm interested in netgraph. If you don't, at least you know you can do it by using the VBoxManage tool... Gustau From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 13:41:50 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 EFC3A106566B; Wed, 21 Mar 2012 13:41:50 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C37898FC0A; Wed, 21 Mar 2012 13:41:50 +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 q2LDfo6S027704; Wed, 21 Mar 2012 13:41:50 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2LDfodw027700; Wed, 21 Mar 2012 13:41:50 GMT (envelope-from glebius) Date: Wed, 21 Mar 2012 13:41:50 GMT Message-Id: <201203211341.q2LDfodw027700@freefall.freebsd.org> To: jaccovanbuuren@gmail.com, glebius@FreeBSD.org, freebsd-net@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: bin/165413: [netgraph]: ngctl(8) does not work as advertised X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 13:41:51 -0000 Synopsis: [netgraph]: ngctl(8) does not work as advertised State-Changed-From-To: open->closed State-Changed-By: glebius State-Changed-When: Wed Mar 21 13:40:46 UTC 2012 State-Changed-Why: Not a bug. The code: # ngctl mkpeer em0: netflow lower iface0 expects presense of em0: node. And you don't have thise node unless you have loaded ng_ether(4). See ng_ether(4) for details. http://www.freebsd.org/cgi/query-pr.cgi?pr=165413 From owner-freebsd-net@FreeBSD.ORG Wed Mar 21 14:16: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 BF7951065677 for ; Wed, 21 Mar 2012 14:16:16 +0000 (UTC) (envelope-from seyit.ozgur@istanbul.net) Received: from spamtrap.istanbul.net (spamtrap.istanbul.net [85.111.12.34]) by mx1.freebsd.org (Postfix) with ESMTP id BC0178FC14 for ; Wed, 21 Mar 2012 14:16:15 +0000 (UTC) X-ASG-Debug-ID: 1332339365-0426ae106492170001-QdxwpM Received: from GAMMA.magnetdigital.local (gamma.magnetdigital.local [192.168.131.244]) by spamtrap.istanbul.net with ESMTP id tTDIDB8dwlzON4i6; Wed, 21 Mar 2012 16:16:05 +0200 (EET) X-Barracuda-Envelope-From: seyit.ozgur@istanbul.net X-Barracuda-RBL-Trusted-Forwarder: 192.168.131.244 Received: from YUHANNA.magnetdigital.local ([fe80::1058:3088:f9b1:1346]) by GAMMA.magnetdigital.local ([fe80::3cca:d6ef:febb:fafb%17]) with mapi id 14.01.0218.012; Wed, 21 Mar 2012 16:15:12 +0200 From: =?iso-8859-9?Q?Seyit_=D6zg=FCr?= X-Barracuda-Apparent-Source-IP: fe80::1058:3088:f9b1:1346 To: Chuck Swiger Thread-Topic: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-ASG-Orig-Subj: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release Thread-Index: Ac0C5Fxpv2wbk7REQXGSXBWgiq7+JP//5aEA//bValA= Date: Wed, 21 Mar 2012 14:15:12 +0000 Message-ID: <3807CE6F3BF4B04EB897F4EBF2D258CE5C064A80@yuhanna.magnetdigital.local> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> In-Reply-To: <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.134.34] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0018_01CD077D.CABBE3B0" MIME-Version: 1.0 X-Barracuda-Connect: gamma.magnetdigital.local[192.168.131.244] X-Barracuda-Start-Time: 1332339365 X-Barracuda-URL: http://10.10.140.221:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_RULE7568M, NORMAL_HTTP_TO_IP X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.91847 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 0.50 BSF_RULE7568M Custom Rule 7568M X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" Subject: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 14:16:16 -0000 ------=_NextPart_000_0018_01CD077D.CABBE3B0 Content-Type: multipart/mixed; boundary="----=_NextPart_001_0019_01CD077D.CABBE3B0" ------=_NextPart_001_0019_01CD077D.CABBE3B0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Hello chris, Here i get tcpdump with X param..=20 First look input errors.. its about 60 mbit/sec and much more packets = can't process packets errs idrops bytes packets errs bytes colls 36356 42777 0 7747642 243 0 263462 0 36732 41709 0 7681242 240 0 359432 0 36422 41975 0 7677434 197 0 258142 0 34042 42339 0 7487618 222 0 227152 0 35987 44405 0 7863192 304 0 377624 0 36454 41799 0 7665082 120 0 276008 0 36870 41471 0 7671950 249 0 402546 0 35951 42431 0 7674562 328 0 258136 0 36398 41853 0 7667556 28 0 78640 0 36098 42070 0 7660804 2 0 256 0 18446744073709551273 8555 0 836906 3 0 642 0 2 0 0 144 2 0 272 0 4 0 0 276 4 0 708 0 2 0 0 148 2 0 260 0 4 0 0 270 3 0 642 0 2 0 0 148 2 0 256 0 Then tcpdump with X param, also i attach txt file in mail.. 16:02:53.954863 IP 88.133.15.78 > x.x.x.x: tcp 0x0000: 4500 0050 10ba 07d0 6b06 7382 5885 0f4e = E..P....k.s.X..N 0x0010: 556f 065a f386 0050 45c4 8c77 9592 0241 = Uo.Z...PE..w...A 0x0020: 00a3 3c4c b5a3 0000 8807 a83a f215 b40d = .. x.x.x.x: tcp 0x0000: 4500 0050 9a48 07d0 6c06 dd1e 5899 1b0f = E..P.H..l...X... 0x0010: 556f 065a 718a 0050 9c79 672b c680 a521 = Uo.Zq..P.yg+...! 0x0020: 00a3 3c4c 2693 0000 8807 a83a f215 b40d = .. x.x.x.x: tcp 0x0000: 4500 0050 6c2b 07d0 6c06 e837 5815 3e97 = E..Pl+..l..7X.>. 0x0010: 556f 065a 8ae5 0050 aac1 6265 1a53 5749 = Uo.Z...P..be.SWI 0x0020: 00a3 3c4c dab7 0000 8807 a83a f215 b40d = .. x.x.x.x: tcp 0x0000: 4500 0050 4807 07d0 6b06 9ee4 582e acf5 = E..PH...k...X... 0x0010: 556f 065a a76b 0050 e3f3 5b68 1e1c 9773 = Uo.Z.k.P..[h...s 0x0020: 00a3 3c4c d991 0000 8807 a83a f215 b40d = .. x.x.x.x: tcp 0x0000: 4500 0050 0db9 07d0 6b06 d159 58f6 b406 = E..P....k..YX... 0x0010: 556f 065a 3348 0050 2817 6a1f 444e 8273 = Uo.Z3H.P(.j.DN.s 0x0020: 00a3 3c4c e1cf 0000 8807 a83a f215 b40d = .. x.x.x.x: tcp 0x0000: 4500 0050 b767 07d0 6b06 b307 58d7 28c9 = E..P.g..k...X.(. 0x0010: 556f 065a abf4 0050 947a 1e32 3a04 e901 = Uo.Z...P.z.2:... 0x0020: 00a3 3c4c 77c5 0000 8807 a83a f215 b40d = .. x.x.x.x: tcp 0x0000: 4500 0050 3789 07d0 6c06 cf55 5853 8bdd = E..P7...l..UXS.. 0x0010: 556f 065a f541 0050 5c12 f670 137b bd08 = Uo.Z.A.P\..p.{.. 0x0020: 00a3 3c4c 7e93 0000 8807 a83a f215 b40d = .. x.x.x.x: tcp 0x0000: 4500 0050 71dc 07d0 6b06 193e 58d0 0825 = E..Pq...k..>X..% 0x0010: 556f 065a 437b 0050 8045 710e dfc0 f23b = Uo.ZC{.P.Eq....; 0x0020: 00a3 3c4c 134c 0000 8807 a83a f215 b40d = .. Today we tried to see what happens Malformed syn packets on FreeBSD = 9.0 release.. >=20 > Those packets rise to CPU %100 and stucks.. >=20 > listening on ix0, link-type EN10MB (Ethernet), capture size 65535 = bytes > 18:33:30.010215 IP vgn44-1-88-123-89-40.fbx.proxad.net > = 85.xxx.xxx.90: tcp > 18:33:30.010242 IP 225.74.196.88.sta.estpak.ee > 85.xxx.xxx.90: tcp > 18:33:30.010269 IP Nnov-Prospekt.71.quantum.rn > 85.xxx.xxx.90: tcp > 18:33:30.010296 IP host52-108-static.49-88-b.business.telecomitalia.it = > 85.xxx.xxx.90: tcp > 18:33:30.010325 IP 125.Red-88-1-75.dynamicIP.rima-tde.net > = 85.xxx.xxx.90: tcp >=20 > i dont know which tool generate those packets.. but as we see i dont = see seq, flag, lenth etc.. just this ouput on tcpdump... >=20 > Is there any kernel feature for do NOT process malformed syn packets = ?? A firewall can block them before the system will see and try to process = them as incoming traffic. Also, running tcpdump with -X will give both hex and ASCII rendition of = the packets, which would be helpful to identify what you mean by = "malformed". Regards, --=20 -Chuck ------=_NextPart_001_0019_01CD077D.CABBE3B0 Content-Type: text/plain; name="tcpdump_X_.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tcpdump_X_.txt" 16:02:53.954863 IP 88.133.15.78 > x.x.x.x: tcp 0x0000: 4500 0050 10ba 07d0 6b06 7382 5885 0f4e E..P....k.s.X..N 0x0010: 556f 065a f386 0050 45c4 8c77 9592 0241 Uo.Z...PE..w...A 0x0020: 00a3 3c4c b5a3 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 9a48 07d0 6c06 dd1e 5899 1b0f E..P.H..l...X... 0x0010: 556f 065a 718a 0050 9c79 672b c680 a521 Uo.Zq..P.yg+...! 0x0020: 00a3 3c4c 2693 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 6c2b 07d0 6c06 e837 5815 3e97 E..Pl+..l..7X.>. 0x0010: 556f 065a 8ae5 0050 aac1 6265 1a53 5749 Uo.Z...P..be.SWI 0x0020: 00a3 3c4c dab7 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 4807 07d0 6b06 9ee4 582e acf5 E..PH...k...X... 0x0010: 556f 065a a76b 0050 e3f3 5b68 1e1c 9773 Uo.Z.k.P..[h...s 0x0020: 00a3 3c4c d991 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 0db9 07d0 6b06 d159 58f6 b406 E..P....k..YX... 0x0010: 556f 065a 3348 0050 2817 6a1f 444e 8273 Uo.Z3H.P(.j.DN.s 0x0020: 00a3 3c4c e1cf 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 b767 07d0 6b06 b307 58d7 28c9 E..P.g..k...X.(. 0x0010: 556f 065a abf4 0050 947a 1e32 3a04 e901 Uo.Z...P.z.2:... 0x0020: 00a3 3c4c 77c5 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 3789 07d0 6c06 cf55 5853 8bdd E..P7...l..UXS.. 0x0010: 556f 065a f541 0050 5c12 f670 137b bd08 Uo.Z.A.P\..p.{.. 0x0020: 00a3 3c4c 7e93 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 71dc 07d0 6b06 193e 58d0 0825 E..Pq...k..>X..% 0x0010: 556f 065a 437b 0050 8045 710e dfc0 f23b Uo.ZC{.P.Eq....; 0x0020: 00a3 3c4c 134c 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 2ccb 07d0 6b06 8f40 582b d7d8 E..P,...k..@X+.. 0x0010: 556f 065a 4a00 0050 1c69 0603 2f38 d011 Uo.ZJ..P.i../8.. 0x0020: 00a3 3c4c df52 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 5f46 07d0 6b06 d63f 58db 5dae E..P_F..k..?X.]. 0x0010: 556f 065a ce82 0050 5b9e 1a07 4b7f 5155 Uo.Z...P[...K.QU 0x0020: 00a3 3c4c e386 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 d14d 07d0 6c06 1177 58fd af4d E..P.M..l..wX..M 0x0010: 556f 065a 692b 0050 dd11 9600 11be 8474 Uo.Zi+.P.......t 0x0020: 00a3 3c4c 0052 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 8d78 07d0 6c06 8752 58fa 7d4a E..P.x..l..RX.}J 0x0010: 556f 065a d058 0050 182b bb48 c6be 6a14 Uo.Z.X.P.+.H..j. 0x0020: 00a3 3c4c d028 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 6ba7 07d0 6a06 e706 587a 41e7 E..Pk...j...XzA. 0x0010: 556f 065a 488c 0050 85b0 6309 582c c926 Uo.ZH..P..c.X,.& 0x0020: 00a3 3c4c 8e12 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 e95d 07d0 6a06 f97f 581e b213 E..P.]..j...X... 0x0010: 556f 065a 4c88 0050 350f a32f d507 055d Uo.ZL..P5../...] 0x0020: 00a3 3c4c 71af 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 2e5e 07d0 6c06 1f13 58ec 44b2 E..P.^..l...X.D. 0x0010: 556f 065a 540a 0050 0f43 c22b 1173 ab62 Uo.ZT..P.C.+.s.b 0x0020: 00a3 3c4c fb1f 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 9ae5 07d0 6a06 062a 5854 f3ab E..P....j..*XT.. 0x0010: 556f 065a 02dc 0050 9037 f051 98ff b852 Uo.Z...P.7.Q...R 0x0020: 00a3 3c4c 5a55 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 a93c 07d0 6c06 e8f5 58ff ffdd E..P.<..l...X... 0x0010: 556f 065a 0612 0050 3099 e04b 6b40 6a53 Uo.Z...P0..Kk@jS 0x0020: 00a3 3c4c 35a5 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 c776 07d0 6b06 4957 58b0 8291 E..P.v..k.IWX... 0x0010: 556f 065a 34a6 0050 5781 1d2f f7fa c432 Uo.Z4..PW../...2 0x0020: 00a3 3c4c 3a47 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 83cd 07d0 6b06 008a 58f5 0ec3 E..P....k...X... 0x0010: 556f 065a d2bb 0050 8dfd c165 bb0b a32a Uo.Z...P...e...* 0x0020: 00a3 3c4c 92ff 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 d1fd 07d0 6b06 2baa 580b 965c E..P....k.+.X..\ 0x0010: 556f 065a e71e 0050 e25e 8520 c359 8303 Uo.Z...P.^...Y.. 0x0020: 00a3 3c4c f7a9 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 c27d 07d0 6a06 e1d1 58b9 f006 E..P.}..j...X... 0x0010: 556f 065a e8ef 0050 add8 be7c cbbe e52b Uo.Z...P...|...+ 0x0020: 00a3 3c4c 2c1d 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 0dce 07d0 6a06 9f51 588f e760 E..P....j..QX..` 0x0010: 556f 065a 5d4e 0050 5bba 1d70 05b4 1a6a Uo.Z]N.P[..p...j 0x0020: 00a3 3c4c 4486 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 d6a8 07d0 6a06 da6e 587c e37b E..P....j..nX|.{ 0x0010: 556f 065a 0d3f 0050 e7e0 6009 bbcf 9f7c Uo.Z.?.P..`....| 0x0020: 00a3 3c4c 8e9f 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 b6a2 07d0 6a06 ef62 589a ee6f E..P....j..bX..o 0x0010: 556f 065a 47ca 0050 0285 7256 083b e16d Uo.ZG..P..rV.;.m 0x0020: 00a3 3c4c 8db4 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 ecd1 07d0 6b06 9b8c 5822 0b8f E..P....k...X".. 0x0010: 556f 065a 42fb 0050 1c9d 8278 7464 d231 Uo.ZB..P...xtd.1 0x0020: 00a3 3c4c eeb4 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 ae8f 07d0 6b06 0b67 5870 d9a8 E..P....k..gXp.. 0x0010: 556f 065a a70f 0050 1b8e 0229 1488 e70d Uo.Z...P...).... 0x0020: 00a3 3c4c 8897 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 377c 07d0 6b06 25d7 587f 363d E..P7|..k.%.X.6= 0x0010: 556f 065a 045b 0050 dac0 9a16 e17a 1a58 Uo.Z.[.P.....z.X 0x0020: 00a3 3c4c 774b 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 00fc 07d0 6c06 1ca9 58b2 74b8 E..P....l...X.t. 0x0010: 556f 065a ab8a 0050 5b20 780a 2fa6 c602 Uo.Z...P[.x./... 0x0020: 00a3 3c4c 3944 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 4251 07d0 6a06 2beb 58df 25f4 E..PBQ..j.+.X.%. 0x0010: 556f 065a cf61 0050 98a7 6d78 f98f 5a66 Uo.Z.a.P..mx..Zf 0x0020: 00a3 3c4c d2c1 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 f18e 07d0 6b06 91c1 58c2 0ffd E..P....k...X... 0x0010: 556f 065a a30a 0050 d9ee 2f5a 4c49 4e26 Uo.Z...P../ZLIN& 0x0020: 00a3 3c4c cb8a 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 2b75 07d0 6a06 b64e 581e b32d E..P+u..j..NX..- 0x0010: 556f 065a ca99 0050 e4c1 d13e 3b1e b013 Uo.Z...P...>;... 0x0020: 00a3 3c4c 03f5 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 d9a7 07d0 6a06 b07c 5874 0a77 E..P....j..|Xt.w 0x0010: 556f 065a 424d 0050 eca9 4547 e8b6 8051 Uo.ZBM.P..EG...Q 0x0020: 00a3 3c4c 3adb 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 00b2 07d0 6c06 ce48 5817 c3fd E..P....l..HX... 0x0010: 556f 065a 165c 0050 a490 136d b9b3 b743 Uo.Z.\.P...m...C 0x0020: 00a3 3c4c 1fa7 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 b102 07d0 6c06 8484 58b6 5cd2 E..P....l...X.\. 0x0010: 556f 065a 642e 0050 66cc a93a 423a 4a0a Uo.Zd..Pf..:B:J. 0x0020: 00a3 3c4c c50a 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 f4cd 07d0 6b06 d03f 5872 ce8f E..P....k..?Xr.. 0x0010: 556f 065a 3e33 0050 606b fc5a 5cf2 6404 Uo.Z>3.P`k.Z\.d. 0x0020: 00a3 3c4c f81a 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 5417 07d0 6b06 97b3 5894 a7b0 E..PT...k...X... 0x0010: 556f 065a 36e1 0050 f978 3701 81a6 5717 Uo.Z6..P.x7...W. 0x0020: 00a3 3c4c 3aaf 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 6ea1 07d0 6b06 26dc 58c9 fdc8 E..Pn...k.&.X... 0x0010: 556f 065a 6f8b 0050 feac 646d 8983 c621 Uo.Zo..P..dm...! 0x0020: 00a3 3c4c 0230 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 a7c6 07d0 6b06 3a28 5870 b1b0 E..P....k.:(Xp.. 0x0010: 556f 065a d8db 0050 7ba3 2d3d 444a ed1e Uo.Z...P{.-=DJ.. 0x0020: 00a3 3c4c bdc6 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 4d90 07d0 6b06 b723 5803 8f58 E..PM...k..#X..X 0x0010: 556f 065a f656 0050 ae2c 5d56 f992 b86b Uo.Z.V.P.,]V...k 0x0020: 00a3 3c4c dfd8 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 b65f 07d0 6b06 6971 5855 73e9 E..P._..k.iqXUs. 0x0010: 556f 065a b1b2 0050 0db2 523a db61 fa7c Uo.Z...P..R:.a.| 0x0020: 00a3 3c4c c750 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 0a9c 07d0 6b06 2e1f 58b5 5a9f E..P....k...X.Z. 0x0010: 556f 065a d93d 0050 89c2 7058 84d9 6175 Uo.Z.=.P..pX..au 0x0020: 00a3 3c4c 0e11 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 4e89 07d0 6a06 6294 58d6 e31b E..PN...j.b.X... 0x0010: 556f 065a f87d 0050 1d82 1915 7ab0 5426 Uo.Z.}.P....z.T& 0x0020: 00a3 3c4c 412f 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 7496 07d0 6c06 8b52 58a1 9285 E..Pt...l..RX... 0x0010: 556f 065a 8059 0050 dcf1 9070 cfb6 6f0e Uo.Z.Y.P...p..o. 0x0020: 00a3 3c4c 6365 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 0582 07d0 6b06 2514 5863 6916 E..P....k.%.Xci. 0x0010: 556f 065a 4ca3 0050 01ed 8803 2e87 2b30 Uo.ZL..P......+0 0x0020: 00a3 3c4c 8948 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 fc82 07d0 6b06 dc4d 58b5 ba89 E..P....k..MX... 0x0010: 556f 065a b698 0050 683f d713 9229 1102 Uo.Z...Ph?...).. 0x0020: 00a3 3c4c ceb6 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 1734 07d0 6b06 9ece 58c1 dd4b E..P.4..k...X..K 0x0010: 556f 065a 13e9 0050 4c15 835a 2a16 e464 Uo.Z...PL..Z*..d 0x0020: 00a3 3c4c 532c 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 a707 07d0 6a06 20d8 581f cd10 E..P....j...X... 0x0010: 556f 065a 6836 0050 c396 f16d 7a2d 8659 Uo.Zh6.P...mz-.Y 0x0020: 00a3 3c4c 381b 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 0a02 07d0 6c06 e5bc 5880 a2d0 E..P....l...X... 0x0010: 556f 065a 3a42 0050 54c9 2318 8ca0 8e3a Uo.Z:B.PT.#....: 0x0020: 00a3 3c4c b2bd 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 fa1e 07d0 6b06 d1bd 585e c7d4 E..P....k...X^.. 0x0010: 556f 065a 62c2 0050 9675 6301 3912 246e Uo.Zb..P.uc.9.$n 0x0020: 00a3 3c4c a120 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 6e39 07d0 6b06 1811 5895 0d30 E..Pn9..k...X..0 0x0010: 556f 065a 0b88 0050 cfb0 636e c815 5b2d Uo.Z...P..cn..[- 0x0020: 00a3 3c4c b35d 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 f4d1 07d0 6c06 08db 5884 94de E..P....l...X... 0x0010: 556f 065a b962 0050 8a46 8e4b bd59 1b28 Uo.Z.b.P.F.K.Y.( 0x0020: 00a3 3c4c e333 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 809c 07d0 6b06 755a 5874 9da4 E..P....k.uZXt.. 0x0010: 556f 065a ae52 0050 814b 0d1c 7cec 5a43 Uo.Z.R.P.K..|.ZC 0x0020: 00a3 3c4c 710a 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 d268 07d0 6b06 1257 584f af00 E..P.h..k..WXO.. 0x0010: 556f 065a eab6 0050 823f 1e38 a8ac 8176 Uo.Z...P.?.8...v 0x0020: 00a3 3c4c be6b 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 c8a4 07d0 6a06 390f 5895 92c6 E..P....j.9.X... 0x0010: 556f 065a d7f7 0050 3af8 c61a eefe 0a20 Uo.Z...P:....... 0x0020: 00a3 3c4c bd87 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 134d 07d0 6b06 92b7 58ae ed5c E..P.M..k...X..\ 0x0010: 556f 065a 66f0 0050 33f3 6479 d742 1202 Uo.Zf..P3.dy.B.. 0x0020: 00a3 3c4c 4c60 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 eb70 07d0 6a06 6101 58c7 47d6 E..P.p..j.a.X.G. 0x0010: 556f 065a 30e2 0050 f82e bd2f 35c4 ce09 Uo.Z0..P.../5... 0x0020: 00a3 3c4c f060 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 97db 07d0 6c06 bf7f 58f2 3ac2 E..P....l...X.:. 0x0010: 556f 065a f21e 0050 de5b da74 ac9b d35e Uo.Z...P.[.t...^ 0x0020: 00a3 3c4c bc6e 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 cbde 07d0 6a06 d940 588e ef61 E..P....j..@X..a 0x0010: 556f 065a 94f6 0050 4d8d ec1e c7f6 da39 Uo.Z...PM......9 0x0020: 00a3 3c4c c249 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 0775 07d0 6b06 ea4f 5815 a235 E..P.u..k..OX..5 0x0010: 556f 065a 88d9 0050 7fc7 ef14 e4e4 ba60 Uo.Z...P.......` 0x0020: 00a3 3c4c e9c6 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 104a 07d0 6a06 93b7 58b4 f059 E..P.J..j...X..Y 0x0010: 556f 065a 9ea5 0050 20a4 e660 09bf a035 Uo.Z...P...`...5 0x0020: 00a3 3c4c e25f 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 6aa6 07d0 6a06 16b0 5886 1333 E..Pj...j...X..3 0x0010: 556f 065a 1d9c 0050 120f 6834 bc87 a828 Uo.Z...P..h4...( 0x0020: 00a3 3c4c 12c4 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 f987 07d0 6c06 e246 58b5 b68b E..P....l..FX... 0x0010: 556f 065a 5b86 0050 25b4 cd0f a3af 4e4f Uo.Z[..P%.....NO 0x0020: 00a3 3c4c 2b83 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 2aeb 07d0 6b06 4f5c 584d 197b E..P*...k.O\XM.{ 0x0010: 556f 065a 1313 0050 a206 3465 e633 6b32 Uo.Z...P..4e.3k2 0x0020: 00a3 3c4c ce5f 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 f99e 07d0 6c06 49c6 5838 4f72 E..P....l.I.X8Or 0x0010: 556f 065a 9439 0050 85d1 d737 c41b 6d0b Uo.Z.9.P...7..m. 0x0020: 00a3 3c4c b0f8 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 505c 07d0 6a06 d445 58a6 6fc7 E..PP\..j..EX.o. 0x0010: 556f 065a 2a29 0050 a38e 6656 f651 ff1c Uo.Z*).P..fV.Q.. 0x0020: 00a3 3c4c 8922 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 87ff 07d0 6a06 3de4 589a ce91 E..P....j.=.X... 0x0010: 556f 065a 1988 0050 057c a246 0dd1 cb66 Uo.Z...P.|.F...f 0x0020: 00a3 3c4c b95e 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 7ea6 07d0 6c06 3988 58d8 da08 E..P~...l.9.X... 0x0010: 556f 065a 3df9 0050 6d08 3c6f 9a4d 667d Uo.Z=..Pm. x.x.x.x: tcp 0x0000: 4500 0050 186b 07d0 6a06 45e7 5849 3674 E..P.k..j.E.XI6t 0x0010: 556f 065a cacd 0050 69b6 8742 6169 3326 Uo.Z...Pi..Bai3& 0x0020: 00a3 3c4c 9bf9 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 9873 07d0 6b06 8732 587b 73ee E..P.s..k..2X{s. 0x0010: 556f 065a 28e4 0050 34d7 3d26 d0db cb0f Uo.Z(..P4.=&.... 0x0020: 00a3 3c4c 77d6 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 365a 07d0 6a06 47e2 586c 1667 E..P6Z..j.G.Xl.g 0x0010: 556f 065a b4ed 0050 d34c 5341 a811 b40c Uo.Z...P.LSA.... 0x0020: 00a3 3c4c d49f 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 ee15 07d0 6b06 cdfd 584a d7b1 E..P....k...XJ.. 0x0010: 556f 065a 1980 0050 13e2 7f7a 3dae df7f Uo.Z...P...z=... 0x0020: 00a3 3c4c 8106 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 8321 07d0 6c06 73a5 58f4 9b54 E..P.!..l.s.X..T 0x0010: 556f 065a 9e13 0050 2e73 6715 e19d 2634 Uo.Z...P.sg...&4 0x0020: 00a3 3c4c 4b56 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 fe36 07d0 6b06 7537 58e9 1fb8 E..P.6..k.u7X... 0x0010: 556f 065a 8973 0050 8324 a146 0d7a b221 Uo.Z.s.P.$.F.z.! 0x0020: 00a3 3c4c 94f1 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 f748 07d0 6b06 e38f 58c5 b871 E..P.H..k...X..q 0x0010: 556f 065a 5f6a 0050 2bb3 d746 0ff6 d567 Uo.Z_j.P+..F...g 0x0020: 00a3 3c4c 2214 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 2e6e 07d0 6b06 4fb8 5867 1582 E..P.n..k.O.Xg.. 0x0010: 556f 065a 04b8 0050 14c0 d608 8442 2c2f Uo.Z...P.....B,/ 0x0020: 00a3 3c4c 6d31 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 85ee 07d0 6b06 7111 5819 9cf6 E..P....k.q.X... 0x0010: 556f 065a e61f 0050 54a3 2345 33e4 e01f Uo.Z...PT.#E3... 0x0020: 00a3 3c4c 13f1 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 d8ee 07d0 6c06 5db0 5838 5c38 E..P....l.].X8\8 0x0010: 556f 065a 21d9 0050 15fe f63e 21a7 681a Uo.Z!..P...>!.h. 0x0020: 00a3 3c4c 0ec5 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 9f11 07d0 6b06 a25d 5828 5278 E..P....k..]X(Rx 0x0010: 556f 065a 3393 0050 c882 806d 7553 f05f Uo.Z3..P...muS._ 0x0020: 00a3 3c4c ee35 0000 8807 a83a f215 b40d .. x.x.x.x: tcp 0x0000: 4500 0050 50dc 07d0 6a06 3656 5899 0d44 E..PP...j.6VX..D 0x0010: 556f 065a fe8c 0050 db1e 057f 5e5c 2075 Uo.Z...P....^\.u 0x0020: 00a3 3c4c b733 0000 8807 a83a f215 b40d .. 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 3B09E1065674 for ; Wed, 21 Mar 2012 19:03:13 +0000 (UTC) (envelope-from freebsd@mikej.com) Received: from remote.confluenttech.com (remote.confluenttech.com [69.55.228.170]) by mx1.freebsd.org (Postfix) with ESMTP id 160608FC0C for ; Wed, 21 Mar 2012 19:03:12 +0000 (UTC) Received: from firewall.mikej.com (99-89-65-18.uvs.lsvlky.sbcglobal.net [99.89.65.18]) by remote.confluenttech.com (8.14.3/8.14.3) with ESMTP id q2LJ2u0W044792; Wed, 21 Mar 2012 12:02:57 -0700 (PDT) (envelope-from freebsd@mikej.com) Received: from firewall.mikej.com (localhost [127.0.0.1]) by firewall.mikej.com (8.14.5/8.13.3) with ESMTP id q2LJ2o1K083163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2012 15:02:55 -0400 (EDT) (envelope-from freebsd@mikej.com) Received: (from www@localhost) by firewall.mikej.com (8.14.5/8.13.4/Submit) id q2LJ2mAc083158; Wed, 21 Mar 2012 15:02:48 -0400 (EDT) (envelope-from freebsd@mikej.com) X-Authentication-Warning: firewall.mikej.com: www set sender to freebsd@mikej.com using -f To: Gustau Perez Querol , MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 21 Mar 2012 15:02:48 -0400 From: jammin2night Mail-Reply-To: In-Reply-To: <4e8108fbc66bbfe24a18d743497cadbd@webmail.entel.upc.edu> References: <51f939ac5fb636ae90ba1b0fd628e40b@mail.mikej.com> <4F69B540.7070706@icritical.com> <4e8108fbc66bbfe24a18d743497cadbd@webmail.entel.upc.edu> Message-ID: <440afe1d425e1718904aebfe9e046ba9@mail.mikej.com> X-Sender: freebsd@mikej.com User-Agent: Roundcube Webmail/0.6-beta Cc: Subject: Re: Cloning VLAN interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@mikej.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:03:13 -0000 On 21.03.2012 09:21, Gustau Perez Querol wrote: > On Wed, 21 Mar 2012 11:02:24 +0000, Matt Burke wrote: >> On 03/20/12 14:54, Gustau Perez Querol wrote: >>> VBoxManage modifyvm "FreeBSD virtual machine" --nic1 bridge >>> --nictype >>> bridge virtio --bridgeadapter vlan10 >> >> On my machines running virtualbox-ose-4.0.14, VBoxManage won't >> accept vlan >> interfaces either - I need to kill the GUI then edit the config >> files to >> change the physical interface to vlanN. > > Mmm, I first tried the 4.1.51r40008 (the devel one). Now I'm > running 4.1.X (from redports) and the VBoxManage accepts an vlan > interface as a bridged interface. > >> >> Also, when altering any other setting by the GUI, the process needs >> repeating. >> > > That is correct, I have just checked that behavior and it also > happens to me. I also noticed that the vbox GUI gets confused only if > you go the properties of the machine using a bridged vlan interface. > If you don't go to the properties of the virtual machine, you will > see > in the panel on the right side that the virtual interfaces remain > bridged to your real vlan interfaces. > > It would appear I've been lucky, as I'm running vbox in a headless > machine so I have always used the TUI (which doesn't get confused > about using vlan interfaces). > > If you succeed with ng, please let us know, I'm interested in > netgraph. If you don't, at least you know you can do it by using the > VBoxManage tool... > > Gustau > _______________________________________________ > 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" I was successful in creating the netgraph interface with the help of rozhuk.im@gmail.com like: #!/usr/local/bin/bash ngctl shutdown re0:lower ngctl shutdown re0:upper ngctl mkpeer re0: hub lower lower ngctl name re0:lower re0-hub ngctl connect re0: re0-hub: upper upper ngctl mkpeer re0-hub: vlan downstream downstream ngctl name re0-hub:downstream re0-vlan ngctl mkpeer re0-vlan: eiface vlan10 ether ngctl msg re0-vlan: addfilter '{ vlan=10 hook="vlan10" }' ifconfig ngeth0 up Using tcpdump on ngeth0 I could see traffic that mirrored the traffic of VLAN 10, but when traffic was generated in a VM, specifically I looked at DHCP traffic I could see the DHCP requests in the VM and on ngeth0, and I could see the DHCP offers back to the VM's MAC address on ngeth0, but I DID NOT see the traffic on the VM's ethernet port. In my case I tested with FreeBSD-9.0-RELASE AMD64 in the VM. I hope to test the VBoxManage command line soon. --mikej From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 01:20: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 5A97B106566C for ; Thu, 22 Mar 2012 01:20:52 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 3CFFE8FC08 for ; Thu, 22 Mar 2012 01:20:52 +0000 (UTC) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from cswiger1.apple.com (unknown [17.209.4.71]) by asmtp026.mac.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M190009HFM8TP50@asmtp026.mac.com> for freebsd-net@freebsd.org; Wed, 21 Mar 2012 17:20:33 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-03-21_10:2012-03-21, 2012-03-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1203210284 From: Chuck Swiger In-reply-to: <3807CE6F3BF4B04EB897F4EBF2D258CE5C064A80@yuhanna.magnetdigital.local> Date: Wed, 21 Mar 2012 17:20:32 -0700 Content-transfer-encoding: quoted-printable Message-id: <2805EAC2-BC15-4BC8-B85B-0908FCF255C5@mac.com> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C064A80@yuhanna.magnetdigital.local> To: =?iso-8859-1?Q?Seyit_=D6zg=FCr?= X-Mailer: Apple Mail (2.1084) Cc: "freebsd-net@freebsd.org" Subject: Re: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 01:20:52 -0000 On Mar 21, 2012, at 7:15 AM, Seyit =D6zg=FCr wrote: > Hello chris, I'm Chuck, but no matter. > Here i get tcpdump with X param..=20 >=20 > First look input errors.. its about 60 mbit/sec and much more packets = can't > process >=20 > packets errs idrops bytes packets errs bytes colls > 36356 42777 0 7747642 243 0 263462 0 > 36732 41709 0 7681242 240 0 359432 0 [ ... ] 60 mbit/s of SYNs is a pretty significant DoS attack. You should be = involving your ISP to filter the source IPs before they hit your pipe, = and probably pull in the police and/or national CERT organization. > Then tcpdump with X param, also i attach txt file in mail.. >=20 > 16:02:53.954863 IP 88.133.15.78 > x.x.x.x: tcp > 0x0000: 4500 0050 10ba 07d0 6b06 7382 5885 0f4e = E..P....k.s.X..N > 0x0010: 556f 065a f386 0050 45c4 8c77 9592 0241 = Uo.Z...PE..w...A > 0x0020: 00a3 3c4c b5a3 0000 8807 a83a f215 b40d = .. 0x0030: 0006 acb5 0038 8f76 afd7 3d00 0000 0000 = .....8.v..=3D..... > 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 = ................ =46rom inspection, that looks to be a normal TCP over IPv4 SYN packet = from client port 62342 to your port 80...I didn't validate the = checksums, though. (No real point in obscuring the destination IP = address, as it's in the packets you're showing.) Regards, --=20 -Chuck From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 09:31:55 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 7469B1065670 for ; Thu, 22 Mar 2012 09:31:55 +0000 (UTC) (envelope-from seyit.ozgur@istanbul.net) Received: from spamtrap1.istanbul.net (spamtrap1.istanbul.net [85.111.12.35]) by mx1.freebsd.org (Postfix) with ESMTP id B7EE38FC1A for ; Thu, 22 Mar 2012 09:31:54 +0000 (UTC) X-ASG-Debug-ID: 1332408706-0426b010a1b70e0001-QdxwpM Received: from GAMMA.magnetdigital.local (gamma.magnetdigital.local [192.168.131.244]) by spamtrap1.istanbul.net with ESMTP id YYvICZPngL9ElzQG; Thu, 22 Mar 2012 11:31:46 +0200 (EET) X-Barracuda-Envelope-From: seyit.ozgur@istanbul.net X-Barracuda-RBL-Trusted-Forwarder: 192.168.131.244 Received: from YUHANNA.magnetdigital.local ([fe80::1058:3088:f9b1:1346]) by GAMMA.magnetdigital.local ([fe80::3cca:d6ef:febb:fafb%17]) with mapi id 14.01.0218.012; Thu, 22 Mar 2012 11:30:54 +0200 From: =?iso-8859-9?Q?Seyit_=D6zg=FCr?= X-Barracuda-Apparent-Source-IP: fe80::1058:3088:f9b1:1346 To: Chuck Swiger Thread-Topic: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-ASG-Orig-Subj: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release Thread-Index: Ac0C5Fxpv2wbk7REQXGSXBWgiq7+JP//5aEA//bValCAEt3kAP//RObQ Date: Thu, 22 Mar 2012 09:30:53 +0000 Message-ID: <3807CE6F3BF4B04EB897F4EBF2D258CE5C0651A4@yuhanna.magnetdigital.local> References: <3807CE6F3BF4B04EB897F4EBF2D258CE5C05F221@yuhanna.magnetdigital.local> <38FA7BAB-AC2B-4515-85CF-27F77C3F4313@mac.com> <3807CE6F3BF4B04EB897F4EBF2D258CE5C064A80@yuhanna.magnetdigital.local> <2805EAC2-BC15-4BC8-B85B-0908FCF255C5@mac.com> In-Reply-To: <2805EAC2-BC15-4BC8-B85B-0908FCF255C5@mac.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.134.34] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0095_01CD081F.3D665F20" MIME-Version: 1.0 X-Barracuda-Connect: gamma.magnetdigital.local[192.168.131.244] X-Barracuda-Start-Time: 1332408706 X-Barracuda-URL: http://10.10.140.223:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.91904 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" Subject: RE: Malformed syn packet cause %100 cpu and interrupts FreeBSD 9.0 release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 09:31:55 -0000 ------=_NextPart_000_0095_01CD081F.3D665F20 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable I solve the problem myself. Thanks anyway Best regards. Seyit =D6zg=FCr Network Y=F6neticisi -----Original Message----- From: Chuck Swiger [mailto:cswiger@mac.com]=20 Sent: Thursday, March 22, 2012 2:21 AM To: Seyit =D6zg=FCr Cc: freebsd-net@freebsd.org Subject: Re: Malformed syn packet cause %100 cpu and interrupts FreeBSD = 9.0 release On Mar 21, 2012, at 7:15 AM, Seyit =D6zg=FCr wrote: > Hello chris, I'm Chuck, but no matter. > Here i get tcpdump with X param..=20 >=20 > First look input errors.. its about 60 mbit/sec and much more packets=20 > can't process >=20 > packets errs idrops bytes packets errs bytes colls > 36356 42777 0 7747642 243 0 263462 0 > 36732 41709 0 7681242 240 0 359432 0 [ ... ] 60 mbit/s of SYNs is a pretty significant DoS attack. You should be involving your ISP to filter the source IPs before they hit your pipe, = and probably pull in the police and/or national CERT organization. > Then tcpdump with X param, also i attach txt file in mail.. >=20 > 16:02:53.954863 IP 88.133.15.78 > x.x.x.x: tcp > 0x0000: 4500 0050 10ba 07d0 6b06 7382 5885 0f4e = E..P....k.s.X..N > 0x0010: 556f 065a f386 0050 45c4 8c77 9592 0241 = Uo.Z...PE..w...A > 0x0020: 00a3 3c4c b5a3 0000 8807 a83a f215 b40d = .. 0x0030: 0006 acb5 0038 8f76 afd7 3d00 0000 0000 = .....8.v..=3D..... > 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 = ................ >From inspection, that looks to be a normal TCP over IPv4 SYN packet from client port 62342 to your port 80...I didn't validate the checksums, = though. (No real point in obscuring the destination IP address, as it's in the packets you're showing.) Regards, -- -Chuck ------=_NextPart_000_0095_01CD081F.3D665F20-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 10:03:31 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 97479106566B for ; Thu, 22 Mar 2012 10:03:31 +0000 (UTC) (envelope-from Traiano.Welcome@mtnbusiness.co.za) Received: from smtprelay01.ops.mtnbusiness.co.za (smtprelay01.ops.mtnbusiness.co.za [41.181.93.235]) by mx1.freebsd.org (Postfix) with ESMTP id 9D8C28FC19 for ; Thu, 22 Mar 2012 10:03:30 +0000 (UTC) Received: from [196.30.97.135] (helo=CPT-EXCH01.int.mtnbusiness.net) by smtprelay01.ops.mtnbusiness.co.za with esmtp (ULTRA Special SMTP Internal Alpha) (envelope-from ) id 1SAerg-0007KL-84 for freebsd-net@freebsd.org; Thu, 22 Mar 2012 12:03:28 +0200 Received: from CPT-EXCH01.int.mtnbusiness.net ([196.30.97.135]) by CPT-EXCH01.int.mtnbusiness.net ([196.30.97.135]) with mapi id 14.01.0218.012; Thu, 22 Mar 2012 12:03:22 +0200 From: Traiano Welcome To: "freebsd-net@freebsd.org" Thread-Topic: FreeBSD: syslog-ng: I/O error occurred while writing; fd='xx', error='No buffer space available (yy)' Thread-Index: AQHNCBMDrRAwT2ab00myKBl/mmLfFA== Date: Thu, 22 Mar 2012 10:03:21 +0000 Message-ID: Accept-Language: en-US, en-ZA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [196.30.72.139] Content-Type: text/plain; charset="us-ascii" Content-ID: <81843D020080AF498B1D4D690084456D@int.mtnbusiness.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: FreeBSD: syslog-ng: I/O error occurred while writing; fd='xx', error='No buffer space available (yy)' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 10:03:31 -0000 Hi List I've been seeing the following in the messages log of my freebsd syslog server for quite some time now: --- Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while writing; fd=3D'12', error=3D'No buffer space available (55)' Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; time_reopen=3D'60' Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while writing; fd=3D'13', error=3D'No buffer space available (55)' Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; time_reopen=3D'60' --- These happen at a frequency of about 7 per minute on average. See attached trend graphs for an idea of the volume of traffic we're doing, as well as the memory and cpu utilisation trends on this server during this period. As can be seen from the graphs, load does not seem to be the issue. Occasionally during the week, the system freezes and requires a reboot, I think it's related to the above message, though I'm not sure. My question is: What does this error mean, and how can I resolve it? I have tried to frame this as an operating system kernel resource issue, and experimented with increasing the freebsd kernel sysctls for UDP performance: --- [root@syslog2 /var/log]# sysctl kern.ipc.nmbclusters=3D102400 kern.ipc.nmbclusters: 25600 -> 102400 [root@syslog2 /var/log]# sysctl kern.ipc.maxsockbuf=3D201326592 kern.ipc.maxsockbuf: 100663296 -> 201326592 [root@syslog2 /var/log]# sysctl net.inet.udp.recvspace=3D33554432 net.inet.udp.recvspace: 16777216 -> 33554432 --- This has reduced the frequency of the errors a little, but in general the problem still remains. Syslog version: -- [root@syslog2]# syslog-ng -V syslog-ng 2.0.10 -- FreeBSD version: -- FreeBSD 7.2-STABLE #0 -- Any help would be much appreciated! Traiano From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 10:07:43 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 BC7A5106566C for ; Thu, 22 Mar 2012 10:07:43 +0000 (UTC) (envelope-from Traiano.Welcome@mtnbusiness.co.za) Received: from smtprelay01.ops.mtnbusiness.co.za (smtprelay01.ops.mtnbusiness.co.za [41.181.93.235]) by mx1.freebsd.org (Postfix) with ESMTP id 40C7A8FC0C for ; Thu, 22 Mar 2012 10:07:37 +0000 (UTC) Received: from [196.30.97.135] (helo=CPT-EXCH01.int.mtnbusiness.net) by smtprelay01.ops.mtnbusiness.co.za with esmtp (ULTRA Special SMTP Internal Alpha) (envelope-from ) id 1SAevf-0007TP-KI for freebsd-net@freebsd.org; Thu, 22 Mar 2012 12:07:35 +0200 Received: from CPT-EXCH01.int.mtnbusiness.net ([196.30.97.135]) by CPT-EXCH01.int.mtnbusiness.net ([196.30.97.135]) with mapi id 14.01.0218.012; Thu, 22 Mar 2012 12:07:29 +0200 From: Traiano Welcome To: Traiano Welcome , "freebsd-net@freebsd.org" Thread-Topic: FreeBSD: syslog-ng: I/O error occurred while writing; fd='xx', error='No buffer space available (yy)' Thread-Index: AQHNCBMDrRAwT2ab00myKBl/mmLfFJZ2FwWA Date: Thu, 22 Mar 2012 10:07:28 +0000 Message-ID: In-Reply-To: Accept-Language: en-US, en-ZA Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [196.30.72.139] Content-Type: multipart/mixed; boundary="_004_CB90C645DD68traianowelcomemtnbusinesscoza_" MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: FreeBSD: syslog-ng: I/O error occurred while writing; fd='xx', error='No buffer space available (yy)' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 10:07:43 -0000 --_004_CB90C645DD68traianowelcomemtnbusinesscoza_ Content-Type: text/plain; charset="us-ascii" Content-ID: <38111E9CC6DD97428C284D5ED8E28AE1@int.mtnbusiness.net> Content-Transfer-Encoding: quoted-printable Performance graphs that were supposed to be attached in the last mail :p On 22/03/2012 12:03, "Traiano Welcome" wrote: >Hi List > >I've been seeing the following in the messages log of my freebsd syslog >server for quite some time now: > >--- >Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while >writing; fd=3D'12', error=3D'No buffer space available (55)' >Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; >time_reopen=3D'60' >Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while >writing; fd=3D'13', error=3D'No buffer space available (55)' >Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; >time_reopen=3D'60' >--- > >These happen at a frequency of about 7 per minute on average. See attached >trend graphs for an idea of the volume of traffic we're doing, as well as >the memory and cpu utilisation trends on this server during this period. >As can be seen from the graphs, load does not seem to be the issue. >Occasionally during the week, the system freezes and requires a reboot, I >think it's related to the above message, though I'm not sure. > >My question is: What does this error mean, and how can I resolve it? > >I have tried to frame this as an operating system kernel resource issue, >and experimented with increasing the freebsd kernel sysctls for UDP >performance: > >--- >[root@syslog2 /var/log]# >sysctl kern.ipc.nmbclusters=3D102400 >kern.ipc.nmbclusters: 25600 -> 102400 > >[root@syslog2 /var/log]# >sysctl kern.ipc.maxsockbuf=3D201326592 >kern.ipc.maxsockbuf: 100663296 -> 201326592 > >[root@syslog2 /var/log]# >sysctl net.inet.udp.recvspace=3D33554432 >net.inet.udp.recvspace: 16777216 -> 33554432 >--- > >This has reduced the frequency of the errors a little, but in general the >problem still remains. > >Syslog version: > >-- >[root@syslog2]# syslog-ng -V >syslog-ng 2.0.10 > >-- > >FreeBSD version: > >-- >FreeBSD 7.2-STABLE #0 >-- > >Any help would be much appreciated! >Traiano > > >_______________________________________________ >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" --_004_CB90C645DD68traianowelcomemtnbusinesscoza_-- From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 11:09:50 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 7B975106566C for ; Thu, 22 Mar 2012 11:09:50 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id 393C18FC0C for ; Thu, 22 Mar 2012 11:09:49 +0000 (UTC) Received: from [172.16.11.44] (unknown [91.208.177.153]) (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 DCAEE2285C; Thu, 22 Mar 2012 10:59:51 +0000 (UTC) Message-ID: <4F6B061F.9050403@rewt.org.uk> Date: Thu, 22 Mar 2012 10:59:43 +0000 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> In-Reply-To: <20120319214744.GC7518@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: Thu, 22 Mar 2012 11:09:50 -0000 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 From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 12:40:15 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 6AA50106566B for ; Thu, 22 Mar 2012 12:40:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5545C8FC19 for ; Thu, 22 Mar 2012 12:40:15 +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 q2MCeFmG043073 for ; Thu, 22 Mar 2012 12:40:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2MCeFe2043072; Thu, 22 Mar 2012 12:40:15 GMT (envelope-from gnats) Date: Thu, 22 Mar 2012 12:40:15 GMT Message-Id: <201203221240.q2MCeFe2043072@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: kern/166255: [net] [patch] It should be possible to disable "promiscuous mode enabled" messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 12:40:15 -0000 The following reply was made to PR kern/166255; it has been noted by GNATS. From: Gleb Smirnoff To: Eugene Grosbein Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: kern/166255: [net] [patch] It should be possible to disable "promiscuous mode enabled" messages Date: Thu, 22 Mar 2012 16:31:09 +0400 On Tue, Mar 20, 2012 at 03:46:31AM +0700, Eugene Grosbein wrote: E> >Fix: E> E> The following patch introduces new sysctl named E> net.link.log_promisc_mode_change with default value 1. E> One may change it to 0 to disable mentioned warnings. IMHO, it'll be better to provide not a boolean, but a unsigned integer that specifies the desired log level, first argument of log(9). LOG_DEBUG would work for those, who don't want to see such messages. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 14:09: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 0BC541065670 for ; Thu, 22 Mar 2012 14:09:26 +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 D1E4C8FC0A for ; Thu, 22 Mar 2012 14:09:25 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 87BE446B2C; Thu, 22 Mar 2012 10:09:25 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 14F9FB940; Thu, 22 Mar 2012 10:09:25 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Thu, 22 Mar 2012 08:16:57 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203220816.58217.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 22 Mar 2012 10:09:25 -0400 (EDT) Cc: Traiano Welcome Subject: Re: FreeBSD: syslog-ng: I/O error occurred while writing; fd='xx', error='No buffer space available (yy)' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:09:26 -0000 On Thursday, March 22, 2012 6:03:21 am Traiano Welcome wrote: > Hi List > > I've been seeing the following in the messages log of my freebsd syslog > server for quite some time now: > > --- > Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while > writing; fd='12', error='No buffer space available (55)' > Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; > time_reopen='60' > Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while > writing; fd='13', error='No buffer space available (55)' > Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; > time_reopen='60' > --- > > These happen at a frequency of about 7 per minute on average. See attached > trend graphs for an idea of the volume of traffic we're doing, as well as > the memory and cpu utilisation trends on this server during this period. > As can be seen from the graphs, load does not seem to be the issue. > Occasionally during the week, the system freezes and requires a reboot, I > think it's related to the above message, though I'm not sure. > > My question is: What does this error mean, and how can I resolve it? > > I have tried to frame this as an operating system kernel resource issue, > and experimented with increasing the freebsd kernel sysctls for UDP > performance: It means that the network driver has "filled" up with packets. Are you using igb(4)? We have to crank the number of descriptors assigned to igb to the max to workaround this at work (we get DNS timeouts during a simple boot otherwise). hw.igb.maxtxd is the tunable you would set. The max value you can set it to is 4096. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 15:00: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 32BF21065677; Thu, 22 Mar 2012 15:00:46 +0000 (UTC) (envelope-from Traiano.Welcome@mtnbusiness.co.za) Received: from smtprelay01.ops.mtnbusiness.co.za (smtprelay01.ops.mtnbusiness.co.za [41.181.93.235]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1518FC08; Thu, 22 Mar 2012 15:00:44 +0000 (UTC) Received: from [196.30.97.135] (helo=CPT-EXCH01.int.mtnbusiness.net) by smtprelay01.ops.mtnbusiness.co.za with esmtp (ULTRA Special SMTP Internal Alpha) (envelope-from ) id 1SAjVK-000Ec0-AG; Thu, 22 Mar 2012 17:00:42 +0200 Received: from CPT-EXCH01.int.mtnbusiness.net ([196.30.97.135]) by CPT-EXCH01.int.mtnbusiness.net ([196.30.97.135]) with mapi id 14.01.0218.012; Thu, 22 Mar 2012 17:00:35 +0200 From: Traiano Welcome To: John Baldwin , "freebsd-net@freebsd.org" Thread-Topic: FreeBSD: syslog-ng: I/O error occurred while writing; fd='xx', error='No buffer space available (yy)' Thread-Index: AQHNCBMDrRAwT2ab00myKBl/mmLfFJZ2GayAgABPOoA= Date: Thu, 22 Mar 2012 15:00:35 +0000 Message-ID: In-Reply-To: <201203220816.58217.jhb@freebsd.org> Accept-Language: en-US, en-ZA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [196.30.72.139] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: Re: FreeBSD: syslog-ng: I/O error occurred while writing; fd='xx', error='No buffer space available (yy)' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:00:46 -0000 Hi John On 22/03/2012 14:16, "John Baldwin" wrote: >On Thursday, March 22, 2012 6:03:21 am Traiano Welcome wrote: >> Hi List >>=20 >> I've been seeing the following in the messages log of my freebsd syslog >> server for quite some time now: >>=20 >> --- >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while >> writing; fd=3D'12', error=3D'No buffer space available (55)' >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; >> time_reopen=3D'60' >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while >> writing; fd=3D'13', error=3D'No buffer space available (55)' >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; >> time_reopen=3D'60' >> --- >>=20 >> These happen at a frequency of about 7 per minute on average. See >>attached >> trend graphs for an idea of the volume of traffic we're doing, as well >>as >> the memory and cpu utilisation trends on this server during this period. >> As can be seen from the graphs, load does not seem to be the issue. >> Occasionally during the week, the system freezes and requires a reboot, >>I >> think it's related to the above message, though I'm not sure. >>=20 >> My question is: What does this error mean, and how can I resolve it? >>=20 >> I have tried to frame this as an operating system kernel resource issue, >> and experimented with increasing the freebsd kernel sysctls for UDP >> performance: > >It means that the network driver has "filled" up with packets. Are you >using=20 >igb(4)? We have to crank the number of descriptors assigned to igb to >the max=20 >to workaround this at work (we get DNS timeouts during a simple boot >otherwise). hw.igb.maxtxd is the tunable you would set. The max value >you=20 >can set it to is 4096. Thanks for the clue. It seems igb is indeed being used. However, I not that when I try to list this tunable, I don't get anything: --- [root@syslog2]# sysctl -a | grep igb [root@syslog2]# --- --- [root@syslog2 /boot]# sysctl hw.igb.maxtxd=3D4000 sysctl: unknown oid 'hw.igb.maxtxd' --- Is this due to the way igb is compiled into the kernel, or am I tuning in the wrong place :-) > >--=20 >John Baldwin From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 15:59: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 021C4106566B for ; Thu, 22 Mar 2012 15:59:53 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7682D8FC1A for ; Thu, 22 Mar 2012 15:59:52 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so1495231wgb.31 for ; Thu, 22 Mar 2012 08:59:44 -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=a6PR0qikftC9AWdGb5g/r9tulSVHsb6+B02g63IpylQ=; b=gWuOvVsChkyf0iF+OVRr45c1k9ukvrCyl84xxIaY2ofPpTSz8ppPYkmwOcQQq6yRIu YuQL9kH4R3kOdYjKDfgwKAEoN2oKnIMPChJYc9oyeYYCLp1EioYJgPGa3K9n3xHhubvF Uzj9AVx3H+mfovPRh9eTxReKURAXm1383AAUhokgRO7uUYwim9bvd1o1EISYvgFcYS/H uEl87kCDFqgpCI3KHRww5CLC6DC2tqfPLsIk0lt1Tq1vgH/e4T3An1pJNHn1W5nf026Q zvkaEklgKXL1GJpCcgM/eAVbeYSMEYQkHUdWn2VPI26sBpg0GPjMNg47asizAAShHB0W wYrA== MIME-Version: 1.0 Received: by 10.180.85.70 with SMTP id f6mr6383796wiz.5.1332431984752; Thu, 22 Mar 2012 08:59:44 -0700 (PDT) Received: by 10.223.110.138 with HTTP; Thu, 22 Mar 2012 08:59:44 -0700 (PDT) Date: Thu, 22 Mar 2012 16:59:44 +0100 Message-ID: From: Monthadar Al Jaberi To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: ifconfig meshforward command bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:59:54 -0000 Hi, I think this is a bug in ifconfig, sending val to kernel always results in zero. There are a couple of these, just want to hear from you guys if you think this is a bug too. --- a/sbin/ifconfig/ifieee80211.c +++ b/sbin/ifconfig/ifieee80211.c @@ -1879,13 +1879,19 @@ DECL_CMD_FUNC(set80211meshttl, val, d) static DECL_CMD_FUNC(set80211meshforward, val, d) { - set80211(s, IEEE80211_IOC_MESH_FWRD, atoi(val), 0, NULL); + set80211(s, IEEE80211_IOC_MESH_FWRD, d, 0, NULL); br, -- Monthadar Al Jaberi From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 18:27:59 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 EA287106564A for ; Thu, 22 Mar 2012 18:27:59 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5637A8FC15 for ; Thu, 22 Mar 2012 18:27:59 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so2723064bkc.13 for ; Thu, 22 Mar 2012 11:27:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id :x-gm-message-state; bh=/UEh39H1bHmy+HHNgE2BeSV2fDoORscZPtf0B5ffYfg=; b=B3gqUvNi6v1NA1RNnPzneH53KAqtm7d7xdTIRa4ivhuk4E595abmzM9ta3TByjofWa WPmd1o7tDVjpUJwcjIePb2lw0Np+5uKHwlL+UN00o6CklvT5rBRmjzjIkgaqELsKuydP QxJss9IGIV9WTDkWEvc80UgdC+K/PliItZcYci865yOHZySKF5wATY57fco4V+vOJ5+1 AxnuTFxGXwoaLtZlPBtl6Q4hJ2M+TiioShzt91zSyKfBgpD6YRAMtYdGUXY8zD+8jv5Y CDB0ieWZndzE7K1cUIEx8m+4gHlOKKKubGwM0bnJ2EjOhQ3+5sISO0+X0zZruED/My8j CWGw== Received: by 10.204.128.152 with SMTP id k24mr3313766bks.127.1332440878159; Thu, 22 Mar 2012 11:27:58 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-065-222-166.pools.arcor-ip.net. [88.65.222.166]) by mx.google.com with ESMTPS id jr13sm11470945bkb.14.2012.03.22.11.27.56 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 11:27:57 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-net@freebsd.org Date: Thu, 22 Mar 2012 19:28:16 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203221928.16271.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQm4Ns9WemXYbI1GAFoOfB6w5Ps0bUd77zC8b0ndZ+SG9ypTyda2p0/PkJ5UWWA46PMti7T1 Cc: Monthadar Al Jaberi Subject: Re: ifconfig meshforward command bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:28:00 -0000 On Thursday 22 March 2012 16:59:44 Monthadar Al Jaberi wrote: > Hi, > > I think this is a bug in ifconfig, sending val to kernel always > results in zero. There are a couple of these, just want to hear from > you guys if you think this is a bug too. > > --- a/sbin/ifconfig/ifieee80211.c > +++ b/sbin/ifconfig/ifieee80211.c > @@ -1879,13 +1879,19 @@ DECL_CMD_FUNC(set80211meshttl, val, d) > static > DECL_CMD_FUNC(set80211meshforward, val, d) > { > - set80211(s, IEEE80211_IOC_MESH_FWRD, atoi(val), 0, NULL); > + set80211(s, IEEE80211_IOC_MESH_FWRD, d, 0, NULL); Seems about right, those declared with DEF_CMD() should use d. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 18:56:28 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 D35C2106564A; Thu, 22 Mar 2012 18:56:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7865F8FC0A; Thu, 22 Mar 2012 18:56:28 +0000 (UTC) Received: by yhgm50 with SMTP id m50so2533753yhg.13 for ; Thu, 22 Mar 2012 11:56:22 -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=NjFdCPoipWiTNNVTB7BtFcpSKkIUHgVUcTI+C0adQNk=; b=aJR+AdStfUvkXAw99rPGoLvH9h5SiXziPyMLeQkvzUt4PBpiYr2U3CM4V1UpVZ5EqG 1F8c0S/JMKAZK/3ZGmoHF+80wA3GqDhFAQK/TJEJdFcfRPRM1L1/4xX5C1L2NC39F3H/ DMypm0IbYJtwfgu6oy4VLd0kebnHnStFhVzgWKS6HqOlGCDT9v4gOv/cuHbTrUBE87ZE v05cGfdM8FkalUq+zFzF+NQtMkpoU6D7edkQ1PMe7FjarwshIQeI/0dqvVEfe3ohqXlP CmR7jdaCXv0k4p7x6HRizRn1F2xM+a2cR4n46sYGXHMk75TvY4/J9G6lhn77EWFl07CK KLUg== MIME-Version: 1.0 Received: by 10.68.225.104 with SMTP id rj8mr22458015pbc.135.1332442581778; Thu, 22 Mar 2012 11:56:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Thu, 22 Mar 2012 11:56:21 -0700 (PDT) In-Reply-To: <201203221928.16271.bschmidt@freebsd.org> References: <201203221928.16271.bschmidt@freebsd.org> Date: Thu, 22 Mar 2012 11:56:21 -0700 X-Google-Sender-Auth: wSM240a9OXMvB6_BO0qGk_pUBPE Message-ID: From: Adrian Chadd To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: Monthadar Al Jaberi , freebsd-net@freebsd.org Subject: Re: ifconfig meshforward command bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:56:28 -0000 On 22 March 2012 11:28, Bernhard Schmidt wrote: > Seems about right, those declared with DEF_CMD() should use d. Shall I commit this? adrian From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 18:56:58 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 B24C91065676; Thu, 22 Mar 2012 18:56:58 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 56D968FC1A; Thu, 22 Mar 2012 18:56:58 +0000 (UTC) Received: by yenl9 with SMTP id l9so2519047yen.13 for ; Thu, 22 Mar 2012 11:56:57 -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=UCM+LQxXsVOume16vdjVOmlb8EZ5AYoGVLUwHXr4X88=; b=JiYkFvcvFGfcztcYz3GPVYOtafNugN6RVeGhTqyRjmWo/Cbj24fNLMpQOdfxnbCMvf 6mFRUQ+byfXl8bzz+X4PlgU95HHiSlI7VBhBsp+RaxNSj0H1/MuC0tel8pEYO/yPBiJb aU1tZcVVVVm2winPmzaOtKndHr8/OuIdQxWoJAWkRrUOa/AYogpQ4s4QXmjNBncuGvdj 8J1GZi3lpJPiIPCmW+GJUuIvedJomNXCII17tbYA/GKRXs43CL0a22h7YZA+IqOy8qBt 1rc7JoYdn7tyOgSzVCiPHv5W5diT0NHnVLIJ8sPdKhpFibCSZPdHXQBOn8kScOfSiIJT iP1g== MIME-Version: 1.0 Received: by 10.68.231.66 with SMTP id te2mr23024420pbc.42.1332442617360; Thu, 22 Mar 2012 11:56:57 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Thu, 22 Mar 2012 11:56:57 -0700 (PDT) In-Reply-To: References: <201203221928.16271.bschmidt@freebsd.org> Date: Thu, 22 Mar 2012 11:56:57 -0700 X-Google-Sender-Auth: mm9u3KWe8NHLpQYir0nFIzV2s9U Message-ID: From: Adrian Chadd To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: Monthadar Al Jaberi , freebsd-net@freebsd.org Subject: Re: ifconfig meshforward command bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 18:56:58 -0000 On 22 March 2012 11:56, Adrian Chadd wrote: > On 22 March 2012 11:28, Bernhard Schmidt wrote: > >> Seems about right, those declared with DEF_CMD() should use d. > > Shall I commit this? .. a lot of these mesh functions use DECL_CMD_FUNC(), should they all be using d? adrian From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 19:08:25 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 374A7106564A for ; Thu, 22 Mar 2012 19:08:25 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from hosted.mx.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id EFEE18FC14 for ; Thu, 22 Mar 2012 19:08:24 +0000 (UTC) Received: from [172.16.11.44] (unknown [91.208.177.153]) (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 D4D3E2285C; Thu, 22 Mar 2012 19:08:10 +0000 (UTC) Message-ID: <4F6B7892.6090805@rewt.org.uk> Date: Thu, 22 Mar 2012 19:08:02 +0000 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> In-Reply-To: <4F6B061F.9050403@rewt.org.uk> 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: Thu, 22 Mar 2012 19:08:25 -0000 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 occurs - the flags I used before did work (whether some didn't have any 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 Thu Mar 22 19:20:08 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 E48AD106567C for ; Thu, 22 Mar 2012 19:20:08 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5B1358FC19 for ; Thu, 22 Mar 2012 19:20:08 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so2777178bkc.13 for ; Thu, 22 Mar 2012 12:20:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id :x-gm-message-state; bh=62J4ZzYwPDgTV8Mpqzh7+QQflMa6RHgJtKEJ+6TPsp0=; b=AW6sCNnc0DK5Mcf1I3vsWRCy3tO8MZxOla23Ijd7rFew1PHSlgq9iCqeWU05WXjxj0 BXWBNbVuPfD7RkvFThQWQpgyl1bhrKILYu2av8nkOtfpVRObHeB4ST/cN62eLY1mhh4U 4cN412w5eaW7Fp6QwdT99miuxOawexRjDecrpLPnhyv91LwivznbkMzymvx/xwQUGiSJ U/QO6CZ9DUs9+2IZMsSjPv2rsob/NGD1SJXSNxGCAzcmERE1cKyzo+V3RUtxmW5ncf8s lkFBf3s6FAUBWFEGVhMsZW7Tw8T2kB4wZYlFJg2+u87lq4hmjG0xNAKdEdu/+cG2K2Hq 0Dvw== Received: by 10.204.145.81 with SMTP id c17mr3613655bkv.39.1332444007292; Thu, 22 Mar 2012 12:20:07 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-065-222-166.pools.arcor-ip.net. [88.65.222.166]) by mx.google.com with ESMTPS id r14sm11737681bkv.11.2012.03.22.12.20.06 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 12:20:06 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Adrian Chadd Date: Thu, 22 Mar 2012 20:20:25 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201203221928.16271.bschmidt@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203222020.25688.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQkx3vBuSII1XVPSmpGh6qyMYwTg8uoNP5TC37TB1rbfWxdhVD8jCBTB4TfmKgoP2kYargmR Cc: Monthadar Al Jaberi , freebsd-net@freebsd.org Subject: Re: ifconfig meshforward command bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 19:20:09 -0000 On Thursday 22 March 2012 19:56:21 Adrian Chadd wrote: > On 22 March 2012 11:28, Bernhard Schmidt wrote: > > > Seems about right, those declared with DEF_CMD() should use d. > > Shall I commit this? There are more of those which use d, someone should go over all of em. But otherwise, yes, that should be fixed. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 19:32: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 858311065673 for ; Thu, 22 Mar 2012 19:32:06 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 09EB48FC19 for ; Thu, 22 Mar 2012 19:32:05 +0000 (UTC) Received: by wern13 with SMTP id n13so2849235wer.13 for ; Thu, 22 Mar 2012 12:32:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id :x-gm-message-state; bh=g4cpy7nli1W+YdWHhzYGyPRbIg54XH5RxQI0Xpr7Cy8=; b=JZjGqOaPxCgKzonozQQVOEtB3pTy0c06EGR8FHlPbgdcm/a/ovUwJ7BvibfLHH5h3f XMk05l7hvdFmXrmyBOWzsuIpJ9R43q76G/bqU8xgFEX+poMcx4UgVbauXtDHChz2SMF0 VD/S4J1BUtK6mUYfeXsz5Jj1K/rI/wth+vh0JgzG2i+JmB1vdS+JnG9SsGzvSoFiosZC G7hmkpCuNvTExcykb1WbHQ1WqBhuTk05e9twk27p76LR3e0XRPk6lbNKWjVkET/wCh+u aW6Nh8ktuIdTxJzCcNQSSrYvqys0v+Nj7M5c2aucwDMXJbOf9cHKeYMoWNafKCoNo2DG Q7Og== Received: by 10.216.138.38 with SMTP id z38mr5333023wei.63.1332444724792; Thu, 22 Mar 2012 12:32:04 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-065-222-166.pools.arcor-ip.net. [88.65.222.166]) by mx.google.com with ESMTPS id fn2sm12553923wib.0.2012.03.22.12.32.01 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 12:32:04 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Adrian Chadd Date: Thu, 22 Mar 2012 20:32:20 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203222032.20699.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQk1JmqT6K5Kc8SUIaUD0MaHGqmBt8X7GjDcoGDsLp2ZsBcyzCCByDvsT4gyOk/QCz9ADvlv Cc: Monthadar Al Jaberi , freebsd-net@freebsd.org Subject: Re: ifconfig meshforward command bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 19:32:06 -0000 On Thursday 22 March 2012 19:56:57 Adrian Chadd wrote: > On 22 March 2012 11:56, Adrian Chadd wrote: > > On 22 March 2012 11:28, Bernhard Schmidt wrote: > > > >> Seems about right, those declared with DEF_CMD() should use d. > > > > Shall I commit this? > > .. a lot of these mesh functions use DECL_CMD_FUNC(), should they all > be using d? Take a look at the top of the file, just the once with DEF_CMD() where the parameter is included, those should use d. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Thu Mar 22 21:23:30 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 B1AF4106564A; Thu, 22 Mar 2012 21:23:30 +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 7D3198FC19; Thu, 22 Mar 2012 21:23:30 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so2232466pbc.13 for ; Thu, 22 Mar 2012 14:23:30 -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=ZpGdwaDGOYfviGHJC1uhu8RNDlSrDJkUFqWfiDPfOY0=; b=dQK2Rttbhmk4gjKSeaFQOa9rBFEclYUPMCvHk2l+YYrpHWK6KiRlBKoJnhJyJm1gsQ dqBcWlMjGFNBstqRLJ0dmkF8sC9ZgTb1raRj5hNLnxLDdDizz25kfvuXscAJw5eokm5i Wgta1BRmVYzNiaC40+hIe6bBzSTJSSoXouJZDVFsmJdmyoVFlPB4X1VZzQJXfQ5FLbXZ 2F3eNAZVoyv9aeF5zPXH8d1ulS6S1gw7J7RGfvLObXaAvWTzrMhaVkO8MqnU2gvgc+oK TQ4jK6LzAKpA6d7TvktUTGm7XHPLKQWhwAORFQ3LeFyIBgvOCIejzfLfLlkjimEhzXOp hKCw== MIME-Version: 1.0 Received: by 10.68.231.66 with SMTP id te2mr23925332pbc.42.1332451410301; Thu, 22 Mar 2012 14:23:30 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Thu, 22 Mar 2012 14:23:30 -0700 (PDT) In-Reply-To: <201203222032.20699.bschmidt@freebsd.org> References: <201203222032.20699.bschmidt@freebsd.org> Date: Thu, 22 Mar 2012 14:23:30 -0700 X-Google-Sender-Auth: VbtTmzpAO6B9dQpEcgBrbeRuBUs Message-ID: From: Adrian Chadd To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: Monthadar Al Jaberi , freebsd-net@freebsd.org Subject: Re: ifconfig meshforward command bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 21:23:30 -0000 I've fixed the one that Monthadar has submitted. Monthadar, would you mind reviewing the rest of the mesh commands and see which others need fixing? Adrian From owner-freebsd-net@FreeBSD.ORG Fri Mar 23 09:00: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 B9DFD1065677; Fri, 23 Mar 2012 09:00:09 +0000 (UTC) (envelope-from Traiano.Welcome@mtnbusiness.co.za) Received: from smtprelay01.ops.mtnbusiness.co.za (smtprelay01.ops.mtnbusiness.co.za [41.181.93.235]) by mx1.freebsd.org (Postfix) with ESMTP id 6BF978FC23; Fri, 23 Mar 2012 09:00:07 +0000 (UTC) Received: from [196.30.97.135] (helo=CPT-EXCH01.int.mtnbusiness.net) by smtprelay01.ops.mtnbusiness.co.za with esmtp (ULTRA Special SMTP Internal Alpha) (envelope-from ) id 1SB0Lt-0009vs-Vm; Fri, 23 Mar 2012 11:00:06 +0200 Received: from CPT-EXCH01.int.mtnbusiness.net ([196.30.97.135]) by CPT-EXCH01.int.mtnbusiness.net ([196.30.97.135]) with mapi id 14.01.0218.012; Fri, 23 Mar 2012 10:59:58 +0200 From: Traiano Welcome To: John Baldwin , "freebsd-net@freebsd.org" Thread-Topic: FreeBSD: syslog-ng: I/O error occurred while writing; fd='xx', error='No buffer space available (yy)' Thread-Index: AQHNCBMDrRAwT2ab00myKBl/mmLfFJZ2GayAgAF80wA= Date: Fri, 23 Mar 2012 08:59:58 +0000 Message-ID: In-Reply-To: <201203220816.58217.jhb@freebsd.org> Accept-Language: en-US, en-ZA Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [196.30.72.139] Content-Type: multipart/mixed; boundary="_002_CB9207D6DFEAtraianowelcomemtnbusinesscoza_" MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: FreeBSD: syslog-ng: I/O error occurred while writing; fd='xx', error='No buffer space available (yy)' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 09:00:09 -0000 --_002_CB9207D6DFEAtraianowelcomemtnbusinesscoza_ Content-Type: text/plain; charset="us-ascii" Content-ID: <5B62C4836E8E914BAFCDE4E83D3CC0CD@int.mtnbusiness.net> Content-Transfer-Encoding: quoted-printable Hi John On 22/03/2012 14:16, "John Baldwin" wrote: >On Thursday, March 22, 2012 6:03:21 am Traiano Welcome wrote: >> Hi List >>=20 >> I've been seeing the following in the messages log of my freebsd syslog >> server for quite some time now: >>=20 >> --- >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while >> writing; fd=3D'12', error=3D'No buffer space available (55)' >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; >> time_reopen=3D'60' >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while >> writing; fd=3D'13', error=3D'No buffer space available (55)' >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; >> time_reopen=3D'60' >> --- >>=20 >> These happen at a frequency of about 7 per minute on average. See >>attached >> trend graphs for an idea of the volume of traffic we're doing, as well >>as >> the memory and cpu utilisation trends on this server during this period. >> As can be seen from the graphs, load does not seem to be the issue. >> Occasionally during the week, the system freezes and requires a reboot, >>I >> think it's related to the above message, though I'm not sure. >>=20 >> My question is: What does this error mean, and how can I resolve it? >>=20 >> I have tried to frame this as an operating system kernel resource issue, >> and experimented with increasing the freebsd kernel sysctls for UDP >> performance: > >It means that the network driver has "filled" up with packets. Are you >using=20 >igb(4)? We have to crank the number of descriptors assigned to igb to >the max=20 >to workaround this at work (we get DNS timeouts during a simple boot >otherwise). hw.igb.maxtxd is the tunable you would set. The max value >you=20 >can set it to is 4096. This seems to be working so far. What I've noticed is that the system is using far less RAM than previously, and CPU utilisation is up to 100% of one core (see attached graph), load average is now 1, which I would guess means that the system is now processing a lot more syslog data now that "more packets are making it through the network driver". I'll keep monitoring over a 24 hour period though, to see how effective this is. > >--=20 >John Baldwin Many Thanks! Traiano > --_002_CB9207D6DFEAtraianowelcomemtnbusinesscoza_-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 23 09:11:09 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 A80AE106566B; Fri, 23 Mar 2012 09:11:09 +0000 (UTC) (envelope-from monthadar@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 CEB458FC14; Fri, 23 Mar 2012 09:11:08 +0000 (UTC) Received: by wern13 with SMTP id n13so3316063wer.13 for ; Fri, 23 Mar 2012 02:11:07 -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=9zhuI5P0wRBsh1g9bpAWfQvjrYcCse5PjCfTynTxgS8=; b=UgdMLVbYcTNG3lAo2DnRzQOWXZy20eUo3BZA2cZ5pNI1vNo7yOf071htfG3sUFlsey V3MYly+yORcR41UO6ZwvddMs26DkLE4Qrunn23pLGgfLwEXyDKMC/LGOB3joJvhF3y7x SC8b9J4pl6g+O2isS3Z8tWRq23MuRXkCLOj7Zk4EQKvnm1wGz0YavSjMJzkghofq1CpD d9oOy0A+j754sUu8Ld9NLjxq/lOACT5MlRJknOgy9Fz5vKQHSPw5e4GiwahJ9HkV5TFu UhjzyK6pb64h3Cn1lkzZKlYvjykS5DdH0IqQQJY2XUzwvAph3+/rEHlIRfcCF0XOms1y rUUw== MIME-Version: 1.0 Received: by 10.180.85.70 with SMTP id f6mr4766134wiz.5.1332493867449; Fri, 23 Mar 2012 02:11:07 -0700 (PDT) Received: by 10.223.110.138 with HTTP; Fri, 23 Mar 2012 02:11:07 -0700 (PDT) In-Reply-To: References: <201203222032.20699.bschmidt@freebsd.org> Date: Fri, 23 Mar 2012 10:11:07 +0100 Message-ID: From: Monthadar Al Jaberi To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Bernhard Schmidt Subject: Re: ifconfig meshforward command bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 09:11:09 -0000 On Thu, Mar 22, 2012 at 10:23 PM, Adrian Chadd wrote: > I've fixed the one that Monthadar has submitted. > > Monthadar, would you mind reviewing the rest of the mesh commands and > see which others need fixing? from what I can see the bug is for flags that we can either turn on or off. Another one I found, static DECL_CMD_FUNC(set80211meshpeering, val, d) { - set80211(s, IEEE80211_IOC_MESH_AP, atoi(val), 0, NULL); + set80211(s, IEEE80211_IOC_MESH_AP, d, 0, NULL); I took a quick look and think this is last one > > > Adrian thnx -- Monthadar Al Jaberi From owner-freebsd-net@FreeBSD.ORG Fri Mar 23 09:12: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 363081065670; Fri, 23 Mar 2012 09:12:47 +0000 (UTC) (envelope-from monthadar@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 6E3178FC0A; Fri, 23 Mar 2012 09:12:46 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so1425699wib.13 for ; Fri, 23 Mar 2012 02:12:45 -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=OJjrxuq+spN0DbkVofINAoM7BtIYvYbO59OPWGOMAcs=; b=Xas30E41qzioQQceCCZYAr4KG7IGaXJQFdHe3wcipiKHJtumn/wtaMhmo4C3PdCQHJ 8bXgZux1Esd4buZbjHsUn/4flB9ljl9bpQxHz5BHIStYwzs4EeqY16MlB4YbAjYNM0b5 AcD/zDsbb0sRG1SS5FClef5M7cuaRtagyQ0AB66ybjBrtTKw86e9u7NinHSKgI+46P5j cQvoVJX9VZzXTN0tq9raso8TTsQFKkzergoFNt0TmTH6Y5SpBN8MevK0H98p4vuLuitn G18mWypK5K8qnH5A37UQ5bRTB9WX4DqdUCgKwDrxLguhwf+HxAxmlPbFGBqnZCSppsoa ILvw== MIME-Version: 1.0 Received: by 10.216.133.72 with SMTP id p50mr6713752wei.78.1332493965287; Fri, 23 Mar 2012 02:12:45 -0700 (PDT) Received: by 10.223.110.138 with HTTP; Fri, 23 Mar 2012 02:12:45 -0700 (PDT) In-Reply-To: References: <201203221928.16271.bschmidt@freebsd.org> Date: Fri, 23 Mar 2012 10:12:45 +0100 Message-ID: From: Monthadar Al Jaberi To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Bernhard Schmidt Subject: Re: ifconfig meshforward command bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 09:12:47 -0000 On Thu, Mar 22, 2012 at 7:56 PM, Adrian Chadd wrote: > On 22 March 2012 11:56, Adrian Chadd wrote: >> On 22 March 2012 11:28, Bernhard Schmidt wrote: >> >>> Seems about right, those declared with DEF_CMD() should use d. >> >> Shall I commit this? > > .. a lot of these mesh functions use DECL_CMD_FUNC(), should they all > be using d? No I dont think all of them should use d. If you send a value like for meshttl for example you should not use d, d is only for enable/disable flags, for example this is CORRECT: static DECL_CMD_FUNC(set80211meshttl, val, d) { set80211(s, IEEE80211_IOC_MESH_TTL, atoi(val), 0, NULL); } br > > > adrian -- Monthadar Al Jaberi From owner-freebsd-net@FreeBSD.ORG Fri Mar 23 12:03:31 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 E4DFE106566C for ; Fri, 23 Mar 2012 12:03:31 +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 B778B8FC0C for ; Fri, 23 Mar 2012 12:03:31 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 57FEA46B2A; Fri, 23 Mar 2012 08:03:31 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E257DB911; Fri, 23 Mar 2012 08:03:30 -0400 (EDT) From: John Baldwin To: Traiano Welcome Date: Thu, 22 Mar 2012 13:49:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203221349.26701.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 23 Mar 2012 08:03:31 -0400 (EDT) Cc: "freebsd-net@freebsd.org" Subject: Re: FreeBSD: syslog-ng: I/O error occurred while writing; fd='xx', error='No buffer space available (yy)' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 12:03:32 -0000 On Thursday, March 22, 2012 11:00:35 am Traiano Welcome wrote: > Hi John > > > > On 22/03/2012 14:16, "John Baldwin" wrote: > > >On Thursday, March 22, 2012 6:03:21 am Traiano Welcome wrote: > >> Hi List > >> > >> I've been seeing the following in the messages log of my freebsd syslog > >> server for quite some time now: > >> > >> --- > >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while > >> writing; fd='12', error='No buffer space available (55)' > >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; > >> time_reopen='60' > >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while > >> writing; fd='13', error='No buffer space available (55)' > >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; > >> time_reopen='60' > >> --- > >> > >> These happen at a frequency of about 7 per minute on average. See > >>attached > >> trend graphs for an idea of the volume of traffic we're doing, as well > >>as > >> the memory and cpu utilisation trends on this server during this period. > >> As can be seen from the graphs, load does not seem to be the issue. > >> Occasionally during the week, the system freezes and requires a reboot, > >>I > >> think it's related to the above message, though I'm not sure. > >> > >> My question is: What does this error mean, and how can I resolve it? > >> > >> I have tried to frame this as an operating system kernel resource issue, > >> and experimented with increasing the freebsd kernel sysctls for UDP > >> performance: > > > >It means that the network driver has "filled" up with packets. Are you > >using > >igb(4)? We have to crank the number of descriptors assigned to igb to > >the max > >to workaround this at work (we get DNS timeouts during a simple boot > >otherwise). hw.igb.maxtxd is the tunable you would set. The max value > >you > >can set it to is 4096. > > > Thanks for the clue. It seems igb is indeed being used. However, I not > that when I try to list this tunable, I don't get anything: > > --- > [root@syslog2]# sysctl -a | grep igb > [root@syslog2]# > --- > > > --- > [root@syslog2 /boot]# sysctl hw.igb.maxtxd=4000 > sysctl: unknown oid 'hw.igb.maxtxd' > --- > > > Is this due to the way igb is compiled into the kernel, or am I tuning in > the wrong place :-) You need to put it in /boot/loader.conf and then reboot. Do try using 4096 rather than 4000. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Mar 23 12:51: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 34F21106564A; Fri, 23 Mar 2012 12:51:23 +0000 (UTC) (envelope-from Traiano.Welcome@mtnbusiness.co.za) Received: from smtprelay01.ops.mtnbusiness.co.za (smtprelay01.ops.mtnbusiness.co.za [41.181.93.235]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC9F8FC0C; Fri, 23 Mar 2012 12:51:21 +0000 (UTC) Received: from [196.30.97.135] (helo=CPT-EXCH01.int.mtnbusiness.net) by smtprelay01.ops.mtnbusiness.co.za with esmtp (ULTRA Special SMTP Internal Alpha) (envelope-from ) id 1SB3xZ-000FZM-Iq; Fri, 23 Mar 2012 14:51:13 +0200 Received: from CPT-EXCH01.int.mtnbusiness.net ([196.30.97.135]) by CPT-EXCH01.int.mtnbusiness.net ([196.30.97.135]) with mapi id 14.01.0218.012; Fri, 23 Mar 2012 14:51:06 +0200 From: Traiano Welcome To: John Baldwin Thread-Topic: FreeBSD: syslog-ng: I/O error occurred while writing; fd='xx', error='No buffer space available (yy)' Thread-Index: AQHNCBMDrRAwT2ab00myKBl/mmLfFJZ2GayAgABPOoCAAA2rAIABYICA Date: Fri, 23 Mar 2012 12:51:05 +0000 Message-ID: In-Reply-To: <201203221349.26701.jhb@freebsd.org> Accept-Language: en-US, en-ZA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [196.30.72.139] Content-Type: text/plain; charset="us-ascii" Content-ID: <5001690633350B4A92FAF06177A72F8A@int.mtnbusiness.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: Re: FreeBSD: syslog-ng: I/O error occurred while writing; fd='xx', error='No buffer space available (yy)' X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 12:51:23 -0000 Hi John On 22/03/2012 19:49, "John Baldwin" wrote: >On Thursday, March 22, 2012 11:00:35 am Traiano Welcome wrote: >> Hi John >>=20 >>=20 >>=20 >> On 22/03/2012 14:16, "John Baldwin" wrote: >>=20 >> >On Thursday, March 22, 2012 6:03:21 am Traiano Welcome wrote: >> >> Hi List >> >>=20 >> >> I've been seeing the following in the messages log of my freebsd >>syslog >> >> server for quite some time now: >> >>=20 >> >> --- >> >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while >> >> writing; fd=3D'12', error=3D'No buffer space available (55)' >> >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; >> >> time_reopen=3D'60' >> >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: I/O error occurred while >> >> writing; fd=3D'13', error=3D'No buffer space available (55)' >> >> Mar 20 12:19:12 syslog2 syslog-ng[35313]: Connection broken; >> >> time_reopen=3D'60' >> >> --- >> >>=20 >> >> These happen at a frequency of about 7 per minute on average. See >> >>attached >> >> trend graphs for an idea of the volume of traffic we're doing, as >>well >> >>as >> >> the memory and cpu utilisation trends on this server during this >>period. >> >> As can be seen from the graphs, load does not seem to be the issue. >> >> Occasionally during the week, the system freezes and requires a >>reboot, >> >>I >> >> think it's related to the above message, though I'm not sure. >> >>=20 >> >> My question is: What does this error mean, and how can I resolve it? >> >>=20 >> >> I have tried to frame this as an operating system kernel resource >>issue, >> >> and experimented with increasing the freebsd kernel sysctls for UDP >> >> performance: >> > >> >It means that the network driver has "filled" up with packets. Are you >> >using=20 >> >igb(4)? We have to crank the number of descriptors assigned to igb to >> >the max=20 >> >to workaround this at work (we get DNS timeouts during a simple boot >> >otherwise). hw.igb.maxtxd is the tunable you would set. The max value >> >you=20 >> >can set it to is 4096. >>=20 >>=20 >> Thanks for the clue. It seems igb is indeed being used. However, I not >> that when I try to list this tunable, I don't get anything: >>=20 >> --- >> [root@syslog2]# sysctl -a | grep igb >> [root@syslog2]# >> --- >>=20 >>=20 >> --- >> [root@syslog2 /boot]# sysctl hw.igb.maxtxd=3D4000 >> sysctl: unknown oid 'hw.igb.maxtxd' > >> --- >>=20 >>=20 >> Is this due to the way igb is compiled into the kernel, or am I tuning >>in >> the wrong place :-) > >You need to put it in /boot/loader.conf and then reboot. Do try using >4096 >rather than 4000. I'm an idiot :-) Looks like the correct driver is bce: --- [root@syslog2]# sysctl dev.bce | grep -v stat dev.bce.0.%desc: Broadcom NetXtreme II BCM5708 1000Base-T (B2) dev.bce.0.%driver: bce dev.bce.0.%location: slot=3D0 function=3D0 dev.bce.0.%pnpinfo: vendor=3D0x14e4 device=3D0x164c subvendor=3D0x1028 subdevice=3D0x01b3 class=3D0x020000 dev.bce.0.%parent: pci7 dev.bce.0.l2fhdr_error_count: 0 dev.bce.0.mbuf_alloc_failed_count: 0 dev.bce.0.fragmented_mbuf_count: 0 dev.bce.0.dma_map_addr_rx_failed_count: 0 dev.bce.0.dma_map_addr_tx_failed_count: 0 dev.bce.0.unexpected_attention_count: 0 dev.bce.0.com_no_buffers: 0 dev.bce.1.%desc: Broadcom NetXtreme II BCM5708 1000Base-T (B2) dev.bce.1.%driver: bce dev.bce.1.%location: slot=3D0 function=3D0 dev.bce.1.%pnpinfo: vendor=3D0x14e4 device=3D0x164c subvendor=3D0x1028 subdevice=3D0x01b3 class=3D0x020000 dev.bce.1.%parent: pci3 dev.bce.1.l2fhdr_error_count: 0 dev.bce.1.mbuf_alloc_failed_count: 0 dev.bce.1.fragmented_mbuf_count: 0 dev.bce.1.dma_map_addr_rx_failed_count: 0 dev.bce.1.dma_map_addr_tx_failed_count: 0 dev.bce.1.unexpected_attention_count: 0 dev.bce.1.com_no_buffers: --- And it looks like the buffer full errors have returned, and the perceived improvement may just have been due to traffic backoff due to the reboot But I can't seem to find any tunables for the bce driver. The man page only indicates one: --- SYSCTL VARIABLES The following variables are available as both sysctl(8) variables and loader(8) tunables: hw.bce.msi_enable Whether or not MSI support is enabled in the driver. The default value is 1. --- The only other solution I can think of is an upgrade. Is there an alternative to this ? > >--=20 >John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Mar 23 18:09:56 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 32CA41065670; Fri, 23 Mar 2012 18:09:56 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id E4D138FC0A; Fri, 23 Mar 2012 18:09:55 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q2NI9ot0014027; Fri, 23 Mar 2012 14:09:50 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4F6CBC59.2060601@sentex.net> Date: Fri, 23 Mar 2012 14:09:29 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <201203151417.04507.jhb@freebsd.org> <201203201457.24776.jhb@freebsd.org> In-Reply-To: <201203201457.24776.jhb@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 64.7.153.18 Cc: freebsd-net@freebsd.org, Adrian Chadd , Hooman Fazaeli , Jason Wolfe Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-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, 23 Mar 2012 18:09:56 -0000 On 3/20/2012 2:57 PM, John Baldwin wrote: >>> TX when link becomes active. I've also updated it to fix resume for em >>> and igb to DTRT when buf_ring is used, and to not include old-style start >>> routines at all when using multiq. It is at >>> http://www.freebsd.org/~jhb/patches/e1000_txeof2.patch >> Thank for the patch sirs, so far it does look like it did the trick. >> I'll know for certain here in a few days if I'm still in the clear. >> I'm guessing after it goes through some more testing it'll be too late >> to slip it into 8.3? > > Yes, this is too late for 8.3, but thanks for testing! Hi, Is there a RELENG_8 version of this patch ? I have a server that used to shows this issue quite a bit, but has not since 7.3.2. I would be happy to stress it on the box. The patch above does not apply cleanly due to the netmap diffs, but I can manually merge if thats the only difference. em1: port 0x2000-0x201f mem 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at device 0.0 on pci11 em1: Using MSIX interrupts with 3 vectors em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:15:17:ed:68:a4 em1@pci0:11:0:0: class=0x020000 card=0x34ec8086 chip=0x10d38086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82574L Gigabit Ethernet Controller (82574L)' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xb4100000, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x2000, size 32, enabled bar [1c] = type Memory, range 32, base 0xb4120000, size 16384, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 001517ffffed68a4 -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Fri Mar 23 18:13:39 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 50C711065673 for ; Fri, 23 Mar 2012 18:13:39 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C71C78FC15 for ; Fri, 23 Mar 2012 18:13:38 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so3774872bkc.13 for ; Fri, 23 Mar 2012 11:13:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id :x-gm-message-state; bh=MxGdG/zee6x63UmWL4IOjv4sBHR5TiQqXsb+QZtqAtg=; b=ADQEEpPN/CpF0b1GG7t1MwDhGZ4vYtMizltD7TGf2MynoFUSA6c1BkvB7Otkgc9f6T k2e1wfulDF166PZXmDHi4RKP/0xdLahLbcil9+qm/OSOQx55sILTQhxyL9Xs1U6NUdCD R30h2vJR6TIZQJXlXMIWk/CFbgB0cerSVQr1K32PJD+491btpIW8z4ekDE1Gm43nt0gp XntHV8GS62W1McaIaLHBlHV21ueNZbjS+5SiUXUB/kObAOvZtkqx0yzhVGlAT0diwSNY 5ys35rGCI6MWBWvtSzvF5lfxr3BmPxrkxXkXax/xSYaF4o3Mw9D7l6v82128U+mCjTLe Hdkg== Received: by 10.204.130.81 with SMTP id r17mr5042528bks.118.1332526417618; Fri, 23 Mar 2012 11:13:37 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-065-061-048.pools.arcor-ip.net. [88.65.61.48]) by mx.google.com with ESMTPS id u5sm17558595bka.5.2012.03.23.11.13.35 (version=SSLv3 cipher=OTHER); Fri, 23 Mar 2012 11:13:37 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: Monthadar Al Jaberi Date: Fri, 23 Mar 2012 19:13:46 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203231913.46980.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQmP3wjMzqMPJ+NuNkdxJxsJZ2EznBkJb34hvtFVWZDP6bk3eiyCkGAZC/IJs/NAXWmppWPm Cc: freebsd-net@freebsd.org, Adrian Chadd Subject: Re: ifconfig meshforward command bug X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 18:13:39 -0000 On Friday 23 March 2012 10:11:07 Monthadar Al Jaberi wrote: > On Thu, Mar 22, 2012 at 10:23 PM, Adrian Chadd wrote: > > I've fixed the one that Monthadar has submitted. > > > > Monthadar, would you mind reviewing the rest of the mesh commands and > > see which others need fixing? > > from what I can see the bug is for flags that we can either turn on or > off. Another one I found, > > static > DECL_CMD_FUNC(set80211meshpeering, val, d) > { > - set80211(s, IEEE80211_IOC_MESH_AP, atoi(val), 0, NULL); > + set80211(s, IEEE80211_IOC_MESH_AP, d, 0, NULL); > > I took a quick look and think this is last one Correct, and committed, thanks! -- Bernhard From owner-freebsd-net@FreeBSD.ORG Fri Mar 23 18:38:30 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 E2C7F1065670; Fri, 23 Mar 2012 18:38:30 +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 844818FC08; Fri, 23 Mar 2012 18:38:30 +0000 (UTC) Received: by obbuo13 with SMTP id uo13so3473719obb.13 for ; Fri, 23 Mar 2012 11:38:24 -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=rf4bdH6kX3f+uQhcm8bSF7Dt9YvbwOJeSstZOBEE3MI=; b=kbOxNJVmhepkQcJAtz+I9wBgmEL31vwHkldpvRR1yrIQR3uYJh1wHdAWPn8hano5T6 Nykmvp086wuKWxoRv59P8KZ9EZFEKJNSzIE7jDJ4PkWP4GvQU5ykhwE43q15xxKnsvHA 97bajjaRna8D5tzTDQmJx7PS6L4u1168GnG8Uaf6E2KEUgH5quEc13RLTbF1Il0UIx/D xfoC7G1dolN16kyj+8AnS5LQQ+JHM3nHYCr4xHq7p6ghHbLSElJJbAqHmQthfmycWvNF Bx/e8RuiTCjeJamn3xvNOMVbyK2NHGNkjAE56rh7kTcLonISKBxqQsx5ITDhJagULDps 4nsA== MIME-Version: 1.0 Received: by 10.182.108.97 with SMTP id hj1mr15885962obb.37.1332527903993; Fri, 23 Mar 2012 11:38:23 -0700 (PDT) Received: by 10.182.47.135 with HTTP; Fri, 23 Mar 2012 11:38:21 -0700 (PDT) In-Reply-To: <4F6CBC59.2060601@sentex.net> References: <201203151417.04507.jhb@freebsd.org> <201203201457.24776.jhb@freebsd.org> <4F6CBC59.2060601@sentex.net> Date: Fri, 23 Mar 2012 11:38:21 -0700 Message-ID: From: Jason Wolfe To: Mike Tancsa Content-Type: multipart/mixed; boundary=f46d04478b775eefcf04bbed54c9 Cc: freebsd-net@freebsd.org, Adrian Chadd , Hooman Fazaeli , John Baldwin Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-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, 23 Mar 2012 18:38:31 -0000 --f46d04478b775eefcf04bbed54c9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 23, 2012 at 11:09 AM, Mike Tancsa wrote: > On 3/20/2012 2:57 PM, John Baldwin wrote: >>>> TX when link becomes active. =A0I've also updated it to fix resume for= em >>>> and igb to DTRT when buf_ring is used, and to not include old-style st= art >>>> routines at all when using multiq. =A0It is at >>>> http://www.freebsd.org/~jhb/patches/e1000_txeof2.patch >>> Thank for the patch sirs, so far it does look like it did the trick. >>> I'll know for certain here in a few days if I'm still in the clear. >>> I'm guessing after it goes through some more testing it'll be too late >>> to slip it into 8.3? >> >> Yes, this is too late for 8.3, but thanks for testing! > > Hi, > Is there a RELENG_8 version of this patch ? I have a server that used to > shows this issue quite a bit, but has not since 7.3.2. I would be happy > to stress it on the box. =A0The patch above does not apply cleanly due to > the netmap diffs, but I can manually merge if thats the only difference. > > em1: port 0x2000-0x201f mem > 0xb4100000-0xb411ffff,0xb4120000-0xb4123fff irq 16 at device 0.0 on pci11 > em1: Using MSIX interrupts with 3 vectors > em1: [ITHREAD] > em1: [ITHREAD] > em1: [ITHREAD] > em1: Ethernet address: 00:15:17:ed:68:a4 > > em1@pci0:11:0:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x34ec8086 chip= =3D0x10d38086 > rev=3D0x00 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' > =A0 =A0device =A0 =A0 =3D 'Intel 82574L Gigabit Ethernet Controller (8257= 4L)' > =A0 =A0class =A0 =A0 =A0=3D network > =A0 =A0subclass =A0 =3D ethernet > =A0 =A0bar =A0 [10] =3D type Memory, range 32, base 0xb4100000, size 1310= 72, > enabled > =A0 =A0bar =A0 [18] =3D type I/O Port, range 32, base 0x2000, size 32, en= abled > =A0 =A0bar =A0 [1c] =3D type Memory, range 32, base 0xb4120000, size 1638= 4, enabled > =A0 =A0cap 01[c8] =3D powerspec 2 =A0supports D0 D3 =A0current D0 > =A0 =A0cap 05[d0] =3D MSI supports 1 message, 64 bit > =A0 =A0cap 10[e0] =3D PCI-Express 1 endpoint max data 128(256) link x1(x1= ) > =A0 =A0cap 11[a0] =3D MSI-X supports 5 messages in map 0x1c enabled > ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 0 corrected > ecap 0003[140] =3D Serial 1 001517ffffed68a4 > > > -- > ------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada =A0 http://www.tancsa.com/ Mike, Attached is my patch with the small issues you mention cleaned up. It worked for me against RELENG_8 (8.3-PRERELEASE) as of 4 days ago. On the testing front, I've been stable for those 4 days across the pool of test machines. Prior I couldn't get past 48 hours without an interface 'wedge'. Thanks again! Jason --f46d04478b775eefcf04bbed54c9 Content-Type: application/octet-stream; name="if_em_fix-fbsd83.diff" Content-Disposition: attachment; filename="if_em_fix-fbsd83.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h05koxla0 ZGlmZiAtcnVOIHNyYy5zdG9jay9zeXMvZGV2L2UxMDAwL2lmX2VtLmMgc3JjL3N5cy9kZXYvZTEw MDAvaWZfZW0uYwotLS0gc3JjLnN0b2NrL3N5cy9kZXYvZTEwMDAvaWZfZW0uYwkyMDEyLTAxLTMx IDE1OjQ3OjEwLjAwMDAwMDAwMCAtMDcwMAorKysgc3JjL3N5cy9kZXYvZTEwMDAvaWZfZW0uYwky MDEyLTAzLTE4IDIzOjA4OjAzLjAwMDAwMDAwMCAtMDcwMApAQCAtMTkzLDEzICsxOTMsMTQgQEAK IHN0YXRpYyBpbnQJZW1fc2h1dGRvd24oZGV2aWNlX3QpOwogc3RhdGljIGludAllbV9zdXNwZW5k KGRldmljZV90KTsKIHN0YXRpYyBpbnQJZW1fcmVzdW1lKGRldmljZV90KTsKLXN0YXRpYyB2b2lk CWVtX3N0YXJ0KHN0cnVjdCBpZm5ldCAqKTsKLXN0YXRpYyB2b2lkCWVtX3N0YXJ0X2xvY2tlZChz dHJ1Y3QgaWZuZXQgKiwgc3RydWN0IHR4X3JpbmcgKik7CiAjaWZkZWYgRU1fTVVMVElRVUVVRQog c3RhdGljIGludAllbV9tcV9zdGFydChzdHJ1Y3QgaWZuZXQgKiwgc3RydWN0IG1idWYgKik7CiBz dGF0aWMgaW50CWVtX21xX3N0YXJ0X2xvY2tlZChzdHJ1Y3QgaWZuZXQgKiwKIAkJICAgIHN0cnVj dCB0eF9yaW5nICosIHN0cnVjdCBtYnVmICopOwogc3RhdGljIHZvaWQJZW1fcWZsdXNoKHN0cnVj dCBpZm5ldCAqKTsKKyNlbHNlCitzdGF0aWMgdm9pZAllbV9zdGFydChzdHJ1Y3QgaWZuZXQgKik7 CitzdGF0aWMgdm9pZAllbV9zdGFydF9sb2NrZWQoc3RydWN0IGlmbmV0ICosIHN0cnVjdCB0eF9y aW5nICopOwogI2VuZGlmCiBzdGF0aWMgaW50CWVtX2lvY3RsKHN0cnVjdCBpZm5ldCAqLCB1X2xv bmcsIGNhZGRyX3QpOwogc3RhdGljIHZvaWQJZW1faW5pdCh2b2lkICopOwpAQCAtMjM0LDcgKzIz NSw3IEBACiBzdGF0aWMgdm9pZAllbV9kaXNhYmxlX2ludHIoc3RydWN0IGFkYXB0ZXIgKik7CiBz dGF0aWMgdm9pZAllbV91cGRhdGVfc3RhdHNfY291bnRlcnMoc3RydWN0IGFkYXB0ZXIgKik7CiBz dGF0aWMgdm9pZAllbV9hZGRfaHdfc3RhdHMoc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIpOwotc3Rh dGljIGJvb2wJZW1fdHhlb2Yoc3RydWN0IHR4X3JpbmcgKik7CitzdGF0aWMgdm9pZAllbV90eGVv ZihzdHJ1Y3QgdHhfcmluZyAqKTsKIHN0YXRpYyBib29sCWVtX3J4ZW9mKHN0cnVjdCByeF9yaW5n ICosIGludCwgaW50ICopOwogI2lmbmRlZiBfX05PX1NUUklDVF9BTElHTk1FTlQKIHN0YXRpYyBp bnQJZW1fZml4dXBfcngoc3RydWN0IHJ4X3JpbmcgKik7CkBAIC04MzYsNiArODM3LDcgQEAKIGVt X3Jlc3VtZShkZXZpY2VfdCBkZXYpCiB7CiAJc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIgPSBkZXZp Y2VfZ2V0X3NvZnRjKGRldik7CisJc3RydWN0IHR4X3JpbmcJKnR4ciA9IGFkYXB0ZXItPnR4X3Jp bmdzOwogCXN0cnVjdCBpZm5ldCAqaWZwID0gYWRhcHRlci0+aWZwOwogCiAJRU1fQ09SRV9MT0NL KGFkYXB0ZXIpOwpAQCAtODQzLDggKzg0NSwyMiBAQAogCQllMTAwMF9yZXN1bWVfd29ya2Fyb3Vu ZHNfcGNobGFuKCZhZGFwdGVyLT5odyk7CiAJZW1faW5pdF9sb2NrZWQoYWRhcHRlcik7CiAJZW1f aW5pdF9tYW5hZ2VhYmlsaXR5KGFkYXB0ZXIpOworCisJaWYgKChpZnAtPmlmX2ZsYWdzICYgSUZG X1VQKSAmJgorCSAgICAoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpICYmIGFk YXB0ZXItPmxpbmtfYWN0aXZlKSB7CisJCWZvciAoaW50IGkgPSAwOyBpIDwgYWRhcHRlci0+bnVt X3F1ZXVlczsgaSsrLCB0eHIrKykgeworCQkJRU1fVFhfTE9DSyh0eHIpOworI2lmZGVmIEVNX01V TFRJUVVFVUUKKwkJCWlmICghZHJicl9lbXB0eShpZnAsIHR4ci0+YnIpKQorCQkJCWVtX21xX3N0 YXJ0X2xvY2tlZChpZnAsIHR4ciwgTlVMTCk7CisjZWxzZQorCQkJaWYgKCFJRlFfRFJWX0lTX0VN UFRZKCZpZnAtPmlmX3NuZCkpCisJCQkJZW1fc3RhcnRfbG9ja2VkKGlmcCwgdHhyKTsKKyNlbmRp ZgorCQkJRU1fVFhfVU5MT0NLKHR4cik7CisJCX0KKwl9CiAJRU1fQ09SRV9VTkxPQ0soYWRhcHRl cik7Ci0JZW1fc3RhcnQoaWZwKTsKIAogCXJldHVybiBidXNfZ2VuZXJpY19yZXN1bWUoZGV2KTsK IH0KQEAgLTk0OCw3ICs5NjQsNyBAQAogCX0KIAlpZl9xZmx1c2goaWZwKTsKIH0KLSNlbmRpZiAv KiBFTV9NVUxUSVFVRVVFICovCisjZWxzZSAgLyogIUVNX01VTFRJUVVFVUUgKi8KIAogc3RhdGlj IHZvaWQKIGVtX3N0YXJ0X2xvY2tlZChzdHJ1Y3QgaWZuZXQgKmlmcCwgc3RydWN0IHR4X3Jpbmcg KnR4cikKQEAgLTEwMDksMTQgKzEwMjUsOSBAQAogCQllbV9zdGFydF9sb2NrZWQoaWZwLCB0eHIp OwogCQlFTV9UWF9VTkxPQ0sodHhyKTsKIAl9Ci0JLyoKLQkqKiBJZiB3ZSB3ZW50IGluYWN0aXZl IHNjaGVkdWxlCi0JKiogYSB0YXNrIHRvIGNsZWFuIHVwLgotCSovCi0JaWYgKGlmcC0+aWZfZHJ2 X2ZsYWdzICYgSUZGX0RSVl9PQUNUSVZFKQotCQl0YXNrcXVldWVfZW5xdWV1ZSh0eHItPnRxLCAm dHhyLT50eF90YXNrKTsKIAlyZXR1cm47CiB9CisjZW5kaWYgLyogRU1fTVVMVElRVUVVRSAqLwog CiAvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqCiAgKiAgSW9jdGwgZW50cnkgcG9pbnQKQEAgLTE0MTMsNyArMTQyNCw4 IEBACiAJaWYgKCFkcmJyX2VtcHR5KGlmcCwgdHhyLT5icikpCiAJCWVtX21xX3N0YXJ0X2xvY2tl ZChpZnAsIHR4ciwgTlVMTCk7CiAjZWxzZQotCWVtX3N0YXJ0X2xvY2tlZChpZnAsIHR4cik7CisJ aWYgKCFJRlFfRFJWX0lTX0VNUFRZKCZpZnAtPmlmX3NuZCkpCisJCWVtX3N0YXJ0X2xvY2tlZChp ZnAsIHR4cik7CiAjZW5kaWYKIAlFTV9UWF9VTkxPQ0sodHhyKTsKIApAQCAtMTQ4NiwxMCArMTQ5 OCwxMSBAQAogCQlpZiAoIWRyYnJfZW1wdHkoaWZwLCB0eHItPmJyKSkKIAkJCWVtX21xX3N0YXJ0 X2xvY2tlZChpZnAsIHR4ciwgTlVMTCk7CiAjZWxzZQotCQllbV9zdGFydF9sb2NrZWQoaWZwLCB0 eHIpOworCQlpZiAoIUlGUV9EUlZfSVNfRU1QVFkoJmlmcC0+aWZfc25kKSkKKwkJCWVtX3N0YXJ0 X2xvY2tlZChpZnAsIHR4cik7CiAjZW5kaWYKIAkJRU1fVFhfVU5MT0NLKHR4cik7Ci0JCWlmICht b3JlIHx8IChpZnAtPmlmX2Rydl9mbGFncyAmIElGRl9EUlZfT0FDVElWRSkpIHsKKwkJaWYgKG1v cmUpIHsKIAkJCXRhc2txdWV1ZV9lbnF1ZXVlKGFkYXB0ZXItPnRxLCAmYWRhcHRlci0+cXVlX3Rh c2spOwogCQkJcmV0dXJuOwogCQl9CkBAIC0xNTEwLDE3ICsxNTIzLDIxIEBACiB7CiAJc3RydWN0 IHR4X3JpbmcgKnR4ciA9IGFyZzsKIAlzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlciA9IHR4ci0+YWRh cHRlcjsKLQlib29sCQltb3JlOworCXN0cnVjdCBpZm5ldAkqaWZwID0gYWRhcHRlci0+aWZwOwog CiAJKyt0eHItPnR4X2lycTsKIAlFTV9UWF9MT0NLKHR4cik7Ci0JbW9yZSA9IGVtX3R4ZW9mKHR4 cik7CisJZW1fdHhlb2YodHhyKTsKKyNpZmRlZiBFTV9NVUxUSVFVRVVFCisJaWYgKCFkcmJyX2Vt cHR5KGlmcCwgdHhyLT5icikpCisJCWVtX21xX3N0YXJ0X2xvY2tlZChpZnAsIHR4ciwgTlVMTCk7 CisjZWxzZQorCWlmICghSUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9zbmQpKQorCQllbV9zdGFy dF9sb2NrZWQoaWZwLCB0eHIpOworI2VuZGlmCisJLyogUmVlbmFibGUgdGhpcyBpbnRlcnJ1cHQg Ki8KKwlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9JTVMsIHR4ci0+aW1zKTsK IAlFTV9UWF9VTkxPQ0sodHhyKTsKLQlpZiAobW9yZSkKLQkJdGFza3F1ZXVlX2VucXVldWUodHhy LT50cSwgJnR4ci0+dHhfdGFzayk7Ci0JZWxzZQotCQkvKiBSZWVuYWJsZSB0aGlzIGludGVycnVw dCAqLwotCQlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9JTVMsIHR4ci0+aW1z KTsKIAlyZXR1cm47CiB9CiAKQEAgLTE1OTgsNyArMTYxNSw4IEBACiAJaWYgKCFkcmJyX2VtcHR5 KGlmcCwgdHhyLT5icikpCiAJCWVtX21xX3N0YXJ0X2xvY2tlZChpZnAsIHR4ciwgTlVMTCk7CiAj ZWxzZQotCWVtX3N0YXJ0X2xvY2tlZChpZnAsIHR4cik7CisJaWYgKCFJRlFfRFJWX0lTX0VNUFRZ KCZpZnAtPmlmX3NuZCkpCisJCWVtX3N0YXJ0X2xvY2tlZChpZnAsIHR4cik7CiAjZW5kaWYKIAlF MTAwMF9XUklURV9SRUcoJmFkYXB0ZXItPmh3LCBFMTAwMF9JTVMsIHR4ci0+aW1zKTsKIAlFTV9U WF9VTkxPQ0sodHhyKTsKQEAgLTE2MDgsNiArMTYyNiw3IEBACiBlbV9oYW5kbGVfbGluayh2b2lk ICpjb250ZXh0LCBpbnQgcGVuZGluZykKIHsKIAlzdHJ1Y3QgYWRhcHRlcgkqYWRhcHRlciA9IGNv bnRleHQ7CisJc3RydWN0IHR4X3JpbmcJKnR4ciA9IGFkYXB0ZXItPnR4X3JpbmdzOwogCXN0cnVj dCBpZm5ldCAqaWZwID0gYWRhcHRlci0+aWZwOwogCiAJaWYgKCEoaWZwLT5pZl9kcnZfZmxhZ3Mg JiBJRkZfRFJWX1JVTk5JTkcpKQpAQCAtMTYxOSw2ICsxNjM4LDE5IEBACiAJY2FsbG91dF9yZXNl dCgmYWRhcHRlci0+dGltZXIsIGh6LCBlbV9sb2NhbF90aW1lciwgYWRhcHRlcik7CiAJRTEwMDBf V1JJVEVfUkVHKCZhZGFwdGVyLT5odywgRTEwMDBfSU1TLAogCSAgICBFTV9NU0lYX0xJTksgfCBF MTAwMF9JTVNfTFNDKTsKKwlpZiAoYWRhcHRlci0+bGlua19hY3RpdmUpIHsKKwkJZm9yIChpbnQg aSA9IDA7IGkgPCBhZGFwdGVyLT5udW1fcXVldWVzOyBpKyssIHR4cisrKSB7CisJCQlFTV9UWF9M T0NLKHR4cik7CisjaWZkZWYgRU1fTVVMVElRVUVVRQorCQkJaWYgKCFkcmJyX2VtcHR5KGlmcCwg dHhyLT5icikpCisJCQkJZW1fbXFfc3RhcnRfbG9ja2VkKGlmcCwgdHhyLCBOVUxMKTsKKyNlbHNl CisJCQlpZiAoIUlGUV9EUlZfSVNfRU1QVFkoJmlmcC0+aWZfc25kKSkKKwkJCQllbV9zdGFydF9s b2NrZWQoaWZwLCB0eHIpOworI2VuZGlmCisJCQlFTV9UWF9VTkxPQ0sodHhyKTsKKwkJfQorCX0K IAlFTV9DT1JFX1VOTE9DSyhhZGFwdGVyKTsKIH0KIApAQCAtMjg5MSwyMCArMjkyMywyMSBAQAog CWlmcC0+aWZfc29mdGMgPSBhZGFwdGVyOwogCWlmcC0+aWZfZmxhZ3MgPSBJRkZfQlJPQURDQVNU IHwgSUZGX1NJTVBMRVggfCBJRkZfTVVMVElDQVNUOwogCWlmcC0+aWZfaW9jdGwgPSBlbV9pb2N0 bDsKKyNpZmRlZiBFTV9NVUxUSVFVRVVFCisJLyogTXVsdGlxdWV1ZSBzdGFjayBpbnRlcmZhY2Ug Ki8KKwlpZnAtPmlmX3RyYW5zbWl0ID0gZW1fbXFfc3RhcnQ7CisJaWZwLT5pZl9xZmx1c2ggPSBl bV9xZmx1c2g7CisjZWxzZQogCWlmcC0+aWZfc3RhcnQgPSBlbV9zdGFydDsKIAlJRlFfU0VUX01B WExFTigmaWZwLT5pZl9zbmQsIGFkYXB0ZXItPm51bV90eF9kZXNjIC0gMSk7CiAJaWZwLT5pZl9z bmQuaWZxX2Rydl9tYXhsZW4gPSBhZGFwdGVyLT5udW1fdHhfZGVzYyAtIDE7CiAJSUZRX1NFVF9S RUFEWSgmaWZwLT5pZl9zbmQpOworI2VuZGlmCQogCiAJZXRoZXJfaWZhdHRhY2goaWZwLCBhZGFw dGVyLT5ody5tYWMuYWRkcik7CiAKIAlpZnAtPmlmX2NhcGFiaWxpdGllcyA9IGlmcC0+aWZfY2Fw ZW5hYmxlID0gMDsKIAotI2lmZGVmIEVNX01VTFRJUVVFVUUKLQkvKiBNdWx0aXF1ZXVlIHN0YWNr IGludGVyZmFjZSAqLwotCWlmcC0+aWZfdHJhbnNtaXQgPSBlbV9tcV9zdGFydDsKLQlpZnAtPmlm X3FmbHVzaCA9IGVtX3FmbHVzaDsKLSNlbmRpZgkKIAogCWlmcC0+aWZfY2FwYWJpbGl0aWVzIHw9 IElGQ0FQX0hXQ1NVTSB8IElGQ0FQX1ZMQU5fSFdDU1VNOwogCWlmcC0+aWZfY2FwYWJpbGl0aWVz IHw9IElGQ0FQX1RTTzQ7CkBAIC0zNzEwLDcgKzM3NDMsNyBAQAogICogIHR4X2J1ZmZlciBpcyBw dXQgYmFjayBvbiB0aGUgZnJlZSBxdWV1ZS4KICAqCiAgKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KLXN0YXRpYyBi b29sCitzdGF0aWMgdm9pZAogZW1fdHhlb2Yoc3RydWN0IHR4X3JpbmcgKnR4cikKIHsKIAlzdHJ1 Y3QgYWRhcHRlcgkqYWRhcHRlciA9IHR4ci0+YWRhcHRlcjsKQEAgLTM3MjQsNyArMzc1Nyw3IEBA CiAJLyogTm8gd29yaywgbWFrZSBzdXJlIHdhdGNoZG9nIGlzIG9mZiAqLwogICAgICAgICBpZiAo dHhyLT50eF9hdmFpbCA9PSBhZGFwdGVyLT5udW1fdHhfZGVzYykgewogCQl0eHItPnF1ZXVlX3N0 YXR1cyA9IEVNX1FVRVVFX0lETEU7Ci0gICAgICAgICAgICAgICAgcmV0dXJuIChGQUxTRSk7Cisg ICAgICAgICAgICAgICAgcmV0dXJuOwogCX0KIAogCXByb2Nlc3NlZCA9IDA7CkBAIC0zODEzLDEw ICszODQ2LDcgQEAKIAkvKiBEaXNhYmxlIHdhdGNoZG9nIGlmIGFsbCBjbGVhbiAqLwogCWlmICh0 eHItPnR4X2F2YWlsID09IGFkYXB0ZXItPm51bV90eF9kZXNjKSB7CiAJCXR4ci0+cXVldWVfc3Rh dHVzID0gRU1fUVVFVUVfSURMRTsKLQkJcmV0dXJuIChGQUxTRSk7CiAJfSAKLQotCXJldHVybiAo VFJVRSk7CiB9CiAKIApkaWZmIC1ydU4gc3JjLnN0b2NrL3N5cy9kZXYvZTEwMDAvaWZfaWdiLmMg c3JjL3N5cy9kZXYvZTEwMDAvaWZfaWdiLmMKLS0tIHNyYy5zdG9jay9zeXMvZGV2L2UxMDAwL2lm X2lnYi5jCTIwMTItMDEtMzEgMTU6NDc6MTAuMDAwMDAwMDAwIC0wNzAwCisrKyBzcmMvc3lzL2Rl di9lMTAwMC9pZl9pZ2IuYwkyMDEyLTAzLTE4IDIxOjQ1OjE1LjAwMDAwMDAwMCAtMDcwMApAQCAt MTcxLDEzICsxNzEsMTQgQEAKIHN0YXRpYyBpbnQJaWdiX3NodXRkb3duKGRldmljZV90KTsKIHN0 YXRpYyBpbnQJaWdiX3N1c3BlbmQoZGV2aWNlX3QpOwogc3RhdGljIGludAlpZ2JfcmVzdW1lKGRl dmljZV90KTsKLXN0YXRpYyB2b2lkCWlnYl9zdGFydChzdHJ1Y3QgaWZuZXQgKik7Ci1zdGF0aWMg dm9pZAlpZ2Jfc3RhcnRfbG9ja2VkKHN0cnVjdCB0eF9yaW5nICosIHN0cnVjdCBpZm5ldCAqaWZw KTsKICNpZiBfX0ZyZWVCU0RfdmVyc2lvbiA+PSA4MDAwMDAKIHN0YXRpYyBpbnQJaWdiX21xX3N0 YXJ0KHN0cnVjdCBpZm5ldCAqLCBzdHJ1Y3QgbWJ1ZiAqKTsKIHN0YXRpYyBpbnQJaWdiX21xX3N0 YXJ0X2xvY2tlZChzdHJ1Y3QgaWZuZXQgKiwKIAkJICAgIHN0cnVjdCB0eF9yaW5nICosIHN0cnVj dCBtYnVmICopOwogc3RhdGljIHZvaWQJaWdiX3FmbHVzaChzdHJ1Y3QgaWZuZXQgKik7CisjZWxz ZQorc3RhdGljIHZvaWQJaWdiX3N0YXJ0KHN0cnVjdCBpZm5ldCAqKTsKK3N0YXRpYyB2b2lkCWln Yl9zdGFydF9sb2NrZWQoc3RydWN0IHR4X3JpbmcgKiwgc3RydWN0IGlmbmV0ICppZnApOwogI2Vu ZGlmCiBzdGF0aWMgaW50CWlnYl9pb2N0bChzdHJ1Y3QgaWZuZXQgKiwgdV9sb25nLCBjYWRkcl90 KTsKIHN0YXRpYyB2b2lkCWlnYl9pbml0KHZvaWQgKik7CkBAIC0yNjEsNiArMjYyLDcgQEAKIHN0 YXRpYyB2b2lkCWlnYl9tc2l4X2xpbmsodm9pZCAqKTsKIHN0YXRpYyB2b2lkCWlnYl9oYW5kbGVf cXVlKHZvaWQgKmNvbnRleHQsIGludCBwZW5kaW5nKTsKIHN0YXRpYyB2b2lkCWlnYl9oYW5kbGVf bGluayh2b2lkICpjb250ZXh0LCBpbnQgcGVuZGluZyk7CitzdGF0aWMgdm9pZAlpZ2JfaGFuZGxl X2xpbmtfbG9ja2VkKHN0cnVjdCBhZGFwdGVyICopOwogCiBzdGF0aWMgdm9pZAlpZ2Jfc2V0X3N5 c2N0bF92YWx1ZShzdHJ1Y3QgYWRhcHRlciAqLCBjb25zdCBjaGFyICosCiAJCSAgICBjb25zdCBj aGFyICosIGludCAqLCBpbnQpOwpAQCAtNzk4LDYgKzgwMCw3IEBACiBpZ2JfcmVzdW1lKGRldmlj ZV90IGRldikKIHsKIAlzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlciA9IGRldmljZV9nZXRfc29mdGMo ZGV2KTsKKwlzdHJ1Y3QgdHhfcmluZwkqdHhyID0gYWRhcHRlci0+dHhfcmluZ3M7CiAJc3RydWN0 IGlmbmV0ICppZnAgPSBhZGFwdGVyLT5pZnA7CiAKIAlJR0JfQ09SRV9MT0NLKGFkYXB0ZXIpOwpA QCAtODA1LDkgKzgwOCwyMSBAQAogCWlnYl9pbml0X21hbmFnZWFiaWxpdHkoYWRhcHRlcik7CiAK IAlpZiAoKGlmcC0+aWZfZmxhZ3MgJiBJRkZfVVApICYmCi0JICAgIChpZnAtPmlmX2Rydl9mbGFn cyAmIElGRl9EUlZfUlVOTklORykpCi0JCWlnYl9zdGFydChpZnApOwotCisJICAgIChpZnAtPmlm X2Rydl9mbGFncyAmIElGRl9EUlZfUlVOTklORykgJiYgYWRhcHRlci0+bGlua19hY3RpdmUpIHsK KwkJZm9yIChpbnQgaSA9IDA7IGkgPCBhZGFwdGVyLT5udW1fcXVldWVzOyBpKyssIHR4cisrKSB7 CisJCQlJR0JfVFhfTE9DSyh0eHIpOworI2lmIF9fRnJlZUJTRF92ZXJzaW9uID49IDgwMDAwMAor CQkJLyogUHJvY2VzcyB0aGUgc3RhY2sgcXVldWUgb25seSBpZiBub3QgZGVwbGV0ZWQgKi8KKwkJ CWlmICgoKHR4ci0+cXVldWVfc3RhdHVzICYgSUdCX1FVRVVFX0RFUExFVEVEKSA9PSAwKSAmJgor CQkJICAgICFkcmJyX2VtcHR5KGlmcCwgdHhyLT5icikpCisJCQkJaWdiX21xX3N0YXJ0X2xvY2tl ZChpZnAsIHR4ciwgTlVMTCk7CisjZWxzZQorCQkJaWYgKCFJRlFfRFJWX0lTX0VNUFRZKCZpZnAt PmlmX3NuZCkpCisJCQkJaWdiX3N0YXJ0X2xvY2tlZCh0eHIsIGlmcCk7CisjZW5kaWYKKwkJCUlH Ql9UWF9VTkxPQ0sodHhyKTsKKwkJfQorCX0KIAlJR0JfQ09SRV9VTkxPQ0soYWRhcHRlcik7CiAK IAlyZXR1cm4gYnVzX2dlbmVyaWNfcmVzdW1lKGRldik7CkBAIC0xMzIxLDE5ICsxMzM2LDE5IEBA CiAJCW1vcmUgPSBpZ2Jfcnhlb2YocXVlLCBhZGFwdGVyLT5yeF9wcm9jZXNzX2xpbWl0LCBOVUxM KTsKIAogCQlJR0JfVFhfTE9DSyh0eHIpOwotCQlpZiAoaWdiX3R4ZW9mKHR4cikpCi0JCQltb3Jl ID0gVFJVRTsKKwkJaWdiX3R4ZW9mKHR4cik7CiAjaWYgX19GcmVlQlNEX3ZlcnNpb24gPj0gODAw MDAwCiAJCS8qIFByb2Nlc3MgdGhlIHN0YWNrIHF1ZXVlIG9ubHkgaWYgbm90IGRlcGxldGVkICov CiAJCWlmICgoKHR4ci0+cXVldWVfc3RhdHVzICYgSUdCX1FVRVVFX0RFUExFVEVEKSA9PSAwKSAm JgogCQkgICAgIWRyYnJfZW1wdHkoaWZwLCB0eHItPmJyKSkKIAkJCWlnYl9tcV9zdGFydF9sb2Nr ZWQoaWZwLCB0eHIsIE5VTEwpOwogI2Vsc2UKLQkJaWdiX3N0YXJ0X2xvY2tlZCh0eHIsIGlmcCk7 CisJCWlmICghSUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9zbmQpKQorCQkJaWdiX3N0YXJ0X2xv Y2tlZCh0eHIsIGlmcCk7CiAjZW5kaWYKIAkJSUdCX1RYX1VOTE9DSyh0eHIpOwogCQkvKiBEbyB3 ZSBuZWVkIGFub3RoZXI/ICovCi0JCWlmIChtb3JlIHx8IChpZnAtPmlmX2Rydl9mbGFncyAmIElG Rl9EUlZfT0FDVElWRSkpIHsKKwkJaWYgKG1vcmUpIHsKIAkJCXRhc2txdWV1ZV9lbnF1ZXVlKHF1 ZS0+dHEsICZxdWUtPnF1ZV90YXNrKTsKIAkJCXJldHVybjsKIAkJfQpAQCAtMTM1Niw4ICsxMzcx LDM1IEBACiB7CiAJc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIgPSBjb250ZXh0OwogCisJSUdCX0NP UkVfTE9DSyhhZGFwdGVyKTsKKwlpZ2JfaGFuZGxlX2xpbmtfbG9ja2VkKGFkYXB0ZXIpOworCUlH Ql9DT1JFX1VOTE9DSyhhZGFwdGVyKTsKK30KKworc3RhdGljIHZvaWQKK2lnYl9oYW5kbGVfbGlu a19sb2NrZWQoc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIpCit7CisJc3RydWN0IHR4X3JpbmcJKnR4 ciA9IGFkYXB0ZXItPnR4X3JpbmdzOworCXN0cnVjdCBpZm5ldCAqaWZwID0gYWRhcHRlci0+aWZw OworCisJSUdCX0NPUkVfTE9DS19BU1NFUlQoYWRhcHRlcik7CiAJYWRhcHRlci0+aHcubWFjLmdl dF9saW5rX3N0YXR1cyA9IDE7CiAJaWdiX3VwZGF0ZV9saW5rX3N0YXR1cyhhZGFwdGVyKTsKKwlp ZiAoKGlmcC0+aWZfZHJ2X2ZsYWdzICYgSUZGX0RSVl9SVU5OSU5HKSAmJiBhZGFwdGVyLT5saW5r X2FjdGl2ZSkgeworCQlmb3IgKGludCBpID0gMDsgaSA8IGFkYXB0ZXItPm51bV9xdWV1ZXM7IGkr KywgdHhyKyspIHsKKwkJCUlHQl9UWF9MT0NLKHR4cik7CisjaWYgX19GcmVlQlNEX3ZlcnNpb24g Pj0gODAwMDAwCisJCQkvKiBQcm9jZXNzIHRoZSBzdGFjayBxdWV1ZSBvbmx5IGlmIG5vdCBkZXBs ZXRlZCAqLworCQkJaWYgKCgodHhyLT5xdWV1ZV9zdGF0dXMgJiBJR0JfUVVFVUVfREVQTEVURUQp ID09IDApICYmCisJCQkgICAgIWRyYnJfZW1wdHkoaWZwLCB0eHItPmJyKSkKKwkJCQlpZ2JfbXFf c3RhcnRfbG9ja2VkKGlmcCwgdHhyLCBOVUxMKTsKKyNlbHNlCisJCQlpZiAoIUlGUV9EUlZfSVNf RU1QVFkoJmlmcC0+aWZfc25kKSkKKwkJCQlpZ2Jfc3RhcnRfbG9ja2VkKHR4ciwgaWZwKTsKKyNl bmRpZgorCQkJSUdCX1RYX1VOTE9DSyh0eHIpOworCQl9CisJfQogfQogCiAvKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq CkBAIC0xNDM3LDcgKzE0NzksNyBAQAogCQlyZWdfaWNyID0gRTEwMDBfUkVBRF9SRUcoJmFkYXB0 ZXItPmh3LCBFMTAwMF9JQ1IpOwogCQkvKiBMaW5rIHN0YXR1cyBjaGFuZ2UgKi8KIAkJaWYgKHJl Z19pY3IgJiAoRTEwMDBfSUNSX1JYU0VRIHwgRTEwMDBfSUNSX0xTQykpCi0JCQlpZ2JfaGFuZGxl X2xpbmsoYWRhcHRlciwgMCk7CisJCQlpZ2JfaGFuZGxlX2xpbmtfbG9ja2VkKGFkYXB0ZXIpOwog CiAJCWlmIChyZWdfaWNyICYgRTEwMDBfSUNSX1JYTykKIAkJCWFkYXB0ZXItPnJ4X292ZXJydW5z Kys7CkBAIC0xNDU0LDcgKzE0OTYsOCBAQAogCWlmICghZHJicl9lbXB0eShpZnAsIHR4ci0+YnIp KQogCQlpZ2JfbXFfc3RhcnRfbG9ja2VkKGlmcCwgdHhyLCBOVUxMKTsKICNlbHNlCi0JaWdiX3N0 YXJ0X2xvY2tlZCh0eHIsIGlmcCk7CisJaWYgKCFJRlFfRFJWX0lTX0VNUFRZKCZpZnAtPmlmX3Nu ZCkpCisJCWlnYl9zdGFydF9sb2NrZWQodHhyLCBpZnApOwogI2VuZGlmCiAJSUdCX1RYX1VOTE9D Syh0eHIpOwogCXJldHVybiBQT0xMX1JFVFVSTl9DT1VOVChyeF9kb25lKTsKQEAgLTE0NzEsMTYg KzE1MTQsMjYgQEAKIHsKIAlzdHJ1Y3QgaWdiX3F1ZXVlICpxdWUgPSBhcmc7CiAJc3RydWN0IGFk YXB0ZXIgKmFkYXB0ZXIgPSBxdWUtPmFkYXB0ZXI7CisJc3RydWN0IGlmbmV0ICAgKmlmcCA9IGFk YXB0ZXItPmlmcDsKIAlzdHJ1Y3QgdHhfcmluZyAqdHhyID0gcXVlLT50eHI7CiAJc3RydWN0IHJ4 X3JpbmcgKnJ4ciA9IHF1ZS0+cnhyOwogCXUzMgkJbmV3aXRyID0gMDsKLQlib29sCQltb3JlX3R4 LCBtb3JlX3J4OworCWJvb2wJCW1vcmVfcng7CiAKIAlFMTAwMF9XUklURV9SRUcoJmFkYXB0ZXIt Pmh3LCBFMTAwMF9FSU1DLCBxdWUtPmVpbXMpOwogCSsrcXVlLT5pcnFzOwogCiAJSUdCX1RYX0xP Q0sodHhyKTsKLQltb3JlX3R4ID0gaWdiX3R4ZW9mKHR4cik7CisJaWdiX3R4ZW9mKHR4cik7Cisj aWYgX19GcmVlQlNEX3ZlcnNpb24gPj0gODAwMDAwCisJLyogUHJvY2VzcyB0aGUgc3RhY2sgcXVl dWUgb25seSBpZiBub3QgZGVwbGV0ZWQgKi8KKwlpZiAoKCh0eHItPnF1ZXVlX3N0YXR1cyAmIElH Ql9RVUVVRV9ERVBMRVRFRCkgPT0gMCkgJiYKKwkgICAgIWRyYnJfZW1wdHkoaWZwLCB0eHItPmJy KSkKKwkJaWdiX21xX3N0YXJ0X2xvY2tlZChpZnAsIHR4ciwgTlVMTCk7CisjZWxzZQorCWlmICgh SUZRX0RSVl9JU19FTVBUWSgmaWZwLT5pZl9zbmQpKQorCQlpZ2Jfc3RhcnRfbG9ja2VkKHR4ciwg aWZwKTsKKyNlbmRpZgogCUlHQl9UWF9VTkxPQ0sodHhyKTsKIAogCW1vcmVfcnggPSBpZ2Jfcnhl b2YocXVlLCBhZGFwdGVyLT5yeF9wcm9jZXNzX2xpbWl0LCBOVUxMKTsKQEAgLTE1MzgsNyArMTU5 MSw3IEBACiAKIG5vX2NhbGM6CiAJLyogU2NoZWR1bGUgYSBjbGVhbiB0YXNrIGlmIG5lZWRlZCov Ci0JaWYgKG1vcmVfdHggfHwgbW9yZV9yeCkKKwlpZiAobW9yZV9yeCkKIAkJdGFza3F1ZXVlX2Vu cXVldWUocXVlLT50cSwgJnF1ZS0+cXVlX3Rhc2spOwogCWVsc2UKIAkJLyogUmVlbmFibGUgdGhp cyBpbnRlcnJ1cHQgKi8K --f46d04478b775eefcf04bbed54c9-- From owner-freebsd-net@FreeBSD.ORG Fri Mar 23 18:43:30 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 E801A106574E; Fri, 23 Mar 2012 18:43:30 +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 B47B48FC17; Fri, 23 Mar 2012 18:43:26 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 27F4F46B2C; Fri, 23 Mar 2012 14:43:26 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 84139B9A8; Fri, 23 Mar 2012 14:43:25 -0400 (EDT) From: John Baldwin To: Mike Tancsa Date: Fri, 23 Mar 2012 14:19:08 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201203201457.24776.jhb@freebsd.org> <4F6CBC59.2060601@sentex.net> In-Reply-To: <4F6CBC59.2060601@sentex.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201203231419.08514.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 23 Mar 2012 14:43:25 -0400 (EDT) Cc: freebsd-net@freebsd.org, Adrian Chadd , Hooman Fazaeli , Jason Wolfe Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-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, 23 Mar 2012 18:43:31 -0000 On Friday, March 23, 2012 2:09:29 pm Mike Tancsa wrote: > On 3/20/2012 2:57 PM, John Baldwin wrote: > >>> TX when link becomes active. I've also updated it to fix resume for em > >>> and igb to DTRT when buf_ring is used, and to not include old-style start > >>> routines at all when using multiq. It is at > >>> http://www.freebsd.org/~jhb/patches/e1000_txeof2.patch > >> Thank for the patch sirs, so far it does look like it did the trick. > >> I'll know for certain here in a few days if I'm still in the clear. > >> I'm guessing after it goes through some more testing it'll be too late > >> to slip it into 8.3? > > > > Yes, this is too late for 8.3, but thanks for testing! > > Hi, > Is there a RELENG_8 version of this patch ? I have a server that used to > shows this issue quite a bit, but has not since 7.3.2. I would be happy > to stress it on the box. The patch above does not apply cleanly due to > the netmap diffs, but I can manually merge if thats the only difference. I suspect netmap is the only difference. I have not yet tried to make a patch for 8.x. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 10:26:50 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 CA287106566B for ; Sat, 24 Mar 2012 10:26:50 +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 57F458FC14 for ; Sat, 24 Mar 2012 10:26:50 +0000 (UTC) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 64BC75D4B8; Sat, 24 Mar 2012 11:26:43 +0100 (CET) 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 O6gQW5aVO6YE; Sat, 24 Mar 2012 11:26:42 +0100 (CET) Received: from mail.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 819615D4B7; Sat, 24 Mar 2012 11:26:42 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.incore (Postfix) with ESMTP id 0B115450A8; Sat, 24 Mar 2012 11:26:41 +0100 (CET) Message-ID: <4F6DA161.9040408@incore.de> Date: Sat, 24 Mar 2012 11:26:41 +0100 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> In-Reply-To: <20120320041647.GE7518@michelle.cdnetworks.com> Content-Type: text/plain; charset=us-ascii 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: Sat, 24 Mar 2012 10:26:50 -0000 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. >> 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". > 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. 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. Regards Andreas Longwitz From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 12:04: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 6E994106564A for ; Sat, 24 Mar 2012 12:04:08 +0000 (UTC) (envelope-from lexa@lexa.ru) Received: from www.lexa.ru (www.lexa.ru [213.59.0.94]) by mx1.freebsd.org (Postfix) with ESMTP id 221018FC14 for ; Sat, 24 Mar 2012 12:04:07 +0000 (UTC) Received: by www.lexa.ru (Postfix, from userid 66) id 82B741149A; Sat, 24 Mar 2012 15:56:06 +0400 (MSK) Received: from [127.0.0.1] (unknown [193.124.130.130]) by home-gw.lexa.ru (Postfix) with ESMTP id EB97161F9A; Sat, 24 Mar 2012 15:52:11 +0400 (MSK) Message-ID: <4F6DB568.1060604@lexa.ru> Date: Sat, 24 Mar 2012 15:52:08 +0400 From: Alex Tutubalin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 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: Sat, 24 Mar 2012 12:04:08 -0000 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. ==== More details on my setup ==== FreeBSD 9-STABLE, cvsuped today. One box is Core 2 Quad (Q9300), second one Core i7-920 1) Device MELLANOX MHEA28-XTC 10GBPS INFINIBAND HCA CARD (two port) Boot message: ib_mthca0: mem 0xfe900000-0xfe9fffff,0xfd000000-0xfd7fffff irq 16 at device 0.0 on pci1 ib_mthca: Mellanox InfiniBand HCA driver v1.0-ofed1.5.2 (August 4, 2010) Two cards connected via cable, no Infiniband switch 2) Kernel config: include GENERIC options OFED options SDP device ipoib options IPOIB_CM device mthca 3) Regardles of MTU settings (tried 16000, 32000, 48000), actual packed size in tcp flow is about 16000. Have not investigated it in details 4) There is no packet loss: lexa@new-gw:/home/lexa# ping -s 32000 -c 10000 -f 10.1.1.1 PING 10.1.1.1 (10.1.1.1): 32000 data bytes . --- 10.1.1.1 ping statistics --- 10000 packets transmitted, 10000 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.157/0.225/1.758/0.156 ms -- Alex Tutubalin Web: http://blog.lexa.ru mailto:lexa@lexa.ru From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 13:30:41 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 6DAB9106564A for ; Sat, 24 Mar 2012 13:30:41 +0000 (UTC) (envelope-from nyoman.bogi@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id D22F38FC08 for ; Sat, 24 Mar 2012 13:30:40 +0000 (UTC) Received: by lboi15 with SMTP id i15so4070673lbo.13 for ; Sat, 24 Mar 2012 06:30:34 -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=lhZ8uEYzOL1HqqyDee+HnYQ5ON1bGKcDGlIvfCStA4U=; b=Xm0VoCZ61pOlvfTUe0hXECBC2enLns7nXnW29DyLn9TwiOzel2uQDV1tszTNjfjKIR eQEf28ubF9giNRh2xT/vfy9Dp1cwS7ggo7AaIxnrFoh0r7Mig/KBBHdfR1R0i2v3+KE0 i/8uVsJiV7E4/A9f7fzTd9ZcB/8fNz4fgSwS72dYpwthoYA8YEmMyhK02ab0I23D2972 ppPoCfUwT7czcoZ3JfZMzjUakuLqNFkqygTIoCQZCE6ibKLTw0JLhcSDKesw58+ylElq o6zjuh3JW1fD352GZBx4BN5Hgj2bjXHWkvYj/do6l+QCKZGkhjwUi4CqkTMlQFDqXzvd YVrQ== MIME-Version: 1.0 Received: by 10.152.105.241 with SMTP id gp17mr12745684lab.21.1332595834360; Sat, 24 Mar 2012 06:30:34 -0700 (PDT) Received: by 10.112.67.49 with HTTP; Sat, 24 Mar 2012 06:30:34 -0700 (PDT) In-Reply-To: References: Date: Sat, 24 Mar 2012 20:30:34 +0700 Message-ID: From: "nyoman.bogi@gmail.com" To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: firewall stuck X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 13:30:41 -0000 On Thu, Mar 15, 2012 at 11:47 AM, Kevin Oberman wrote: > Please don't top post. It makes following the thread very difficult. > (Yes, I know too many MUAs make this difficult.) > > > On Wed, Mar 14, 2012 at 1:12 PM, Kevin Oberman > wrote: > >> > >> On Tue, Mar 13, 2012 at 7:27 PM, nyoman.bogi@gmail.com > >> wrote: > >> > dear guru, > >> > > >> > every time I open my firewall to allow SSH connection from Internet > >> > after few days my firewall always stuck. Stuck in here meaning > >> > that it deny all request (deny any from any). > >> > And after I "ipfw disable firewall" and then "ipfw enable firewall" > >> > everything works fine > >> > > >> > when I checked /var/log/messages I found lots of attempts > >> > people try to connect to my machine. > >> > why my machine get stuck when lots of people try to SSH to my machine? > >> > >> We need a bit more information, especially your ipfw configuration. Is > >> it a statefull firewall? It sounds a lot like your state table might > >> be filling for some reason. Of course, if it is not a statefull > >> firewall, that idea is probably wrong, though it could be a > >> misconfiguration of some statefull rule that is inadvertently catching > >> the SSH attempts. > >> > >> Have you done an 'ipfw show' to see what rules are being matched? it > >> may or may not provide a clue. > >> -- > >> R. Kevin Oberman, Network Engineer > >> E-mail: kob6558@gmail.com > On Wed, Mar 14, 2012 at 6:04 PM, nyoman.bogi@gmail.com > wrote: > > thanks Kevin, > > this is my "ipfw show" : > > > > 00100 4352617 2413620288 allow ip from any to any via lo0 > > 00200 0 0 deny ip from any to 127.0.0.0/8 > > 00300 0 0 deny ip from 127.0.0.0/8 to any > > 00400 0 0 deny ip from any to ::1 > > 00500 0 0 deny ip from ::1 to any > > 00600 54387 5454184 allow icmp from any to any > > 00700 3142231 1681082246 allow ip from 10.1.1.28 to 10.1.1.0/26 > > 00800 4659459 4478397111 allow ip from 10.1.1.0/26 to 10.1.1.28 > > 00900 0 0 check-state > > 01000 137997 89083135 allow tcp from 10.1.1.28 to any setup > keep-state > > 01100 0 0 allow tcp from 10.16.10.84 to any setup > > keep-state > > 01150 401205 276677828 allow tcp from any to 10.1.1.28 dst-port 22 > setup > > keep-state > > 01200 245718 44249729 allow udp from 10.1.1.28 to any keep-state > > 01300 5876930 239194755 allow tcp from any to any established > > 01400 0 0 allow tcp from any to 10.1.1.28 dst-port 389 > > setup keep-state > > 01500 26341187 22030370786 allow tcp from any to 10.1.1.28 dst-port 80 > setup > > keep-state > > 01600 80945 61013964 allow tcp from any to 10.1.1.28 dst-port 443 > > setup keep-state > > 01700 0 0 allow tcp from 10.1.1.2 to 10.1.1.28 dst-port > 22 > > setup keep-state > > 01800 149642 97939477 allow tcp from any to 10.1.1.28 dst-port 25 > setup > > keep-state > > 01900 140 7501 allow tcp from 10.1.0.0/16 to 10.1.1.28 > dst-port > > 110 setup keep-state > > 02000 1677982 89212845 allow tcp from any to 10.1.1.28 dst-port 110 > > setup keep-state > > 02100 8996 432096 deny tcp from any to any setup > > 02200 244111 24117256 allow udp from any to 10.1.1.28 dst-port 53 > > keep-state > > 02300 0 0 allow udp from any to 10.1.1.12 dst-port 53 > > keep-state > > 65535 4610 1422974 deny ip from any to any > > > > I use FreeBSD 8.2 : > > FreeBSD 8.2-RELEASE (GENERIC) #0: Fri Feb 18 02:24:46 UTC 2011 > > > > the problem start after I add rule 01150 > > so you do have a stateful rule for ssh. Putting stateful rules on > services is risky because you always open yourself to DOS, ether > intentionally or by accident. Every stateful access requires resources > from a limited pool. You can look at this pool information with: > sysctl net.inet.ip.fw | grep dyn > man ipfw describes them in the "SYSCTL VARIABLES" section. > > I am wondering why you want a stateful rule for this. It's very risky > and it looks like you are getting bitten, either by accident or a > deliberate effort to DOS you. I suspect the former. > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6558@gmail.com > thanks a lot Kevin, your hint is really helpful. I have change the SSH connection into non stateful. do you think I should change the HTTP connection into non stateful also? -- ------------------------------- Bogi Aditya Sisfo - IMTelkom http://bogi.blog.imtelkom.ac.id From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 15:14:34 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 E72F6106566B; Sat, 24 Mar 2012 15:14:34 +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 BA6B48FC08; Sat, 24 Mar 2012 15:14:34 +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 q2OFEYok093930; Sat, 24 Mar 2012 15:14:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2OFEYCj093926; Sat, 24 Mar 2012 15:14:34 GMT (envelope-from linimon) Date: Sat, 24 Mar 2012 15:14:34 GMT Message-Id: <201203241514.q2OFEYCj093926@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166372: [patch] ipfilter drops UDP packets with zero checksum on some interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 15:14:35 -0000 Synopsis: [patch] ipfilter drops UDP packets with zero checksum on some interfaces Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 24 15:14:26 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166372 From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 17:06:38 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 4645B106566C for ; Sat, 24 Mar 2012 17:06:38 +0000 (UTC) (envelope-from kob6558@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 C97128FC18 for ; Sat, 24 Mar 2012 17:06:37 +0000 (UTC) Received: by wern13 with SMTP id n13so4436368wer.13 for ; Sat, 24 Mar 2012 10:06:36 -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=x9BsfBUzKzMyIeTXdJMpxl/0f28H5vL5+xNCi+vmgF8=; b=XTjSF4xqKJCRs4Ry8SsXPnIbf00cHhe0Q3f/Bn5/e705eifSoVx64dche0WvhlMtDv GjSvcE3ynt/P0oBN5Zf6Pu+7Kt64Tqn+9QAxouR+jIL1j1ysUl/1bMa3SbwL9b8H9AQo JEeLbM6PZNuGrRdjLNrHNim7lh3JrNTC64+e+OztjkDyebq0kC+b2EQa3H8afrMp/X76 920eEynkRb+Ta8PpHhPT8TPd0NKrqCMXcLGpVp4dvxu7cxrfWZtRWvlxZiCh9ZiBWV8T 1WhLpuHeR2wOBdIOK8KqJAlrC1BhfW7Aa8p8AbAh14Is5ZVdssXtbDamuoJVxIGusPYr T+2Q== MIME-Version: 1.0 Received: by 10.180.81.166 with SMTP id b6mr6066359wiy.0.1332608796926; Sat, 24 Mar 2012 10:06:36 -0700 (PDT) Received: by 10.223.143.3 with HTTP; Sat, 24 Mar 2012 10:06:36 -0700 (PDT) In-Reply-To: References: Date: Sat, 24 Mar 2012 10:06:36 -0700 Message-ID: From: Kevin Oberman To: "nyoman.bogi@gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: firewall stuck X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 17:06:38 -0000 On Sat, Mar 24, 2012 at 6:30 AM, nyoman.bogi@gmail.com wrote: > On Thu, Mar 15, 2012 at 11:47 AM, Kevin Oberman wrote= : >> >> Please don't top post. It makes following the thread very difficult. >> (Yes, I know too many MUAs make this difficult.) >> >> =A0> On Wed, Mar 14, 2012 at 1:12 PM, Kevin Oberman >> wrote: >> >> >> >> On Tue, Mar 13, 2012 at 7:27 PM, nyoman.bogi@gmail.com >> >> wrote: >> >> > dear guru, >> >> > >> >> > every time I open my firewall to allow SSH connection from Internet >> >> > after few days my firewall always stuck. Stuck in here meaning >> >> > that it deny all request (deny any from any). >> >> > And after I "ipfw disable firewall" and then "ipfw enable firewall" >> >> > everything works fine >> >> > >> >> > when I checked /var/log/messages I found lots of attempts >> >> > people try to connect to my machine. >> >> > why my machine get stuck when lots of people try to SSH to my >> >> > machine? >> >> >> >> We need a bit more information, especially your ipfw configuration. I= s >> >> it a statefull firewall? It sounds a lot like your state table might >> >> be filling for some reason. Of course, if it is not a statefull >> >> firewall, that idea is probably wrong, though it could be a >> >> misconfiguration of some statefull rule that is inadvertently catchin= g >> >> the SSH attempts. >> >> >> >> Have you done an 'ipfw show' to see what rules are being matched? it >> >> may or may not provide a clue. >> >> -- >> >> R. Kevin Oberman, Network Engineer >> >> E-mail: kob6558@gmail.com >> On Wed, Mar 14, 2012 at 6:04 PM, nyoman.bogi@gmail.com >> wrote: >> > thanks Kevin, >> > this is my "ipfw show" : >> > >> > 00100 =A04352617 =A02413620288 allow ip from any to any via lo0 >> > 00200 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 0 deny ip from any to 127.0= .0.0/8 >> > 00300 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 0 deny ip from 127.0.0.0/8 = to any >> > 00400 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 0 deny ip from any to ::1 >> > 00500 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 0 deny ip from ::1 to any >> > 00600 =A0 =A054387 =A0 =A0 5454184 allow icmp from any to any >> > 00700 =A03142231 =A01681082246 allow ip from 10.1.1.28 to 10.1.1.0/26 >> > 00800 =A04659459 =A04478397111 allow ip from 10.1.1.0/26 to 10.1.1.28 >> > 00900 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 0 check-state >> > 01000 =A0 137997 =A0 =A089083135 allow tcp from 10.1.1.28 to any setup >> > keep-state >> > 01100 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 0 allow tcp from 10.16.10.8= 4 to any setup >> > keep-state >> > 01150 =A0 401205 =A0 276677828 allow tcp from any to 10.1.1.28 dst-por= t 22 >> > setup >> > keep-state >> > 01200 =A0 245718 =A0 =A044249729 allow udp from 10.1.1.28 to any keep-= state >> > 01300 =A05876930 =A0 239194755 allow tcp from any to any established >> > 01400 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 0 allow tcp from any to 10.= 1.1.28 dst-port 389 >> > setup keep-state >> > 01500 26341187 22030370786 allow tcp from any to 10.1.1.28 dst-port 80 >> > setup >> > keep-state >> > 01600 =A0 =A080945 =A0 =A061013964 allow tcp from any to 10.1.1.28 dst= -port 443 >> > setup keep-state >> > 01700 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 0 allow tcp from 10.1.1.2 t= o 10.1.1.28 dst-port >> > 22 >> > setup keep-state >> > 01800 =A0 149642 =A0 =A097939477 allow tcp from any to 10.1.1.28 dst-p= ort 25 >> > setup >> > keep-state >> > 01900 =A0 =A0 =A0140 =A0 =A0 =A0 =A07501 allow tcp from 10.1.0.0/16 to= 10.1.1.28 >> > dst-port >> > 110 setup keep-state >> > 02000 =A01677982 =A0 =A089212845 allow tcp from any to 10.1.1.28 dst-p= ort 110 >> > setup keep-state >> > 02100 =A0 =A0 8996 =A0 =A0 =A0432096 deny tcp from any to any setup >> > 02200 =A0 244111 =A0 =A024117256 allow udp from any to 10.1.1.28 dst-p= ort 53 >> > keep-state >> > 02300 =A0 =A0 =A0 =A00 =A0 =A0 =A0 =A0 =A0 0 allow udp from any to 10.= 1.1.12 dst-port 53 >> > keep-state >> > 65535 =A0 =A0 4610 =A0 =A0 1422974 deny ip from any to any >> > >> > I use FreeBSD 8.2 : >> > FreeBSD 8.2-RELEASE (GENERIC) #0: Fri Feb 18 02:24:46 UTC 2011 >> > >> > the problem start after I add rule 01150 >> >> so you do have a stateful rule for ssh. Putting stateful rules on >> services is risky because you always open yourself to DOS, ether >> intentionally or by accident. Every stateful access requires resources >> from a limited pool. You can look at this pool information with: >> sysctl net.inet.ip.fw | grep dyn >> man ipfw describes them in the "SYSCTL VARIABLES" section. >> >> I am wondering why you want a stateful rule for this. It's very risky >> and it looks like you are getting bitten, either by accident or a >> deliberate effort to DOS you. I suspect the former. >> -- >> R. Kevin Oberman, Network Engineer >> E-mail: kob6558@gmail.com > > > > thanks a lot Kevin, your hint is really helpful. > I have change the SSH connection into non stateful. > > do you think I should change the HTTP connection into non stateful also? Almost certainly. One of the most common DOS attacks is just to flood a popular port with connection requests and port 80 is the most commonly used. There are ways to mitigate this a bit by quickly dropping the state entry when the 3-way handshake is not completed, but it's still pretty easy to exploit. and, of course, if your website ever gets significant publicity, the number of legitimate connections can cause you trouble. (This is commonly called being "slashdoted".) What you need to do is ask if a stateful firewall is really of any benefit for port 80. What does it help, if anything? For UDP apps, where the protocol does not maintain any state, stateful may make sense, but for TCP, it's less obvious. Can you gethte same benefits from a stateless entry? Perhaps with the addition of tables so block entries can be quickly added and deleted? --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 20:12:43 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 171E4106564A; Sat, 24 Mar 2012 20:12:43 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id E18928FC1C; Sat, 24 Mar 2012 20:12:42 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id q2OK8sh7084220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Mar 2012 13:08:54 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id q2OK8sgn084219; Sat, 24 Mar 2012 13:08:54 -0700 (PDT) (envelope-from jmg) Date: Sat, 24 Mar 2012 13:08:53 -0700 From: John-Mark Gurney To: Juli Mallett Message-ID: <20120324200853.GE2253@funkthat.com> Mail-Followup-To: Juli Mallett , Ivan Voras , freebsd-net@freebsd.org References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 24 Mar 2012 13:08:54 -0700 (PDT) Cc: freebsd-net@freebsd.org, Ivan Voras Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 20:12:43 -0000 Juli Mallett wrote this message on Thu, Feb 23, 2012 at 08:03 -0800: > Which sounds slightly off-topic, except that dedicating loads of mbufs > to receive queues that will sit empty on the vast majority of systems > and receive a few packets per second in the service of some kind of > magical thinking or excitement about multiqueue reception may be a > little ill-advised. On my desktop with hardware supporting multiple > queues, do I really want to use the maximum number of them just to > handle a few thousand packets per second? One core can do that just > fine. > > FreeBSD's great to drop-in on forwarding systems that will have > moderate load, but it seems the best justification for this default is > so users need fewer reboots to get more queues to spread what is > assumed to be an evenly-distributed load over other cores. In > practice, isn't the real problem that we have no facility for changing > the number of queues at runtime? > > If the number of queues weren't fixed at boot, users could actually > find the number that suits them best with a plausible amount of work, > and the point about FreeBSD being "slow" goes away since it's perhaps > one more sysctl to set (or one per-interface) or one (or one-per) > ifconfig line to run, along with enabling forwarding, etc. > > The big commitment that multi-queue drivers ask for when they use the > maximum number of queues on boot and then demand to fill those queues > up with mbufs is unreasonable, even if it can be met on a growing > number of systems without much in the way of pain. It's unreasonable, > but perhaps it feels good to see all those interrupts bouncing around, > all those threads running from time to time in top. Maybe it makes > FreeBSD seem more serious, or perhaps it's something that gets people > excited. It gives the appearance of doing quite a bit behind the > scenes, and perhaps that's beneficial in and of itself, and will keep > users from imagining that FreeBSD is slow, to your point. We should > be clear, though, whether we are motivated by technical or > psychological constraints and benefits. Sorry the wake up this thread, but I wanted to add another announce I've had with most of the ethernet drivers relating to mbufs. This is the fact that if upon packet receive that it can't allocate a new mbuf cluster to replace the received packet in the receive queue that it "drops" the packet to use the received packets as a replacement. There should either be another thread or after the packet has been processed the option of the ethernet driver getting it back to put back into the receive queue. I've run into systems that were very low memory and ran out of mbufs, but you couldn't log into them over the network because all the mbufs were busy, and each attempt to log in was dropped. It doesn't make much sense to keep possibly 4MB/port (or more) of memory used that "effictively" never gets used, just increasing the ammount of memory required to run a "quiet" system... If we had some sort of tuning algorithm that would keep track of the current receive queue usage depth, and always keep enough mbufs on the queue to handle the largest expected burst of packets (either historical, or by looking at largest tcp window size, etc), this would both improve memory usage, and in general reduce the number of require mbufs on the system... If you have fast processors, you might be able to get away with less mbufs since you can drain the receive queue faster, but on slower systems, you would use more mbufs. This tuning would also fix the problem of interfaces not coming up since at boot, each interface might only allocate 128 or so mbufs, and then dynamicly grow as necessary... Just my 2 cents. P.S. I removed -stable from the CC list. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 20:33:19 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 667FF106564A; Sat, 24 Mar 2012 20:33:19 +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 5DCDC8FC0C; Sat, 24 Mar 2012 20:33:18 +0000 (UTC) Received: by wibhq7 with SMTP id hq7so2576072wib.13 for ; Sat, 24 Mar 2012 13:33:17 -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=ApLJYtP0OE6T29kL24sVmufDtNUd9iVqDxS3rmJhBSs=; b=VsxO1BxmGsIapPFMXNP4zAw8IPkI3NrV76RfEWKv3cKuzodabagSCYvg4G9+okIpIX PIeYEHAIpz4TrxLc4M97I0IdXAx1M0CVNUXuN62xZCkz1O9yytErNTxEfNP+J3+vBRSr QRVfqM3JXm3nBmuP1/m9J0XO74BgISa9fBS1Nb/WqZH0abZi0WLpfAt8SInYmaQnwWAV m3VwBuMpw+aYNe8SqQMZ+D/tyvynrdhCc4vyE7oXkDP7vTi/JmL96l371Le4Hb68/qv+ o2QgVCLr/zLp7FP/gk635gOf/7rx8QZbGbTXgRjvQi8s1iiCexKYUUdD3qfOA48LVDU+ KVmw== MIME-Version: 1.0 Received: by 10.216.131.24 with SMTP id l24mr9423981wei.76.1332621197394; Sat, 24 Mar 2012 13:33:17 -0700 (PDT) Received: by 10.180.82.168 with HTTP; Sat, 24 Mar 2012 13:33:17 -0700 (PDT) In-Reply-To: <20120324200853.GE2253@funkthat.com> References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> <20120324200853.GE2253@funkthat.com> Date: Sat, 24 Mar 2012 13:33:17 -0700 Message-ID: From: Jack Vogel To: Juli Mallett , Ivan Voras , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 20:33:19 -0000 On Sat, Mar 24, 2012 at 1:08 PM, John-Mark Gurney wrote: > Juli Mallett wrote this message on Thu, Feb 23, 2012 at 08:03 -0800: > > Which sounds slightly off-topic, except that dedicating loads of mbufs > > to receive queues that will sit empty on the vast majority of systems > > and receive a few packets per second in the service of some kind of > > magical thinking or excitement about multiqueue reception may be a > > little ill-advised. On my desktop with hardware supporting multiple > > queues, do I really want to use the maximum number of them just to > > handle a few thousand packets per second? One core can do that just > > fine. > > > > FreeBSD's great to drop-in on forwarding systems that will have > > moderate load, but it seems the best justification for this default is > > so users need fewer reboots to get more queues to spread what is > > assumed to be an evenly-distributed load over other cores. In > > practice, isn't the real problem that we have no facility for changing > > the number of queues at runtime? > > > > If the number of queues weren't fixed at boot, users could actually > > find the number that suits them best with a plausible amount of work, > > and the point about FreeBSD being "slow" goes away since it's perhaps > > one more sysctl to set (or one per-interface) or one (or one-per) > > ifconfig line to run, along with enabling forwarding, etc. > > > > The big commitment that multi-queue drivers ask for when they use the > > maximum number of queues on boot and then demand to fill those queues > > up with mbufs is unreasonable, even if it can be met on a growing > > number of systems without much in the way of pain. It's unreasonable, > > but perhaps it feels good to see all those interrupts bouncing around, > > all those threads running from time to time in top. Maybe it makes > > FreeBSD seem more serious, or perhaps it's something that gets people > > excited. It gives the appearance of doing quite a bit behind the > > scenes, and perhaps that's beneficial in and of itself, and will keep > > users from imagining that FreeBSD is slow, to your point. We should > > be clear, though, whether we are motivated by technical or > > psychological constraints and benefits. > > Sorry the wake up this thread, but I wanted to add another announce > I've had with most of the ethernet drivers relating to mbufs. This is > the fact that if upon packet receive that it can't allocate a new mbuf > cluster to replace the received packet in the receive queue that it > "drops" the packet to use the received packets as a replacement. > Drivers have always had this design, the rx hardware has to do something with the data in the pipeline, so if there's nowhere to DMA it, it drops it. Its not a problem, it gets retransmitted. The goal is to have a system tuned to minimize the event. > > There should either be another thread or after the packet has been > processed the option of the ethernet driver getting it back to put back > into the receive queue. I've run into systems that were very low > memory and ran out of mbufs, but you couldn't log into them over the > network because all the mbufs were busy, and each attempt to log in > was dropped. It doesn't make much sense to keep possibly 4MB/port (or > more) of memory used that "effictively" never gets used, just > increasing the ammount of memory required to run a "quiet" system... > > If we had some sort of tuning algorithm that would keep track of the > current receive queue usage depth, and always keep enough mbufs on the > queue to handle the largest expected burst of packets (either historical, > or by looking at largest tcp window size, etc), this would both improve > memory usage, and in general reduce the number of require mbufs on the > system... If you have fast processors, you might be able to get away with > less mbufs since you can drain the receive queue faster, but on slower > systems, you would use more mbufs. > These are the days when machines might have 64 GIGABYTES of main storage, so having sufficient memory to run high performance networking seems little to ask. > > This tuning would also fix the problem of interfaces not coming up since > at boot, each interface might only allocate 128 or so mbufs, and then > dynamicly grow as necessary... > > You want modern fast networked servers but only giving them 128 mbufs, ya right , allocating memory takes time, so when you do this people will whine about latency :) When you start pumping 10G...40G...100G ...the scale of the system is different, thinking in terms of the old 10Mb or 100Mb days just doesn't work. Sorry but the direction is to scale everything, not pare back on the network IMHO. Jack > Just my 2 cents. > > P.S. I removed -stable from the CC list. > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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 Sat Mar 24 21:02:22 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 D9EE21065672 for ; Sat, 24 Mar 2012 21:02:22 +0000 (UTC) (envelope-from juli@clockworksquid.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 5CE688FC1A for ; Sat, 24 Mar 2012 21:02:21 +0000 (UTC) Received: by wern13 with SMTP id n13so4529572wer.13 for ; Sat, 24 Mar 2012 14:02:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=DL3Qz/i3T/gmv2anBMpoh4sy7qMVgA31sOm8G+XkxqA=; b=Wsbtw1j6lPkPBPLSUsP2SwC7iAHIZAushb6bsMrKuRM+qhLPe/KLscaa0CjHGIkGYq jyMo4HC3Q++BY9aDx25sHzHrVmh8P1pAK5Gw8EJ1PTemjxvEZd4l5a5n0IX03IpMUBYU 355REYV4GV/P8GVaUPmmGmbmz3jWp4OUt58rYP6LLIG6yim1Fdzv4vL2XhF+SI616sNI cYj9ASAbEP1atznFPzaWOJIHb/v0Fk9APri9qE7IEHqcAQHPhUofhd+KbexaQnKiZg/b j/vdu1ZcUFIStdD/EQc9oI1KYOwHh/Tix2lI9V8Pv5QDwRXDFyxaBAmfcDOIFl09E7pf C4jg== Received: by 10.180.83.198 with SMTP id s6mr7010712wiy.8.1332622941120; Sat, 24 Mar 2012 14:02:21 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.180.106.198 with HTTP; Sat, 24 Mar 2012 14:02:00 -0700 (PDT) In-Reply-To: References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> <20120324200853.GE2253@funkthat.com> From: Juli Mallett Date: Sat, 24 Mar 2012 14:02:00 -0700 X-Google-Sender-Auth: dl6dFl2QxyK_oibODQquPO2Dy0g Message-ID: To: Jack Vogel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkboCpRM9bGQYCrRJNiKopwdJItzkcMsOeVwCFWxxKtc4pGhqIPRR/Tyg9F7W3e/q+DawRX Cc: freebsd-net@freebsd.org, Ivan Voras Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 21:02:22 -0000 On Sat, Mar 24, 2012 at 13:33, Jack Vogel wrote: > On Sat, Mar 24, 2012 at 1:08 PM, John-Mark Gurney wrot= e: >> If we had some sort of tuning algorithm that would keep track of the >> current receive queue usage depth, and always keep enough mbufs on the >> queue to handle the largest expected burst of packets (either historical= , >> or by looking at largest tcp window size, etc), this would both improve >> memory usage, and in general reduce the number of require mbufs on the >> system... =C2=A0If you have fast processors, you might be able to get aw= ay with >> less mbufs since you can drain the receive queue faster, but on slower >> systems, you would use more mbufs. > > These are the days when machines might have 64 GIGABYTES of main storage, > so having sufficient memory to run high performance networking seems litt= le > to > ask. I think the suggestion is that this should be configurable. FreeBSD is also being used on systems, in production, doing networking-related tasks, with <128MB of RAM. And it works fine, more or less. >> This tuning would also fix the problem of interfaces not coming up since >> at boot, each interface might only allocate 128 or so mbufs, and then >> dynamicly grow as necessary... > > You want modern fast networked servers but only giving them 128 mbufs, > ya right , allocating memory takes time, so when you do this people will > whine about latency :) Allocating memory doesn't have to take much time. A multi-queue driver could steal mbufs from an underutilized queue. It could grow the number of descriptors based on load. Some of those things are hard to implement in the first place and harder to cover the corner cases of, but not all. > When you start pumping 10G...40G...100G ...the scale of the system > is different, thinking in terms of the old 10Mb or 100Mb days just doesn'= t > work. This is a red herring. Yes, some systems need to do 40/100G. They require special tuning. The default shouldn't assume that everyone's getting maximum pps. This seems an especially-silly argument when much of the silicon available can't even keep up with maximum packet rates with minimally-sized frames, at 10G or even at 1G. But again, 1G NICs are the default now. Does every FreeBSD system with a 1G NIC have loads of memory? No. I have an Atheros system with 2 1G NICs and 256MB of RAM. It can't do anything at 1gbps. Not even drop packets. Why should its memory usage model be tuned for something it can't do? I'm not saying it should be impossible to allocate a bajillion gigaquads of memory to receive rings, I certainly do it myself all the time. But choosing defaults is a tricky thing, and systems that are "pumping 10G" need other tweaks anyway, whether that's enabling forwarding or something else. Because they have to be configured for the task that they are to do. If part of that is increasing the number of receive descriptors (as the Intel drivers already allow us to do =E2=80=94 thanks, Jack) and the number of queues, is that such a bad thing? I really don't think it makes sense for my 8-core system or my 16-core system to come up with 8- or 16-queues *per interface*. That just doesn't make sense. 8/N or 16/N queues where N is the number of interfaces makes more sense under heavy load. 1 queue per port is *ideal* if a single core can handle the load of that interface. > Sorry but the direction is to scale everything, not pare back on the netw= ork > IMHO. There is not just one direction. There is not just one point of scaling. Relatively-new defaults do not necessarily have to be increased in the future. I mean, should a 1G NIC use 64 queues on a 64-core system that can do 100gbps @ 64 bytes on one core? It's actively-harmful to performance. The answer to "what's the most sensible default?" is not "what does a system that just forwards packets need?" A system that just forwards packets already needs IPs configured and a sysctl set. If we make it easier to change the tuning of the system for that scenario, then nobody's going to care what our defaults are, or think us "slow" for them. From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 21:17: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 3CF91106564A; Sat, 24 Mar 2012 21:17:15 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 90CAB8FC17; Sat, 24 Mar 2012 21:17:14 +0000 (UTC) Received: by yhgm50 with SMTP id m50so4062883yhg.13 for ; Sat, 24 Mar 2012 14:17:08 -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:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=AGIOFSLeIpZoVBDXm2lzUNUE2a1VLSzCbnJwv/aRMps=; b=MIMTGlI78OxiIPWg/yVQNHO8onTvL+EmDxggmlgbOsDgZTFr5Uc49K01tdahWk8zRn ZZiqnnbVKM2jR+4fmmnmjKC3J9YIZubiG+Up1cHmaVw6HSwOCtc3yz3y2NnN+Lz/E1iN i18+LgqNJ2Z07bHD4VD+RGhUsFjVqjGw413hhM5cd4twD8v41h6hKdIUyNiMNiBQDZr1 10EZdwZctGLIYRfCoNrVLFXuN2mSSOlW7l9nww/5ou18e8XTkQp/hU4V8Y896dZFBUk7 I+nGB4NxLqXQzAPVUU8WVgQNDSQnsopfRrb6/kJPE9AvlilQHdDzQmVxMVG5jo1k9If1 YK6A== Received: by 10.236.152.73 with SMTP id c49mr16969114yhk.91.1332623828484; Sat, 24 Mar 2012 14:17:08 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.101.101.10 with HTTP; Sat, 24 Mar 2012 14:16:28 -0700 (PDT) In-Reply-To: References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> <20120324200853.GE2253@funkthat.com> From: Ivan Voras Date: Sat, 24 Mar 2012 22:16:28 +0100 X-Google-Sender-Auth: aluScvRRQxZix_hYqRODFPdbZMA Message-ID: To: Juli Mallett Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 21:17:15 -0000 On 24 March 2012 22:02, Juli Mallett wrote: > If we make it easier to change the > tuning of the system for that scenario, then nobody's going to care > what our defaults are, or think us "slow" for them. Unfortunately, years of past experience goes against this particular argument. There are simply too many cases where users complain on the mailing lists that "X is slow", only to receive an answer "well then, tune Y, the last time Y has been updated has been in 4.4BSD" or somesuch. > But again, 1G NICs are the default now. Does every FreeBSD system > with a 1G NIC have loads of memory? No. I have an Atheros system > with 2 1G NICs and 256MB of RAM. It can't do anything at 1gbps. Not > even drop packets. Why should its memory usage model be tuned for > something it can't do? I don't think anyone is advocating such nonsense as tuning the defaults so that they blow out the memory configuration :) Any such tuning will probably be done either as a linear function of the present RAM, or as a "stepped" function of the same, e.g. "if RAM < 256MB then keep the defaults from 1980s, else if RAM < 1024 MB, use defaults from 1990s, else do the right thing and use an equation". Would you be happy with this? From owner-freebsd-net@FreeBSD.ORG Sat Mar 24 21:18:04 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 AB505106567F; Sat, 24 Mar 2012 21:18:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by mx1.freebsd.org (Postfix) with ESMTP id A227A8FC1A; Sat, 24 Mar 2012 21:18:03 +0000 (UTC) Received: by wibhr17 with SMTP id hr17so2743222wib.1 for ; Sat, 24 Mar 2012 14:17:57 -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=qqw+E28ybgHipYM9OGFzuBu+5Pbrvsj40rlhPx4mTvc=; b=OvKLgSbAtypaDBCriVg0NCqFEv4VgxmbbktNLQeQiTlJsoZWpHuDo/ZuiS8oPVzwLI jt5QQs3iIjOMclZMVDEc+Uyr/C8QP3DeGlS2zUR3U8HoT/TBeQfhsbvYO0SOYdM7RXqP AlipTh8rWP72VKvdHz41Zz8J1wj2dTRHaU3ikJqrPwtyhCuLegsl94+98mTD/Gb5r7kB HfPnB0oaAakLa2Dri/YCXm+mTIyeM63pLRaSSpi6RFOGsaT1eY5yYtBnwYhvmNZv0Muw 762lxR+xSIO05UKoVgnjV8zQ1PL6+cvKZs5Y2djdh8aW0HbgU7zaEFaeKLQ0QlzEBFFE x2vQ== MIME-Version: 1.0 Received: by 10.180.82.132 with SMTP id i4mr7071099wiy.12.1332623877495; Sat, 24 Mar 2012 14:17:57 -0700 (PDT) Received: by 10.180.82.168 with HTTP; Sat, 24 Mar 2012 14:17:57 -0700 (PDT) In-Reply-To: References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> <20120324200853.GE2253@funkthat.com> Date: Sat, 24 Mar 2012 14:17:57 -0700 Message-ID: From: Jack Vogel To: Juli Mallett Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Ivan Voras Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 21:18:04 -0000 This whole issue only came up on a system with 10G devices, and only igb does anything like you're talking about, not a device/driver on most low en= d systems. So, we are trading red herrings it would seem. I'm not opposed to economizing things in a sensible way, it was I that brought the issue up after all :) Jack On Sat, Mar 24, 2012 at 2:02 PM, Juli Mallett wrote: > On Sat, Mar 24, 2012 at 13:33, Jack Vogel wrote: > > On Sat, Mar 24, 2012 at 1:08 PM, John-Mark Gurney > wrote: > >> If we had some sort of tuning algorithm that would keep track of the > >> current receive queue usage depth, and always keep enough mbufs on the > >> queue to handle the largest expected burst of packets (either > historical, > >> or by looking at largest tcp window size, etc), this would both improv= e > >> memory usage, and in general reduce the number of require mbufs on the > >> system... If you have fast processors, you might be able to get away > with > >> less mbufs since you can drain the receive queue faster, but on slower > >> systems, you would use more mbufs. > > > > These are the days when machines might have 64 GIGABYTES of main storag= e, > > so having sufficient memory to run high performance networking seems > little > > to > > ask. > > I think the suggestion is that this should be configurable. FreeBSD > is also being used on systems, in production, doing networking-related > tasks, with <128MB of RAM. And it works fine, more or less. > > >> This tuning would also fix the problem of interfaces not coming up sin= ce > >> at boot, each interface might only allocate 128 or so mbufs, and then > >> dynamicly grow as necessary... > > > > You want modern fast networked servers but only giving them 128 mbufs, > > ya right , allocating memory takes time, so when you do this people wil= l > > whine about latency :) > > Allocating memory doesn't have to take much time. A multi-queue > driver could steal mbufs from an underutilized queue. It could grow > the number of descriptors based on load. Some of those things are > hard to implement in the first place and harder to cover the corner > cases of, but not all. > > > When you start pumping 10G...40G...100G ...the scale of the system > > is different, thinking in terms of the old 10Mb or 100Mb days just > doesn't > > work. > > This is a red herring. Yes, some systems need to do 40/100G. They > require special tuning. The default shouldn't assume that everyone's > getting maximum pps. This seems an especially-silly argument when > much of the silicon available can't even keep up with maximum packet > rates with minimally-sized frames, at 10G or even at 1G. > > But again, 1G NICs are the default now. Does every FreeBSD system > with a 1G NIC have loads of memory? No. I have an Atheros system > with 2 1G NICs and 256MB of RAM. It can't do anything at 1gbps. Not > even drop packets. Why should its memory usage model be tuned for > something it can't do? > > I'm not saying it should be impossible to allocate a bajillion > gigaquads of memory to receive rings, I certainly do it myself all the > time. But choosing defaults is a tricky thing, and systems that are > "pumping 10G" need other tweaks anyway, whether that's enabling > forwarding or something else. Because they have to be configured for > the task that they are to do. If part of that is increasing the > number of receive descriptors (as the Intel drivers already allow us > to do =97 thanks, Jack) and the number of queues, is that such a bad > thing? I really don't think it makes sense for my 8-core system or my > 16-core system to come up with 8- or 16-queues *per interface*. That > just doesn't make sense. 8/N or 16/N queues where N is the number of > interfaces makes more sense under heavy load. 1 queue per port is > *ideal* if a single core can handle the load of that interface. > > > Sorry but the direction is to scale everything, not pare back on the > network > > IMHO. > > There is not just one direction. There is not just one point of > scaling. Relatively-new defaults do not necessarily have to be > increased in the future. I mean, should a 1G NIC use 64 queues on a > 64-core system that can do 100gbps @ 64 bytes on one core? It's > actively-harmful to performance. The answer to "what's the most > sensible default?" is not "what does a system that just forwards > packets need?" A system that just forwards packets already needs IPs > configured and a sysctl set. If we make it easier to change the > tuning of the system for that scenario, then nobody's going to care > what our defaults are, or think us "slow" for them. >